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.
On Thursday, I received the ADATA Ultimate SU800 SSD replacements in the mailbox. ADATA gave me brand new units, and neither units have markings indicating that they were “refurbished” (hard drive manufacturers usually ship back a “refurbished” unit marked on the unit label). Since I purchased earlier lot of Ultimate SU800 in late 2016, the box and unit label designs have changed with the newer lot. There is a little bit of cost cutting going on like the summary of warranty information written on the back of the Box or not coming with a plastic spacer, but these are not that important to me.
I have not played around with the unit’s yet, but I must say that ADATA honored the warranty without any issues despite the fact that one of the unit’s (256 GB model) “warranty avoid if removed” sticker was damaged by the previous owner. All I can say is that I am happy with ADATA regarding their RMA handling.
I discussed my troubles with ADATA Ultimate SU800 SSD several times last year (here, here, and here), but I finally went ahead to send back the items. I just got a notice from ADATA that I am getting the replacements back from them. We will see if I get both of them warrant replaced since one of them (256 GB model) happened to be an open box item with the “warranty void if removed” sticker damaged by the previous purchaser (thanks Fry’s Electronics). They will arrive in the next 2 to 3 business days.