Hi,
As some of you may know, Soeren Sandmann, Kristian Hogsberg, Adam Jackson, and Kevin Martin have been working on getting special effects into the desktop. While all their work is in CVS, it's a little hard to set up, so I thought I'd make packages for people who have wanted to try the stuff but haven't wanted to spend a lot of time recompiling everything.
Note it's still takes some effort to get a workable setup and for a lot of people things won't work at all.
Testing has been mostly done on radeon 7500 (r100) cards. Other cards probably won't work (but you can still try!).
Steps to test:
1) get the packages from http://people.redhat.com/rstrode/bling If you point yum to it by creating a repo file in /etc/yum.repos.d, you should be able to do something like:
yum install mesa-libGL xorg-x11-server-Xair spififity
This will install a specially compiled version of Xorg that supports accelerated indirect rendering which is the key to making the compositing manager have a reasonable frame rate. Eventually these changes will go into the main Xorg package.
The above yum install command will also install a version of metacity with its compositing manager code turned on. I called the package spififity so that we can parallel install it with the non-compositing manager version of metacity.
2) Configure gdm to use the accelerated indirect compiled version of Xorg. You can probably do something like:
sed -i -e 's/Xorg/Xair/g' /usr/share/gdm/config/gdm.conf-custom
to make that happen.
3) Configure your X server to not use offscreen pixmaps. Strictly speaking this step is optional, but it should dramatically increase performance. You can do that by adding Option "XAANoOffscreenPixmaps" to the "Device" section of your /etc/X11/xorg.conf file. Some people have reported that this option actually breaks things for them, so you may have to try it with and without.
4) Configure your X server to enable the composite extension. You can do that by adding
Section "Extensions" Option "Composite" EndSection
to your /etc/X11/xorg.conf
5) restart gdm.
6) Log into GNOME, press alt-f2 to get a run dialog to come up and then type spififity --replace and press enter.
At this point you may see drops shadows, fading menus and wobbly minimization effects or your system may freeze or one followed by the other.
If you see drop shadows and a bunch of solid white windows, you probably aren't running the right X server. Make sure you're running Xair and not Xorg.
If after using things for a while all your window borders disappear, you may have better luck by setting the METACITY_SYNC environment variable to 1 and rerunning spififity. Setting the environment variable incurs a minor performance hit, but it will also mask a lingering bug in the compositing manager code.
Things are still quite raw, so expect things to crash, your system to lock up, effects to be unpolished, etc.
--Ray
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
- get the packages from http://people.redhat.com/rstrode/bling
If you point yum to it by creating a repo file in /etc/yum.repos.d, you should be able to do something like:
This should be http://people.redhat.com/rstrode/bling/$basearch
On 2/8/06, Jesse Keating jkeating@j2solutions.net wrote:
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
- get the packages from http://people.redhat.com/rstrode/bling
If you point yum to it by creating a repo file in /etc/yum.repos.d, you should be able to do something like:
This should be http://people.redhat.com/rstrode/bling/$basearch
-- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBD6sNd4v2HLvE71NURAu8SAJ90WXvWuxZ4PIjCbGTul9TiVTNZSQCgnLKx UiB1ai9Q0LGYPy0RKTMvZJ0= =Litk -----END PGP SIGNATURE-----
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
First victim to try and fail :)
cat spififity.sh #!/bin/bash METACITY_USE_LOGFILE=1 METACITY_VERBOSE=1 METACITY_SYNC=1 spififity --replace
$ sh spififity.sh Opened log file /tmp/metacity-6320-debug-log-KGfE0w Xlib: extension "GLX" missing on display ":0.0". spififity.sh: line 2: 6320 Trace/breakpoint trap METACITY_USE_LOGFILE=1 METACITY_VERBOSE=1 METACITY_SYNC=1 spififity --replace
/tmp/meta* attached.
Not sure I understand why GLX is missing? I do have the "closed nvidia drivers" running. (maybe not correctly from the looks of it)
On 2/8/06, Justin Conover justin.conover@gmail.com wrote:
On 2/8/06, Jesse Keating jkeating@j2solutions.net wrote:
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
- get the packages from http://people.redhat.com/rstrode/bling
If you point yum to it by creating a repo file in /etc/yum.repos.d,
you
should be able to do something like:
This should be http://people.redhat.com/rstrode/bling/$basearch
-- Jesse Keating RHCE ( geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub )
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBD6sNd4v2HLvE71NURAu8SAJ90WXvWuxZ4PIjCbGTul9TiVTNZSQCgnLKx UiB1ai9Q0LGYPy0RKTMvZJ0= =Litk -----END PGP SIGNATURE-----
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
First victim to try and fail :)
cat spififity.sh #!/bin/bash METACITY_USE_LOGFILE=1 METACITY_VERBOSE=1 METACITY_SYNC=1 spififity --replace
$ sh spififity.sh Opened log file /tmp/metacity-6320-debug-log-KGfE0w Xlib: extension "GLX" missing on display ":0.0". spififity.sh: line 2: 6320 Trace/breakpoint trap METACITY_USE_LOGFILE=1 METACITY_VERBOSE=1 METACITY_SYNC=1 spififity --replace
/tmp/meta* attached.
Not sure I understand why GLX is missing? I do have the "closed nvidia drivers" running. (maybe not correctly from the looks of it)
Oh, I should mention that it sort of works ;)
I do get some drop shadow effects but before I run it, on one screen (twinview) I have 2 terminals open and the left screen has firefox open. They lock in place and wont move and gnome-panel does disappear.
metacity --replace
Brings me back to normal
On 2/8/06, Justin Conover justin.conover@gmail.com wrote:
On 2/8/06, Justin Conover justin.conover@gmail.com wrote:
On 2/8/06, Jesse Keating < jkeating@j2solutions.net> wrote:
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
- get the packages from http://people.redhat.com/rstrode/bling
If you point yum to it by creating a repo file in /etc/yum.repos.d,
you
should be able to do something like:
This should be http://people.redhat.com/rstrode/bling/$basearch
-- Jesse Keating RHCE ( geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub )
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBD6sNd4v2HLvE71NURAu8SAJ90WXvWuxZ4PIjCbGTul9TiVTNZSQCgnLKx UiB1ai9Q0LGYPy0RKTMvZJ0= =Litk -----END PGP SIGNATURE-----
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
First victim to try and fail :)
cat spififity.sh #!/bin/bash METACITY_USE_LOGFILE=1 METACITY_VERBOSE=1 METACITY_SYNC=1 spififity --replace
$ sh spififity.sh Opened log file /tmp/metacity-6320-debug-log-KGfE0w Xlib: extension "GLX" missing on display ":0.0". spififity.sh: line 2: 6320 Trace/breakpoint trap METACITY_USE_LOGFILE=1 METACITY_VERBOSE=1 METACITY_SYNC=1 spififity --replace
/tmp/meta* attached.
Not sure I understand why GLX is missing? I do have the "closed nvidia drivers" running. (maybe not correctly from the looks of it)
Oh, I should mention that it sort of works ;)
I do get some drop shadow effects but before I run it, on one screen (twinview) I have 2 terminals open and the left screen has firefox open. They lock in place and wont move and gnome-panel does disappear.
metacity --replace
Brings me back to normal
Alright, still broke but I verified I am using Xair, by
rm /usr/bin/X ln -s /usr/binXair /usr/bin/X
X -version
Didn't seem to show a change so I just did it that way for now, easy to change back.
Guess I need to figure out why GLX isn't working right atm.
On Wed, 2006-02-08 at 22:32 -0600, Justin Conover wrote:
Not sure I understand why GLX is missing? I do have the "closed nvidia drivers" running. (maybe not correctly from the looks of it)
Ray should have probably mentioned that these rpms are known not to work with nvidia cards at this time. This is because the compositing manager in spififity relies on a new X extension that is not supported by the the nvidia drivers.
Matthias
On Wed, 2006-02-08 at 22:32 -0600, Justin Conover wrote:
Not sure I understand why GLX is missing? I do have the "closed nvidia drivers" running. (maybe not correctly from the looks of it)Ray should have probably mentioned that these rpms are known not to work with nvidia cards at this time. This is because the compositing manager in spififity relies on a new X extension that is not supported by the the nvidia drivers.
I guess the ATI drivers are in the same boat as this?
Hi,
Not sure I understand why GLX is missing? I do have the "closed nvidia drivers" running. (maybe not correctly from the looks of it)
Sorry. I should have mentioned this won't work with nvidia at all at this point.
The closed drivers are missing a needed extension, and the open drivers don't have 3d, I think.
--Ray
On 2/8/06, Ray Strode rstrode@redhat.com wrote:
Hi,
Not sure I understand why GLX is missing? I do have the "closed nvidia drivers" running. (maybe not correctly from the looks of it)
Sorry. I should have mentioned this won't work with nvidia at all at this point.
The closed drivers are missing a needed extension, and the open drivers don't have 3d, I think.
--Ray
grep GLX Xorg.0.log
(II) Loading extension GLX (II) Loading extension NV-GLX (EE) GLX is not supported with the Composite extension
Yeah, just found that out, what a bummer ;(
Well, I'll try it on my laptop with an ati card tomorrow.
Justin Conover wrote:
On 2/8/06, *Ray Strode* <rstrode@redhat.com mailto:rstrode@redhat.com> wrote:
Hi, > Not sure I understand why GLX is missing? I do have the "closed > nvidia drivers" running. (maybe not correctly from the looks of it) Sorry. I should have mentioned this won't work with nvidia at all at this point. The closed drivers are missing a needed extension, and the open drivers don't have 3d, I think. --Raygrep GLX Xorg.0.log (II) Loading extension GLX (II) Loading extension NV-GLX (EE) GLX is not supported with the Composite extension
Yeah, just found that out, what a bummer ;(
Well, I'll try it on my laptop with an ati card tomorrow.
adding Option "AllowGLXWithComposite" "1" to your device section might help
ons, 08 02 2006 kl. 23:05 -0500, skrev Ray Strode:
When trying to run this I get the following error message:
spififity: error while loading shared libraries: libGL.so.1: cannot enable executable stack as shared object requires: Permission denied
according to Google this is because there are known textrels in the DSO and chcon system_u:object_r:texrel_shlib_t /usr/lib/libGL.so.1
should fix it, however it doesn't.
Anyone have an idea as to an easy fix?
- David
On Thu, Feb 09, 2006 at 06:16:11AM +0100, David Nielsen wrote:
ons, 08 02 2006 kl. 23:05 -0500, skrev Ray Strode:
When trying to run this I get the following error message:
spififity: error while loading shared libraries: libGL.so.1: cannot enable executable stack as shared object requires: Permission denied
according to Google this is because there are known textrels in the DSO and chcon system_u:object_r:texrel_shlib_t /usr/lib/libGL.so.1
should fix it, however it doesn't.
Anyone have an idea as to an easy fix?
Try "setsebool allow_execstack 1". This will take effect until you reboot.
HTH,
Nalin
Dnia 02/09/2006 06:17 AM, Użytkownik David Nielsen napisał:
spififity: error while loading shared libraries: libGL.so.1: cannot enable executable stack as shared object requires: Permission denied
according to Google this is because there are known textrels in the DSO and chcon system_u:object_r:texrel_shlib_t /usr/lib/libGL.so.1
You confused text relocations with executable stack. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178262
Nalin showed you the proper workaround :)
On Thu, Feb 09, 2006 at 06:16:11AM +0100, David Nielsen wrote:
ons, 08 02 2006 kl. 23:05 -0500, skrev Ray Strode: When trying to run this I get the following error message:
spififity: error while loading shared libraries: libGL.so.1: cannot enable executable stack as shared object requires: Permission denied
according to Google this is because there are known textrels in the DSO and chcon system_u:object_r:texrel_shlib_t /usr/lib/libGL.so.1
should fix it, however it doesn't.
Anyone have an idea as to an easy fix?
I suggested enabling allow_execstack before, but dwalsh set me straight. The SELinux type on /usr/bin/Xair should match that of /usr/bin/Xorg (which can already use an executable stack), so chcon -t xserver_exec_t /usr/bin/Xorg is the more correct way to fix this.
Cheers,
Nalin
Hi,
I suggested enabling allow_execstack before, but dwalsh set me straight. The SELinux type on /usr/bin/Xair should match that of /usr/bin/Xorg (which can already use an executable stack), so chcon -t xserver_exec_t /usr/bin/Xorg is the more correct way to fix this.
Thanks Nalin. Presumably you mean /usr/bin/Xair, of course.
--Ray
I updated my Xair packages today. Everything was working before, but now at login to GNOME, it hangs at "Window Manager" on the splash screen. Logging into KDE works fine. Changing "aixgl" to "Standard" in the Security tab of the Login program in the Administration menu didn't fix anything. I'm not really sure what to do to make GNOME start working again.
As a side note, assuming I get this working, how do I toggle between the main wobbly minimize and the second one with the demo video on the wiki?
Thanks,
Chris Kurecka
On 2/20/06, Chris Kurecka ckurecka@gmail.com wrote:
I updated my Xair packages today. Everything was working before, but now at login to GNOME, it hangs at "Window Manager" on the splash screen. Logging into KDE works fine. Changing "aixgl" to "Standard" in the Security tab of the Login program in the Administration menu didn't fix anything. I'm not really sure what to do to make GNOME start working again.
As a side note, assuming I get this working, how do I toggle between the main wobbly minimize and the second one with the demo video on the wiki?
As a follow-up to my own email, it appears it has to do with selinux. Doing "setsebool allow_execstack 1" from the command line before logging into GNOME fixes it, but chcon -t xserver_exec_t /usr/bin/Xair doesn't. I'm still curious about a real fix for this, and how to do the other minimization effect if anyone knows.
Thanks,
Chris Kurecka
I have read in the wiki that it does not work on 64bit systems... why? which kind of bug does prevent it from working?
On Tuesday 21 February 2006 11:16, Nalin Dahyabhai nalin@redhat.com wrote:
I suggested enabling allow_execstack before, but dwalsh set me straight. The SELinux type on /usr/bin/Xair should match that of /usr/bin/Xorg (which can already use an executable stack), so chcon -t xserver_exec_t /usr/bin/Xorg is the more correct way to fix this.
Is Xair an X server? If not then assigning that type isn't the correct solution, even though it may work.
On Wed, 2006-02-22 at 11:16 +1100, Russell Coker wrote:
On Tuesday 21 February 2006 11:16, Nalin Dahyabhai nalin@redhat.com wrote:
I suggested enabling allow_execstack before, but dwalsh set me straight. The SELinux type on /usr/bin/Xair should match that of /usr/bin/Xorg (which can already use an executable stack), so chcon -t xserver_exec_t /usr/bin/Xorg is the more correct way to fix this.
Is Xair an X server? If not then assigning that type isn't the correct solution, even though it may work.
Yes, it is an X server.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a witless guerilla waffle chef who must take medication to keep him sane. She's a wealthy red-headed snake charmer who inherited a spooky stately manor from her late maiden aunt. They fight crime!
On Wednesday 22 February 2006 20:21, Alexander Larsson alexl@redhat.com wrote:
On Wed, 2006-02-22 at 11:16 +1100, Russell Coker wrote:
On Tuesday 21 February 2006 11:16, Nalin Dahyabhai nalin@redhat.com
wrote:
I suggested enabling allow_execstack before, but dwalsh set me straight. The SELinux type on /usr/bin/Xair should match that of /usr/bin/Xorg (which can already use an executable stack), so chcon -t xserver_exec_t /usr/bin/Xorg is the more correct way to fix this.
Is Xair an X server? If not then assigning that type isn't the correct solution, even though it may work.
Yes, it is an X server.
In that case xserver_exec_t is definitely the correct label.
Russell Coker wrote:
On Tuesday 21 February 2006 11:16, Nalin Dahyabhai nalin@redhat.com wrote:
I suggested enabling allow_execstack before, but dwalsh set me straight. The SELinux type on /usr/bin/Xair should match that of /usr/bin/Xorg (which can already use an executable stack), so chcon -t xserver_exec_t /usr/bin/Xorg is the more correct way to fix this.
Is Xair an X server? If not then assigning that type isn't the correct solution, even though it may work.
Yes.
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
If after using things for a while all your window borders disappear, you may have better luck by setting the METACITY_SYNC environment variable to 1 and rerunning spififity. Setting the environment variable incurs a minor performance hit, but it will also mask a lingering bug in the compositing manager code.
Yes I ran into this, and have since went back to original metacity (I think, does rebooting work?). But I have lost my borders and such and can't think/don't know how to get them back?
Hi,
If after using things for a while all your window borders disappear, you may have better luck by setting the METACITY_SYNC environment variable to 1 and rerunning spififity. Setting the environment variable incurs a minor performance hit, but it will also mask a lingering bug in the compositing manager code.
Yes I ran into this, and have since went back to original metacity (I think, does rebooting work?). But I have lost my borders and such and can't think/don't know how to get them back?
Weird. Maybe you saved your session with spififity running then uninstalled the spififity rpm?
If so, log into a virtual console or failsafe xterm as your username, then run:
sed -i -e 's/spififity/metacity/' ~/.gnome2/session
Alternatively, reinstall the spififity package, log in, press alt-f2 and then type "metacity --replace"
--Ray
On Thu, 2006-02-09 at 17:22 -0500, Ray Strode wrote:
Weird. Maybe you saved your session with spififity running then uninstalled the spififity rpm?
Yes, I believe that is what I actually did.
Alternatively, reinstall the spififity package, log in, press alt-f2 and then type "metacity --replace"
Doing the above, well alt-f2 didn't work, but typing it in an xterm got it back and working. Guess won't be messing with *that* for a while :P
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
If you see drop shadows and a bunch of solid white windows, you probably aren't running the right X server. Make sure you're running Xair and not Xorg.
I don't quite get that. Here is what I get:
http://geek.j2solutions.net/shots/blang.png
Am Donnerstag, den 09.02.2006, 16:33 -0800 schrieb Jesse Keating:
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
If you see drop shadows and a bunch of solid white windows, you probably aren't running the right X server. Make sure you're running Xair and not Xorg.
I don't quite get that. Here is what I get:
I can add another one:
http://www.bfki.net/test/Bildschirmfoto.png
-- Karsten Fischer
Hi,
Am Donnerstag, den 09.02.2006, 16:33 -0800 schrieb Jesse Keating:
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
If you see drop shadows and a bunch of solid white windows, you probably aren't running the right X server. Make sure you're running Xair and not Xorg.
I don't quite get that. Here is what I get:
I can add another one:
Are you using a laptop with an external monitor? If so, if you lower your resolution to be the same as the native resolution of the laptop does your problem go away?
What if you add
Option "MonitorLayout" "NONE,LCD" (or "NONE,CRT" if your monitor is a crt)
to the device section or your xorg.conf?
--Ray
Hi,
After updating Xorg to rawhide I've installed bling today. Everything works until spififity --replace which causes X to crash on my Intel Corporation 82865G Integrated Graphics Controller
No errors are generated to X log, I've attached it.
How to debug this?
Thanks, -- Marius Andreiana
On 2/12/06, Marius Andreiana mandreiana.lists@gmail.com wrote:
Hi,
After updating Xorg to rawhide I've installed bling today. Everything works until spififity --replace which causes X to crash on my Intel Corporation 82865G Integrated Graphics Controller
No errors are generated to X log, I've attached it.
Also attached /etc/X11/xorg.conf; I've added Composite but I don't see it in X log
-- Marius Andreiana
I followed the steps as listed in the first email of this thread (plus the selinux suggestion later on), with the only deviation being that sed -i -e 's/Xorg/Xair/g' /usr/share/gdm/config/gdm.conf-custom didn't work, so I created a /usr/share/gdm/config folder and then touched gdm.conf-custom and then ran the command. Not sure if that's wrong to do.
I do indeed get drop shadows and a bunch of solid white windows, and an earlier email said that might be because I'm using Xorg instead of Xair. However, I removed /usr/bin/X and made a symlink to /usr/bin/Xair. Was that not the right way to make sure Xair is working?
This is all on a Radeon 9000 Pro (RV250) with Xorg drivers, by the way (I can try fglrx if you need me to, but I thought those didn't support the composite extension).
Any help would be appreciated. I'd really like to try this.
Thanks,
Chris Kurecka
On 2/8/06, Ray Strode rstrode@redhat.com wrote:
If you see drop shadows and a bunch of solid white windows, you probably aren't running the right X server. Make sure you're running Xair and not Xorg.
--Ray
Hi,
I followed the steps as listed in the first email of this thread (plus the selinux suggestion later on), with the only deviation being that sed -i -e 's/Xorg/Xair/g' /usr/share/gdm/config/gdm.conf-custom didn't work, so I created a /usr/share/gdm/config folder and then touched gdm.conf-custom and then ran the command. Not sure if that's wrong to do. I do indeed get drop shadows and a bunch of solid white windows, and an earlier email said that might be because I'm using Xorg instead of Xair. However, I removed /usr/bin/X and made a symlink to /usr/bin/Xair. Was that not the right way to make sure Xair is working?
So with the latest rawhide, gdm's configuration file has moved to /etc/gdm/custom.conf
Add something like this to it:
[servers] 0=Xair
[server-Xair] name=Accelerated Indirect server command=/usr/bin/Xair -audit 0
If you already have a [servers] section, change what's already there instead of adding a second entry (but still add the [server-Xair] section.
Then run /usr/sbin/gdm-restart as root
Note, it appears all x86-64 users get the white boxes no matter what. That bug is being worked on.
--Ray
Ray Strode wrote:
Hi,
I followed the steps as listed in the first email of this thread (plus the selinux suggestion later on), with the only deviation being that sed -i -e 's/Xorg/Xair/g' /usr/share/gdm/config/gdm.conf-custom didn't work, so I created a /usr/share/gdm/config folder and then touched gdm.conf-custom and then ran the command. Not sure if that's wrong to do. I do indeed get drop shadows and a bunch of solid white windows, and an earlier email said that might be because I'm using Xorg instead of Xair. However, I removed /usr/bin/X and made a symlink to /usr/bin/Xair. Was that not the right way to make sure Xair is working?
So with the latest rawhide, gdm's configuration file has moved to /etc/gdm/custom.conf
Is there any particular reason gdm (and kdm for that matter) don't simply default to /usr/bin/X? It's supposed to be the default X server, which seems a better way to handle it IMHO. Then one merely need point the /usr/bin/X symlink to the server of choice, in theory at least.
We don't have anything for managing the symlink currently (Xconfigurator used to do that), but it could be done manually by hand. Or someone could whip up a craptastic python GUI system-config-xserver-symlink or switchx or somesuch. ;)
Note, it appears all x86-64 users get the white boxes no matter what. That bug is being worked on.
X on x86_64 has been a bit rough around the edges in 7.0 thus far, but hopefully smooths out soon.
On Thu, 2006-02-16 at 12:57 -0500, Mike A. Harris wrote:
Is there any particular reason gdm (and kdm for that matter) don't simply default to /usr/bin/X? It's supposed to be the default X server, which seems a better way to handle it IMHO. Then one merely need point the /usr/bin/X symlink to the server of choice, in theory at least.
I'd far rather be making changes to config files than doing the symlink voodoo we used to
Jeremy
Jeremy Katz wrote:
On Thu, 2006-02-16 at 12:57 -0500, Mike A. Harris wrote:
Is there any particular reason gdm (and kdm for that matter) don't simply default to /usr/bin/X? It's supposed to be the default X server, which seems a better way to handle it IMHO. Then one merely need point the /usr/bin/X symlink to the server of choice, in theory at least.
I'd far rather be making changes to config files than doing the symlink voodoo we used to
The way the symlink voodoo was done before via Xconfigurator, I'd agree, as it was IMHO quite a nasty mess. It doesn't need to be such a disaster though, at least in theory. ;oP
I'd prefer for there to never ever be more than one X server to ever want to install, thus making /usr/bin/X a hardlink to /usr/bin/Xlinux, but that has some drawbacks too. ;)
Hi,
Is there any particular reason gdm (and kdm for that matter) don't simply default to /usr/bin/X? It's supposed to be the default X server, which seems a better way to handle it IMHO. Then one merely need point the /usr/bin/X symlink to the server of choice, in theory at least.
The problem I think is that you can't have a package own the symlink (because then if you changed it rpm -V would shout, etc), so that leaves making it in %post. But doing it in %post has issues anyway (think about shared /usr).
--Ray
Ray Strode wrote:
Hi,
Is there any particular reason gdm (and kdm for that matter) don't simply default to /usr/bin/X? It's supposed to be the default X server, which seems a better way to handle it IMHO. Then one merely need point the /usr/bin/X symlink to the server of choice, in theory at least.
The problem I think is that you can't have a package own the symlink (because then if you changed it rpm -V would shout, etc), so that leaves making it in %post. But doing it in %post has issues anyway (think about shared /usr).
The filesystem package could own the symlink, and it could be flagged %verify (not md5 mtime size) etc. with a custom %verifyscript that checks that the link is pointing to an actual X server and is not a dead symlink.
Another way to do it could be using alternatives, but I'd rather not go there. As for shared /usr, /usr/bin/X would point to /etc/X11/X, which would point to /usr/bin/X<whatever>, allowing each system to customize the X link to a different server if desired.
Another possibility, is to have /usr/bin/X be a wrapper script instead of a symlink, and have it source a config file that specifies the X server to use, and perhaps other stuff. That way there would be a single config file that would set the default X server for:
gdm, kdm, xdm, startx, xinit
Avoiding any symlink issues, and allowing all of the above programs to simply invoke /usr/bin/X. The config file would reside in /etc somewhere (/etc/sysconfig/Xserver?), thus allowing it to work on shared /usr systems also.
Anyway, just some ideas to toss around, as it seems a bit backwards to hard code X server name in multiple packages, to have to change it over time as the OS changes, if it can be configurable and adaptable with little pain. I'm thinking more about the end users here than anything, as they're the ones least likely to know they have to edit gdm.conf or kdm.conf or <insert other item>, etc. For tech types it isn't a huge issue, but I'm sure it'll generate a lot of mailing list questions, etc. ;)
Thanks Ray.
That got it working for me. It doesn't cause any major issues or anything, but it seemed to die on its own a couple times (just showing a normal GNOME desktop without shadows). Rerunning spififity after that brought it back up. On my Radeon 9000 it's kind of slow. I was wondering if anything can be done to make it faster?
My xorg.conf options are:
Option "XAANoOffscreenPixmaps" Option "AllowGLXWithComposite" "1" Option "RenderAccel" "yes" Option "AccelMethod" "xaa"
I tried exa, but that made it seem even slower. Should I consider ATI's proprietary drivers? Is there any other flag worth trying?
Thanks for the help. It's pretty cool.
Chris Kurecka
On 2/16/06, Ray Strode rstrode@redhat.com wrote:
Hi,
I followed the steps as listed in the first email of this thread (plus the selinux suggestion later on), with the only deviation being that sed -i -e 's/Xorg/Xair/g' /usr/share/gdm/config/gdm.conf-custom didn't work, so I created a /usr/share/gdm/config folder and then touched gdm.conf-custom and then ran the command. Not sure if that's wrong to do. I do indeed get drop shadows and a bunch of solid white windows, and an earlier email said that might be because I'm using Xorg instead of Xair. However, I removed /usr/bin/X and made a symlink to /usr/bin/Xair. Was that not the right way to make sure Xair is working?
So with the latest rawhide, gdm's configuration file has moved to /etc/gdm/custom.conf
Add something like this to it:
[servers] 0=Xair
[server-Xair] name=Accelerated Indirect server command=/usr/bin/Xair -audit 0
If you already have a [servers] section, change what's already there instead of adding a second entry (but still add the [server-Xair] section.
Then run /usr/sbin/gdm-restart as root
Note, it appears all x86-64 users get the white boxes no matter what. That bug is being worked on.
--Ray
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Chris Kurecka wrote:
Thanks Ray.
That got it working for me. It doesn't cause any major issues or anything, but it seemed to die on its own a couple times (just showing a normal GNOME desktop without shadows). Rerunning spififity after that brought it back up. On my Radeon 9000 it's kind of slow. I was wondering if anything can be done to make it faster?
My xorg.conf options are:
Option "XAANoOffscreenPixmaps" Option "AllowGLXWithComposite" "1" Option "RenderAccel" "yes" Option "AccelMethod" "xaa"
I tried exa, but that made it seem even slower. Should I consider ATI's proprietary drivers? Is there any other flag worth trying?
Thanks for the help. It's pretty cool.
Chris Kurecka
I hope these nifty features (eye candy) can be useful using the native xorg dri drivers. It would be a shame to end up requiring proprietary drivers.
Hi,
That got it working for me. It doesn't cause any major issues or anything, but it seemed to die on its own a couple times (just showing a normal GNOME desktop without shadows). Rerunning spififity after that brought it back up.
you might try
running sh -c "METACITY_SYNC=1 spififity --replace" instead of just spififity --replace. It may solve your stability issues.
On my Radeon 9000 it's kind of slow. I was wondering if anything can be done to make it faster?
My xorg.conf options are:
Option "XAANoOffscreenPixmaps" Option "AllowGLXWithComposite" "1" Option "RenderAccel" "yes" Option "AccelMethod" "xaa"
The XAANoOffscreenPixmaps is the most important bit for good performance and you already have that. RenderAccel defaults to yes I think, so that's not necessary. I don't know what AllowGLXWithComposite does or how it interacts with accelerated indirect rendering. I don't have it in my xorg.conf
I tried exa, but that made it seem even slower.
Yea, right now the X guys (Soeren, Kristian, Adam, and Kevin) are using XAA, with the longer term plan to make this work well with EXA I think.
Should I consider ATI's proprietary drivers? Is there any other flag worth trying?
You can't use an alternative GL implementation with this (unless it supports the texture_from_pixmap extension). I don't know if the ATI drivers ship their own GL.
Does your computer do speed stepping? One (obvious) way to increase your frame rate might be to max out your cpu clockspeed if you haven't already.
It's already got pretty acceptable frame rates (~30fps) on my r100 card. This should get faster over time, too. Adam is looking into various ways to make things faster, I believe.
--Ray
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
[snip]
Things are still quite raw, so expect things to crash, your system to lock up, effects to be unpolished, etc.
Is there a bugzilla component I should file problems against?
Are there debuginfo packages for the repo?
I'm getting the Xair server apparently crashing during the login. Upon investigation, it's an exit here: (gdb) bt #0 0x00b718c6 in exit () from /lib/libc.so.6 #1 0x00f4cb96 in intelAllocateMemoryMESA () from /usr/lib/dri/i915_dri.so #2 0x00f4d708 in intelWaitForIdle () from /usr/lib/dri/i915_dri.so #3 0x00f4d732 in intelFinish () from /usr/lib/dri/i915_dri.so #4 0x00f6aaf2 in _mesa_Finish () from /usr/lib/dri/i915_dri.so #5 0x003e6423 in __glXSwapBuffers () from /usr/lib/xair/modules/extensions/libglx.so #6 0x003ec750 in __glXForceCurrent () from /usr/lib/xair/modules/extensions/libglx.so #7 0x008a8ddc in DRIUnlockedCallback () from /usr/lib/xair/modules/extensions/libdri.so #8 0x003ec8e1 in __glXForceCurrent () from /usr/lib/xair/modules/extensions/libglx.so #9 0x080845d6 in Dispatch () #10 0x0806e2f9 in main ()
Top tip for debugging: ssh into the test machine from another host, locate the Xair process, and run a "gdb attach" onto that process from there, type "cont" to get the X server to continue. You then have a vaguely sane debug environment, and can "break exit" (how I got the above).
Should these notes be on the wiki?
Dave
Hi,
On Wed, 2006-02-08 at 23:05 -0500, Ray Strode wrote:
[snip]
Things are still quite raw, so expect things to crash, your system to lock up, effects to be unpolished, etc.
Is there a bugzilla component I should file problems against?
Not, yet. Everything but the updated server is in rawhide, so maybe we can get away with sneaking in another component to FC5. Then again, Adam is thinking about pushing regular driver updates, mesa updates, etc, to his repo, so maybe we should create a new product. I guess it's really up to Adam and Mike. What do you guys think?
Are there debuginfo packages for the repo?
The ones in rawhide have debuginfo packages of course. The updated server didn't because my disk quota filled up. I removed the packages that we got in rawhide and that made room for the debuginfo package.
I'm getting the Xair server apparently crashing during the login. Upon investigation, it's an exit here: (gdb) bt #0 0x00b718c6 in exit () from /lib/libc.so.6 #1 0x00f4cb96 in intelAllocateMemoryMESA () from /usr/lib/dri/i915_dri.so
It's calling exit() from an AllocateMemory function? Maybe you don't have enough texture memory or something? What resolution are you running at? What happens if you lower your resolution?
#2 0x00f4d708 in intelWaitForIdle () from /usr/lib/dri/i915_dri.so #3 0x00f4d732 in intelFinish () from /usr/lib/dri/i915_dri.so #4 0x00f6aaf2 in _mesa_Finish () from /usr/lib/dri/i915_dri.so #5 0x003e6423 in __glXSwapBuffers () from /usr/lib/xair/modules/extensions/libglx.so #6 0x003ec750 in __glXForceCurrent () from /usr/lib/xair/modules/extensions/libglx.so #7 0x008a8ddc in DRIUnlockedCallback () from /usr/lib/xair/modules/extensions/libdri.so #8 0x003ec8e1 in __glXForceCurrent () from /usr/lib/xair/modules/extensions/libglx.so #9 0x080845d6 in Dispatch () #10 0x0806e2f9 in main ()
Top tip for debugging: ssh into the test machine from another host, locate the Xair process, and run a "gdb attach" onto that process from there, type "cont" to get the X server to continue. You then have a vaguely sane debug environment, and can "break exit" (how I got the above).
Should these notes be on the wiki?
Sure! Please add them.
--Ray
On Wed, Feb 22, 2006 at 11:11:45AM -0500, Ray Strode wrote:
have enough texture memory or something? What resolution are you running at? What happens if you lower your resolution?
I'd suggest experimenting with a lower depth, too. On the one system I tried it on, 1600x1200x24 resulted in a mostly white screen, while 16bit worked, although I could still see noticeable tearing while dragging windows.
Has anyone tried killing Nautilus with the compositing manager enabled? Now that's an interesting and probably unexpected effect.
Another question since we're at it: are there reasons why this should not work with a dualhead setup? Of course Xinerama is mutually exclusive with DRI, but I am wondering if there are going to be other limitations, too.
-
Alexander Larsson -
Chris Kurecka -
David Malcolm -
David Nielsen -
Dawid Gajownik -
dragoran -
Jeremy Katz -
Jesse Keating -
Justin Conover -
Karsten Fischer -
Marius Andreiana -
Matthias Clasen -
Mike A. Harris -
Mike Chambers -
Nalin Dahyabhai -
Ray Strode -
Rudi Chiarito -
Russell Coker -
Steven Haigh -
Will H. Backman