You are not logged in.
Firstly apologies if this has already been asked before. A preliminary search did not yield any relevant results.
I am trying to model a multi-monitor (multi-screen) layout using Xephyr for debugging a window manager I have been developing.
Xephyr can be run with the arguments
+xinerama -screen 200x200 -screen 100x100
to model a two screens/monitors multi-monitor setup.
The issue I have is that the stitching of the screens is not seamless in terms of the pointer coordinates that are reported..
For example, the X library reports XMotionEvent on the root window with coordinates relative to x_root and y_root. However the coordinates in each Xephyr window revert to 0 wrt the origin of each Xephyr window/screen/monitor.
Why is that?
I would expect that when the pointer focusses onto the second Xephyr window that its initial coordinate (in the x-axis) starts off not from 0 but at the size of the first screen/monitor (ie, 200 in this case).
This seems problematic and is making debugging rather difficult.
Offline
IDK if the display server would report a continuation of coordinates when the wm is run out of Xephyr?
Can anyone confirm?
Offline
That switch doesn't get you multiscreen behavior à la xrandr and xinerama should be pretty much irrelevant these days.
Idk whether or how you can add a second output to Xephyr (possibly w/ a specific xorg config, I'd have to test that myself)
You can split the default output into several logical monitors via the 1.5 randr version, but that only makes sense if your WM is going to support that feature and also randr 1.5 isn't supported by all X11 drivers (nvidia) for real-metal use later on.
What you see w/ xinerama is probably what you can expect, you've still two X11 screens that are just merged via xinerama.
The easiest solution is probably to fake the randr structure in your WM (ie. have one Xephyr window and instead of querying the layout via randr, feed fake results into the WM)
Offline
Yes I suspected as much. Thanks for replying.
When you say that Xinerama is pretty much irrelevant these days, what do you mean by that?
The wm needs to be able to piece together the various monitors connected to the hardware into a seamless user display canvas.
Offline
When you say that Xinerama is pretty much irrelevant these days, what do you mean by that?
15 years - outputs are controlled via the randr extension, randr and xinerama are mutually incompatible, a bunch of clients/toolkits blindly relies on randr so if you've to actually use xinerama (because it can combine random screens across GPUs and hosts) you quickly run into trouble so in practice, virtually nobody uses xinerama anymore.
If you get meaningful output separation via "xrandr -q", you're not using xinerama
The term might occasionally show up to refer to spanning the root window across all outputs, reflection the union of X11 screens (though that's no longer happening)
Your WM can oc implement support for xinerama and xrandr, but xrandr is the important one for the majority of users (unless you're serving a specific niche of users to begin with)
Offline