LWN.net Logo

Modular X.org / Xgl / Xegl plans

From:  Gustavo Pichorim Boiko <boiko-AT-mandriva.com>
To:  cooker-AT-mandrivalinux.org
Subject:  Modular X.org / Xgl / Xegl plans
Date:  Mon, 13 Feb 2006 15:33:03 -0200
Archive-link:  Article, Thread

Hi all

As some of you already know I'm the new maintainer of X.org. So as I see many 
discussions about Xorg 7.0, Xgl and all this stuff, I thought it was time for 
me to show my plans on that.

X.org
-------
I have already started packaging Xorg 7.0 but I don't have any set of packages 
useful at this moment. The ideas proposed in [1] will certainly be considered 
(as they really make sense) and I'm opened for discussions on what is the 
packaging model that best fits the needs of everybody. 
As some other distro are doing, I think it is a good idea to remove the X11R7 
prefix and start using the xorg stuff in the default prefix (unless someone 
provides good reasons for not doing that).
Colin Guthrie said he was starting to make his own RPMs for that, so I would 
ask him (and everyone interested on having that done as soon as possible) to 
discuss and help (if possible) doing the official Mandriva packages. I want 
to have the Xorg development as open as possible for the community 
contributors.
As I haven't written anything about packaging layout yet, I will adopt [1] as 
the place explaining the model used for modular X.

Xgl
---
Mandriva is not going to officially adopt the Novell Xgl server (Xglx). 
Instead, we are trying to push the Xegl[2] development. It is not a short 
term solution though. The main idea on that is not having an Xorg server 
running behind the Xgl server. EGL[3] is an API for native platform window 
system interface that is used in the Xegl as kind of substitute for GLX 
avoiding the need of another X server running together with Xgl. The main 
problem curently we have is that there is no EGL interface implemented in the 
binary graphics drivers and only some cards have open source 3D acceleration 
support (see the previous thread "Xgl in mandriva?"). 
Even not supporting the Xglx project, some requirements for EGL and GLX are 
the same (like the DRM, glitz, etc), so it won't be that difficult for one to 
try the Xglx code using cooker packages.
For the Xegl, we will try to make everything needed for Xegl 
testing/development available in cooker (or in a separate repository as this 
may require CVS snapshots of xorg, mesa and other libraries) making it easier 
for one to test or even start developing the Xegl.
The same I said for Xorg is valid for Xegl: I want to have the Xegl 
development as open as possible, so feel free to contact me about 
suggestions, bug reports, patches, etc.


[1] http://qa.mandriva.com/twiki/bin/view/Main/ModularX
[2] http://www.freedesktop.org/wiki/Xegl
[3] http://www.khronos.org/egl/

Cheers
-- 
Gustavo Pichorim Boiko
----------------------
boiko @ mandriva . com
Mandriva - http://www.mandriva.com



(Log in to post comments)

Modular X.org / Xgl / Xegl plans

Posted Feb 17, 2006 7:29 UTC (Fri) by hingo (guest, #14792) [Link]

How is the Xgl vs Xegl situation unraveling in general? Will it be Novell vs rest of the world or what is the feeling on mailing lists at the moment?

Modular X.org / Xgl / Xegl plans

Posted Feb 21, 2006 14:02 UTC (Tue) by sylware (guest, #35259) [Link]

A lot of packages for modular X.org... BTW, mozilla should do the same than X.org: clean modularization, GNU autotooled properly.
Back to the real subject :). The deal is we can have a full X server over OpenGL ES/EGL(hum... haven't got the time to read the specs, I base myself only on reports on this subject). The thing is, if we want to keep network transparency, client side, the applications will have to stick to OpenGL GLX.
We can go even further, when network transparency is not needed, to have a desktop directly over OpenGL ES/EGL. Indeed modern graphical applications are relying on toolkits(Qt for C++, GTK for C, etc...) which start to properly abstract X11. We can expect to see mainstream toolkits to have at the end an X11 backend and an OpenGL ES/EGL backend.
BUT: the only normalized ways for applications to hit the 3D GPU will be OpenGL GLX/X11 and OpenGL ES/EGL. So if applications with 3D want to remain compatible with both backends, they will have to maintain 2 code lines for GLX and EGL (erk!!!) OR we should have a *normalized* way to tap in 3D GPUs power on both backends. I think we can slowly but surely see that the need of a kind of 3D support is taking shape for toolkits...

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds