For the past few weeks, I did not make any code commits. This is because I was really busy trying to fix OpenChrome DRM’s runtime screen resolution change X Server crash bug. After struggling with this issue for the past 2 to 3 weeks, I am now starting to realize OpenChrome DDX might appear to be triggering this X Server crash, and it may not necessarily be entirely OpenChrome DRM’s fault. I came to this conclusion after trying everything I can think of to fix OpenChrome DRM, and none of them worked.

I know it sounds really like a beginner’s issue, but I just discovered that some of OpenChrome DDX’s KMS (Kernel Mode Setting) code originally came from xf86-video-modesetting. I am now using xf86-video-modesetting’s mode setting code as an reference to fix OpenChrome DDX’s KMS code.

This will mean that I will not be releasing OpenChrome DDX Version 0.7 for several more months. It will miss going into Ubuntu 18.04’s repository, but since Ubuntu is already a quasi-rolling release Linux distribution anyway as long as HWE (Hardware Enablement) upgrade is activated, I do not think this is a huge issue anymore.

Since XDC2017 where I presented about the state of OpenChrome Project, I have made big strides towards getting OpenChrome DRM mainlined within the Linux kernel. I will go over the progress I have made since then, in addition to discussing the remaining issues that need to be resolved.

The biggest I have been able to resolve is standby resume support. This was the original reason why I started to work on OpenChrome DDX back in Year 2015. One thing I have noticed about sub-par Linux / BSD graphics device drivers, in general, is the lack of standby resume support. After spending so much time on this issue, I was able to figure out why it was not working, and was able to fix it.

There were several reasons why standby resume was not working. The biggest reason why it was not working was due to DRM not asking for a mode setting after resuming from standby. Basically, the previous developer who worked on OpenChrome DRM did not put the necessary code for a mode setting to get retriggered after standby resume. I finally put in the code to do this after analyzing Radeon DRM’s standby resume code.

Another related issue I observed after I got standby resume working on most models was with setting display FIFO. Again, the previous developer who worked on OpenChrome DRM did not put in the code to do this for CLE266 and KM400 chipsets. This is related to the fact that OpenChrome DRM did not originally contain PLL settings code for CLE266 and KM400 chipsets back in September 2016. Both of these chipsets have UniChrome (not UniChrome Pro) IGP. Due to the necessity to support rather bandwidth limited DDR200 (PC1600) DDR SDRAM, they do require fairly complicated display FIFO settings code. I did not have the actual hardware with me for several weeks, so I did not catch the regression prior to the code commit, but as of OpenChrome DRM Version 3.0.71, the issues are resolved.

Also, due to lacking access to K8M800 chipset based hardware, I caused similar display FIFO issues (i.e., wrong IGA1 display FIFO parameters), but this was fixed as of OpenChrome DRM Version 3.0.75 since I regained access to the actual hardware for testing.

Today, standby resume is working with VGA (analog) and most FPs (Flat Panel); starting with CLE266 chipset and all the way to VX900 chipset. Yes, there are some hardware out there where the standby resume is not working, but this appears to be issues unrelated to OpenChrome DRM. If I were to cite one example, I will say Averatec 3250 laptop (KN400 chipset). Regarding this troubled laptop, it also has issues with OpenChrome DDX’s mode setting code when it comes to standby resume.

Regarding the outstanding issues, I still have issues with runtime change of screen resolution. Changing the screen resolution during runtime I will talk about this in the next post, but this is the biggest outstanding issue OpenChrome has. OpenChrome DRM still lacks external DVI (TMDS) transmitter support, but this will get worked on probably in the next few months. There are still issues with FP recognition some times, and I am aware of the issue, but it will not get worked on until I fix the runtime change of screen resolution issue.

One white elephant I have not talked about is the rendering performance of OpenChrome DDX along with OpenChrome DRM. It appears to vary by the chipset, but in general, the current OpenChrome DDX along with OpenChrome DRM is way below of that of existing OpenChrome DDX running DRM free or with DRI1 based VIA DRM (only older UniChrome and UniChrome Pro devices are supported). For my main development computer (HP 2133 mini-note; VN896 chipset), the rendering performance is at an acceptable level for the OpenChrome DDX along with OpenChrome DRM, but I have noticed severe performance issues with CLE266 and VX900 chipsets. Note that this is particularly noticeable when moving a window around on the desktop screen (it is painfully slow . . .). The reason for this is really simple; OpenChrome DDX along with OpenChrome DRM does not utilize 2D acceleration hardware currently. I expect to fix this issue after OpenChrome DRM is mainlined. The previous developer appeared to be working on some code for 2D acceleration, but for the purpose of mainlining, I expect to remove the 2D acceleration support code for now (obviously, it will come back eventually).

That’s it for now.

OpenChrome DRM drm-next-4.16 branch is now EOL (End of Life). Due to the time it took to handle Spectre and Meltdown mitigation, the DRM maintainer got additional code that would have gone into Linux 4.17 pulled in, in addition to the Linux 4.16’s DRM pull. What this means is that by the time of drm-next-4.16 branch, OpenChrome DRM has caught up with the bleeding edge of drm-next branch of DRM. OpenChrome DRM drm-next-4.17 branch will stay on Linux 4.15 rc8+ kernel for a while, but will migrate to Linux 4.16 kernel in a month or so when drm-next branch of DRM migrates to something like Linux 4.16 rc4 or rc5.

As promised, I committed the hardware cursor fix for single HI (Hardware Icon) devices like K8M890 chipset. This also marks the first occasion in several months where drm-next-4.xx branch has newer code than drm-next-3.19 branch.

Even though it is only February, outside is early summer like temperature here in San Jose, California today. I better go outside now to enjoy the early summer like weather before sunset.

As discussed recently, drm-next-4.15 branch is now EOL (End of Life). The bleeding edge development has moved onto drm-next-4.16 branch.

I usually commit the code with a patchlevel update (those ubiquitous “Version bumped to . . .” commit titles), but since pulling the code from drm-next branch of Linux DRM maintainer repository, the OpenChrome DRM code will no longer compile against Linux 4.15 rc8+ kernel. Anyway, I uploaded three commits that fixes the compilation issue. If you wanted to, OpenChrome DRM will now compile against Linux 4.15 rc8+ kernel. More commits to catch up to drm-next-3.19 branch will likely be available tomorrow.

Finished compiling Linux 4.15 rc8+ kernel, and OpenChrome DRM is working fine. I will have to break the changes I made to the code into several commits, mostly dealing with TTM. It might take a few hours to a day or two for this to happen.

For the past few days, I was attending an electronics hardware trade show called DesignCon 2018 held at Santa Clara Convention Center. During that period, I brought my small OpenChrome development computer, HP 2133 mini-note, and continued to work on solving various serious blocker bugs that still exist within OpenChrome DRM in between sessions over at the Hyatt Regency next door.

Most of OpenChrome DRM code appears to have originated from xf86-video-via DDX released around Year 2011 to 2012 and possibly the ill fated VIA Technologies Chrome9 DRM that never got mainlined within the Linux kernel tree around Year 2009 to 2010. Then, a developer named James Simmons further developed OpenChrome DRM up to early Year 2015.

The biggest blocker bug that currently exists within OpenChrome DRM is a nasty bug that crashes the X.Org X Server when changing the screen resolution during runtime. Interestingly, OpenChrome DDX between Version 0.3.3 and 0.4 had the same type of a bug within the UMS (User Mode Setting) code that also crashed the X Server. I was finally able to fix this bug with OpenChrome DDX Version 0.5.

Although I should probably not criticize past developers of OpenChrome, it appears James did not really care about this vital functionality, and other maintainers failed to notice the regression (Note: this functionality worked between Version 0.3.0 to Version 0.3.2). It is funny (actually, it is not) that the same bug strikes again, but this time, it is with OpenChrome DRM.

As a self described newbie to mid-level developer (my own opinion), I must note that it is a pretty hard way to start Linux graphics device driver development with a DRM written by someone else that happened to be incomplete. Fortunately for me, I was able to start this with OpenChrome DDX, which was far easier to get the development going than to start with any DRM (i.e., it is far harder to set up and compile DRM than DDX).

It is my opinion that it is pretty hard to attract newbie developers into Linux / BSD graphics stack development due to various initial set up hurdles that discourage most people from continuing for more than a few days to weeks (I have seen this even with OpenChrome Project. There are definitely a few people who showed interest in developing OpenChrome, but disappeared soon after.).

Going back to OpenChrome DRM, again as a self described newbie to mid-level developer, it is pretty hard to fix other developer’s bug, particularly ones related to GEM (Graphics Execution Manager) and TTM (Translation Table Maps). After studying Radeon DRM for 3 days straight during my free time, I have come to the conclusion of writing my own memory allocation modules that use GEM / TTM.

After months or trying to understand why OpenChrome DRM crashes when the screen resolution is changed during runtime, I think the reason for this bug is due to memory management related issues, particularly with releasing allocated frame buffer memory. One way or another, I have spent a lot of time trying to understand what James Simmons written memory allocation code is doing, but I no longer want to waste my time fixing the bugs he has left behind.

Another motivation of why I will like to write my own memory allocation code, is due to my interest in developing other forgotten graphics devices from late 1990s to early 2000s (i.e., AGP generation graphics devices). I have described my interest in this area during my XDC2017 presentation. What I will like to do is to prove that the new memory allocation code works with OpenChrome DRM and then port it (i.e., code reuse) to DRMs for these devices.

I probably should have waited until I finished upgrading OpenChrome DRM code meant for Linux 4.14 rc7+ to be compilable with Linux 4.15 rc8+, but nonetheless, I pulled in Linux 4.15 rc8+, and committed it into the drm-next-4.15 branch of OpenChrome DRM upstream repository. As a result, drm-next-4.15 branch does not currently compile due to small changes made again to TTM related modules. It took me (mere) 4 hours to figure out the changes, and as I write this blog post, I am compiling Linux 4.15 rc8+ kernel in the background. I need to validate basic functionality after the new kernel port, so it might take me a day or two before I can commit the changes made to the code.

The good news here is that OpenChrome DRM is catching up to the bleeding edge of Linux kernel / DRM (Direct Rendering Manager) development. OpenChrome DRM is still a little off when it comes to using the correct version of Linux kernel for the given drm-next-x.xx branch (i.e., as of today, OpenChrome DRM’s drm-next-4.15 branch should really be called drm-next-4.17), but I should be able to remedy this in the next weeks. Anyway, I expect to move to drm-next-4.16 branch soon, and then in a few weeks, move again to drm-next-4.17 branch. Fairly soon, drm-next-4.16 or drm-next-4.17 branch will be at the same OpenChrome DRM version as the drm-next-3.19 branch (Version 3.0.71).