New unichrome.sf.net code... Finally.

The latest unichrome X release was r30, which already dates back to january 27th of this year. There was a lot of solid development all through february, the brunt of this code was becoming ready for another release. Sadly, this is where VBE modesetting was introduced, and this code wasn't ready at all. r31 was put off.

Personally, i find VBE modesetting fundamentally unacceptable and it goes in against all i have done and am doing. Together with some semi-latent issues, this led to the final falling out of those "involved" in unichrome.sf.net. And unichrome-X-r31 never happened. By then I was too busy to churn out a suitable amount of code anyway.

Now, 8 months later, i'm introducing new code. One change is that releases will no longer be named unichrome-X-r??. The driver has been named xf86-video-unichrome, matching X.orgs modular driver names. The driver directory structure was altered too.

The first release will be called xf86-video-unichrome-0.2.1. Because, first of all, the 0.1.31 version had been hijacked by the forkers, even though this was a numbering scheme i had introduced. So now people will once again be able to tell which is which and who is to blame. And secondly, this release is quite far away from the old code, it represents a (slightly) different direction and it is a new CVS module (even though the trunks history has been kept).

This codedrop is quite large, so there will undoubtedly be hairy stuff in there.

Main changes:
- rework: Except for 2 nasty bits, Xv support has been completely rewritten. This has taken most of my time but i'm pretty happy with the endresult. That big, ugly and highly illogical blob, that no-one could get a hold on, has been reduced to some 2400 highly managable lines.

- removal: Video1 support. There is no real Xv way to compose 2 overlay engines on the same head currently. So, since Video3 is the only engine available on VT3205 and VT3204, I kept only HQV and Video3. Both are already largely seperate from eachother (except the toplevel PutImage), and full separation will be trivial to implement. Video1 can be added easily when the need arises.

- removal: cache prefetching memcpy. Should get an X wide implementation, and shouldn't care about pitch alignment. Actually, the only good solution here is the dma copy Thomas Hellstrom implemented in drm, but i still have to look into that. For those solely interested in cpu usage, feel free to port memcpy, you'll see my Xv rework performing measurably better than the old code.

- removal: XvMC VLD. Thomas Hellstrom is hereby invited to stick patches against xf86-video-unichrome up on the unichrome.sf.net tracker.

- addition: funky image formats: YUV420, RV15, RV16 and RV32. UYVY is not possible in hardware alone. Mainly to showcase the flexibility of managable code, as no-one uses these FourCCs anyway.

- rework: the in-driver-memory-management-abstraction was completely reworked. Xv also required 16byte alignment.

- addition: For those who like a bit of "chrome": i've implemented the alpha plane.
Get the util xvattr (http://freshmeat.net/redir/xvattr/19550/url_tgz/ , GPLed sadly, someone should write an MIT implementation and stick it in utils) and adjust XV_OPACITY. Now hold something over the Xv window :) Sadly, this is not a very efficient use of resources. Thank VIA's implementation of an alpha plane on the unichrome for that.

- removal: VBE modesetting. Feel free to scream at me as much as you want, this is out and will stay out. Problems should get a proper and free solution or none at all. All a proper solution takes is clue, hardware and time.

- addition: CH7011 support. The CH7011 is a nice little chip. When i got my SK43G, i dropped everything else and implemented it. The code is cu-u-ute. Urgently needs an attribute system though.

- change: TV encoders now no longer have unichrome dependant code in their implementations. With two different output devices connected to two different chips, i felt confident to move the DI0/DVP0 bus setting away from the tv encoders. pBIOSInfo still needs to be broken up, but that won't happen until TTL, LVDS and TMDS code has been cleaned up or inserted.

- rework: driver layout matches X.org modular. All branches were surgically removed from the RCS files. New releases will branch off of HEAD at each release. Actual autoconf/automake build still needs to be added.

As one final note; I believe in drivers enjoying some amount of independence. It allows people to write code faster and have it tested independently of X releases. In the past, unichrome.sf.net was an active community and many people who enjoy throwing stuff at their hardware had gathered there. Problems were found quickly and efficiently and development was reasonably swift, with hardware availability being the main bottleneck. Unichrome.sf.net was, all in all, a good environment for driver development.

I now hope to have regular releases again. And hopefully, after several weeks of testing, stable code will trickle through to X.org again.