It took me more than 15 months to fix this bug, but I finally accomplished it! I am happy to announce now that OpenChrome can now handle runtime screen resolution change when KMS (Kernel Mode Setting) is being utilized.

Previously, this only worked reliably when OpenChrome DDX was performing UMS (User Mode Setting), but due to many Linux distributions not automatically installing UMS only DDX when installing the OS, it has been a very high priority for the OpenChrome Project to get KMS working, so that OpenChrome does not get treated like a second class citizen in the Linux world.

Again, I will have to go into my usual “blaming the previous developer” commentary, but KMS runtime screen resolution change functionality was already broken when I inherited the project. In fact, UMS side was broken as well. I did fix the UMS runtime screen resolution change crash with OpenChrome DDX Version 0.5.

Anyway, for KMS, I always believed that there was something wrong with OpenChrome DRM itself, so until very recently, my focus was to find the bug inside OpenChrome DRM. Eventually, I had to conclude that there was nothing wrong with OpenChrome DRM, and started to suspect DDX was at fault. The first time I got this confirmation was on March 2nd, 2018, but due to the regression I caused with the FP, I had to make fixes to OpenChrome DRM code first before I can fully test the runtime screen resolution change functionality. OpenChrome DRM Version 3.0.78 fixes the FP detection regression I have observed, and without this fix, crashes involving the X Server still occurs. Now that OpenChrome DRM’s issue with FP is fixed, I updated OpenChrome DDX’s code. OpenChrome DDX Version 0.6.171 fixes this nasty bug.

I only tested the code fixes with HP 2133 mini-note on Xubuntu 16.04.4 LTS so far, but as far as runtime screen resolution change is concerned, KMS based one has about the same stability as the legacy UMS based one. Of course, standby resume was fixed in October 2017, so now, I finally have a stable desktop environment where basic functionality like runtime screen resolution change or standby resume no longer crashes the computer regularly.

What this means is that, OpenChrome DRM getting into the Linux kernel mainline tree by end of Year 2018 is a realistic possibility as long as the DRM maintainer will not mind accepting code that does not support universal plane and atomic mode setting. If those two have to be implemented, I think it can take another 6 months or so.

I also feel vindicated with my development approach of OpenChrome DRM. Back in September 2017 over at XDC2017, one senior developer who works at one tier-1 semiconductor company very strongly urged me to immediately convert the mode setting code to support atomic mode setting. If I were to describe what I mean by “strongly urged,” it was almost like a zeal of an evangelist in how this person wanted me to convert the code to support atomic mode setting. I politely turned this idea down for following reasons.

1. I only got OpenChrome DRM ported to Linux 4.13 for about a week prior to XDC2017
2. At the time, OpenChrome DRM did not contain the better FP mode setting code proven with DDX’s UMS code path (again mainly due to point 1)
3. Overall, OpenChrome DRM was at something of a “bring up” level state, therefore, I was not willing to go implement new functionality like atomic mode setting until things stabilized

The discussion about this issue continued over at the bar where the after party was being held (downtown Mountain View, California). As one can imagine, the senior developer who works at one tier-1 semiconductor company held on to the same view (immediately convert to atomic mode setting) and I was not willing to give in regarding this issue due to the above reasons. Another developer with a major Linux distribution company who works on the graphics stack joined the conversation, and it was essentially the senior developer who works at one tier-1 semiconductor company trying to double team me regarding the atomic mode setting issue. I had to rephrase the above point 2 by noting that OpenChrome DRM currently does not have the improved FP detection code that uses strapping resistors to detect the FP type, and I wanted to port that code first before venturing into the risky atomic mode setting code conversion. The reaction I got from this senior developer was a little surprising. “What is strapping resistors?” Since this senior developer worked at a tier-1 semiconductor company and worked on the Linux graphics stack, I assumed that someone like him at least has some rudimentary understanding of the underlying graphics hardware. I did explain to him how some graphics cards use a few resistors at a power on time to learn the basic configuration of the hardware. VIA Technologies Chrome IGP does this as well, and one of the reason why OpenChrome appears to handle standby resume a lot better than it did in the past is because I started to look at the strapping resistors to figure out the hardware configuration when performing the mode setting. This is why your display is working after standby resume with the fairly recent version of OpenChrome as opposed to older versions (Version 0.3.3 or older) I was not involved with. The other developer did not appear to know what strapping resistors are. I guess this is what happens when software only type people work on device drivers (Note: I come from hardware engineering background.).

I guess this sort of thing happens at large corporations where people only know their own section, and have to rely on others for portions they do not know. I just wished this person was willing to listen to my concerns about this risky and time consuming code conversion work I will have to perform with atomic mode setting support when I only had OpenChrome DRM running on Linux 4.13 for about a week. OpenChrome DRM at that time had “bring up” level code reliability, so I felt doing this kind of code change at that time was not prudent.

Since then, I fixed many issues within OpenChrome DRM, and finally yesterday, I figured out why runtime screen resolution change was crashing the X Server. Now, OpenChrome DRM based mode setting (KMS) appears to be as reliable as OpenChrome DDX’s more mature mode setting (UMS). Looking back, I largely followed what I said during the presentation about OpenChrome DRM, and I am glad the strategy worked.