[PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY

[PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY

[David Herrmann]

Lets move forward and hide the remaining DRI1 drivers behind a config
option, so we have a central place to disable them all. Furthermore, we
can provide a clear warning to anyone enabling them.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
 drivers/gpu/drm/Kconfig | 135 ++++++++++++++++++++++++++++--------------------
 1 file changed, 78 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index fc35731..d8f6203 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -108,24 +108,8 @@ config DRM_KMS_CMA_HELPER
 
 source "drivers/gpu/drm/i2c/Kconfig"
 
-config DRM_TDFX
-	tristate "3dfx Banshee/Voodoo3+"
-	depends on DRM && PCI
-	help
-	  Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
-	  graphics card.  If M is selected, the module will be called tdfx.
-
 source "drivers/gpu/drm/arm/Kconfig"
 
-config DRM_R128
-	tristate "ATI Rage 128"
-	depends on DRM && PCI
-	select FW_LOADER
-	help
-	  Choose this option if you have an ATI Rage 128 graphics card.  If M
-	  is selected, the module will be called r128.  AGP support for
-	  this card is strongly suggested (unless you have a PCI version).
-
 config DRM_RADEON
 	tristate "ATI Radeon"
 	depends on DRM && PCI
@@ -177,49 +161,8 @@ source "drivers/gpu/drm/amd/acp/Kconfig"
 
 source "drivers/gpu/drm/nouveau/Kconfig"
 
-config DRM_I810
-	tristate "Intel I810"
-	# !PREEMPT because of missing ioctl locking
-	depends on DRM && AGP && AGP_INTEL && (!PREEMPT || BROKEN)
-	help
-	  Choose this option if you have an Intel I810 graphics card.  If M is
-	  selected, the module will be called i810.  AGP support is required
-	  for this driver to work.
-
 source "drivers/gpu/drm/i915/Kconfig"
 
-config DRM_MGA
-	tristate "Matrox g200/g400"
-	depends on DRM && PCI
-	select FW_LOADER
-	help
-	  Choose this option if you have a Matrox G200, G400 or G450 graphics
-	  card.  If M is selected, the module will be called mga.  AGP
-	  support is required for this driver to work.
-
-config DRM_SIS
-	tristate "SiS video cards"
-	depends on DRM && AGP
-	depends on FB_SIS || FB_SIS=n
-	help
-	  Choose this option if you have a SiS 630 or compatible video
-          chipset. If M is selected the module will be called sis. AGP
-          support is required for this driver to work.
-
-config DRM_VIA
-	tristate "Via unichrome video cards"
-	depends on DRM && PCI
-	help
-	  Choose this option if you have a Via unichrome or compatible video
-	  chipset. If M is selected the module will be called via.
-
-config DRM_SAVAGE
-	tristate "Savage video cards"
-	depends on DRM && PCI
-	help
-	  Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
-	  chipset. If M is selected the module will be called savage.
-
 config DRM_VGEM
 	tristate "Virtual GEM provider"
 	depends on DRM
@@ -290,3 +233,81 @@ source "drivers/gpu/drm/arc/Kconfig"
 source "drivers/gpu/drm/hisilicon/Kconfig"
 
 source "drivers/gpu/drm/mediatek/Kconfig"
+
+# Keep legacy drivers last
+
+menuconfig DRM_LEGACY
+	bool "Enable legacy drivers (DANGEROUS)"
+	depends on DRM
+	help
+	  Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
+	  APIs to user-space, which can be used to circumvent access
+	  restrictions and other security measures. For backwards compatibility
+	  those drivers are still available, but their use is highly
+	  inadvisable and might harm your system.
+
+	  You are recommended to use the safe modeset-only drivers instead, and
+	  perform 3D emulation in user-space.
+
+	  Unless you have strong reasons to go rogue, say "N".
+
+if DRM_LEGACY
+
+config DRM_TDFX
+	tristate "3dfx Banshee/Voodoo3+"
+	depends on DRM && PCI
+	help
+	  Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
+	  graphics card.  If M is selected, the module will be called tdfx.
+
+config DRM_R128
+	tristate "ATI Rage 128"
+	depends on DRM && PCI
+	select FW_LOADER
+	help
+	  Choose this option if you have an ATI Rage 128 graphics card.  If M
+	  is selected, the module will be called r128.  AGP support for
+	  this card is strongly suggested (unless you have a PCI version).
+
+config DRM_I810
+	tristate "Intel I810"
+	# !PREEMPT because of missing ioctl locking
+	depends on DRM && AGP && AGP_INTEL && (!PREEMPT || BROKEN)
+	help
+	  Choose this option if you have an Intel I810 graphics card.  If M is
+	  selected, the module will be called i810.  AGP support is required
+	  for this driver to work.
+
+config DRM_MGA
+	tristate "Matrox g200/g400"
+	depends on DRM && PCI
+	select FW_LOADER
+	help
+	  Choose this option if you have a Matrox G200, G400 or G450 graphics
+	  card.  If M is selected, the module will be called mga.  AGP
+	  support is required for this driver to work.
+
+config DRM_SIS
+	tristate "SiS video cards"
+	depends on DRM && AGP
+	depends on FB_SIS || FB_SIS=n
+	help
+	  Choose this option if you have a SiS 630 or compatible video
+	  chipset. If M is selected the module will be called sis. AGP
+	  support is required for this driver to work.
+
+config DRM_VIA
+	tristate "Via unichrome video cards"
+	depends on DRM && PCI
+	help
+	  Choose this option if you have a Via unichrome or compatible video
+	  chipset. If M is selected the module will be called via.
+
+config DRM_SAVAGE
+	tristate "Savage video cards"
+	depends on DRM && PCI
+	help
+	  Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
+	  chipset. If M is selected the module will be called savage.
+
+endif # DRM_LEGACY
-- 
2.9.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[David Herrmann]

The legacy DRI1 drivers expose highly broken interfaces to user-space. No
modern system should enable them, or you will effectively allow user-space
to circumvent most of your kernel security measures. The DRI1 kernel APIs
are simply broken.

User-space can always use vesafb/efifb/simplefb and friends to get working
graphics.

Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
be still used (really?), we can easily revert this and figure out a way to
move them out of sight (e.g., moving all DRI1 drivers to
drivers/gpu/dri1/).

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
 drivers/gpu/drm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d8f6203..48d9223 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -239,6 +239,7 @@ source "drivers/gpu/drm/mediatek/Kconfig"
 menuconfig DRM_LEGACY
 	bool "Enable legacy drivers (DANGEROUS)"
 	depends on DRM
+	depends on BROKEN
 	help
 	  Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
 	  APIs to user-space, which can be used to circumvent access
-- 
2.9.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: hide legacy drivers with CONFIG_DRM_LEGACY

[Chris Wilson]

On Thu, Aug 04, 2016 at 10:06:56AM +0200, David Herrmann wrote:
> Lets move forward and hide the remaining DRI1 drivers behind a config
> option, so we have a central place to disable them all. Furthermore, we
> can provide a clear warning to anyone enabling them.
> 
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

Very neatly done.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[Chris Wilson]

On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote:
> The legacy DRI1 drivers expose highly broken interfaces to user-space. No
> modern system should enable them, or you will effectively allow user-space
> to circumvent most of your kernel security measures. The DRI1 kernel APIs
> are simply broken.
> 
> User-space can always use vesafb/efifb/simplefb and friends to get working
> graphics.
> 
> Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
> be still used (really?), we can easily revert this and figure out a way to
> move them out of sight (e.g., moving all DRI1 drivers to
> drivers/gpu/dri1/).
> 
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>

I'd rather have a couple of distro devs check if they are still using
any of these, and would value their a-b/r-b.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[Daniel Vetter]

On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote:
> > The legacy DRI1 drivers expose highly broken interfaces to user-space. No
> > modern system should enable them, or you will effectively allow user-space
> > to circumvent most of your kernel security measures. The DRI1 kernel APIs
> > are simply broken.
> > 
> > User-space can always use vesafb/efifb/simplefb and friends to get working
> > graphics.
> > 
> > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
> > be still used (really?), we can easily revert this and figure out a way to
> > move them out of sight (e.g., moving all DRI1 drivers to
> > drivers/gpu/dri1/).
> > 
> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> 
> Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> I'd rather have a couple of distro devs check if they are still using
> any of these, and would value their a-b/r-b.

Mesa stopped shipping dri1 drivers years ago, and neither Fedora and
Debian here have that old version packaged (it should keep working since
the dri loader is an ABI). I don't think anyone needs this, and if I'm
wrong we'll hear about it ;-)

Both applied to drm-misc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[Emil Velikov]

On 25 August 2016 at 12:14, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote:
>> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote:
>> > The legacy DRI1 drivers expose highly broken interfaces to user-space. No
>> > modern system should enable them, or you will effectively allow user-space
>> > to circumvent most of your kernel security measures. The DRI1 kernel APIs
>> > are simply broken.
>> >
>> > User-space can always use vesafb/efifb/simplefb and friends to get working
>> > graphics.
>> >
>> > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
>> > be still used (really?), we can easily revert this and figure out a way to
>> > move them out of sight (e.g., moving all DRI1 drivers to
>> > drivers/gpu/dri1/).
>> >
>> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>>
>> Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
>>
>> I'd rather have a couple of distro devs check if they are still using
>> any of these, and would value their a-b/r-b.
>
> Mesa stopped shipping dri1 drivers years ago, and neither Fedora and
> Debian here have that old version packaged (it should keep working since
> the dri loader is an ABI). I don't think anyone needs this, and if I'm
> wrong we'll hear about it ;-)
>
Archlinux (which seems to be picking more users) is still shipping
dri1 drivers - both mesa and X. No idea for many actually use those
and/or for how much longer the packages will be around.

IIRC the maintainer, Connor, used to hack on the xf86-video-r128 with
plans(?) on getting things KMS aware. Not sure if that was by
extending the existing radeon kernel, ddx, mesa driver(s) or
otherwise.
Connor, can you shed some light ?

-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[Alex Deucher]

On Thu, Aug 25, 2016 at 11:04 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> On 25 August 2016 at 12:14, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote:
>>> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote:
>>> > The legacy DRI1 drivers expose highly broken interfaces to user-space. No
>>> > modern system should enable them, or you will effectively allow user-space
>>> > to circumvent most of your kernel security measures. The DRI1 kernel APIs
>>> > are simply broken.
>>> >
>>> > User-space can always use vesafb/efifb/simplefb and friends to get working
>>> > graphics.
>>> >
>>> > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
>>> > be still used (really?), we can easily revert this and figure out a way to
>>> > move them out of sight (e.g., moving all DRI1 drivers to
>>> > drivers/gpu/dri1/).
>>> >
>>> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>>>
>>> Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>
>>> I'd rather have a couple of distro devs check if they are still using
>>> any of these, and would value their a-b/r-b.
>>
>> Mesa stopped shipping dri1 drivers years ago, and neither Fedora and
>> Debian here have that old version packaged (it should keep working since
>> the dri loader is an ABI). I don't think anyone needs this, and if I'm
>> wrong we'll hear about it ;-)
>>
> Archlinux (which seems to be picking more users) is still shipping
> dri1 drivers - both mesa and X. No idea for many actually use those
> and/or for how much longer the packages will be around.
>
> IIRC the maintainer, Connor, used to hack on the xf86-video-r128 with
> plans(?) on getting things KMS aware. Not sure if that was by
> extending the existing radeon kernel, ddx, mesa driver(s) or
> otherwise.
> Connor, can you shed some light ?
>

r128 is 90% the same as early radeons so it would make sense to add
support to radeon.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[Connor Behan]

[-- Attachment #1.1.1: Type: text/plain, Size: 3020 bytes --]

On 25/08/16 11:13 AM, Alex Deucher wrote:
> On Thu, Aug 25, 2016 at 11:04 AM, Emil Velikov
> <emil.l.velikov@gmail.com> wrote:
>> On 25 August 2016 at 12:14, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote:
>>>> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote:
>>>>> The legacy DRI1 drivers expose highly broken interfaces to user-space. No
>>>>> modern system should enable them, or you will effectively allow user-space
>>>>> to circumvent most of your kernel security measures. The DRI1 kernel APIs
>>>>> are simply broken.
>>>>>
>>>>> User-space can always use vesafb/efifb/simplefb and friends to get working
>>>>> graphics.
>>>>>
>>>>> Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
>>>>> be still used (really?), we can easily revert this and figure out a way to
>>>>> move them out of sight (e.g., moving all DRI1 drivers to
>>>>> drivers/gpu/dri1/).
>>>>>
>>>>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>>>> Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>>
>>>> I'd rather have a couple of distro devs check if they are still using
>>>> any of these, and would value their a-b/r-b.
>>> Mesa stopped shipping dri1 drivers years ago, and neither Fedora and
>>> Debian here have that old version packaged (it should keep working since
>>> the dri loader is an ABI). I don't think anyone needs this, and if I'm
>>> wrong we'll hear about it ;-)
>>>
>> Archlinux (which seems to be picking more users) is still shipping
>> dri1 drivers - both mesa and X. No idea for many actually use those
>> and/or for how much longer the packages will be around.
>>
>> IIRC the maintainer, Connor, used to hack on the xf86-video-r128 with
>> plans(?) on getting things KMS aware. Not sure if that was by
>> extending the existing radeon kernel, ddx, mesa driver(s) or
>> otherwise.
>> Connor, can you shed some light ?
>>
> r128 is 90% the same as early radeons so it would make sense to add
> support to radeon.
>
> Alex

Ccing Kevin Brace.

The drivers were removed from mesa and "you won't have to freeze your
kernel or anything" was one of the justifications given at the time for
why this wasn't a bad idea. So yes, I have dri1 packages in the
Archlinux repos with no plans to drop them. The people who have emailed
me about them and filed bugs are probably much less than 1% of the user
base but I've never considered that relevant. The point is that
hobbyists who want to use old hardware or play with seldomly updated
drivers should be able to do this without too many additional hurdles.

AFAIK the drivers still work as well as they did in the late 90s. And
it's easy for security conscious people to not modprobe them. My -1
would probably mean more if I were still following my initial plans of
adding r128 support to the radeon kernel module but at some point while
reading documentation I lost motivation. Hopefully this is temporary.



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[Dave Airlie]

On 4 August 2016 at 18:06, David Herrmann <dh.herrmann@gmail.com> wrote:
> The legacy DRI1 drivers expose highly broken interfaces to user-space. No
> modern system should enable them, or you will effectively allow user-space
> to circumvent most of your kernel security measures. The DRI1 kernel APIs
> are simply broken.
>
> User-space can always use vesafb/efifb/simplefb and friends to get working
> graphics.
>
> Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
> be still used (really?), we can easily revert this and figure out a way to
> move them out of sight (e.g., moving all DRI1 drivers to
> drivers/gpu/dri1/).
>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

So my opinion is that no modern system enables them in practice.

You can only load dri1 drivers on dri1 hardware, so you aren't exactly leaving
yourself open to root holes here. If you mean the fact that we keep leaving the
ioctls answering when dri2 drivers are loaded due to errors, then I hope we've
figured all those out by now.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[Kevin Brace]

Hi Connor,

> > r128 is 90% the same as early radeons so it would make sense to add
> > support to radeon.
> >
> > Alex
> 
> Ccing Kevin Brace.
> 
> The drivers were removed from mesa and "you won't have to freeze your
> kernel or anything" was one of the justifications given at the time for
> why this wasn't a bad idea. So yes, I have dri1 packages in the
> Archlinux repos with no plans to drop them. The people who have emailed
> me about them and filed bugs are probably much less than 1% of the user
> base but I've never considered that relevant. The point is that
> hobbyists who want to use old hardware or play with seldomly updated
> drivers should be able to do this without too many additional hurdles.
> 
> AFAIK the drivers still work as well as they did in the late 90s. And
> it's easy for security conscious people to not modprobe them. My -1
> would probably mean more if I were still following my initial plans of
> adding r128 support to the radeon kernel module but at some point while
> reading documentation I lost motivation. Hopefully this is temporary.
> 
> 
> 

I should not make any mockery of people's sincere beliefs, but at this point as a non-corporate graphics stack developer (of course, I have worked only on DDX so far), I am starting to see the perspectives of those who are anti-consumerism a little bit.
Every year around Black Friday (For those who are not too familiar with US customs and holidays, Thanksgiving is one of the major holiday here, but more importantly for retailers and computer hardware corporations, Black Friday is really the biggest event of the year where silicon-based products assembled in China as circuit boards moves in huge numbers, hence, they get to keep engineers, marketers, and CEOs employed.) there are people who preach anti-consumerism against the huge Black Friday tide.
Of course, based on what I see around the parking lot of Fry's Electronics (a major US based electronics retailer HQed here in San Jose, CA, USA) on Black Friday, I do not think they are winning the conversion war (I am not religious, but it is sort of a pseudo-religion, similar to "some" evangelical Protestant Christians or Mormons who do street evangelism from time to time, but do not appear to convert too many people.), but sometimes when I see the still usable computer hardware being tossed out at the so called "e-waste" site, I always wonder if there is a good way to give second or even third life to the soon to be crushed computer hardware still fairly useful for ordinary (i.e., non-gamer) use.
Anyway, I started collecting probably too much abandoned computer hardware, and I have to joking call it "I built a computer parts empire" where I live since I own so much computer equipment, probably more than I really need.
I will like to give second and third life to the hardware I have collected over the past 6 years, and ultimately, this is how I ended up working on OpenChrome as a result.
    Since I am starting to show sympathy towards anti-consumerism people and views (I am still not totally sold on it, but starting to understand where they are coming from.) I sort of have to wonder about the motivations of many of the corporate "paid" OSS developers, especially the device driver developer types.
I know security issues do matter, but in some ways, rapid obsolescence thing I am sure comes into play.
Corporations like Intel and AMD (and many others involved in OSS) have to keep selling silicon based products to keep their engineers (and marketers and CEOs) employed, and it is not too nice financially to them if people keep clinging onto their dated hardware (like clinging onto a gun and religion as one politician once said privately, but it was supposedly a taboo subject in portions of the country, hence, it became a big story prior to an election) due to some guy like myself or Connor Behan continues to somehow churn out code that makes the dated hardware a little more useful.
    As a developer of OpenChrome, I am getting into this ad hoc alliance of convenience (That's the way I see it. I hope Connor gets my humor.) with Connor Behan of xf86-video-r128.
In fact, it was Connor that CCed me the reply he sent to this mailing list, and this is why I am even writing this post.
Like Connor, I will not want to see VIA DRI1 module removed from the Linux kernel for now, but since this is a mere ad hoc alliance of convenience, I am okay with dropping or demoting DRI1 support as long as some other more experienced OSS developers can assist in developing drm-openchrome and EXA acceleration support for DRI2 inside OpenChrome DDX since a lot of the drm-openchrome has been written already.
I probably already offended too many people in this post (i.e., anti-consumerism people, religious people, gun owners, people who were offended by the "guns and religon" comment, engineers who work at silicon vendors like Intel, AMD, etc, and maybe even Connor Behan.), I will keep it there.
But I am sure some people enjoyed my essay here.

Regards,

Kevin Brace 

P.S. I will not be surprised if I am blacklisted at various silicon vendors for showing sympathy towards anti-consumerism.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel