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