[Openchrome-devel] Regarding the progress made on drm-openchrome

Kevin Brace kevinbrace at gmx.com
Mon Dec 5 04:40:26 UTC 2016

Hi everyone,

I made some progress in the development of drm-openchrome, so I will like to discuss the progress I have made.
I just committed a fix that will allow the FP (Flat Panel) to work solo.
Previously, FP will work only when analog VGA is used simultaneously.
In fact, I am writing this message from a computer running drm-openchrome OpenChrome DRM and OpenChrome DDX on Xubuntu 14.04.
Like OpenChrome DDX, I am primarily developing drm-openchrome on my VIA Technologies silicon (microprocessor + chipset) laptop. (Epic Learning 1314 laptop)
This laptop has a relatively tiny 40 GB SATA hard drive (a good condition hard driver salvaged from a e-waste site), and with drm-openchrome consuming about 10 GB when I compile the Linux kernel 3.19-rc6 along with 4 images of Ubuntu-based OSes for testing purposes, the hard drive is close to full at this point.
    Anyway, I have personally fixed two major bugs of drm-openchrome, but the code itself still contains number of substantial problems.
The biggest bug drm-openchrome still contains is the fact that when the screen resolution is changed, drm-openchrome will crash.
Since I fixed this kind of a bug with OpenChrome DDX Version 0.5 for the UMS (User Mode Setting) side of the code, I am not too surprised that drm-openchrome contains this bug on the KMS (Kernel Mode Setting) side of the code.
Personally, I am trying to avoid criticizing the previous developer who worked on drm-openchrome, but I see this as a recurring pattern that significantly slows down the further development of the code.
I just wished previous people tested basic rudimentary features like changing screen resolutions since this happens all the time, and this bug also made it harder to fix the FP solo display issue since I could not attach a second monitor (analog VGA in this case) after the computer has booted to diagnose what is going wrong since turning on the second monitor will also cause a crash of X.Org server.
For those who are wondering about the pace of the development, I inherited the project without obtaining too much help or tips in how to develop the code, and I am still trying to figure out the weird "quirks" of drm-openchrome like what I saw with the FP solo situation.
Like in a corporate environment, if the previous developers suddenly quit, the new people inheriting the project without the proper handover from the previous developers will likely struggle to figure out how to fix the existing problems even if their skill levels were high.
That is basically what I am going through right now.
I am sure the previous developer could have fixed the runtime screen resolution change crash far faster than I would have been able to.
    Regarding the major stability issues drm-openchrome still contains, these are the known issues I am aware of.

- Runtime screen resolution change will crash X.Org server
- The display will go blank when resuming from standby

Besides those major issues, 2D acceleration is still not working although I am fortunate to have a laptop (Epic Learning 1314 laptop with VN896 chipset) where the rendering performance is reasonably good, so drm-openchrome is definitely usable for development and general use purposes. 
Other than those issues, the following major features are missing from drm-openchrome

- Use of strapping resistors to aid display initialization
- Support for VIA Technologies VT1632(A) external TMDS transmitter for DVI support
- External TV encoder support
- DisplayPort support (VX900 chipset only)

    My medium term goal is to have "mostly" common display initialization code between OpenChrome DDX UMS code and drm-openchrome OpenChrome DRM.
I quote the word "mostly" because the code cannot simply be copied between the two, but the hardware register access procedure will become similar so that the two will have similar behavior.
There are some aspects of drm-openchrome OpenChrome DRM that is better than the existing OpenChrome DDX code like frame buffer size detection method, and good aspects of drm-openchrome OpenChrome DRM will be backported to OpenChrome DDX in the future.
    I will definitely need whoever that maintains Linux DRM to give me guidance in how to get OpenChrome DRM mainlined, but my attempt back in August 2016 got virtually ignored.
If someone can get their attention so that they can contact me to resolve mainlining issues, then that will be very helpful to this project, but in case I get ignored again, I will continue the development of OpenChrome DRM with the existing Linux kernel 3.19-rc6.


Kevin Brace
The OpenChrome Project Maintainer / Developer

More information about the Openchrome-devel mailing list