[Openchrome-devel] The OpenChrome Project - Year 2016 year end review

[Kevin Brace]

Hi everyone,

I suppose I do not have to do this, and no one is compelling me to do so, but since there has been some progress made in developing OpenChrome graphics stack this year, I figured I should spend some time reflecting on the progress made this year.
While The OpenChrome Project has been effectively dormant for a number of years, Year 2016 saw a revival.
Although no one really asked to step up, someone who happened to meet the following characteristics showed up to pick up the development pretty much by an accident.

- Someone who has device driver development experience
- Someone who rescues too many abandoned computers like rescuing a pet
- Someone who owns way too many computers and computer parts as a result
- Someone who buys old computer parts from ebay or Weird Stuff Warehouse (Sunnyvale, CA, USA) if it appears to be unique or rare
- Someone who has a lot of free personal time who does not resent doing unpaid work that much
- Someone who tries to fix other people's broken code
- Someone who does not really like Linux or xBSD, but realizing that there is little alternative

I guess I, Kevin Brace (the author of this shameless self promoting piece), happened to meet the above characteristics.
I do use this as an excuse often, but I am really not an OS / device driver guy, and I am really an electronic hardware engineer (RTL design) more than anything else.
However, due to number of issues facing electronic hardware industry employment situation like industry consolidation (i.e., Intel purchase of Altera, Avago purchase of Broadcom and then changing the name back to Broadcom, Qualcomm purchase of NXP Semiconductors, etc.), layoffs related to the changing consumer preference (i.e., Intel's April 2016 layoff getting rid of 12,000 people or 11% of their "official" workforce, mostly older experienced ones, and replacing them with recent college graduates who will need to be trained extensively to get them up to speed.), excessive use of foreign worker visa (i.e., H-1B, L-1, F-1 / OPT, etc.) here in Silicon Valley, and the lack of electronic hardware startups in Silicon Valley, I am gradually moving away from my natural habitat of electronic hardware design.
At least that was part of the reason why I got into developing OpenChrome.
This is one reason why the code fixes mainly was with hardware detection related areas closer to my comfort level, and I have not really touched more of the OS interfacing portions of OpenChrome like rendering and memory management.
    Anyway, I did not originally really plan to work on OpenChrome besides fixing standby resume bug, but I realized that the code itself was in a really bad shape, so I started to make improvement to the code outside of the standby resume issue.
Based on what I remember, these are the major accomplishments in OpenChrome DDX (2D device driver for X.Org Server) for the year.

- Got rid of "known device table" where people reported the known VIA Technologies Chrome IGP display configuration
- Fixed DVI-I to VGA converter screen recognition regression
- Released a long awaited new version (it was called Version 0.4.0 back then)
- Fixed the run time screen resolution change X.Org Server crash bug
- Added Silicon Image SiI 164 and VIA Technologies VT1632(A) external DVI transmitter support
- Added dual screen support (initial support)
- Released an improved current version (Version 0.5)
- Fixed CX700 / VX700 chipset DVI related bugs

In addition to that, after a slow start, some progress was made in developing the next generation OpenChrome DRM supporting KMS. (Kernel Mode Setting)

- A small fix to HDMI code
- Added UniChrome IGP support (PLL code addition)
- Fixed FP (Flat Panel) only configuration screen bug
- Fixed FP not turning off bug

For the next year, I will likely work on the following issues.

- HP 2133 Mini-Note's PCI Express based Broadcom WLAN card getting disabled by OpenChrome DDX (https://bugs.freedesktop.org/show_bug.cgi?id=99007)
- Messed up screen when switching to virtual terminal (Ctrl + Alt + F1 through F6) regression
- Try to find the root cause of various standby resume bugs (OpenChrome DDX and DRM)
- Back port OpenChrome DRM's HDMI code to OpenChrome DDX
- Completely revamp OpenChrome DDX's TV encoder code since it is broken (at least composite output is)
- Fix excessive RAM usage issue of OpenChrome DRM (when having <= 512 MB total RAM) that leads to a crash during boot time
- Fix run time screen resolution change X.Org Server crash bug of OpenChrome DRM

Personally, I will like to work on developing graphics stack for older, forgotten graphics devices from SiS, Trident Microsystems, S3 Savage, Matrox Gx00, ATI Technologies RAGE 128, etc., but fixing OpenChrome is consuming all the free time I have, so I will likely remain stuck working on this project alone for the foreseeable future.
While I have seem to have caused a regression with HP 2133 Mini-Note's PCIe WLAN and virtual terminal screen switch, overall OpenChrome has been moving in the direction of becoming more reliable than ever.
After those two issues are resolved, and register save / restore improvement is made, I will move OpenChrome into Version 0.6 RC (Release Candidate) testing phase.
In general, I emphasize code reliability more than other Linux / xBDS developers (I think), and I will continue in this direction by fixing more issues even though it is very hard fixing existing code bugs.
    Just to let people know, I am writing this message from a VN896 chipset laptop with Xubuntu 14.04 and next generation OpenChrome DRM running on it.
I am using the latest OpenChrome DRM Version 3.0.8 I just released on 12/29/2016 where I fixed FP turn off bug.
In the long run, I will likely have to get the OpenChrome DRM mainlined by Linux kernel developers.
Personally, I did not have particularly good experiences dealing with them during Year 2016.
I am not sure when I will ask to get the code mainlined, but prior to that, I will have to get various bugs I have identified fixed along with getting 2D acceleration working for KM400 and VX900 chipsets. (These are the two chipsets I have done some testing, and 2D acceleration is definitely not working.)
That being said, some form of acceleration appears to be working with VN896 chipset, and this is the reason why I can even write this e-mail from this computer, or the computer will be utterly useless. (i.e., window movement)
Considering how low people tend to think of the performance of VIA Technologies Chrome IGPs, the graphics performance I am seeing here is more than good enough for nominal 2D graphics use with no observable rendering issues.
That's all for this year, and I hope OpenChrome will be even better next year than it is today.

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer