linux-kernel - Re: [git pull] drm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <21d7e9970901091803o36f1f07dk6436d1fbe5b2d084@mail.gmail.com>
Date:	Sat, 10 Jan 2009 12:03:08 +1000
From:	"Dave Airlie" <airlied@...il.com>
To:	"Gabriel C" <nix.or.die@...glemail.com>
Cc:	"Dave Airlie" <airlied@...ux.ie>, torvalds@...ux-foundation.org,
	dri-devel@...ts.sf.net, linux-kernel@...r.kernel.org,
	"Jesse Barnes" <jbarnes@...tuousgeek.org>,
	"Eric Anholt" <eric@...olt.net>
Subject: Re: [git pull] drm

On Mon, Jan 5, 2009 at 5:19 AM, Gabriel C <nix.or.die@...glemail.com> wrote:
> Dave Airlie wrote:
>
> Hi Dave ,
>
> ...
>
>
>
>> Please pull the 'drm-next' branch from
>> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
>>
>> Major highlights:
>> Kernel Modesetting (KMS) core code (jbarnes you can go to drinking island
>> now)
>> Intel i915 support for kernel modesetting
>
>
> ....
>
>
>
>> commit 79e539453b34e35f39299a899d263b0a1f1670bd
>> Author: Jesse Barnes <jbarnes@...tuousgeek.org>
>> Date:   Fri Nov 7 14:24:08 2008 -0800
>>
>>     DRM: i915: add mode setting support
>>
>>     This commit adds i915 driver support for the DRM mode setting APIs.
>>     Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
>>     supported.  HDMI, DisplayPort and additional SDVO output support will
>>     follow.
>>
>>     Support for the mode setting code is controlled by the new 'modeset'
>>     module option.  A new config option, CONFIG_DRM_I915_KMS controls the
>>     default behavior, and whether a PCI ID list is built into the module for
>>     use by user level module utilities.
>>
>>     Note that if mode setting is enabled, user level drivers that access
>>     display registers directly or that don't use the kernel graphics memory
>>     manager will likely corrupt kernel graphics memory, disrupt output
>>     configuration (possibly leading to hangs and/or blank displays), and
>>     prevent panic/oops messages from appearing.  So use caution when
>>     enabling this code; be sure your user level code supports the new
>>     interfaces.
>>
>>     A new SysRq key, 'g', provides emergency support for switching back to
>>     the kernel's framebuffer console; which is useful for testing.
>>
>>     Co-authors: Dave Airlie <airlied@...ux.ie>, Hong Liu <hong.liu@...el.com>
>>
>>     Signed-off-by: Jesse Barnes <jbarnes@...tuousgeek.org>
>>     Signed-off-by: Eric Anholt <eric@...olt.net>
>>     Signed-off-by: Dave Airlie <airlied@...hat.com>
>>
>
>
> This commit added the following text to drivers/gpu/drm/Kconfig :
>
> config DRM_I915_KMS
>       bool "Enable modesetting on intel by default"
>       depends on DRM_I915
>       help
>       Choose this option if you want kernel modesetting enabled by default,
>       and you have a new enough userspace to support this. Running old
>       userspaces with this enabled will cause pain.  Note that this causes
>       the driver to bind to PCI devices, which precludes loading things
>       like intelfb.
>
>
> I don't think any 'normal' user has a clue what you guys meant by
> 'new and old userspace' . Could someone clarify 'what versions of probably Xorg and libs are
> needed to have that support and which are for sure broken or old' please ?
>
> Also while testing this with xorg-server 1.4* I found out the 'pain' means an broken X and a broken box since
> it broke the kernel as well and the only way to get the box to live again was an hard reset. Please clarify the 'pain' part too.

There is no new enough userspace yet, so I can't say what version will
have it, maybe I should mark enabled by default as experimental or
something.

If pain doesn't equate to doing something that will hurt, then I'm not
sure what will, it actually will work for some people, so I can't say
it will always be broken.

I'll see if Jesse can provide some nicer wordings...

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/