Delaying OpenChrome DDX Version 0.7 release indefinitely

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.

Status of OpenChrome DRM (February 2018)

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

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.

Committed OpenChrome DRM hardware cursor fix for single HI (Hardware Icon) devices

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.

Quick fix for OpenChrome DRM drm-next-4.15 branch committed

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.