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