Modular X.org and the Unichrome forks.

[Luc Verhaegen]

As many are probably aware, unichrome.sf.net split up in the past year. 
I remained at the project i started, while Thomas Hellstrom created 
openchrome.org.

Recently, the X.org via driver has been altered by both sides, in a 
civilised way (fairly - via_dri.h 5.0.0 shouldn't get a repeat). Before 
the fork I was pulling in unichrome.sf.net releases, a few weeks after 
each release. After the fork, unichrome.sf.net CVS code (there were no 
releases for a while) plus some changes were added to the tree by 
Thomas. In the run up to the X.org release, bugfixes were committed by 
both.

Now the tree is re-opened and the "bugfixes only" regulation is no more. 
I've always tried to keep this whole mess as far away from X.org as 
possible (except for the endless whining on irc, it had to spill out 
somewhere :)), but now things have come to a point where it can no 
longer be ignored. It's time to bring some clarity in this whole issue.

In the time since the fork both trees have grown apart quite 
considerably:

unichrome.sf.net code:
- VBE modesetting removed (only hurts unichrome Pro panels - VBE was 
part of the reason for the fork)
- XvMC removed.
- Cache prefetching memcpy removed.
- Clean and maintainable Xv implementation.
- Clean driver level fb allocation abstraction.
- Very high degree of output device seperation. (my pet peeve)
- Chrontel CH7011 TV encoder support.

Openchrome.org code:
- Kept XvMC.
- Kept VBE modesetting for unichrome pro panel.
- Kept cache prefetching memcpy.
- Routine to generate unichrome Pro dotclocks.
- Dma blit (drm).
- EXA support plus XAA changes.
- Expands vt162x code with some support for vt1625 (in as far as either 
can claim support for any of the VIA TV encoders - no free datasheets 
:))

These are by no means complete lists, but they do outline in what ways 
both trees have grown apart.

It has become close to impossible to merge the unichrome.sf.net code 
into the openchrome code, the only feasible merge direction is the other 
way around. The unichrome.sf.net code has seen fundamental changes, 
while the major openchrome changes mainly were additions. I do have to 
commend Thomas on his drm dma blit (a good solution for the painful Xv 
buffer copy which i will support really soon) and Exa support.

But this is not the solution I have been suggested and which I am going 
to repeat now.

Every time the fork and the repercussions on X.org have been discussed, 
the option to "deprecate" the X.org side driver was mentioned. This 
means that the driver is maintained on a "bugfixes only" level, as it 
has in the last few months. This probably translates to a cvs remove on 
HEAD, leaving the code in the monolith and 7.0 branch for bugfixes 
releases.

This means that, unless the fork is resolved, future X releases will not 
officially endorse any unichrome driver. X.org will not choose a side.

For X.org and especially for release managers, this means one less thing 
to worry about. You can just point the bugs to either of us, and the 
issue will be handled by us. You do not have to do deal with the issues 
of two people at odds committing conflicting code to your CVS tree.

This will also remove a third "fork" from this mess, and bring a lot 
more clarity, for both users, distributors and developers.

For distributors, the fact that the driver isn't maintained in X 
directly is no longer a problem, thanks to the great work put into 
modularising X. You are now free to package whichever you want, and you 
can place blame accordingly :). I'm sure both Thomas and I will do 
whatever is in our power to make this no more painful than it needs to 
be.

I'm also certain that both of us will continue to contribute to the 
higher levels of X as we have done in the past.

As for the projects themselves, this allows each project to progress on 
their own merit, as this means a level playing field for both. It's 
healthy competition, that drives code further, faster, the way free 
software is meant to be. It also gives us both the ability to continue 
down the paths we each have chosen.

I hope that this clears this painful situation, in a way that is 
acceptable for all parties.

Luc Verhaegen.