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

Re: [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 <dh.herrmann at 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_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
_______________________________________________
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]

Hi Kevin,

On 26 August 2016 at 01:19, Kevin Brace <kevinbrace@gmx.com> 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
_______________________________________________
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 Emil,

> Hi Kevin,
> 
> On 26 August 2016 at 01:19, Kevin Brace <kevinbrace@gmx.com> 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
_______________________________________________
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 26 August 2016 at 04:04, Kevin Brace <kevinbrace@gmx.com> wrote:
> Hi Emil,
>
>> Hi Kevin,
>>
>> On 26 August 2016 at 01:19, Kevin Brace <kevinbrace@gmx.com> 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
_______________________________________________
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

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

[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

[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

[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

[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

[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

[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