During Day 1’s Lightning Talk session of X.Org Developer’s Conference 2019 (XDC 2019), I gave an update on the status of OpenChrome Project.  It is merely an update presentation since the last presentation was at XDC 2017. (The summary is here.  Presentation slides can be downloaded from here.)  As usual, only one graphics object (the title page OpenChrome Linux penguin logo I stole from the OpenChrome Project main website over at freedesktop.org) in the entire slides since I tend not to really put much effort into making the slides look nice.  To be honest, my presentation delivery was pretty awful for these reasons.

1. Wanted to present on Friday (last day), but the organizers strongly wanted me to go on Wednesday
2. When I attached overhead projector’s VGA connector, OpenChrome DRM caused a crash (known frame buffer management bug), and I had to reboot the computer (I went back to using OpenChrome DDX’s UMS code for the dual screen.)
3. HP 2133 mini-note does not fully open 180 degrees, so when put on a tiling stand, it could not really read the screen very well
4. Relating to the Point 3, I felt like I “had to” speak into the microphone attached to a microphone stand
5. I used a smartphone based stopwatch (set for 4 minutes and 30 or 45 seconds) during the presentation so that I do not go over the 5 minutes limit, but I did not set up smartphone’s screen settings properly, so the screen kept turning off after 30 seconds of inactivity

Because I used a smartphone based stopwatch to time myself, I was told by the organizer that I was the only speaker who did not go over the 5 minute limit during the Day 1’s Lightning Talk session.  I guess that is about the only thing that went right.

As for the contents of the presentation, I went over the status of OpenChrome DDX and DRM.

For OpenChrome DDX, a new official release version has not been released for more than 2 years, and I mentioned 2 blockers (Less than reliable VGA connector detection code and EDID acquisition issue on GPIO based I2C bus) preventing the release.  I also mentioned the improvements made to the code slated for Version 0.7.  For those who have X.Org X Server 1.20, you will need Version 0.7 for a proper operation.

For OpenChrome DRM, I went over the progress I made with it since XDC 2017 and remaining issues before the code can be included in the Linux kernel mainline tree.  In terms of the progress made with the code, standby resume is mostly working (I use it almost everyday) and display device support is close to feature parity with OpenChrome DDX’s UMS (User Mode Setting) code.

As for recent progress, I announced that I got “legacy” universal plane (primary and cursor planes) working roughly 2 weeks prior to XDC 2019. (I was saving this good news to be announced first at XDC 2019 rather than posting a short blog post prior to the conference.)  I have been working on universal plane for several months, so getting this done roughly 2 weeks prior to XDC 2019 was not really intentional in terms of the timing. (Proposal to present was submitted in June, and resubmitted for Lightning Talk session in July since it got rejected for a half slot presentation session.  Back in June, there was no guarantee I could get cursor plane working prior to XDC 2019.)  Furthermore, I mentioned that I started the work to convert to atomic mode setting using transition helpers immediately, and while the code was finished in a week, I could not get it to work prior to XDC 2019. (I did try pretty hard to get it working in a week and half, but it crashes the system during boot time.)

I discussed all the remaining issues preventing Linux kernel mainline tree inclusion, and those are atomic mode setting (already discussed), frame buffer management issue (the cause of run time screen resolution change crash that appears to have gotten worse fairly recently), and code cleanup issues.

Finally, I talked about what I will do with OpenChrome Project after the OpenChrome DRM is mainlined in the Linux kernel mainline tree.  Obviously, I will like to get 2D acceleration (EXA) working when OpenChrome DRM is in use since the unaccelerated 2D performance is pretty awful.

Anyway, for more details, here is the slides I used for the presentation.  For those who use OpenChrome, I hope this presentation gives you some idea of where the thing is headed.

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.

• Update on OpenChrome Project
• Reviving vintage (underserved) graphics hardware on X Server

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.

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.