Modular X.org and the Unichrome forks.

[Luc Verhaegen]

On Thu, Dec 22, 2005 at 11:06:59AM +0000, Alan Cox wrote:
> On Iau, 2005-12-22 at 04:36 +0100, Luc Verhaegen wrote:
> > - VBE modesetting removed (only hurts unichrome Pro panels - VBE was 
> > part of the reason for the fork)
> 
> So your code causes reversions and loss of support for end users.
> 
> > Openchrome.org code:
> > - Kept XvMC.
> > - Kept VBE modesetting for unichrome pro panel.
> > - Kept cache prefetching memcpy.
> 
> And openchrome doesnt
> 
> > 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.
> 
> X.org needs to choose a side so that it packages something.
> 
> > I hope that this clears this painful situation, in a way that is 
> > acceptable for all parties.
> 
> It makes it worse for everyone. Whats next, vendors together fork X.org
> to include a VIA driver ?
> 
> <Vendor hat on>
> 
> The fact openchrome supports hardware and the new code breaks existing
> functional hardware means its totally obvious that the openchrome code
> should be used and shipped as a default in X.org. Reversions are bad.
> 
> </Vendor hat>
> 
> Once the new code supports everything the old code does, then perhaps
> there should be a discussion and some planning around best options.
> Until then it seems people are jumping the gun and X should just ship
> openchrome so that users don't suffer.
> 
> Alan
> 
For any modesetter worth his salts VBE is unacceptable.

The unichrome driver allowed, from the very start, complete and free 
modesetting. This is what i realised very early on and what i have been 
working on ever since. Proof of that is the very high degree of output 
device seperation in the unichrome.sf.net driver.

You might also remember this:
http://bugs.xfree86.org/show_bug.cgi?id=812
comment #13: "At one point i will have to go dig out these tables, but  
it will be very painful without datasheets (output abstraction will need
this)."

The only real modetables that remain is for the panel and I have been 
literally begging (more like screaming actually) to be given half an 
opportunity to fix up the panel code ever since. VBE was added to cover 
up the fact that i hadn't been given the opportunity.

Actually, right before the fork, i was spending a lot of time with Terry 
Lewis, the owner of an Acer Aspire 135x 
(http://bugs.xfree86.org/show_bug.cgi?id=813, still not really fixed).
Over his 56k line, we managed to fix a lot of issues, but this sort of 
work is very slow and very frustrating. Most of this is poke a bit, 
build, restart X, wait for Terry to say wether this changes anything, 
and so on and so forth. I owe that man about a whole crate of Delerium 
Tremens (locally brewed beer).

Now, with most of the unichrome modesetting fundamentally changed, the
panel code takes up more than a third of the whole driver. I reckon 
that, when given half a chance, i can bring down via_panel.c to between 
200 and 400lines, removing the last of the modetables. It would of 
course also remove the rather artificial seperation i have now given 
this black box. But that was also done for kicks, and to see how well my 
abstraction would hold up (Not that well with _all_ modesetting done 
through the tables in the panel code, but it's far from unacceptable).

What has happened on the panel front ever since VBE was added? Has there 
been any change openchrome.org side since? No. VBE is the easy way out, 
it is used to cover up that what people are unable to fix.

So, the next time something modewise breaks, the easy option will be 
chosen again, and VBE usage will be expanded. This goes on and on, until 
you end up with a driver that's completely VBE based, like the intel
one.

People always assumed that the reason for the intel driver using VBE 
was that the many possible output devices aren't managable. I've been 
able to convince a lot of people that this is a myth. And the code at 
unichrome.sf.net is living proof of how this is possible.

In fact, if it wasn't for the work i had put into modesetting in the 
first place, all unichromes except CLE266 and KM400 would've required 
VBE already. I'm sure that by now, the modetables would've been 
removed completely and modesetting was VBE only.

So why have i been unable to clean up the panel code then? The reason is 
hardware. And hardware was the major reason for unichrome.sf.net 
breaking up.

But then, the pre-fork unichrome.sf.net cohesion was apparently based 
upon a single thing: me shutting up and silently doing what was expected 
of me; which was keep the thing building and running, writing most of 
the code, and being some sort of a release nazi (who amazingly had to 
keep his trap shut.).

As for XvMC, you'll see that most people can't be bothered with it. Most 
people who buy IGP graphics just want their desktop to show up on 
whatever screen they use. But those people also barely ever make noise,
except when their screen doesn't show their desktop. It is then that 
telling them that you can't help them because you've been doing VBE 
all along backfires on you.

Part of the reason for the fork was also based on the fact that i was 
finally cleaning up Xv code (someone had to do it), work which i 
finished (in as far as code is ever finished) a few months ago. I never 
am content with a black box, but the XvMC support was added on top of as 
big and ugly a black box i've ever seen. The fact that i was then also 
uncovering cruft in the XvMC code expedited the fork.

If i cared about XvMC, and the limited benefit i think it provides, i 
could fix it up in a matter of days. But if Hellstrom in any way cared 
about Xv, he could've fixed his XvMC to sit on top of my clean Xv 
implementation in a matter of days as well. Because cleaning up 
openchrome Xv even to the point where you can start claiming that you 
know what the code is doing, is most certainly not a matter of days, 
even when under NDA.

All of the above somewhat outlines my motives for doing things the way i 
am and have been doing. But they don't explain why i found removal a 
good solution.

In the past 2.5years, i have learnt that good code and vision get you 
nowhere. It more and more seems that free software is only about 
money and politics.

I was hoping that my previous mail would take politics out of this 
equation. Making it code against money.

Luc Verhaegen.