Red Hat Bugzilla – Bug 192436
Review Request: xorg-x11-server-Xgl
Last modified: 2009-04-06 15:08:33 EDT
Spec URL: http://users.telenet.be/quenta/SPECS/xorg-x11-server-Xgl.spec
SRPM URL: http://users.telenet.be/quenta/repo/xorg-x11-server-Xgl-220.127.116.11-1.src.rpm
Xgl is an Xserver that uses OpenGL for its drawing operations. Some
operations like antialiased font rendering is noticably faster with
this technology, and future graphics hardware might only have support
for 3D operations and no 2D core any more.
For compile xgl, I have only must update xorg-x11-proto-devel from the Tom's srpms.
xorg-x11-proto-devel updated source:
compositeproto - > 0.3
fixesproto - > 4.0
scrnsaverproto - > 1.1.0
For all the others build requieres, I have just recompiler those provided by Tom.
This paquage is based on that proposed by Tom Callaway for FC3TEST3 and that of suse, i have especially use these of suse in order to find a stable version of (compiz, xgl and mesa), packaged by the developer of the program it self.
They are my first paquackages and I need a sponsor.
sorry for the request title, the good package name is xorg-x11-server-Xgl.
+ patch -p0 -b --suffix .maprules-tolower-fix.diff -s
1 out of 1 hunk FAILED -- saving rejects to file xkb/maprules.c.rej
unfortunately i see an error with the patch.
when trying to rebuild without patches:
make: *** [api_arrayelt.lo] Error 1
make: *** Waiting for unfinished jobs....
In file included from accum.h:41,
mtypes.h:44:20: error: bitset.h: No such file or directory
accum.c: In function '_mesa_ClearAccum':
accum.c:50: warning: dereferencing type-punned pointer will break
In file included from api_loopback.c:39:
mtypes.h:44:20: error: bitset.h: No such file or directory
The problem comes from the mesa version, the current version on FC5 does not
contain bitset.h header file. There must be an error with the build of mesa in
ps: I think that the patch must be correct, another persons that me, have build
it for X86_64 and they haven't give any feedback about that.
I have made new SPEC files somewhat based on the ones by Alphonse. These
include a more updated Mesa version. These build fine on both i386 and x86_64
under mock with very minor rpmlint warning.
SPEC URL: http://www.ece.ucdavis.edu/~ewwork/repo/5/SPECS/xgl.spec
Oh I forgot to add that this package requires that glitz also be installed which
is awaiting review at bug #193804.
SPEC Url: http://fedoraxgl.tuxfamily.org/repository/5/SPECS/xorg-x11-server-Xgl.spec
Several changes, some based on the above 'Eric' version.
- update mesa version with this of yesterday. (According to what I read here
http://lists.freedesktop.org/archives/compiz/2006-May/000203.html this version
of mesa would add support for old INTEL i810 cards).
- add Xgl patch for the new mesa version.
- add default gdm configuration in post install.
- add build requiered packages.
- add package documentations.
- always use macro when it is possible.
- --disable-static and remove the line that delele these static libs.
- Remove many pushd and popd stuff.
I think that this version is well cleaned, rpmlint has only problem about the
licence (X11/MIT), but according with what there's in COPYING file, the licence
is not easy to determine.
Thx to Eric for him work!
I am sorry for the confusion about the SPEC files. I should have sent my
changes to Alphonse Van Assche instead of submiting my own. Ignore my SPEC file
and use the one supplied by Alphonse as his is now much better than mine.
W: xorg-x11-server-Xgl invalid-license X11/MIT
W: xorg-x11-server-Xgl spurious-bracket-in-%post
W: xorg-x11-server-Xgl dangerous-command-in-%post cp
The cp command is used for create a .rpmsave file but for the bracket warning, i
did not find from where that came.
- Remove Mesa sources
- bump to 18.104.22.168.76 (ChangeLog cvs version).
(In reply to comment #9)
The xgl package doesn't not build with last rawhide mesa package because
rbadaptors.c, rbadaptors.h, bitset.h (there are provide in mesa 6.5 cvs HEAD)
files are not present in the mesa-source package.
I have many idea to resolve this problem but i ask you to have the best practice
to do that.
1. Ask mesa maintainers to add these files to de current rawhide sources.
2. Make a patch to add these files to the sources, and create a new request on
3. Create a package (with dependencie on mesa-source) that add xgl requieres
sources to the current mesa sources directory. ( i think, that's a dirty way).
Just an operability comment...
I'm not sure how many others may be having trouble with these packages, but at
first I couldn't get gdm to start with Xgl.
The problem was that Xgl was taking too long to start and gdm was timing out.
The (simple) solution was to put the following line in /etc/gdm/custom.conf
after the [daemon] line:
Poking around on several Xgl and compiz lists it looks like this is a fairly
(In reply to comment #11)
Yes, it is a known solution for launching KDE from GDM.
Considering that this solution requires changes in a config file of a core
package, we wait until the package is reviewed for asking Core packages to apply
a patch to do that.
I would like to ask about progress of work with this package, I have a hope
that it'll be ready to include it into FC6 to extras repository
additionally I want to report a bug in XGL
I have problem with XGL in KDE with compiz installed with this tutorial:
The problem is Polish letters- shortcuts for XGL are
- Left Shif
- Left Ctrl
- Left Alt,
but right alt is locked too, so I can't write polish characters.
my Xorg.conf is
[uosiu@uosiumen ~]$ pastebin /etc/X11/xorg.conf
The build fails with :
hw/dmx/doc/Makefile.am:24: BUILD_LINUXDOC does not appear in AM_CONDITIONAL
hw/dmx/doc/Makefile.am:27: BUILD_PDFDOC does not appear in AM_CONDITIONAL
hw/xfree86/doc/sgml/Makefile.am:24: BUILD_LINUXDOC does not appear in AM_CONDITIONAL
hw/xfree86/doc/sgml/Makefile.am:27: BUILD_PDFDOC does not appear in AM_CONDITIONAL
autoreconf: automake failed with exit status: 1
in %prep. The net says there should be additional Xorg macros installed (eg :
Any idea in which package those could be ?
OK, I finally got it to build and run properly on FC5.
Here's what I had to do :
- backport libdrm, mesa and xorg-x11-proto-devel from FC6
- add a few missing buildrequires
- patch Xgl for the new mesa files and a missing library
The necessary backports make it impossible to add this rpm in FC5. In FC6
however, it can be done.
Here's a diff to the specfile, I've added the missing BRs, and changed a few
lines to be more fedora-policy-complient :
Here are the patches I needed to add to make it compile and work :
I don't have an FC6 system available yet so I can't tell if those are needed on
I'll build it in mock to see if there are more missing BuildRequires.
Right now it works fine, except one small problem : my keyboard layout is
broken, I need to run xmodmap on each session startup to fix it.
(In reply to comment #15)
- Patches applied.
- Update with last git version.
- Add some other missing dependencies.
- fix lines size in the spec.
W: xorg-x11-server-Xgl invalid-license X11/MIT (this may be ignored according
with a discuse on irc with jima and delero, it'a rpmlint bug)
W: xorg-x11-server-Xgl dangerous-command-in-%post cp (create .rpmnew file)
> Right now it works fine, except one small problem : my keyboard layout is
> broken, I need to run xmodmap on each session startup to fix it.
Same problem on FC6 with the last git update.
- The keyboard layout is now correctly mapped!
- Add of a quick faq and a small but useful script to workaround some Xgl
limitations. (like play OpenGL based games)
Have forgot to say that libxkbui package must be rebuild.
It would be nice if someone could get this working with Fedora, as currently the
only way for ATI X200M owners to have dri is to use ATI's fglrx driver, and the
only way to have a 3D desktop is to use fglrx + xgl.
(In reply to comment #20)
> It would be nice if someone could get this working with Fedora
Then help reviewing (even if you are not a contributor yet).
This is not a full review, but there are some obvious things that need to be fixed:
- The files
need a xorg-x11-server-Xgl- prefix and get renamed to their final names during
install (that's done already), as other source packages that people might
install in parallel could contain files with the same filenames
# remove uneeded files
needs a more verbose comment -- why are all of those unneeded (it's obvious for
the .la files, but not for the rest)?
- the %post script looks just crazy -- sorry, but such things are frowned upon
and should be avoided as much as possible. They might be needed in some very
rare situations, but then they need a comment. I don't think they are needed here
%defattr(-, root, root)
%defattr(-, root, root, -)
- and how does one check out the snapshot to check that the code actually
matches upstream? Needs a comment, too. (/me curses stupid upstream projects
that have no proper release scheme)
> - The files
> Source1: noXgl
> Source2: README.Fedora
> need a xorg-x11-server-Xgl- prefix and get renamed to their final names during
> install (that's done already), as other source packages that people might
> install in parallel could contain files with the same filenames
> - this
> # remove uneeded files
> needs a more verbose comment -- why are all of those unneeded (it's obvious for
> the .la files, but not for the rest)?
comment "these file are already provided by the Xorg package", is that enough?
> - the %post script looks just crazy -- sorry, but such things are frowned upon
> and should be avoided as much as possible. They might be needed in some very
> rare situations, but then they need a comment. I don't think they are needed here
Have move the launch of XGL to xsessions, but the problem is that it's necessary
to add a .desktop file by WM and I am not sure is that well.
Any other idea?
> - This
> %defattr(-, root, root)
> should be
> %defattr(-, root, root, -)
> - and how does one check out the snapshot to check that the code actually
> matches upstream? Needs a comment, too. (/me curses stupid upstream projects
> that have no proper release scheme)
The package is build for the moment but i work tomorrow, so i should push it
after 9h pm.
I was able to build the xgl from 02/07/2007
I rebuilt libxkbui from fc5
This is with ati x1400 and beryl is now working.
I will keep testing new builds when you have them.
(In reply to comment #23)
> I was able to build the xgl from 02/07/2007
Did you use mock? When I mockbuild this srpm I end up missing
/usr/lib/xorg/modules/xgl/libxglx.so and Xgl then does not work. If you did not
use mock, would you please:
rpm -qa|grep devel
> This is with ati x1400 and beryl is now working.
How are you starting Xgl?
Also, I have made the suggested changes to the spec per comment #21. I don't
want to step on the package owners toes and publish my changes.
Ok. There is a missing buildreq. The spec needs added:
The above packages mockbuild for FC6 (x86) and have been tested.
(In reply to comment #25)
> Ok. There is a missing buildreq. The spec needs added:
> BuildRequires: libXinerama-devel
Strange, it build in mock here without that.
Have you make change in %configure?
Have make changes suggested on comment #21, but have not found how to fix the
%post script trick.
(In reply to comment #24)
> (In reply to comment #23)
> > I was able to build the xgl from 02/07/2007
> Did you use mock? When I mockbuild this srpm I end up missing
> /usr/lib/xorg/modules/xgl/libxglx.so and Xgl then does not work. If you did not
> use mock, would you please:
> rpm -qa|grep devel
I used "rpmbuild -ba" against the spec file, if there are missing deps it will
tell you what you need (buildreqs) and then yum install those. Everything is in
FC6/extras except for libxbui but I rebuilt the spec file from FC5 just fine.
> > This is with ati x1400 and beryl is now working.
> How are you starting Xgl?
Xgl :1 -fullscreen -ac -accel xv:pbuffer -accel glx:pbuffer &
exec dbus-launch --exit-with-session gnome-session
chmod +x /usr/bin/startxgl
Comment=Start an Xgl Session
> Also, I have made the suggested changes to the spec per comment #21. I don't
> want to step on the package owners toes and publish my changes.
I made no changes to configure. It builds, but does not work without:
Also, your latest spec does not include all of the changes from comment #21.
a) Remove everything you have from %post. This should be done completely different.
b) Name your Source files correctly.
c) Update your comment as to why # remove uneeded files
d) Comment how you build the source tar.
e) Update your %defattr
There is more. This is a good start. I will be working on suggested changes here
for my changes so far. I understand fedora-xgl-settings is obsolete. A new
solution must be setup.
Last specfile was not correctly overwrite on the ftp, have make the trick to
Change between 0-3 and 0-4
- Add BR suggested by Steffan and remove the %post script.
Sometimes ago, I have wrote (just for the fun) a simple tools to configure the
system to choice a Xorg "implementation".
Today , I have implement support to add a server definitions for Xgl in GDM, the
idea is to use this tools in the posts script.
What do you thing of such a solution to replace the crazy post script?
ps: sorry for not answer quickly but I had hard work these last weeks.
Please take a look at what I have done. I think at this point it might be best
if we collaborate on getting this packaged and reviewed.
Per "What do you thing of such a solution to replace the crazy post script?",
please take a look at what has been done in Xgl-settings.
These packages have been testing on FC6 and are working very well. I have been
using them for over a week now and no issues. I have a personal use for XGL as
my laptop has ATi and there still is no GLX_EXT_texture_from_pixmap support in
fglrx. My Xpress 200M is also not supported by the raedon driver.
I think the next step is to make sure we are both not duplicating work. If we
need to setup a VCS for this, let's do it.
Some things to be done:
Per comment #20, we need to make sure we comment how to checkout the source from
upstream. This means we need to be able to git-clone something such as a tag or
We should also look to get these package not only building on FC6, but on
rawhide also. Last test showed these do not build on rawhide.
(In reply to comment #31)
> Per "What do you thing of such a solution to replace the crazy post script?",
> please take a look at what has been done in Xgl-settings.
There is some problem with this type of solution,
so I'm not sure if such a solution can be approved by a reviewer.
1. Traditionally X is started on the display :0, but that is not possible if we
start Xgl from GDM (dislay :0 should already used by GDM)
2. There are 3 log files for X (Xorg.0.log, Xorg.1.log and Xorg.93.log) that
should appear strange for the end user.
3. For each WM available for fedora, we needs a .desktop file (GDM session menu
can quickly look too big)
I we start GDM with Xgl all these problem can be forgotten.
> I think the next step is to make sure we are both not duplicating work. If we
> need to setup a VCS for this, let's do it.
I am not a partisan of duplicate work too ;)
Sorry for my ignorance, but what is VCS?
> Per comment #20, we need to make sure we comment how to checkout the source from
> upstream. This means we need to be able to git-clone something such as a tag or
> a revision.
Last specfile contain this line, is that not enough?
# git tar-tree xgl-0-0-1 xorg-x11-server-Xgl | bzip2 >
> We should also look to get these package not only building on FC6, but on
> rawhide also. Last test showed these do not build on rawhide.
Personally, I have not enough internet band-width to download and to keep
up-to-date more than one branch at once.
If you can take a look on the rawhide problem, it should be very appreciated.
VCS = Version Control System
I installed the xgl server, libxkbgui and xgl-settings from the location in
comment #31 but I can't get it to work with the current compiz in FC6. I've got
an ATI 200M with 8.34 drivers. The error is:
[user@localhost ]$ compiz --replace
compiz: GLX_SGIX_fbconfig is missing
compiz: Failed to manage screen: 0
compiz: No manageable screens found on display :0.0
but glxinfo |grep GLX_SGIX_fbconfig shows it is there.
Any help very welcome.
Seems to be the problem with the driver fglrx.
LD_LIBRARY_PATH=/usr/lib compiz --replaces
can solve the trick.
I'll try that later. I can report it works well with beryl - have been testing
it over the weekend. One possible bug, which I will cross check when I try
xgl/compiz, is that xgl/beryl sometime repeats keys - eg Ctrl+T in firefox
sometimes open tens of new windows, Ctrl+Alt+Left can sometimes send the cube
spinning around. It always recovers in the end though.
I'm willing to help in this area, since I have a laptop with a ATI X1300 graphic
card and it doesn't support AIGLX. In such, I would like to get the Xgl enabled
on my fedora Core 6.
I tried to go through the all comments, but didn't really find a summary of the
Which src.rpm should I get ?
Well, this review become too long and it's not easy to know what's up in the
current state, so I will try to summary the problem.
The specfile follow the packaging guide line, and seem to be clean. The only
blocker that stay is "howto start Xgl". There is two solutions to launch Xgl and
we must choice one.
Start Xgl from GDM (session menu)
(+) The login time is shorter (last Xorg improvement)
(+) Can choice a X type before login
(-) Traditionally X is started on the display :0, but that is not possible if we
start Xgl from GDM (dislay :0 should already used by GDM)
(-) There are 3 log files for X (Xorg.0.log, Xorg.1.log and Xorg.93.log) that
should appear strange for the end user.
(-) For each WM available available on fedora, we needs a .desktop file (GDM
can quickly look too long)
(-) two X are loaded at boot time + 1 if rgbd is used (graphical boot).
Try it: http://files.damaestro.us/xgl/Xgl-settings-0.1-3.fc6.noarch.rpm
Start GDM with Xgl
(+) do not have any of (-) thing of the first solution.
(-) The only thing that I see is that the login take more time between the
username input and the password input.
IMHO, If we *really* want to fix that immediately, we can just add a procedure
in the Fedora.README file. I don't thing that a tools to do that simple trick is
absolutely require for inclusion in the repo.
reply on comment#36: seem to be a beryl bug (have the same trick here with beryl)
reply on comment#37: the two tools configure the system differently, but the
srpms are the same.
ps: If somebody can make a try on rawhide and send the log error here so that
more people can take a look, it should be really useful.
Sorry, I have not had much free time for Xgl. I'll spend a little time on it
today and build on rawhide. I wont be able to test the packages as I don't have
a rawhide machine with ATi hardware (that is not virtual.) I will, however, put
them up for download. I am going to also work to update the source version we
are building from.
I will also take a look at system-config-xselector and see what magic it provides.
FYI, the sources have not be changed, you don't have to re-checkout it.
I send you the last SRPM (with your last modifications) on your private mail.
I'm going to move this back to unassigned so folks know that it's looking for a
After some discussion about Xgl and why we are working to make it usable, it
seems the best place for Xgl is going to be a 3rd party repo. Really, the best
solution for providing the features that Xgl provides is aiglx. I understand the
reasoning behind why Xgl is still currently needed. Please comment on moving
things to Livna (my choice would be at least) and closing this bug.
Advantages to Livna:
1) No resistance to this package from within the Fedora dev world
2) No bugs on the fedora bugzilla, so no additional overhead for the Fedora devs
3) Ability to use livna-config-display vs yet another package
4) Existing trusted 3rd party repo that is enabled on a lot of systems
5) Existing infrastructure to support collaborative maintenance of the package
6) Livna already packages fglrx
1) It's Xgl, we want a good solution... such as aiglx
2) It does not get the "Fedora" stamp, which might end up being more good then bad
3) Less of a mirror infrastructure, but really... not that big of a deal
I've maybe missed some +- stuff, but I do think we should move this to livna.
Livna contain non free software that cannot be include in Fedora because of
license so IMO Xgl is not a good pace for a free software. The only free
software on livna is livna-config-display (not entirely sure about that).
Fedora provide many soft that do the same stuff, personally I like that and
don't see it like a problem.
Like we have discus in private, I would prefer make a dedicate repo for Xgl and
like you know, your are welcome to help and we are already working in that way
at the moment.
http://fedoraxgl.tuxfamily.org (web site -- must be updated)
http://download.tuxfamily.org/fedoraxgl (the repo)
If this package is going to live in a separate external repository, shouldn't
this ticket be closed?
Is there a policy that would preclude XGL from being included in the Fedora
repos? If not, how is this any different from having both Gnome and KDE
available (especially since there is some hardware that cannot run AIGLX)?
The submitter says he wants to put it in an external repository. That's up to
him; if you want to submit this to Fedora then I guess that would be up to you.
If we can solve how to enable Xgl, putting it in Fedora is fine.
(In reply to comment #47)
> The submitter says he wants to put it in an external repository. That's up to
> him; if you want to submit this to Fedora then I guess that would be up to you.
I have update the external repo because of the fact that this package is still
here for review from about one year now without any interest from any reviewers.
To unblock the situation I had send a mail on the fedora-packaging ml and nobody
have show any interest there too, so I have updated the external repo.
(In reply to comment #48)
> If we can solve how to enable Xgl, putting it in Fedora is fine.
There is a good solution for that. Starting Xgl using GDM, all is there for a
while now, you have never reply to comment #38, this should be a begin to
unblock the situation.
(In reply to comment #49)
> (In reply to comment #47)
> > The submitter says he wants to put it in an external repository. That's up to
> > him; if you want to submit this to Fedora then I guess that would be up to you.
> I have update the external repo because of the fact that this package is still
> here for review from about one year now without any interest from any reviewers.
> To unblock the situation I had send a mail on the fedora-packaging ml and nobody
> have show any interest there too, so I have updated the external repo.
I think it is right to provide a package under review in a different repo
to have people be albe to test it, especially for that kind of package
which requires work to be integrated. But this package should definitely
be in fedora and properly integrated.
> (In reply to comment #48)
> > If we can solve how to enable Xgl, putting it in Fedora is fine.
> There is a good solution for that. Starting Xgl using GDM, all is there for a
> while now, you have never reply to comment #38, this should be a begin to
> unblock the situation.
I'll try to have a look over the next week, or if I can't in the next month.
Do the solutions proposed above fit other display managers, especially kdm?
(In reply to comment #50)
> I'll try to have a look over the next week, or if I can't in the next month.
> Do the solutions proposed above fit other display managers, especially kdm?
Yes you can see a example on how to run xgl from kdm in livna-config-display
Are you meaning that livna-config-display should be used instead of
system-config-xselector or Xgl-settings?
Anyway a graphical application to switch is not necessarily required
for the review of this package. However, it would be nice to have
instructions on how to enable Xgl (in gdm, xdm) manually by editing
the relevant config files, with command line options that are standard,
also with reference to the other packages that allow to set up Xgl
(livna-config-display, system-config-xselector and/or Xgl-settings).
This could be explained in a file named README.dist for example (it is
better to avoid using 'Fedora' such that it is easier to reuse the
The current README.Fedora should certainly be renamed along
README.noXgl since it is basically the noXgl documentation.
It is wrong to call system-config-xselector to set things automatically.
The user should do it himself.
It is also wrong to depend on a Xgl selector package.
I am not sure, but shouldn't xorg-x11-server-Xgl depend on
First issue is that the way (the command) to get the source is
The BuildRequires: libxkbui-devel doesn't exist on rawhide.
Also the build fail on rawhide:
checking for GL... yes
Creating destination directories for mesa module ...
error: Source directory /usr/share/mesa/source/src/mesa/array_cache does
configure: error: Failed to link Mesa source tree. Please specify a proper path
to Mesa sources, or disable GLX.
$ rpm -q mesa-source
Forgot to say that in the README.dist I advocate, you could reuse
a lot from http://gentoo-wiki.com/XGL
This code hasn't been updated with anything even resembling what anyone is
shipping in nearly thirty months. It hasn't built out of the box since
7.1. Most of its features over AIGLX are accomplished with DRI2 and
Is this review worth trying?
Thanks Michal, I don't had see that...
We can now happily close this review.