Bug 233112

Created attachment 112164 [details]
X server configuration xorg.conf

Created attachment 112165 [details]
XDM configuration

If the xgl package is built with xinerama support you must add "+xinerama" to the xgl command line options for it to work. However, the xgl package should be patch to turn on xinerama by default so this command line option isn't necessary.

I didn't know that the xgl package had been updated..

I thought I added you BCC to the xgl and compiz distmails. Maybe I forgot.

I haven't removed any of the patches in the package related to Xinerama, so either this is a regression, or the mechanism has changed?

Bodo, does multimonitor support work if you add +xinerama to DISPLAYMANAGER_XGL_OPTS in /etc/sysconfig/displaymanager?

xgl didn't include xinerama or multi-screen support before. Now that both xinerama and multi-screen support is present, the xinerama flag determines what to use. Compiz got much better support for xinerama so that's what you want to use and hence the +xinerama flag. I'll attach a patch that will turn that flag on by default.

Created attachment 112962 [details]
xinerama

Re  #4: Yes, adding +xinerama seems solve the issue. However performance got badand the desktop feels sluggish now. 

i also suffer from this problem.
all xgl-releases from 060522-branch seem to have the problem that they don't know about xinerama. on opensuse-page http://en.opensuse.org/Xgl you can read:

 * How do I configure a multiple monitor setup for Xgl?
Xgl and compiz don't support the Xinerama extension at the moment. This is being worked on.
Xgl will, of course, work with merged framebuffer setups, but it will not be aware of the different monitors, e.g. the login screen will be split between the monitors.

and this is how the 060522 release of xgl from the opensuse10.2-dvd works.
the xgl-releases (060729) from Compiz-Quinn-repo for suse10.1 worked with dual-screen.
and the newset and latest xgl releases (070104) from xorg72 repo for opensuse10.2 don't do xinerama out of the box.
when you load/start xgl-git_070104, you can see at the x-session-login screen, that you can't move the mouse to the second monitor.
with xgl-060729 and "normal" xorg you can.

but the workaround with adding "+xinerama" to the xgl-start-options seems to fix it.
although i also have the feeling, that it is a bit slower than it was with the 060729-release.

The Xinerama implementation of the compiz-Quinn packages was conceptually flawed, and thus not included in the standard packages. These include a completely new approach now and should work.

I'm a bit unsure about the current openSUSE packages (have to resync, but I'm busy right now), but adding "+xinerama" should do the trick.

Depending on the hardware this could be slower, but if it is recent enough hardware with enough GFX memory (i.e. an NVidia 6xxx with >=128 MB) it shouldn't  be. If this is still slower, please open another bug for that.

yes, "+xinerama" does the trick.

but beside the speed issue (it is really slower than with the xinerama-approach from the compiz-Quinn-repo. at least on my nc8430 notebook with ati mobility radeon x1600 with 256mb ram) there is also another bug.

when i rotate desktop-cube with mouse-button (scroll-wheel), then suddenly the kde-window-list (in german: fensterleiste ;-) becomes empty, and i really can't see any of the windows on the other sides of the cube.
sometimes even the windows of first cube-side disappear.
when rotating cube with ctrl-alt-mouse1 this effect does not appear.
and it also does not appear on single-monitor-setup (without "+xinerama").

so, IMHO xinerama-support in recent xgl (070104) should not be called "working".

but, at least it (some kind of) works now with the "+xinerama" workaround.

forget about "rotate desktop-cube error" in my last posting.

i have to apologize.

it was the kde-setting for "switching virtual-desktop with mouse-wheel" which disturbed the "cube-rotating with mouse wheel" from xgl.

so, it is only a little bit slower now, but not broken any more....
thanks for the "+xinerama" workaround.

Matthias, can you check if the patch is in opensuse and enabled by default?

No, this has only been submitted to SLE-SP1.

This is why I always asked to have STABLE on the most recent development line.
Will submit that tomorrow.

Copied all missing changes to SLE-SP1 to openSUSE + STABLE. That includes a speedup patch for intel and ati, so Rainer, you might want to retest as soon as the new packages are built in openSUSE.

compiz is still more recent for SLE-SP1 than openSUSE + STABLE, though.

i am looking forward to test it.
but where does the new packages show up?
in the xorg7.2 repository on http://repos.opensuse.org/xorg72/openSUSE_10.2/ ?
or as an online-update for opensuse10.2?
and how do i know that your changes are inside?
is there a changelog with some info from you?

Find already built packages at

  http://software.opensuse.org/download/X11:/XGL/openSUSE_10.2/

xorg72 has this package as well, but build for i386 failed for unknown reason :P

Please report your findings here.

WHOW!
it not only works now, without adding "+xinerama" to the XGL-options in /etc/sysconfig/displaymanager, it is really faster now on the ati mobility radeon x1600 of my hp nc8430 notebook!

you did a great job!
glxgears gives me higher values now.
under xgl/beryl the system feels much more responsive now.
i now can use much more of the window-animations.
i now can use the normal window resize method instead of the stretch variant.
maximize/minimize now works as expected, and doesn't freeze/stutter.

thanks alot!

Great to hear that!

Just for the record: glxgears frame numbers don't tell you anything. However, if increases are consistent with the feel of the rest of the system...

what did you do to speed up things with ati-gfx-cards?

and, yes, i know that glxgears frame numbers don't tell me anything.
but there is one thing, i can use it for:
it is good to find out differences.
the numbers themself are not important, but if i change something (install update, change config-file,...) then glxgears can be used to find out the impact of then change.
and in our case here it proved my personal "feelings".
it also did, when i optimized my xorg.conf

It's the composite-avoid-frame-buffer-reads.patch from David. It avoids frame buffer reads (but imposes other costs by that) which are still very slow on intel and radeon.

maybe this one will speed up yours all:
https://bugzilla.novell.com/post_bug.cgi

Greets

R

sorry double! very sorry i put in the wrong link: the trick i wanted to tell ist:

 Desktop/ DISPLAYMANAGER_XGL_OPTS gets set to "+xinerama" only instead that it should be:
-accel glx:pbuffer -accel xv:pbuffer +xinerama
i think

It boosted my Bigdesk with making FooBillard run fluently.
I activated Xgl with

gnome-xgl-switch --enable-xgl +xinerama.

Sorry for the bad reply up there again. *blushs*


Greets 

R

+xinerama is no longer necessary.