No driver supports composite and xinerama at the same time. That is not likely to change any time in the near future due to a limitation in the X server. Sorry.

And.. So, let's say I had 4 monitors (just for kicks).. I could have two per card; each combination of CARD+MONITOR could have pretty much any configuration or effects I wanted, but I would STILL be stuck here when came the time to integrate the left side + the right side (the 2 + 2).

Adam, you're pretty well informed on this subject -- do you happen to have any thoughts about the defunct + unmaintained "Xgl-server" version of the x-server?

You are probably (maybe?) aware of the situation over on the Ubuntu forums (and it's on you-tube too), in a thread involving a member named "d2globalinc", where he has got 6 monitors running on nVidia hardware (iirc), using 3 pairs of twinviewed monitors, each pair connected by Xinerama, with full compositing on the entire giant display? He's using the defunct xserver-Xgl or whatever it's called. So the technology + software exists, I just wonder why it is that we are in the current state that we are, with the Xgl-server code abandoned, and the current stuff unable to do what lots of folks want to do..

d2globalinc google search

For the record, I tried for a few minutes, to build that old broken xserver-Xgl on my Slack box, but no go; and besides, I'd rather use the newer Xorg.

Sorry a little bit of a rant.. But, this topic gets increasingly on my nerves as time goes by and nothing seems to change..

No need to apologize but thank you.

Yes, that's what the nVidia driver people say too: "limitation (or bug, depending where you read) of the Xorg server".

I've even read of people willing to collect funds and PAY people to try to fix this, but last I checked, there were no takers.

Yes, you summarized the situation quite well. It is possible to get compositing working using Xgl across multiple xinerama combined displays and, yes, Xgl has been abandoned. I'm really not in a position to discuss the reasons for it but, open source driver development being what it is, I'd guess that no one with the technical skills capable of fixing this (assuming anyone with those skills exists in the first place) is interested in removing this limitation from Xorg.

As for Xgl... Well, despite handling this particular situation properly (or, at least, better than the alternative) most developers seemed to consider it a giant hack, and one that none of them wanted to maintain. So when David Reveman stopped working on Xgl (and compiz, for that matter) no one stepped up to continue that work.

I'm not being argumentative, but to close, I have to say that "somebody wrote the working xgl code in the first place, so *somebody* out there must have the skills to fix the current situation."

Oh well thanks for your input on this!

Cheers,
Sasha

Yeah, but the one person who is familiar enough with Xgl to maintain it stopped maintaining it :-) And no one else seems to want to work on it, most likely because they consider it a hack and would rather see this limitation removed in Xorg itself.

Adam

What am I doing now? Thinking up a suitable punishment for thread hijackers.

LOL..

What I'm doing now: wondering which mirror BrianL has uncommented to upgrade his machine to slackware64-current.

I'm not running current. I did try it briefly in between 12.2 and 13.0, but then I chickened out. I started out using a UK mirror, but it was always 2 or 3 days behind, so I switched to the tds mirror in the US.

OK, well the tds mirror is/was the one I usually use(d) too. If I had a rope right now, I'd be at the end of it as I still cannot get it to update to current. Trying other mirrors, but I feel I'm wasting my time.

I just got home and looked at the thread, so, here are some of the answers to the questions that were asked.

My system:
System: Host Fedora13dw32 Kernel 2.6.33-1.fc13.i686.PAE i686 (32 bit) Distro Fedora release 13 (Rawhide)
CPU: Quad core AMD Phenom II X4 955 (SMP) cache 2048 KB flags (sse4a nx lm svm) bmips 25602.8
Clock Speeds: (1) 800.00 MHz (2) 800.00 MHz (3) 800.00 MHz (4) 800.00 MHz
Graphics: Card nVidia GeForce 9800 GT Fedora 1.7999.1 Res: 1680x1050@59.9hz, 1680x1050@59.9hz
GLX Renderer Gallium 0.4 on NV92 GLX Version 2.1 Mesa 7.8-devel Direct Rendering Yes

[GoinEasy9@Fedora13dw32 ~]$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately 1/1936613746 the monitor refresh rate.
3882 frames in 5.0 seconds = 776.289 FPS
3978 frames in 5.0 seconds = 795.432 FPS
3993 frames in 5.0 seconds = 798.509 FPS
3979 frames in 5.0 seconds = 795.622 FPS
3982 frames in 5.0 seconds = 796.397 FPS
3965 frames in 5.0 seconds = 792.929 FPS
3970 frames in 5.0 seconds = 793.983 FPS

No xorg.conf - from looking at Xorg.0.log it seems like it's setting up everything automatically. The cursor can go between the two monitors in twinview mode, I didn't have to set up anything in xrandr to make it work.

I can drag windows from one monitor to the other

[GoinEasy9@Fedora13dw32 ~]$ xdpyinfo -ext XINERAMA | grep head
head #0: 1680x1050 @ 0,0
head #1: 1680x1050 @ 1680,0

[GoinEasy9@Fedora13dw32 ~]$ xdpyinfo | grep -i COMPOSITE
Composite

This is the version of the drivers I installed:
Name : mesa-dri-drivers-experimental
Arch : i686
Version : 7.8
Release : 0.18.fc13
Size : 6.7 M
Repo : installed
From repo : fedora
Summary : Mesa-based DRI drivers (experimental)
URL : http://www.mesa3d.org
License : MIT
Description: Mesa-based DRI drivers (experimental).

If anyone has any other tests I could give results to, I'd be happy to execute them. I really don't do much with graphics, I'm not a user who needs much eye-candy, so, if I get 3D graphics running, and things like Google Earth work, then I don't usually go farther than that.

I'd say this is interesting, huh?

Interesting, yes.. One thing though -- you write that "The cursor can go between the two monitors" -- but it cannot move WINDOWS between the two monitors using TwinView, right? Or can it?

I too can cursor across the two screens, but it won't drag windows across for me without using Xinerama. I believe the main difference in my situation vs yours, is that I use two separate graphics cards, one per monitor -- which is why I'm kinda stuck in some regards: I want to be able to move windows from screen to screen (requires Xinerama) but I would like to have transparency/composite too (won't work with Xinerama).

My problem (and evaluation of (im)possible solutions) is pretty clear in the few posts that Adamk75 and I exchanged earlier in this thread; and no solution in sight

Thanks for posting that info!

Sasha

I guess you missed that.

I can do everything with the dual monitors that I did when the Nvidia drivers were installed.

I only have one video card, though I wanted to experiment with 2 cards and see if I could get four monitors working, but that experiment is going to have to wait till I get much more time.

Here's mine when I turn off vsync (NVIDIA binary, GeForce 7300GT, 512MiB VRAM):

Naturally I figured there would be a bit of a performance drop (considering you're on a newer-generation card, those stats would probably be about half what they are on my machine, i.e. I would probably be getting less than about 4/500 FPS), but hopefully with time that'll get better!

Now to turn on vsync again so that 3D apps don't always take 100% CPU! I don't get why people don't use vsync...if you're not benchmarking, then it just doesn't make sense to have a frame rate faster than your display's refresh rate IMO.

What is vsync?

Anyway, I ran glxgears and it took 100% CPU on one of the cores, here's the output: