[Openchrome-devel] [ANNOUNCE] Fixing FP and TV code

[Kevin Brace]

Hi,

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 with.
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 recently.
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.

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer