Arrived in Montréal this morning. I could not really fall asleep during the long cross continental flight, so I tried to stay awake by spending a few hours at a coffee shop (sorry for the cross border corporate imperialism) right across the hotel I will be staying at, and work on a few items. I pulled in drm-next-2019-09-27 version of upstream DRM code, and made a few code commits. After that, I checked into the hotel around 1 P.M., and slept for about 5 hours.
I am writing this blog post from XDC 2019 Welcome Party being held at Kampai Garden. Personally, I just showed up to pickup free food and beer, but the food they have served us has not been that great. The bar beer is okay. I am now onto my second glass of beer, and I am starting to get a little drunk. I am writing this while I drink my beer. I still need to do some slides preparation for tomorrow or Friday.
For those who have been following my open source graphics stack development effort, XDC 2019 (X.Org Developer’s Conference 2019) is coming up in several days. I am working hard (i.e., long hours) trying to get more of the OpenChrome DRM code working before the presentation, but I will have to reduce the hours in order to prepare presentation slides for 2 Lightning Talk sessions I will be speaking for.
Originally, the organizers were trying to combine the 2 presentations into one, but apparently have backed off trying to do so. The original rational was that 2 presentations are similar in nature, so I should be able to do it in one session, but I did not really like that since I can easily spend 5 minutes on OpenChrome Project itself.
Most of the talk during the update on OpenChrome Project will obviously be dedicated to the development status of OpenChrome DRM, but I will go over the status of OpenChrome DDX Version 0.7 code as well.
Regarding the second presentation (the vintage or “underserved” graphics hardware one), I will go over the personal origin of the word “underserved.” (It is not yet a dictionary term.) I will explain where I first heard the term, and explain why I felt that the use of this term with regards to older generation graphics hardware perfectly describes the situation.
I am not sure if my presentation will be on Wednesday (October 2nd) or Friday (October 4th), but regardless it will be in the later afternoon hours.
I resolved a few initial code issues, but the use of cursor plane freezes the system. The only good news here is that I do see a cursor on the screen. Apparently. the code is accessing the correct source address of the cursor pattern, and transferring it to the correct VRAM address reserved for a hardware cursor. Figuring out the correct way to do this was the biggest obstacle for implementing cursor plane code. I had to analyze DRM core code related to cursor callbacks to figure out what goes on inside the DRM core, and then use the knowledge gained from analyzing the code to write the cursor plane code.
The bug that is freezing the system currently appears to get triggered when a frame buffer is released. This appears to be a new bug introduced with the new TTM memory allocator I wrote fairly recently. As a result of having this bug, currently OpenChrome DRM will crash the system if one tries to change the screen resolution from a lower screen resolution to a higher screen resolution during runtime. I will now go figure out why this is happening.
In the previous post, I mentioned that I will go ahead and implement atomic mode setting for cursor plane. It now appears that I will need to implement atomic mode setting for primary plane (i.e., frame buffer) before this can work. I do not have the atomic mode setting code written for primary plane at this point, so I will have to postpone the work related to atomic mode setting for now.
Instead, I will convert the existing “legacy” KMS (Kernel Mode Setting) code to fully support universal plane. Going back in history (somewhere around 2014 to 2017), this is the orthodox way DRM developers converted their device drivers before supporting atomic mode setting. At least that’s how Intel handled it for i915 DRM back in 2014. For primary plane, this work has been completed a few months ago, but not for cursor plane. After analyzing how DRM core handles cursor plane for the last several days, I wrote the callbacks that handle cursor plane. At this point, the code is not working, but I hope to get the code working in the next few days.
Since XDC 2019 (X.Org Developer’s Conference 2019) is coming up in about 3 weeks, I am trying to make major progress in the development of OpenChrome DRM. Although code commit will likely done much later, I am getting ready to try atomic mode setting code for cursor plane. I still have to write the callback for atomic_disable, but hopefully this will be done in a day or two. As for primary plane (i.e., frame buffer), I have not converted the code to support atomic mode setting yet. It is still stuck with universal plane implementation. While the universal plane implementation is considered an upgrade over the “legacy” KMS (Kernel Mode Setting) implementation, as far as DRM maintainers are concerned, it is still a “legacy” implemention. The lack of support for atomic mode setting is pretty much the only technical reason why OpenChrome DRM is not in the mainline Linux kernel tree.
XDC 2019 (X.Org Developer’s Conference 2019) is coming up in less than a month. Although I originally requested 2 half time presentation slots to give updates on OpenChrome Project and my other “vintage” graphics revival project, it appeared that there were other more important presentations other developers wanted to give, so my proposal for 2 half time presentation slots were turned down. Considering the proposed topics other developers are going to discuss, I was not terribly surprised with the let down. Anyway, Lightning Talk session was still open, so I applied for 2 presentation slots, and both were proved. The only problem now is, the organizers want me to combine the 2 presentations slots into a single slot. Since one Lightning Talk slot goes for only 5 minutes, so I feel like this is pretty tough request coming from them.
The problem of developing OpenChrome DRM on HP 2133 mini-note is that the microprocessor it comes with (VIA Technologies C7-M) is simply too underpowered for compiling Linux kernel regularly. I eventually decided to set up a new system for running more Linux kernel compilation runs, and for this task, I had to use a microprocessor that is much faster than C7-M. About a year or so ago, I bought ASUS P5V800-MX mainboard off ebay for about $30 (shipping included), so I decided to pop in Intel Pentium D 2.8 GHz I happened to have, along with a junk Seagate 500 GB SATA hard drive. The junk Seagate 500 GB SATA hard drive contains about 1,900 bad sectors that needed zeroing the content out so that the bad sectors are replaced with spare sectors.
ASUS P5V800-MX mainboard contains VIA Technologies VT8251 southbridge. The interesting thing about VT8251 southbridge is that it actually supports AHCI for SATA devices. That being said, VT8251 southbridge was rarely adopted by mainboard vendors for some reason (cost?).
Anyway, I installed two images of Lubuntu 18.04 LTS, 32-bit and 64-bit, respectively. After setting up the OS, I compiled the Linux kernel from OpenChrome DRM repository. I have to admit that Linux kernel compilation run runs about 6 to 7 times faster than HP 2133 mini-note. I booted Lubuntu 18.04 LTS with OpenChrome DRM, but I discovered major issues with OpenChrome DRM code, especially on UniChrome Pro graphics. I will write more about this in another post.