Wlroots: Sections of Xwayland windows within negative output coordinates receive incorrectly positioned cursor events

Created on 6 May 2018 · 13Comments · Source: swaywm/wlroots

If a portion of an Xwayland window is positioned within negative display coordinates, the cursor events received within that portion will be forced to zero on any axis which is negative. This is probably easier to show than tell:

                          +-----------------------------+
                          |1920,-380 +---------+        |
                          |          |xxxxxxxxx|        |
                          |          |xxxxxxxxx|        |
+-------------------------+          |xxxxxxxxx|        |
|0,0                     ||1920,0    | window  |        |
|                        ||          |         |        |
|                        ||          +---------+        |
|                        ||                             |
|                        +------------------------------+
|                        |
|                        |
|                        |
+------------------------+

The "x" filled portion of the window will only ever receive events with a y coordinate of zero.

I discovered this in sway 1.0 alpha, but it can be reproduced in rootston. I did so by positioning a Chromium window as in the diagram, and observing that interaction with the top of the window triggered click events along y=0 instead.

It can also be seen in the output of xev, as you move the cursor up onto that area. Note that both the local and root y coordinate stops decrementing:

MotionNotify event, serial 34, synthetic NO, window 0x1c00001,
    root 0x342, subw 0x0, time 88351420, (189,350), root:(2927,3),
    state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 34, synthetic NO, window 0x1c00001,
    root 0x342, subw 0x0, time 88351443, (189,349), root:(2927,2),
    state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 34, synthetic NO, window 0x1c00001,
    root 0x342, subw 0x0, time 88351454, (189,348), root:(2927,1),
    state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 34, synthetic NO, window 0x1c00001,
    root 0x342, subw 0x0, time 88351476, (189,347), root:(2927,0),
    state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 34, synthetic NO, window 0x1c00001,
    root 0x342, subw 0x0, time 88351499, (189,347), root:(2927,0),
    state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 34, synthetic NO, window 0x1c00001,
    root 0x342, subw 0x0, time 88351521, (189,347), root:(2927,0),
    state 0x0, is_hint 0, same_screen YES

bug xwayland

Source

vilhalmer

Most helpful comment

https://gitlab.freedesktop.org/xorg/xserver/issues/899

emersion on 26 Sep 2019

🚀1 👍1

All 13 comments

I think this is an Xwayland bug

ddevault on 6 May 2018

I was hoping to try reproducing it in weston to narrow it further, but they still don't have output position configuration. If I get a moment to install something that does I will report back.

vilhalmer on 6 May 2018

would this be easy to work around by translating output coordinates when going in and out of XWayland apps such that they are consistent within XWayland and always positive?

I find it easier to understand a monitor configuration for e.g. a laptop when the internal screen is at 0,0 and other screens are positioned relative to it, as in the example here. And this is quite a bad bug when it happens.

hedgepigdaniel on 22 Mar 2019

No. The right solution is to fix Xwayland.

emersion on 22 Mar 2019

I don't see a bug report at the XWayland bug tracker[1]. Maybe someone more into the specifics (so, not me) can open one?

[1] https://bugs.freedesktop.org/buglist.cgi?component=XWayland&product=Wayland&resolution=---

maxhille on 13 Sep 2019

The Xwayland bug tracker is on GitLab.

emersion on 13 Sep 2019

👍1

https://gitlab.freedesktop.org/xorg/xserver/issues/899

emersion on 26 Sep 2019

🚀1 👍1

Patch available here: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/395

emersion on 11 Mar 2020

Anyone know if this patch exists for 1.20.7 stable branch instead of master?

oniGino on 11 Apr 2020

Anyone know if this patch exists for 1.20.7 stable branch instead of master?

As long as the MR hasn't been merged into master, upstream won't backport to a stable release. I also recommend using 1.20.8 since it includes a fix for a race between xwayland and the compositor which could result in flickering.