Status of xserver/debrix/modular tree?

[Daniel Stone]

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

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

Yeah, it's drm/libdrm in the DRI repository.

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

And, as I said, we are in the process of appointing a release manager
for 7.0.

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

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.

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

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

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

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

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.

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.

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

So, in that case, you are effectively forcing them to leave.

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.

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

6.8.1 was unplanned in its form -- it ended up as a security release,
and 6.8.2 was needed to fix bugs.  Discussion about the next major
release is now occurring, and has been for quite some time.

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

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.

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

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

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

It's not clear to anyone except the toolkit authors, really.

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

You'd think that, wouldn't you ...

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

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.

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

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.

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

I think that this is not as much of a problem as you suspect, although
it could obviously be better..

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

Yes, I remember the calls back in the day when 6.7 was just a stepping
stone to modularity.  *sigh*.

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

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.

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.

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.

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

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.

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

Yes, it would be handy to have.

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

What you have to realise is that a whole stack of the code within X
is dead code that just sort of limps along.  Sometimes someone fixes a
bug, but (especially with the client-side libraries) there is often no
reason to ever touch large swathes of the tree.

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

This would be a very worthwhile tasks; marking functions with various
GCC attributes (noreturn, deprecated, printf, whatever) would also
be awesome.
-------------- 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/a095b757/attachment.pgp>