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.