Status of xserver/debrix/modular tree?

[Daniel Stone]

On Fri, Feb 11, 2005 at 12:42:42AM +0100, Bernardo Innocenti wrote:
> Daniel Stone wrote:
> >On Thu, Feb 10, 2005 at 03:32:44AM +0100, Bernardo Innocenti wrote:
> >
> >>So Debrix isn't the successor of the xserver/kdrive repository?
> >>Are these projects intended to live together?  Wouldn't this
> >>require much more maintenance work?
> >
> >They are entirely different projects with entierly different purposes.
> >Debrix was once a subproject of xserver (separate from kdrive), but
> >now it's grown up, moved out of home, is paying its own rent and bills,
> >and has nothing to do with xserver.
> 
> I see there are no drivers in Debrix's copy of xorg.
> Is there another repository or should one use
> preinstalled drivers from the regular xorg tree?
> 
> 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

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

> >You missed the XRX + xterm debate, which included a debate about the
> >future of the monolithic tree?
> 
> 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.

> > How about 'xc/programs considered harmful'?
> 
> I had read this one too, but there wasn't a final decision
> after the discussion.
> 
> 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.

> >There are about three other huge discussions that are hugely
> >relevant to the stuff you're complaining about that apparently
> >hasn't been at all talked about that I can think of.
> 
> 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.

> 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.

> >Yes, and have you ever considered that maybe that has something to do
> >with the amount of people that contribute to the kernel and/or find it
> >'sexy', as opposed to the amount of people that do the same for X.Org?
> >
> >I repeat: X is undermanned.
> 
> I clearly see this.  What I can hardly understand is WHY.
> 
> One may say that hackers are more attracted to kernels
> and development tools than windowing systems, but then
> why are Gnome and KDE so vital?

I don't know, but it's certainly true.

> >The libdl-based loader (it does not load DLLs) has been in the CVS tree
> >for around six years; maybe more.  I think it's been there ever since
> >the MetroLink loader was introduced, anyway.
> >
> >The only change -- and it was a tiny change, given it was like one line
> >in a config file -- was to use it by default.  Some distributions have
> >already done this.
> 
> I see... I remember when XFree86 4.0 introduced the custom
> archive loader.  The original goal was to abstract drivers
> from the underlaying OS and bus.  This way, the same binary
> driver would be portable to any system with the same CPU.
> 
> In practice, existing binary drivers never were made
> portable enough, and sharing open-source drivers between
> two OSes is useless.  I'm glad to kiss goodbye to the
> old self-made elf loader.

I'm largely glad to kiss the ELF loader goodbye, because in all the
glory of making drivers portable across OSes and whatever, they forgot
to make it so everyone could actually use it, ironically.  Loaders were
never written for HPPA, SuperH, and a few other architectures.

> >And, again, this is X being undermanned.  Everyone is busy coding
> >instead of blowing hot air on lists or whatever.
> 
> Coding and coding in different directions without
> a common goal is a very inefficient use of time.
> 
> 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?

> >Yes.  So, clearly, the current system of developer
> >communication is not inherently broken.
> 
> I think Xorg has a good procedure for guiding releases
> and good release managers.  Handling of bugs, patches
> and code reviews is also quite good.
> 
> 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.

> >For X.Org, this is the release manager, and ostensibly the Architecture
> >Board.  In practice, the release manager tends to rubber-stamp the
> >consensus of developers on the lists and conference calls, and the
> >Architecture Board has not decided on anything in months.  Things happen
> >by consensus.
> 
> Hmmm... I clearly remember reading the initial Xorg announcements
> from Keith Packard.  Keith had shown lots of promisign technology
> and set a general direction...
> 
> I'll try to summarize what I remember (my free interpretation):
> 
> - Modularize the tree, replacing imake with autoconf/automake;

People are doing this.

> - Move away from XAA and redesign driver acceleration around DRI;

I would posit that Xgl and Mesa-solo are moves towards this direction.

> - Switch to a MacOSX-like composite rendering model;

If you're talking about the Composite extension, or Render, this has
already been done.

> - 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.

> - Provide a high-level vector graphics API for modern
>   applications (Cairo);

And this has already been done.

> This plan came with nice screenshots of alpha blended windows
> that made many Slashdot readers quite excited :-)
> 
> All these projects were already half-finished in CVS by the time
> Xorg was born.
> 
> 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.  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.  Plus it's
bootstrappable from nothing.  Debrix didn't exist, so there's a fully
modular X server right there, 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.

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

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.

> 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.

> I'm looking forward to see all development stop on xorg/xc and
> everybody contributing to a new X server (thus fixing the
> "Composite is slow" bug ;-)

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.

> >You do know that we have a release manager, right?  Roland Mainz is the
> >6.8.2 release manager.  Who will release-manage 7.0 is as yet undecided.
> 
> 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?

> [snip ramblings]
> 
> This is probably the single largest infrastructure change
> that ever happened in GCC, and it's soon going to be
> released officially.

Er, in that case, congratulations to gcc.  But I don't see how it
applies here.  People do development on branches here if it's too
intrusive (e.g. DAMAGE-XFIXES), and then do merges of those branches
back at strategic times (e.g. DAMAGE-XFIXES).

> >But, as I said, the release manager largely tends to just rubber-stamp
> >existing consensus.
> 
> 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.

> >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.

> >We already do code review, but the problem with this is two-fold.
> >
> >Firstly, if you're raising the barrier to entry any further (the
> >*perceived* barrier to entry is already staggeringly high, not to
> >mention the dual penalty of having a massive tree built by imake),
> >it had better be worthwhile, and the value of this is unclear.
> 
> The Xorg project as a whole appears to be much easier to approach
> than the Linux kernel (technially) and GCC (politically).
> 
> 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.

> 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.

> >X.Org does not have the critical mass of developers needed to make this
> >work.  It would simply slow down the pace of development enough to make
> >it unusable, and in practice, most people don't care about goings-on
> >outside of their particular subsystem.  There are are a few nomads who
> >wander through lots of random X components, but most people just stick
> >to their subsystem, the nomads defer to them, and that's it.
> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20050211/7b2f7f12/attachment.pgp>