WindowId broken with xinerama?


I have

Key Left A 4 WindowId root 1 WarpToWindow 50 50
Key Right A 4 WindowId root 0 WarpToWindow 50 50

Easy enough, to move the pointer to the center of a given screen. Screen 0 is to the right of screen 1. When I press either binding, the pointer always to to a place near the left margin of the screen 0, and on the Y-axis it goes to the middle (50). I think it is always going to (50,50) but relative to the whole xinerama display.

If that is true, it means that WindowId is blatantly ignoring the numbers I passed on the commands above after the “root” keyword.

In my understanding, looking at the commands above, and at this:

WindowId [id] [(conditions)] | [root [screen]] command

It should go to (50,50) on screen 0 if I press win+right, and to (50,50) on the left display (screen 1) if I press win+left. In the man page even there’s an example that confirms this:

              [...]For example it is possible to warp the
              pointer to the center of the root window on screen 1:

                  WindowId root 1 WarpToWindow 50 50

Can anyone confirm this? If so, I will report a bug.

For now I just work around this issue with these:

Key Left A 4 WindowId root 1 WarpToWindow 10 50
Key Right A 4 WindowId root 0 WarpToWindow 90 50

But this is not supposed to be the way it should work, otherwise, what would be the point of the [screen] number?

Thanks for reading :slight_smile:

I think you’ll find that’s screen in the non-xinerama sense, since to FVWM it really is just one large root window anyway.

– Thomas Adam

That is exactly how it behaves, but there is the point: I can’t understand what the meaning of “screen” is here.

As far as I know, if we talk about “screen” on the X sense as “separate display device”, there is completely no point in that parameter, because you can’t -as far as my humble brain knows- move one thing from one fvwm session to another fvwm session which is running into another display.

If you use the xinerama sense of the “screen” word, then it is buggy, as my post above describes.

Just a note: the Move command, DO accept a “screen” parameter, and it works as expected, even if fvwm doesn’t know what a physical screen is.

You can easily test if you have a xinerama display, just open a FvwmConsole, and do this alternatively:

All (FvwmConsole) Move screen 0 0 0
All (FvwmConsole) Move screen 1 0 0
All (FvwmConsole) Move screen 0 0 0

You will see how your FvwmConsole moves from a physical screen to the other. Easy as that, if Move can, I don’t see why “WarpToWindow root” could not, and if it is intentional, I don’t see why it should, just for sake of consistency.

And there is still the question about what is the usefulness of the “screen” parameter in WarpToWindow if it is not referred to xinerama screens.

Thanks for the response :slight_smile:

The physical screen – but note that Xinerama changes that turning them both into one big “screen”.

Right – which is why Xinerama was created. Note that “screen in the X sense” is useless; it’s just a physical device from our point of view.

But as far as the root window is concerned, it isn’t. Technically speaking it’s not buggy at all, but it should probably be changed to comply with the fact that the root window is the bounds of the physical screen (read: monitor) when warping the pointer.

Remember that the “Move” command is completely different and calculates what a screen is based on the screen’s width and height.

I’ve not looked at any code, not bothered to find out, etc., etc., but I bet this is what’s happening.

Won’t be me patching it though, I’m not really interested these days.

– Thomas Adam