Modular X.org and the Unichrome forks.

[Thomas Hellström]

Adam Jackson wrote:

>On Thursday 22 December 2005 13:10, Alan Cox wrote:
>  
>
>>Modular means that Luc can maintain his driver seperately and people can
>>easily try it. Thats great - its really good that people can try
>>alternatives and hopefully knock remaining bugs out. In the mean time
>>X.org needs to ship a driver, and the one with the least regressions is
>>the logical conservative choice until the developers figure out what
>>they are doing.
>>    
>>
>
>I have no desire to turn a choice among two drivers into a choice among three.  
>If Xorg ships effectively the stable branch of one or the other project, then 
>we're creating driver number 3.  We _had_ to do this for 7.0 because we had 
>to have parity with 6.9.  Doing it again in the 7.1 timeframe is mistake 
>unless, and only unless, the driver we ship as part of the 7.1 katamari is 
>clearly superior to either of the other two in terms of user experience.
>
>  
>
I think the situation needs to be clarified, and X.org needs to make a 
decision on how to proceed.

The openChrome project was not started by me, although I have been the 
most active developer lately, but by the  people wanting continued 
support for their Unichrome Pro chips and for XvMC. It is based on the 
code currently in Xorg with some additions for backwards compatibility 
and unstable development like EXA support and Xv DMA transfer. 
Development is currently focusing on EXA HW composite acceleration and 
XvMC mpeg4 acceleration.

The reason for almost all developers leaving the unichrome.sf.net 
project one by one had very little to do with technical disagreement. 
For those few interested in gossip, I think the Unichrome mailing list 
archives are still open. It had more to do with people having enough of 
and wanting to be nowhere near statements like this:

http://lists.freedesktop.org/archives/xorg/2005-December/011739.html

I still think all developers involved agree technically on where the 
driver needs to go. There is a disagreement on how to get there, since 
there are people prioritizing usability and people prioritizing code 
cleanups no matter what price is paid.

Recapping what's been said previously in this thread everybody seems to 
be favouring usability. This currently rules out replacing the existing 
via driver with the unichrome driver since it, in addition to what's 
been said earlier, also lacks support for Unichrome Pro modes, tv-out, 
and Xv, the latter requiring quite some effort to fix. I think Alan Cox 
clearly outlined what is going to happen if the via driver is removed 
from head.

The other option (if conflicting commits are feared) is to appoint a 
maintainer for the driver who OKs or denies the commits. I think it has 
been pretty clear from the list discussions that there are to be no 
usability reversions unless _really_ motivated. I'd happily accept any 
qualified maintainer who agrees to follow those recommendations. Even Luc.

Finally, to Luc, If lack of hardware is the reason for not extending 
your cleanups to Unichrome Pro, the offer of a CN400 board is still 
there. No VIA money involved.

/Thomas







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20051223/086c71a4/attachment.html>