[Openchrome-devel] [ANNOUNCE] Post XDC2017 OpenChrome Project status update

[Kevin Brace]

Hi everyone,

XDC2017 was held more than 2 weeks ago, and as I have previewed it prior to the conference, I had the opportunity to present about the status of OpenChrome Project.

https://www.x.org/wiki/Events/XDC2017/Program/#kevin_brace

Anyway, to those interested, here is the video clip and the slides of my presentation.

https://www.youtube.com/watch?v=F3uRpOI0xi0&t=6h33m16s
https://www.x.org/wiki/Events/XDC2017/brace_openchrome.pdf

Although I did not prepare for it, the organizers had a little extra time slot for another demo, so I threw in a small demo of OpenChrome.

https://www.youtube.com/watch?v=g5T5wSCXkH4&t=8h26m55s

The demo was OpenChrome DDX performing standby resume flawlessly on Xubuntu 16.04.3 LTS along with a preview of OpenChrome DDX and DRM (with KMS support) running on Linux 4.13 rc5 kernel.
Please note that I did put OpenChrome DDX and DRM into standby and resumed it shortly.
Since standby resume was not working perfectly at all at that time, all I was able to demonstrate was that the computer has not completely crashed, and at least I had some control of the computer via VT.
Even for this demo, I only got this far the Saturday prior to XDC2017, and I only had OpenChrome DRM running on Linux 4.13 rc5 for 4 days.
    I am sending out this status update since I was able to figure out how to get my primary development system (HP 2133 mini-note; VN896 chipset) to now perform standby resume properly with OpenChrome DRM running.
Yes, I am talking here of getting KMS code to resume from standby correctly, and get VGA and FP to be restored properly as well.
Yes, there are still number of issues remaining, but this is a huge progress for OpenChrome DRM.
Here is the version that gets it working correctly for VN896 chipset.

https://cgit.freedesktop.org/openchrome/drm-openchrome/commit/?h=drm-next-4.13&id=5fb286ec71cf7cd4a058d7ae7bfeb3fa8ef1ed3f

Just to not disappoint anyone, based on the way the code is written, display cursor may not work properly on many older UniChrome / UniChrome Pro hardware due to older hardware having only one HI (Hardware Icon).
In OpenChrome, HI is used as a full color hardware cursor instead of using a conventional hardware bi-color cursor.
HI is a full color hardware cursor like movable object that is displayed over the display bitmap.
For the newer hardware like VN896 chipset, VIA did add a second HI, and this is important when mirroring two screens (i.e., VGA and FP or VGA and DVI, etc.).
    There is one more major bug outstanding for OpenChrome DRM, and it is the fact that changing the screen resolution during runtime will crash the X Server.
I have been after this bug as well for the past 2 months, and at this point, it appears that OpenChrome DRM not releasing the frame buffer GEM object when performing a screen resize is the culprit of the crash.
I will start working on this issue very soon, and if I can get this issue solved, there will be several more major issues I will need to deal with prior to sending in the pull request to the DRM maintainer.

1) Display device support needs to be similar to the existing OpenChrome DDX UMS code path except TV out
2) Figure out how to activate software cursor when operating in a dual head mode with a single HI hardware (i.e., KM400, P4M800 Pro, etc.)
3) May have to convert the existing mode setting code (KMS) to adopt the newer atomic mode setting

Regarding (3), I had a "heated" discussion with one major silicon vendor's point person of their DRM (I will not name the name here.) at XDC2017, and this person very strongly encouraged me to immediately convert the existing KMS code (I will call it "legacy" KMS here.) to atomic mode setting.
I do not want to sound critical of this person here, but I did explain to this person that I first wanted to stabilize the mode setting code first before I can consider converting to support atomic mode setting, but I felt like this person did not try to understand my approach to the development of OpenChrome.
As someone from computer architecture / digital design (Xilinx FPGA, PCI / PCIe interface controller, and DRAM controller) background, I know that this firm in question (again, I will not name it, but it is fairly obvious) has lower per employee productivity than its smaller competitors.
This firm has laid off about 10% of their workforce in 2016, and the layoff has targeted the more experienced (but expensive) 40s to 50s age group employees, but has continued to hire mid 20s master's degree NCG (New College Graduate) who will likely require extensive OJT (On the Job Training) to get up to speed.
Based on what I already knew and just experienced, I think their approach to design is to make individual contributors expert on one or maybe two areas because they can afford to continue doing this financially (they have very large revenue, but it has been fairly flat for the past few years).
Furthermore, their approach is to throw more people at the problem rather than improving per employee productivity.
However, doing so means that the individual contributor lacks understanding of related field done by some other expert.
In other words, they are very bad at growing their talent who can handle multiple tasks / fields, and instead have too many people who are good at one or maybe two tasks / fields.
That was my takeaway from the "heated" discussion over what to do with mode setting for mainlining.
For OpenChrome, I have to basically handle everything myself, so inevitably, I get good at many different things along the way.
At least so far, I have continued the design approach I mentioned to this individual, and I think it is producing good results since I got standby resume figured out in 3 weeks.
I felt that converting to atomic mode setting at this point will be a major disruption, and I will only do so when the "legacy" KMS code has been largely stabilized.
    Regarding the OpenChrome development roadmap, what was mentioned during the presentation is still largely intact.
The only change to the roadmap will be to implement atomic mode setting prior to Linux kernel mainlining since I got the impression from this major silicon vendor's point person of their DRM that it is unlikely that the DRM maintainer will now accept the code without the use of atomic mode setting.
Also, I have invested some time in installing Debian 8 to my VIA EPIA-M based computer (CLE266 chipset) and try to test OpenChrome DRM to work on Debian 8.
So far, I have not been successful in getting OpenChrome DDX to recognize OpenChrome DRM from Linux 3.19 rc6.
DDX for some reason doesn't see the DRM, hence, I have not been able to test OpenChrome DRM on CLE266 chipset.
Anyway, getting standby resume to work on HP 2133 is a major achievement towards mainlining OpenChrome DRM, and I think OpenChrome DRM is well on track toward getting mainlined sometime in 2018.

Kevin Brace
OpenChrome Project Maintainer / Developer