Status of xserver/debrix/modular tree?

[Bernardo Innocenti]

Daniel Stone wrote:
> On Fri, Feb 11, 2005 at 06:47:32AM +0100, Bernardo Innocenti wrote:
>>Daniel Stone wrote:
>>
>>>On Fri, Feb 11, 2005 at 12:42:42AM +0100, Bernardo Innocenti wrote:
>>>
>>>>By the way, my build failed because of missing drm.h
>>>>in hw/xorg/os-support/.  I copied it over from Xorg.
>>>
>>>baz get daniel at fooishbar.org/debrix-driver-ati--devel--0.1
>>
>>Thank you.  How can I get a list of all... er... repositories?
>>I have very little experience with arch/bazaar and, no I have
>>not RTFM yet.
> 
> I think it's 'baz categories'.

Hmm... it just prints the list of modules I've already checked out.
Or are there just these?  There used to be more pieces back when
Debrix was in CVS.


>>I used to find it very useful to checkout *everything* in a
>>single command...
> 
> Yeah, it's drm/libdrm in the DRI repository.

I realized this later, thanks.

Back when freedesktop.org was started, I very much appreciated
the online build instructions for the xserver project.

For xlibs and xapps, a top-level configure script to build
all subprojects in the correct order would be even more useful
than up to date documentation.

That would be an easy thing I could try to contribute.


>>That's where a designated (RM|board|dictator|whatever) would
>>step in and make a decision.  Even the wrong decision is better
>>than such a limbo of uncertainty.
> 
> And, as I said, we are in the process of appointing a release manager
> for 7.0.

I see.  As soon as he's in charge, I'll ask him if we can get
a release plan and some guidelines.


>>The Mesa project made a good move by importing the GLX stuff
>>from Xorg, but the files are still present in the xorg tree
>>and are soon going to get out of sync.
> 
> Right now, it is not entirely possible to build Mesa out-of-tree and
> still get all the features you get with an in-tree build.

Since a few months, I already build Mesa standalone and use it
with the regular Xorg server.  GLX and DRI both work fine and
I get twice glxgears fps than with the 6.8.1 libGL.

What am I missing?




>>I see massive code duplication everywhere.  For instance:
>>
>>$ locate xf86drm.h | grep src/fdo | wc -l
>>11
> 
> This is exactly the problem libdrm is solving.

Nice!


>>All repositories are full of old junk such as:
>>
>> fdo/dri/drm-old
>> fdo/dri/xc
>> fdo/mesa/Mesa-oldtree
>> fdo/xorg/debrix
>> fdo/xorg/testdir
>> fdo/xserver/debrix*
>> etc.
> 
> So?  These are there for historical purposes.  You don't have to check
> them out if you don't want to, and there's no sense in throwing history
> away.  In fact, I would say that it's a positive step, given that it is
> showing an obvious deprecation of code.

I'm not arguing we should "rm -rf" them from the repository,
just "cvs remove" them so the old stuff does not get in the
way when you grep through the repository.  One can always
checkout an old revision in case it's needed.

Not checking them out is an option, but it's harder for
subdirectories.


>>Not to mention imported copies in the extras/ subdirectory
>>of xorg/xc/ which are mostly a relic of XFree86.
> 
> Not really.  Apparently some people actually do want to build FreeType,
> zlib, xterm and all that sort of stuff, and x86emu, for one, thanks to
> not being a shared library, needs in-tree building.

It's the same bootstrap problem we mentioned earlier: despite
imake, building everything in xorg/ is much easier because it
follows the "one command to build them all" rule.

Modular tree is nice, but I think we should have something
similar to GCC's top-level bootstrap to simplify dependency
tracking, expecially for distributors.


>>Someone looking at the fdo pages wouldn't know what Debrix is!
>>I found it out just because there are still old copies of
>>it left around in other repositories.
> 
> Yes, I've not had time to update it lately.  Since I was last working
> intensively on Debrix, I've joined a company which has built itself and
> released a distribution in the space of a few months, and spent
> virtually half a year overseas.  I've really just not had the time to
> bring everything back up to date.  Indeed, my mail is still on a
> 'temporary arrangement' that I brought up in November, and intended to
> last about two weeks.

I did not mean to criticize your work, sorry.  I just think
that more people would help (at least by reporting bugs) if
it was more visible.


> The point of Arch is to enable distributed development, which means that
> everyone is free to branch off my repository and work from that, so I can
> then merge back.  If I get hit by a bus, then the mainline moves
> somewhere else.  Currently the contributor interest has not been high
> enough to move to a centralised repository that others can merge in to.
> 
> Using this centralised model, I was able to get invaluable help from
> JakubS and Kristian Høgsberg.

I know about distributed VCS and its advantages.  The topic has
also been extensively debated in GCC too.  CVS is no longer
able to support GCC development, with branching and tagging
operations taking over 3 hours.

Daniel Berlin finally convinced everyone that migrating to SVN
will solve most of the problems we face today with minimal
changes in the current workflow and infrastructure.

Of course Subversion is no way near a real distributed VCS, but
it's quite mature and better than CVS in many ways and people
don't need to learn how to use it.

(this is not svn propaganda, I don't use svn myself and don't
have an opinion on arch VS. svn or similar issues).


>>People are intelligent enough to see that someone must be leading
>>the project... and in the best interest of the project one should
>>either follow his decisions, try to change his mind, or leave.
>>
>>Any society works this way, except the Borg :-)
> 
> So, in that case, you are effectively forcing them to leave.

The "leave" part in my statement could be rephrased as "work alone
on a fork".  It doesn't mean dissidents are banned forever.

Forks happen continously in the Linux Kernel, and has even some
value (remember the VM saga?).  But Linus isn't ever going to
allow code implementing the Win32 API in his tree :-)


> X.Org has some hard decisions ahead that need to be made, and rushing
> them wielding a big sword of authority would be doing everyone a
> disservice.

A good RM would first try to get consensus and not rush
things beyond what can be achieved in practice.

GCC and Mozilla both learned to make realistic feature
plans and release schedules.

Xorg seems to be able to perform frequent releases too,
which is good, but features too often don't match original
plans.


> The Radeon driver has Render acceleration, but yes, while XAA remains,
> it is arse-slow, and it sucks.  But the entire Composite framework is
> there and working.

KDE and Gnome (or, better, QT and GTK) can't build on Composite
until it's fully hardware accelerated for a large user base.

When it's devivered, it will probably take another year or two
before users will enjoy it.  MacOSX already had something similar
two years ago and Longhorn won't keep slipping schedule forever.


> The original question of your thread is which acceleration theory should
> we go for in the long term?

Basically, yes.  I know it's yet undecided, but a decision
should be made in order to ever get it out.


>>So it's still not clear to me whether next year's Linux desktop
>>will be using Cairo with Glitz, Cairo with Render, Render on
>>steroids, Xgl, or still the old core graphics.
> 
> It's not clear to anyone except the toolkit authors, really.

GTK seems to be moving to Cairo.  Trolltech recently demoed
their portable Andrew technology which could probably be made
to work with Cairo or Render.

Cairo has backends for both Render and GL, so either
would do.


> xserver (and KDrive) is basically an experimental X server that is not
> usable for day-to-day use for several reasons, not least of which being
> sparse device support (it's great if you own an M6 or R200 ...).  If we
> move modular, then the Debrix framework with a re-imported Xorg source
> tree is almost certainly going to be the way forward,
> but I can't speak as to which revision control system will get used.

Luckly, the revision control system issue is orthogonal with
the chosen acceleration architecture and the modular VS monolithic
question :-)


> No, beacuse this is a massive and ongoing debate with very, very
> strongly-held feelings on both sides.  It's not a simple problem to
> solve.

I've read the threads... and it seems to me that most (all?)
developers agree we will eventually go modular.  What's being
debated is whether it will be ye old XAA, KAA or Xglx, right?

That's the kind of issue on which management would make a clear
decision.  Making the wrong decision is still better than
stalling forever.


>>Kdrive already supports all required Render acceleration, at least for
>>ATI.  Xgl would even make all the accelerated 2D drivers pretty useless
>>by relying only on DRM+DRI+Mesa.  Am I misinformed?
> 
> Yes, but KDrive uses an entirely different acceleration architecture and
> massively different systems for managing, well, everything.  It's not even
> close to the same DDX as Xorg.

Rewriting all 2D drivers almost from scratch seems too
expensive to me...

Distributions would fall into the same hell that happened
when XFree86 4.0 came out without drivers for many common
chipsets and XFree86 3.3.x remained around for years.


> If you used Xgl, then you could accelerate all your 2D operations through
> OpenGL by reworking them into 3D primitives.  But today's current Xorg
> drivers would be left by the wayside, yes.

Running a full-GL desktop would be very sexy, but there's still too much
popular hardware that don't support (fast enough) 3D acceleration.
Linux distributors wouldn't take this route, at least not for a
few years.


> These are major shakeups being proposed, both of them.  And I think that
> moving to KAA would be very worthwhile, but a huge amount of effort to
> migrate to.

Isn't there a way to fix XAA incrementally?  I don't know that
code well enough, but even Microsoft could retain existing
video drivers while adding fast alpha blended primitives to GDI.


> Ehm, it also introduced the Composite extension to the Xorg DDX (and
> was the first Xorg to ship with Damage and Fixes enabled by default),
> and much development such as that on XEvIE happened, as well as a few
> major changes within the X server.

Yeah, I know... and it's impressive work too, but not in
the direction that was originally envised.

That's what I meant when I first said "continously shifting
focus".  Extending the old Xorg server does not bring
Xgl/KAA/whatever any closer and increases the amount of
maintenance work required to keep the other servers
synchronized.


>>Ok, but wouldn't a MAINTAINERS file in Xorg's root
>>directory make it more clear for people outside the
>>project?  It's a quite common practice in many projects.
> 
> Yes, it would be handy to have.

I'd like to contribute this, but I don't know who the
maintainers are.  Let's ask the new RM as soon as he
gets on the bridge :-)


>>I'd volunteer to work on such trivial improvements
>>for Xorg over my next holidays if there will already
>>be a single copy of the sources to work with.
> 
> This would be a very worthwhile tasks; marking functions with various
> GCC attributes (noreturn, deprecated, printf, whatever) would also
> be awesome.

It's something I could certainly do with my limited knowledge of
the Xorg code base.

The only problem is that, work like this would have to be synced
up between xorg/xc/ and xlibs/ therefore it's better to delay it
until the monolithic tree finally rests in peace.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/