Modular X.org and the Unichrome forks.
Luc Verhaegen
libv at skynet.be
Thu Dec 22 07:51:31 PST 2005
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.
More information about the xorg
mailing list