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
_______________________________________________
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel
