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.