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

[Emil Velikov]

On 26 August 2016 at 04:04, Kevin Brace  wrote:
> Hi Emil,
>
>> Hi Kevin,
>>
>> On 26 August 2016 at 01:19, Kevin Brace  wrote:
>>
>> > I do not want to be seen as stopping progress, but there are still people 
>> > who use less than current hardware (myself and countless others) or non 
>> > Big 3 x86 graphics (NVIDIA, AMD, and Intel) for things like thin clients.
>>
>> [snip]
>> > Anyway, regarding the move to DRI2 / KMS so that DRI1 can be discontinued, 
>> > I am not personally against it in the long run, but the work on it has 
>> > stalled.
>> >
>> Afaict nobody is discontinuing DRI1, but marking it as BROKEN. Why you
>> may ask - simply because there has been virtually zero development
>> effort (general refactoring do not count) and serious testing, for
>> those drivers over the last 5+ years.
>>
>
> If I am correct, OpenChrome DDX's Xv and XvMC still uses DRI1 if I am correct.
> That being said, I have not really touched that part of the code. (I have 
> been working on mainly fixing display detection and standby resume issues for 
> the past 6 months since I obtained commit privilege.)
>
Guess I should have put stronger emphasis on _serious testing_.

And yes, most people here are familiar with your work on the DDX side
and the previous one by James.

>
>> FWIW I would strongly recommend leaving UMS at peace and working
>> towards KMS. Having a hybrid UMS/KMS stack is possible, but it's far
>> too picky and time consuming even for larger teams.
>> On the forward porting efforts - DRM evolves rapidly so one could
>> consider starting from scratch. Wire up the (atomic?) mode setting
>> side first then think about the render side of things.
>>
>> Regards,
>> Emil
>>
>
> Here is the drm-openchrome's new DRM James Simmons (the previous OpenChrome 
> developer who did tremendous work between 2011 to early 2015, but has 
> completely disappeared) worked on.
>
> https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/via
>
> I do not mean to criticize you, but how easy is it to start from scratch when 
> there is that much code I will have to replace?
As suggested above - start small. Here is a more comprehensive list:
Stage 1:
KMS (display only) driver, without any custom ioctls/uapi that works
~ok with the modesetting ddx.
Only a single working output (type) is needed and the driver should be
ok to merge upstream.

 1 pick a trivial (ideally atomic) KMS driver as a base
 2 add the stubs, consider using CMA at first.
 3 pick a single display engines/resources (VGA, HDMI...) and wire it up.
 4 add hw module/engines only when needed by the above.
 5 make sure it's working OK(ish) with the modesetting ddx.

Stage 2(?)
As you can now drive an output you can continue with a) the other
output types b) look into PM or c) start on the render side of things.
If the last one - once the driver has achieved milestone push towards
upstream inclusion.

 1 Reconsider CMA vs other memory management, fb and other HW specifics
 2 Pick one usespace component - mesa/ddx.
 3 Design _new_ UAPI, get initial code (kernel and userspace), do very
rough benchmarking/perf analysis
 4 Get X, glxgears or XXX (sort of) working.

...
Profit ;-)

That's enough divergion from the original thread from me. If we have
anything else can we keep it separate ?

Sorry for hijacking the thread.
Emil

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

[Dave Airlie]

On 4 August 2016 at 18:06, 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 

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.

[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 

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

[Kevin Brace]

Hi Emil,

> Hi Kevin,
> 
> On 26 August 2016 at 01:19, Kevin Brace  wrote:
> 
> > I do not want to be seen as stopping progress, but there are still people 
> > who use less than current hardware (myself and countless others) or non Big 
> > 3 x86 graphics (NVIDIA, AMD, and Intel) for things like thin clients.
> 
> [snip]
> > Anyway, regarding the move to DRI2 / KMS so that DRI1 can be discontinued, 
> > I am not personally against it in the long run, but the work on it has 
> > stalled.
> >
> Afaict nobody is discontinuing DRI1, but marking it as BROKEN. Why you
> may ask - simply because there has been virtually zero development
> effort (general refactoring do not count) and serious testing, for
> those drivers over the last 5+ years.
> 

If I am correct, OpenChrome DDX's Xv and XvMC still uses DRI1 if I am correct.
That being said, I have not really touched that part of the code. (I have been 
working on mainly fixing display detection and standby resume issues for the 
past 6 months since I obtained commit privilege.)


> FWIW I would strongly recommend leaving UMS at peace and working
> towards KMS. Having a hybrid UMS/KMS stack is possible, but it's far
> too picky and time consuming even for larger teams.
> On the forward porting efforts - DRM evolves rapidly so one could
> consider starting from scratch. Wire up the (atomic?) mode setting
> side first then think about the render side of things.
> 
> Regards,
> Emil
> 

Here is the drm-openchrome's new DRM James Simmons (the previous OpenChrome 
developer who did tremendous work between 2011 to early 2015, but has 
completely disappeared) worked on.

https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/via

I do not mean to criticize you, but how easy is it to start from scratch when 
there is that much code I will have to replace?
Again, most of my work for the past 6 months have been focused on display 
detection, and to a lesser degree, standby resume fix. (i.e., ACPI S3 State 
resume)
I have tried to merge drm-openchrome's new DRM (the above link) with Linux 4.2 
kernel source code, but ran into many problems, so I have not tried this since 
then.
The problems I face in improving OpenChrome UMS code is pretty much related 
to properly detecting display resources. (i.e., analog VGA, DVI, FP, TV, etc.)
Prior to myself taking over the project, I did get some push back from one 
longtime maintainer (Anybody who follows the OpenChrome saga may know him, but 
I will not name him here. I do not mean to criticize him here.) who was against 
getting rid of this 300 line "known device table."
This "known device table" was a large inside the code database of various known 
VIA IGP hardware and their display device support. (i.e., FP, TV, etc.)
I am the person who managed to ignore him, and got rid of that awful table that 
did not really serve any good purpose.
He was against removing it, but I tried my best in not breaking the code as 
much as possible, so there weren't too many regressions when I removed this 
table. (He found one regression I caused with TV, but he did help me fix it 
eventually.)
So, OpenChrome really starts out from a very tough position since it was not 
maintained very well for the past 10 years, and just today (I wrote the code 
this early morning.), got support code for Silicon Image SiI 164 TMDS 
transmitter (DVI) working with one thin client user. (HP T5550 thin client)
My plan was to prove some of the display detection code in UMS since I have 
more control of the OS and hardware there, and once the code is proven, move it 
to the new KMS code.
Our code (I am really the only developer) does not have manual settings anymore 
(I removed most of them. A few irrelevant ones remain.), and does almost 
everything automatic detection.
I think that this experience will help develop the KMS portion of the DRM code 
faster when I decide to put more emphasis on the new DRM development at some 
point.

Regards,

Kevin Brace
OpenChrome Project Maintainer / Developer

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

[Emil Velikov]

Hi Kevin,

On 26 August 2016 at 01:19, Kevin Brace  wrote:

> I do not want to be seen as stopping progress, but there are still people who 
> use less than current hardware (myself and countless others) or non Big 3 x86 
> graphics (NVIDIA, AMD, and Intel) for things like thin clients.

[snip]
> Anyway, regarding the move to DRI2 / KMS so that DRI1 can be discontinued, I 
> am not personally against it in the long run, but the work on it has stalled.
>
Afaict nobody is discontinuing DRI1, but marking it as BROKEN. Why you
may ask - simply because there has been virtually zero development
effort (general refactoring do not count) and serious testing, for
those drivers over the last 5+ years.

FWIW I would strongly recommend leaving UMS at peace and working
towards KMS. Having a hybrid UMS/KMS stack is possible, but it's far
too picky and time consuming even for larger teams.
On the forward porting efforts - DRM evolves rapidly so one could
consider starting from scratch. Wire up the (atomic?) mode setting
side first then think about the render side of things.

Regards,
Emil

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

[Kevin Brace]

Hi David,

> 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 
> ---
>  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_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.
> +
. . .
> +endif # DRM_LEGACY
> -- 
> 2.9.2 

I am the sole developer of OpenChrome (VIA Technologies IGP), and I do still 
actively develop OpenChrome DDX every day.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome

I do not want to be seen as stopping progress, but there are still people who 
use less than current hardware (myself and countless others) or non Big 3 x86 
graphics (NVIDIA, AMD, and Intel) for things like thin clients.
In fact, I just got DVI via (no pun intended) Silicon Image SiI 164 TMDS 
transmitter working for one thin client user with VIA IGP. (HP T5550 thin 
client)

https://bugs.freedesktop.org/show_bug.cgi?id=95059#c22
https://bugs.freedesktop.org/attachment.cgi?id=126035

He uses ThinStation OS.

http://thinstation.github.io/thinstation/

Anyway, regarding the move to DRI2 / KMS so that DRI1 can be discontinued, I am 
not personally against it in the long run, but the work on it has stalled.

https://cgit.freedesktop.org/openchrome/drm-openchrome/

Personally, I have had issues compiling the drm-openchrome code (the newer VIA 
IGP DRM) with a newer Linux kernel. (tried 4.2 with little success)
If someone knowledgeable about porting the current drm-openchrome code to the 
latest Linux kernel can assist me in doing it, that will certainly be helpful.
One box I have (HP Pavilion a800n; AMD Athlon XP + VIA Technologies KM400A 
chipset) has Lubuntu 14.04 installed with drm-openchrome (Linux 3.19-rc6) 
compiled for it, but due to a bug I have not been able to track down yet (I do 
not know how to get the Linux kernel to preserve a kernel panic dump.), it will 
kernel panic if I try to boot Lubuntu with drm-openchrome.
Lubuntu itself will boot fine with the latest OpenChrome DDX as long as I am 
using the stock Linux 3.13 kernel provided by Lubuntu or drm-openchrome with 
ATI Technologies RAGE 128 Pro AGP.
I must note that this kernel panic appears to be specific to UniChrome IGP 
(this is the very early VIA IGP model), and I have personally seen 
drm-openchrome successfully boot Linux 3.19-rc6 with the newer UniChrome Pro 
and Chrome9 IGPs.
OpenChrome DDX itself is developed so that it can be DRI1 / DRI2 and UMS / 
KMS selectable.
With the current OpenChrome DDX, it will disable EXA and Xv acceleration.
At this point, this is a rather poor trade off for current VIA IGP users since 
2D acceleration will go off.
As for myself, I am spending pretty much all of my personal time in fixing the 
existing DRI1 / UMS OpenChrome DDX code, and do not have the time resources to 
work on porting OpenChrome to support DRI2 / KMS.
That being said, if someone can assist me in getting drm-openchrome code ported 
to the latest Linux kernel, then maybe I can start spending more time in 
getting EXA to work with DRI2, and when that is achieved, DRI1 can be retired 
for good.

Sincerely,

Kevin Brace
OpenChrome Project Maintainer / Developer

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

[Emil Velikov]

On 25 August 2016 at 12:14, Daniel Vetter  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 
>>
>> Acked-by: Chris Wilson 
>>
>> 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

[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 
> 
> Acked-by: Chris Wilson 
> 
> 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

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

[Connor Behan]

On 25/08/16 11:13 AM, Alex Deucher wrote:
> On Thu, Aug 25, 2016 at 11:04 AM, Emil Velikov
>  wrote:
>> On 25 August 2016 at 12:14, Daniel Vetter  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 
 Acked-by: Chris Wilson 

 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.


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 

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

[Alex Deucher]

On Thu, Aug 25, 2016 at 11:04 AM, Emil Velikov  
wrote:
> On 25 August 2016 at 12:14, Daniel Vetter  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 
>>>
>>> Acked-by: Chris Wilson 
>>>
>>> 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

[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 
---
 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

[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 

Acked-by: Chris Wilson 

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