Now that VIA Technologies VT1632(A) and Silicon Image SiI 164 DVI transmitters support were added to OpenChrome DRM, that concludes adding new device support to OpenChrome DRM for now. Since my XDC2017 presentation (presentation PDF is here), I have made major improvements in improving the stability of OpenChrome DRM in the areas of runtime screen resolution change, standby resume, and dual head display. Furthermore, I fixed many small bugs that affected specific devices like CLE266 chipset, KM400 chipset, K8M800 chipset, VX855 chipset, and Samsung NC20 netbook (The last one is untested for OpenChrome DRM. The testing was done on OpenChrome DDX UMS code.). At this point, the reliability of OpenChrome DRM KMS is comparable to the legacy OpenChrome DDX UMS, and the device support is about the same. The device support I am talking about here are VGA, DVI (except VX900 chipset integrated DVI / HDMI transmitter), and flat panel. That being said, there are small device support differences between the two.
- TV out is supported by OpenChrome DDX UMS (User Mode Setting) code, but it is really broken
- VX900 chipset integrated DVI / HDMI transmitter is supported by OpenChrome DRM KMS (Kernel Mode Setting) code, but it is somewhat broken
The TV out and VX900 chipset integrated DVI / HDMI transmitter code was entirely written by previous developers, so I am not really responsible for their code quality. Although some may not like it, I can possibly disable VX900 chipset integrated DVI / HDMI transmitter initially, and go fix it after the code is mainlined inside the Linux kernel tree. This affects those who might want to use Zotac VD01 HTPC box since it does not support VGA (it has HDMI and DisplayPort). I am planning to work on improving TV out support during the OpenChrome DDX Version 0.8 development cycle.
I have never done this, so I do not really know what to expect, but I will post an RFC (Request for Comment) over at dri-devel mailing list shortly about how to proceed for OpenChrome DRM. Since I have never done this, I may look foolish or ignorant about the procedures on how to get the code reviewed by much more experienced DRM maintainers, but I guess I need to go through this now rather than right at the last minute. I will likely have to defend the continued use of legacy (i.e., Year 2008 time frame) KMS interface, and the decision not to adopt universal planes and atomic mode setting at this point. If the DRM maintainer grants an exception to the continued use of legacy KMS interface, then I think OpenChrome DRM can be mainlined during Linux 4.19 or 4.20 development cycle. That will fulfill my prediction I made during XDC2017 presentation that I should be able to get OpenChrome DRM mainlined by 2H2018.
What is really motivating me to get OpenChrome DRM mainlined is the second class citizen treatment OpenChrome gets from Canonical and Fedora. OpenChrome DDX is no longer installed by default when performing a fresh install, and this causes various inconveniences to the average (non-computer technical) user. Ostensibly, this is due to DRI1 support, but it really appears to be the lack of KMS support that got Canonical and RedHat to drop the default install of OpenChrome DDX. I want things to be easier for the average user, hence, the need to get OpenChrome DDX back onto the list of default installed graphics device drivers.
To be honest, I know the window movement performance is pretty bad when OpenChrome DRM is in use since there is no acceleration activated at this point, but this will be worked on later after the code is mainlined. This was outlined during my XDC2017 presentation, and I am merely following what I predicted back then on how I will be proceeding forward. I guess I consider getting out of the second class citizenship status to be more important than the window movement performance. That’s the trade off I am making at this point.