However, since Xinerama and MergedFB (or Twinview, if you want) is not entirely the same, I encountered a logical problem during programming:
With Xinerama, the two screens never change size (unless you use RandR, this theoretical possibility is left aside in the following), nor position during server life-time. Hence, filling in the PanoramiXData structure is trivial and only needs to be done once at server startup.
MergedFB mode is different in this regard: Here, there is only one screen visible for the server and the clients, and heads' viewports can float around more or less freely in the virtual framebuffer. There are no "2 screens" in the true meaning of that word; the "screens" (which should be given information about by querying the Xinerama extension) in MergedFB/Twinview are determined by the very metamode used.
Imagine the following example:
Virtual framebuffer 2304x1024, meta modes 1280x1024-1024x768 and 1024x768-1280x1024 (meaning: Mode 1 is 1280x1024 on head 1, 1024x768 on head 2; Mode 2 is 1024x768 on head 1 and 1280x1024 on head 2).
Mode 1: (fixed width font required for viewing)
+------------------------------------------+ |+--------------------+ +-----------------+| || | | || || | | || || | | head 2 || || | | 1024x768 || || head 1 | | || || 1280x1024 | | || || | +-----------------+| || | | || | Virtual framebuffer| |+--------------------+ | +------------------------------------------+
Mode 2:
+------------------------------------------+ |+-----------------+ +--------------------+| || | | || || | | || || head 1 | | || || 1024x768 | | head 2 || || | | 1280x1024 || || | | || |+-----------------+ | || | | || | | || | +--------------------+| +------------------------------------------+
(For those not familiar with MergedFB mode: The "smaller" head in this szenario can be scrolled freely within its boundaries, ie there is never an area of the framebuffer which is not reachable.)
As you can see, the boundary line between the two heads differs depending on the current metamode: At Mode 1, it is at 1280, at Mode 2 at 1024.
Now for the problem:
At least KDM (which I used for testing) queries the Xinerama extension only once, during startup.
What values should the XineramaQueryScreens() function return?
Preliminarily, I went for the following solution:
If head 2 is right of head 1, (other positions not regarded in this example)
screen 0 (head 1)
x = 0
y = 0
width = maximum X of all modes for this head
height = virtual Y framebuffer size
screen 1 (head 2)
x = virtual X fb size - maximum X of all modes for this head
y = 0
width = maximum X of all modes for this head
height = virtual Y framebuffer sizeIn numbers:
screen 0 (head 1)
x = 0
y = 0
width = 1280
height = 1024
screen 1 (head 2)
x = 1024
y = 0
width = 1280
height = 1024This gives two overlapping screens... The result is:
If running in Mode 1, a smart application might place a window meant for head 2 at (1024, 0) - which is partly in head 1's viewport, and partly outside head 2's viewport. However, the window is correctly placed at these coordinates if currently running in Mode 2.
Does anybody have a better solution?
Should I perhaps use the current viewport positions/sizes for this, and update the structure on each mode switch? (At least with KDM, this won't have any effect as it seems to query the Xinerama data only once, as said)
Especially for Mark V.: How is the binary NVidia driver doing this?
Any advice appreciated.
Thomas
-- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
