Last night, I sent out an announcement that the release of OpenChrome Version 
0.6 may have to be delayed by 1 to 2 months.
The thing is, the code quality of FP (Flat Panel) and TV support code is still 
in a very bad shape.
For example, TV support code appears to be written to only target CLE266 
chipset, even though many other Chrome IGPs support external TV encoders.
The code has to be rewritten so that other Chrome IGPs can be supported as well.
The thing is, when VIA Technologies went from CLE266 chipset to KM400 chipset, 
they made extensive changes to how external transmitters / encoders are 
connected to the chipset's external video port. (They call it DVP or Digital 
Video Port in their datasheets.)
The change affected not only the hardware configuration, but also the register 
addresses the code uses.
I plan to start tinkering with the FP and TV code fairly soon, however, the 
problem is, I do not own the very old hardware that the code was written for 
about 10 to 12 years ago. (2004 to 2006)
The very old hardware I am referring to are: CLE266, KM400 (including P4M800), 
and K8M800.
Regarding CLE266, ECS (Elite Computer Systems) used to sell a laptop called 
G320 that has CLE266 chipset.
This model obviously comes with an FP.
I do own EPIA M mainboard, but due to the displacement incident that happened 
to me 2 months ago, it is likely buried somewhere in the pile of my household 
belongings. (It is likely inside one of the many black garbage bags littered 
around my apartment room.)
This one can be used to play around with the TV code, and can handle DVI or FP 
if an optional adapter is used. (I do not own these adapters.)
Anyway, just in case I make a bad commit to the repository that "breaks" your 
FP or TV, let me know as soon as possible so that it does not get out of hand.
If you can help me debug the code, that will be highly appreciated.
    I do not want to overpromise too much at this point, but all this work is 
really being done in order to have better device support when the new DRM code 
(drm-openchrome) is mainlined with the Linux kernel someday.
Personally, I am not a huge fan of how Linux (or for that matter, Unix based 
OSes) handle graphics device driver stacks (Personally, I prefer how Microsoft 
handles graphics device drivers with Windows, but I am no fan of Microsoft, so 
please don't send hate e-mails to me over this comment.), but Linux is pretty 
much the only viable alternative to Windows, so I need to live with this weird 
separated graphics device driver architecture (i.e., DRM + DDX) someone came up 
The thing is, the test turnaround time for OpenChrome DDX UMS code versus 
OpenChrome DDX + drm-openchrome is something like 3 minutes versus 25 minutes 
(most of the time is being consumed by installing all of that compiled device 
drivers when I install drm-openchrome code) when I was doing some testing 
I do not know if there is a shortcut to shorten this 25 minutes wait to 
something like 5 minutes, but as a result of this, the development pace for 
drm-openchrome will be very slow compared to OpenChrome DDX.
This is why I will like to perfect the display device support while in 
OpenChrome DDX UMS code development rather than with drm-openchrome.
This is the major reason why I still "bother" with OpenChrome DDX UMS code, in 
the first place.


Kevin Brace
The OpenChrome Project maintainer / developer
Openchrome-devel mailing list

Reply via email to