Status of xserver/debrix/modular tree?

[Bernardo Innocenti]

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.


> ditto -input-keyboard, -input-mouse, et al.  As for the missing
> drm.h, you really want libdrmcore for that.

Where is libdrmcore?  Is it the same of drm/libdrm in the DRI
project?  I'm having a hard time chasing out all fdo repositories
now that the top-level CVSROOT has been disabled.

I used to find it very useful to checkout *everything* in a
single command...


>>No, actually I had read that one... That's where I've read that
>>the xapps/ and xlibs/ repositories were unofficial and mostly
>>abandoned.  IIRC, that thread ended without a clear decision.
> 
> How you read that from that thread and missed all the rest is beyond
> me.

At that time I was still reading the list through the
archives, now I'm subscribed.


>>And, yes, I agree with you that the monolithic tree should be
>>made lighter by moving pieces away from it.
> 
> People don't tend to arrive at clear consensus when they're at
> complete loggerheads on future directions.

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.


>>Sorry, several months have passed since the threads you
>>mentioned and I still see Xorg not taking any of the routes
>>that were proposed.
> 
> I see xlibs having been synced with the monolithic tree.  I see Debrix
> bootstrappable from the bottom of xlibs to the top of Debrix without
> the need for a single piece of the monolithic tree.  I see Mesa-solo
> work progressing.  I see libdrm finally becoming a first-class library.
>
> I see many, many things happening (no dead people), a lot of them which
> are leading the path towards modularisation.  This development is going
> on every day, and there's now a board-approved modularisation working
> group.

I can also see some of the things you mentioned too, but efforts
are *not* being coordinated, really.

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.

I see massive code duplication everywhere.  For instance:

 $ locate xf86drm.h | grep src/fdo | wc -l
 11

This causes lots of confusion, expecially for people who only
occasionally follow X development.

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.

Not to mention imported copies in the extras/ subdirectory
of xorg/xc/ which are mostly a relic of XFree86.


>>Development proceeds in multiple directions without a
>>particular focus on a common goal and this, IMHO, is a
>>wasteful use of the available resources.
> 
> Look, it's suboptimal, but welcome to a volunteer project; I can't force
> everyone to work on the modular tree, e.g.  Such is life.

With all due respect, moving debrix to a personal repository,
using a different revision control system, and not keeping the
developer information in the wiki up-to-date... all this isn't
going to convince other Xorg developers line up to join the
effort.

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.


>>Discussions about high-level issues such as the
>>development model and long-term plans may cost much time,
>>but are badly needed in any large scale project.
> 
> And when such discussions have been going on for years without any
> conclusion?  Do you suggest we somehow decide on a direction and force
> everyone to obey?

Forcing people is not an option in OSS projects and usually not
effective even in a business.

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 :-)



>>What's mostly missing is a long-term development plan
>>and general consensus on it.  Don't you agree?
> 
> Yes, but again, only because you can't force everyone to agree with
> you.

Many other OSS projects quite successfully do that,
at least with fuzzy plans.


>>- Modularize the tree, replacing imake with autoconf/automake;
> 
> People are doing this.

I remember reading that there would have been a single maintenance
release of the Xorg tree, and then the modular tree would take
over...


>>- Move away from XAA and redesign driver acceleration around DRI;
> 
> I would posit that Xgl and Mesa-solo are moves towards this direction.

Or maybe KAA?  Both are being worked on at the same time... by
now it should be easy to see which solution is going to offer
the best benefits/cost ratio.


>>- Switch to a MacOSX-like composite rendering model;
> 
> If you're talking about the Composite extension, or Render, this has
> already been done.

That was already done one year ago, but it works for users only
with NVidia's proprietary driver.  As far as I understand, the XAA
drivers can't be easily extended to support accelerated Render
operations needed by Composite.

Both KAA and Xgl+Mesa-solo would solve the problem, but none
has been chosen to be the successor of the current Xorg
server, which brings us back to the original question of this
thread.

>>- Replace the X core graphics with something along the lines
>>  of Render;
> 
> Bzzt.  You don't get to replace X core.  Render being there is enough,
> and it is widely used by things such as GTK+.  So, again, I would posit
> that this has already been done.

AFAIK, Render existed with almost all the current functionality
even in the XFree86 era.  There was some talking about adding
missing primitives to match functionality offered by core
graphics... then Cairo raised as a client-side solution that
only needed a fast trapezoid primitive in Render or even no
Render at all by using Glitz instead.

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.


>>- Provide a high-level vector graphics API for modern
>>  applications (Cairo);
> 
> And this has already been done.

Quite successfully, I'd say.  Kudos!


>>One year has passed and none of these projects is deliverable
>>or even made substantial progress, with the notable exception
>>of Cairo.
> 
> I think that's a load of crap, sorry.

No offense taken... flames are flames :)


> I know just how much progress has been made in the modular tree.
> It was out of sync with the monolithic tree back then, and xlibs
> is now fully synced up.

Granted, but I would have expected the old libX11 in the xorg
tree to rest in peace long time ago while everybody was busy
working on the new xlibs/ right from the start.


> Plus it's bootstrappable from nothing.

I remmeber bootstrapping it several months ago too.


> Debrix didn't exist, so there's a fully modular X server right there,

Sorry, I used to see Debrix, Xserver and Xorg as three forks in
three opposite directions, and that's why I asked.

It's still not clear which one will take over... or is it?


> and indeed -- you mentioned the libdl
> loader change earlier.  This change was proven-in-concept within Debrix
> when the loader was thrown away and replaced with a simple wrapper
> around dlopen.  Adam Jackson did a lot of work on various modules to
> make them safe for the libdl-based loader, and now here we are, in a
> position we weren't previously, where we can avoid the ELF loader in the
> monolithic tree.

Which is a nice improvement... but why is the monolithic tree still
getting any attention?  The point is that the modular Xorg has not
yet been blessed as the main line of development.


> Composite is in Xorg.  It wasn't, previously.  Mesa-solo has made
> terrific progress.

Mesa in general made terrific progress... For many GL applications,
my old 9200 board became twice as fast over the last months 


> You won't get many friends by asserting that work that has been done has
> not, indeed, been done, and will never get done.  Especially if you
> haven't done any work yourself.

I've not exactly said that no work has been done here and that
would indeed be very inappropriate for someone who has never
submitted a patch.

My impression is that this project requires more discussion and
coordination so that valuable work is not wasted by continuously
shifting focus or in competing projects.


>>This is not just because of lack of man-power: the focus seems to
>>have slowly shifted from the original goals to merely maintaining
>>the monolithic tree while at the same time a few developers grow
>>their own X server projects in isolation.
> 
> Bear in mind that, when the X.Org Foundation started, its original
> focus was on the 6.7 release, which was of ... the monolithic tree.

Yes... that came soon after the migration, thus giving Xorg
credibility and authority among all distributors and users
(to be fair, X11R6.7 was already frozen when the Xorg repository
was created).  What was said at that time was that, after the
release, work would have immediately started towards a fully
modular tree.


> Moving to the modular tree does not fix the 'Composite is slow' bug, and
> moving away from XAA isn't something to while away an afternoon with.

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?


>>XOrg's release managers really manage maintenance releases
>>of the monolithic trees.  As I said, they do a good job by
>>providing high-quality stable releases.
> 
> So, er, how do the major releases come about?  How do 6.7 and 6.8, which
> both had major shakeups in their own right, come into existence?

Uh?  6.7 -> 6.8 mostly merged in stuff that already existed in
other repositories (Mesa, Xserver, Xprint...) plus the usual bug
fixes and driver improvements.  It certainly was a big improvement,
but it has subtracted time and resources from the original goals
of providing modular X distribution with an accelerated composite
rendering model.


>>There seems to be little consensus on the future direction
>>of Xorg... forgive me if I'm wrong, that's the impression
>>I get from watching the traffic on the mailing-list and CVS.
> 
> No, and you'll note that there is no release manager for 7.0 yet, so
> there is no-one to set this direction when people are still in
> disagreement.  The process of selecting a release manager is going on
> right now.
> 
> On this very list.

Good... I'm reading.


>>>You do know this has already been done, right?
>>
>>I didn't.  Where is this information available?
> 
> Bugzilla, with default owners for components.  People tend to respect
> that.

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.


>>The code I've seen is quite readable and understandable...
>>No intricate locking and fancy data structures as in the
>>Linux kernel... no complex algorithms and abstractions as
>>in GCC.
> 
> I said 'perceived'.  X is perceived as very hard.

A "make World" takes just a fraction of the time
required by GCC's "make bootstrap".  People should
be told this :-)



>>These would be good janitorial projects for newbies like
>>me, but polishing Xorg this way is useless until it
>>remains undecided which tree will live.
> 
> It's also useless if you spend six months polishing, and realise that
> the rest of the tree hasn't moved in that time.

There's no such thing as a complete halt until everything
is perfectly cleaned up.

Cleaning is something you do day by day along with
regular work (which tends to create more mess to be
cleaned up later).

This is generally considered good practice for any
software project and being 20 years old is no excuse.
GCC is also very old, but has gradually been upgraded
to C89 syntax and to build with -Wall -Werror.

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.


>>Sad, but true... I think people who care about Xorg as a whole
>>should assume leadership and guide the project toward a common
>>direction.
> 
> That's, theoretically, a matter for the architecture board.  People who
> do care are showing direction.  People who care deeply about the
> modular tree are off syncing it with the latest code in the monolithic
> tree, making sure the server compiles and is usable, syncing that back,
> tweaking the build system, et al.  People who care deeply about either
> are arguing feverishly on mailing lists.

:-) Let's just hope the situation will soon improve.

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