Bug 192436 - Review Request: xorg-x11-server-Xgl
Review Request: xorg-x11-server-Xgl
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
:
Depends On: 193804
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-19 14:37 EDT by Alphonse Van Assche
Modified: 2009-04-06 15:08 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-28 11:01:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 192432 None None None Never

  None (edit)
Description Alphonse Van Assche 2006-05-19 14:37:01 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-1.1.99.1-1.src.rpm

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

regards,
Al
Comment 1 Alphonse Van Assche 2006-05-19 14:59:29 EDT
sorry for the request title, the good package name is xorg-x11-server-Xgl.
Comment 2 Rudolf Kastl 2006-05-19 15:40:48 EDT
+ 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.
Comment 3 Rudolf Kastl 2006-05-19 16:24:06 EDT
when trying to rebuild without patches:

make[3]: *** [api_arrayelt.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from accum.h:41,
                 from accum.c:26:
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
strict-aliasing rules
In file included from api_loopback.c:39:
mtypes.h:44:20: error: bitset.h: No such file or directory
Comment 4 Alphonse Van Assche 2006-05-20 10:00:06 EDT
Hi Rudolf,

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

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.




Comment 5 Eric Work 2006-06-01 16:54:20 EDT
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
SRPM URL:
http://www.ece.ucdavis.edu/~ewwork/repo/5/SRPMS/xorg-x11-server-Xgl-0.0.1cvs-1.src.rpm
Comment 6 Eric Work 2006-06-01 16:56:48 EDT
Oh I forgot to add that this package requires that glitz also be installed which
is awaiting review at bug #193804.
Comment 7 Alphonse Van Assche 2006-06-05 07:25:49 EDT
SPEC Url: http://fedoraxgl.tuxfamily.org/repository/5/SPECS/xorg-x11-server-Xgl.spec
SRPM Url:
http://fedoraxgl.tuxfamily.org/repository/5/SRPMS/xorg-x11-server-Xgl-1.1.99.1-4.fc5.src.rpm

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.
-  --enable-xkb.
-  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!
Comment 8 Eric Work 2006-06-05 14:14:21 EDT
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.
Comment 9 Alphonse Van Assche 2006-06-23 13:33:05 EDT
New urls:
http://fedoraxgl.tuxfamily.org/repository/5/SPECS/xorg-x11-server-Xgl.spec
http://fedoraxgl.tuxfamily.org/repository/5/SRPMS/xorg-x11-server-Xgl-1.1.99.2-1.src.rpm

rpmlint output:
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. 

ChangeLog:
- Remove Mesa sources
- bump to 1.1.99.2.76 (ChangeLog cvs version).


Regards,
Alphonse
Comment 10 Alphonse Van Assche 2006-06-29 09:07:06 EDT
(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
bugzilla.
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).

Cheers,
Alphonse
Comment 11 Rick L Vinyard Jr 2006-07-05 09:52:45 EDT
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:
    GdmXserverTimeout=60

Poking around on several Xgl and compiz lists it looks like this is a fairly
common issue.
Comment 12 Alphonse Van Assche 2006-07-06 05:16:02 EDT
(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.

Comment 13 Krzysztof "Uosiu" Hajdamowicz 2006-08-24 13:14:28 EDT
Hi
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:
http://illawarra.org/linux/index.php?id=howto
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
http://en.pastebin.ca/147785
Comment 14 Aurelien Bompard 2006-09-28 12:49:36 EDT
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 :
http://www.fedoraforum.org/forum/showthread.php?t=104404&page=3 )
Any idea in which package those could be ?

Comment 15 Aurelien Bompard 2006-10-08 19:52:20 EDT
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 :
http://gauret.free.fr/fichiers/rpms/fedora/xgl/xorg-x11-server-Xgl.spec.diff

Here are the patches I needed to add to make it compile and work :
http://gauret.free.fr/fichiers/rpms/fedora/xgl/xorg-x11-server-Xgl-1.1.99.1-mesa.patch
http://gauret.free.fr/fichiers/rpms/fedora/xgl/xorg-x11-server-Xgl-1.1.99.1-selinux.patch

I don't have an FC6 system available yet so I can't tell if those are needed on
FC6 too.

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.
Comment 16 Alphonse Van Assche 2006-10-10 10:37:13 EDT
SPEC URL:
http://fedoraxgl.tuxfamily.org/repository/development/SPECS/xorg-x11-server-Xgl.spec
SRPM URL:
http://fedoraxgl.tuxfamily.org/repository/development/SRPMS/xorg-x11-server-Xgl-1.1.99.1-4.fc5.src.rpm

(In reply to comment #15)

- Patches applied.
- Update with last git version. 
- Add some other missing dependencies.
- fix lines size in the spec.

rpmlint output:
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.

Comment 18 Alphonse Van Assche 2007-02-07 16:43:01 EST
SPEC: http://download.tuxfamily.org/fedoraxgl/SPECS/xorg-x11-server-Xgl.spec
SRPM:
http://download.tuxfamily.org/fedoraxgl/SRPMS/xorg-x11-server-Xgl-0-0.2.20070102git.fc6.src.rpm

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



Comment 19 Alphonse Van Assche 2007-02-10 07:00:10 EST
Have forgot to say that libxkbui package must be rebuild.
Comment 20 Ra P. 2007-02-23 17:11:40 EST
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.
Comment 21 Thorsten Leemhuis 2007-02-24 02:42:04 EST
(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
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)?

- 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

- 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)
Comment 22 Alphonse Van Assche 2007-02-24 17:42:03 EST
> - 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

fixed

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

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

fixed
	
The package is build for the moment but i work tomorrow, so i should push it 
after 9h pm.
Comment 23 Justin Conover 2007-02-26 05:03:55 EST
I was able to build the xgl from 02/07/2007

I rebuilt libxkbui from fc5

http://download.fedora.redhat.com/pub/fedora/linux/core/5/source/SRPMS/libxkbui-1.0.1-1.2.src.rpm

This is with ati x1400 and beryl is now working.

Thanks, 

I will keep testing new builds when you have them.
Comment 24 Jonathan Steffan 2007-02-26 12:53:34 EST
(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.
Comment 25 Jonathan Steffan 2007-02-26 15:54:02 EST
Ok. There is a missing buildreq. The spec needs added:

BuildRequires:  libXinerama-devel

http://files.damaestro.us/xgl/

The above packages mockbuild for FC6 (x86) and have been tested.
Comment 26 Alphonse Van Assche 2007-02-26 17:44:50 EST
(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?


Comment 27 Alphonse Van Assche 2007-02-26 17:58:46 EST
SPEC: http://download.tuxfamily.org/fedoraxgl/SPECS/xorg-x11-server-Xgl.spec
SRPM:
http://download.tuxfamily.org/fedoraxgl/SRPMS/xorg-x11-server-Xgl-0-0.3.20070102git.fc6.src.rpm

Have make changes suggested on comment #21, but have not found how to fix the
%post script trick.

Any idea?
Comment 28 Justin Conover 2007-02-26 20:55:56 EST
(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?
> 

vi /usr/bin/startxgl

#!/bin/sh
Xgl :1 -fullscreen -ac -accel xv:pbuffer -accel glx:pbuffer &
DISPLAY=:1
exec dbus-launch --exit-with-session gnome-session

chmod +x /usr/bin/startxgl

vi /usr/share/xsessions/xgl.desktop

[Desktop Entry]
Encoding=UTF-8
Name=Xgl
Comment=Start an Xgl Session
Exec=/usr/bin/startxgl
Icon=
Type=Application


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

Comment 29 Jonathan Steffan 2007-02-26 21:44:39 EST
I made no changes to configure. It builds, but does not work without:

BuildRequires:  libXinerama-devel

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

View
http://files.damaestro.us/xgl/xorg-x11-server-Xgl-0-0.3.20070102git.fc6.src.rpm
for my changes so far. I understand fedora-xgl-settings is obsolete. A new
solution must be setup.
Comment 30 Alphonse Van Assche 2007-03-05 10:06:18 EST
SPEC: http://download.tuxfamily.org/fedoraxgl/SPECS/xorg-x11-server-Xgl.spec
SRPM:
http://download.tuxfamily.org/fedoraxgl/SRPMS/xorg-x11-server-Xgl-0-0.4.20070102git.fc6.src.rpm

Last specfile was not correctly overwrite on the ftp, have make the trick to
quickly, sorry.

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? 

system-config-xselector
SPEC: http://download.tuxfamily.org/fedoraxgl/SPECS/system-config-xselector.spec 
SRPM:
http://download.tuxfamily.org/fedoraxgl/SRPMS/system-config-xselector-0.1-1.src.rpm
RPM:
http://download.tuxfamily.org/fedoraxgl/6/i386/system-config-xselector-0.1-1.noarch.rpm

ps: sorry for not answer quickly but I had hard work these last weeks.

Thanks all,
Comment 31 Jonathan Steffan 2007-03-07 03:22:48 EST
Alphonse,

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.

http://files.damaestro.us/xgl/

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

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.
Comment 32 Alphonse Van Assche 2007-03-07 06:28:38 EST
(In reply to comment #31)
> Alphonse,
Hi Steffan,

> 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 >
%{name}-%{version}-%{release}.tar.bz2

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

Thanks,
Comment 33 Jonathan Steffan 2007-03-08 12:30:48 EST
VCS = Version Control System
Comment 34 Philip Frampton 2007-03-09 18:19:07 EST
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.
Comment 35 Alphonse Van Assche 2007-03-09 18:26:08 EST
Seems to be the problem with the driver fglrx. 

LD_LIBRARY_PATH=/usr/lib compiz --replaces

can solve the trick.
Comment 36 Philip Frampton 2007-03-12 11:33:19 EDT
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.
Comment 37 Patrick Pichon 2007-03-13 10:18:54 EDT
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
last stage.

Which src.rpm should I get ?



Comment 38 Alphonse Van Assche 2007-03-21 10:12:20 EDT
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
session menu
 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.

Try it:
http://download.tuxfamily.org/fedoraxgl/6/i386/system-config-xselector-0.1-1.noarch.rpm

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.

Regards,
Comment 39 Jonathan Steffan 2007-05-23 14:40:14 EDT
Alphonse,

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.
Comment 40 Alphonse Van Assche 2007-05-25 11:15:53 EDT
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.
Comment 41 Kevin Fenzi 2007-06-09 00:22:09 EDT
I'm going to move this back to unassigned so folks know that it's looking for a
reviwer. 
Comment 42 Alphonse Van Assche 2007-06-09 07:47:41 EDT
Thanks!
Comment 43 Jonathan Steffan 2007-06-09 16:08:56 EDT
Alphonse,

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

Disadvantages:

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.
Comment 44 Alphonse Van Assche 2007-06-09 18:32:52 EDT
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)



Comment 45 Jason Tibbitts 2007-06-27 18:03:43 EDT
If this package is going to live in a separate external repository, shouldn't
this ticket be closed?
Comment 46 Steven Garrity 2007-06-27 18:23:54 EDT
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)?
Comment 47 Jason Tibbitts 2007-06-27 18:29:24 EDT
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.
Comment 48 Jonathan Steffan 2007-06-27 20:46:30 EDT
If we can solve how to enable Xgl, putting it in Fedora is fine.
Comment 49 Alphonse Van Assche 2007-06-28 06:55:24 EDT
(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.

Best Regards,
Alphonse
Comment 50 Patrice Dumas 2008-04-30 04:23:13 EDT
(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?
Comment 51 Alphonse Van Assche 2008-04-30 04:43:18 EDT
(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

Thanks!

Comment 52 Patrice Dumas 2008-04-30 18:53:05 EDT
Integration issues:


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

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 
xorg-x11-server?


Packaging issues:

First issue is that the way (the command) to get the source is 
lacking. See:
http://fedoraproject.org/wiki/Packaging/SourceURL

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
not exist
configure: error: Failed to link Mesa source tree.  Please specify a proper path
to Mesa sources, or disable GLX.

$ rpm -q mesa-source
mesa-source-7.1-0.28.fc9.i386
Comment 53 Patrice Dumas 2008-04-30 18:54:05 EDT
Forgot to say that in the README.dist I advocate, you could reuse
a lot from http://gentoo-wiki.com/XGL
Comment 54 Michal Nowak 2008-07-28 10:27:44 EDT
FYI: 

[[
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=d15b3790307053587df8daed1936ff6923881b63
]]

"""
Remove 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
friends.
"""

Is this review worth trying?
Comment 55 Alphonse Van Assche 2008-07-28 11:01:08 EDT
Thanks Michal, I don't had see that... 

We can now happily close this review.

Note You need to log in before you can comment on or make changes to this bug.