[RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

Kevin Brace kevinbrace at gmx.com
Mon May 28 01:28:33 UTC 2018


I work on developing OpenChrome graphics stack for VIA Technologies Chrome integrated graphics.
I am looking to get OpenChrome DRM pulled into the Linux kernel tree in the near future.
This is not a pull request.
The code not quite ready for that, but I will like to start orienting my development activities towards getting OpenChrome DRM mainlined in the next one or two Linux kernel development cycles since OpenChrome DRM has been living outside the mainline kernel tree for 7+ years (at least since Year 2011).
    If someone reading this post is not too familiar with OpenChrome graphics stack, I did a presentation during XDC2017 that discussed the history of OpenChrome Project and its future plans.


Since XDC2017, I have fixed many issues like standby resume and runtime screen resolution change crashes, and as a result, I am pretty confident now that OpenChrome DDX with OpenChrome DRM performing mode setting (KMS) is as reliable as OpenChrome DDX performing mode setting (UMS).
In the past week, I officially added two external DVI transmitters to the OpenChrome DRM (VIA Technologies VT1632(A) and Silicon Image SiI 164), and as a result, OpenChrome DRM KMS now has virtually identical display device support to the legacy OpenChrome DDX UMS.
This will allow a seamless transition from UMS to KMS.
    However, there are some areas of concern I have with OpenChrome DRM getting mainlined inside Linux kernel tree.
During XDC2017, I spoke with one or two developers that strongly urged me to convert to atomic mode setting from the Year 2008 vintage "legacy" KMS.
I declined this since I just got OpenChrome DRM ported to Linux 4.13 one week prior to XDC2017, but furthermore, I needed to stabilize the code itself since it was still pretty buggy compared to OpenChrome DDX UMS.
The reason OpenChrome DRM still uses "legacy" KMS despite its flaws is the fact that previous developer, James Simmons, started the development back in Year 2011 or so, and I have merely continued the development starting around Year mid-2016.
My personal wish is to get OpenChrome DRM "grandfathered" from the strong expectation of implementing universal plane and atomic mode setting since the code development started well before those two got incorporated into the DRM.
I can consider converting the code to support these two features down the road, but just for the initial mainlining, I will like to be exempted from it since it will likely delay the mainlining by 6 months or so.
    Other than the universal plane and atomic mode setting, I have several other concerns.

1) James left some unfinished acceleration related code inside OpenChrome DRM, but I do not plan to activate it for the initial mainlined version. Do I need to remove the code?
2) James appears to have implemented custom Libdrm ABI / API calls. I do not plan to activate it for the initial mainlined version. Do I need to remove the code?
3) Almost all the functions start with "via_" instead of "openchrome_" at this point. Do I need to convert them all to "'openchrome_'?"
4) Is the essentially deprecated VIA DRM going to be removed from the Linux kernel tree? VIA DRM is DRI1 based, and OpenChrome DRM supersedes VIA DRM for obvious reasons. Since OpenChrome DRM supersedes VIA DRM, I strongly support deleting VIA DRM from the Linux kernel tree.

Since the code size is quite substantial, I hope providing the cgit location for the code is adequate.
Here is the main code page.


At this time, the code development is being done on drm-next-4.18 branch.


Here is the latest drm-next-4.18 branch OpenChrome DRM source code.
This is where the code to review is located.


    The strong desire to get OpenChrome DRM mainlined is driven by the decisions major Linux distributions like Ubuntu and Fedora made in dropping OpenChrome DDX from their default installed graphics device driver list some years ago due to the lack of DRI2 and / or KMS support with OpenChrome.
This causes installation difficulties with non-technical computer users who wish to use VIA Technologies hardware with Linux, and I will like to resolve this situation by getting OpenChrome DRM mainlined and getting OpenChrome DDX back on their default installation list.


Kevin Brace
Brace Computer Laboratory blog

More information about the dri-devel mailing list