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.