Xwayland monitor doesn't change position (to the left/to the right) when changing position of monitor in sway

[naibaf0]

• Sway Version: sway version 1.0-rc1-240-gd7d29fe5 (Apr 17 2019, branch 'master')
• Debug Log: I didn't obtain one, if necessary I will try to reproduce later at home
• Configuration File: https://pastebin.com/A1LbU6Jm

I started up my notebook with the monitor configuration you can see in the pastebin. Afterwards I executed the following command: swaymsg output '"Seiko Epson Corporation 0x5441 0x00000000" position 0 0'
Up until very recently this would result in my Notebook monitor (the Seiko one) being displayed on the left and the external Dell in the middle. When I did this today (after upgrading sway) I was unable to click applications on the left monitor (e.g. Thunderbird, Spotify, I assume Xwayland). Instead the pointer would be display on the external monitor. When checking lxrandr I saw that the Notebook Monitor was still listed to the right, so I assume the error lies there, when I changed that to the left it worked.

Previously, at most two weeks ago, this was working perfectly, so I assume something must have changed in between, causing that effect?

[Ferdi265]

I noticed this as well, this has actually been this way for a few weeks now, (can currently reproduce this using latest master).

Test case:

• Start sway, laptop monitor (eDP-1, 1920x1080) is per default located to the right of the external monitor (HDMI-A-1, 1920x1080)
• Xwayland applications on laptop monitor are responsive
  • swaymsg -t get_outputs reports "Output eDP-1 ... Position: 1920,0" and "Output HDMI-A-1 ... Position: 0,0"
  • xrandr reports "XWAYLAND0 connected 1920x1080+1920+0" and "XWAYLAND1 connected 1920x1080+0+0"
• execute swaymsg output eDP-1 pos 0 1080
• Xwayland applications on laptop monitor do not respond to clicks, xeyes seems to look in weird directions
  • swaymsg -t get_outputs reports "Output eDP-1 ... Position: 0,1080" and "Output HDMI-A-1 ... Position: 0,0"
  • xrandr still reports "XWAYLAND0 connected 1920x1080+1920+0" and "XWAYLAND1 connected 1920x1080+0+0"

It seems to me that sway is not communicating changes in the output configuration to Xwayland correctly.

EDIT:

trying to bisect this I found that this issue already existed 3 weeks ago, at commit d9de5b8

I wanted to bisect futher, but at some point I hit a commit that doesn't compile any more with the latest wlroots.

[RedSoxFan]

Possibly related to #2668. Although that was several months ago so wouldn't be related to a recent change.

The only recent change that I see is swaywm/wlroots#1611. However, xwayland should be using xdg-output's logical position instead anyway

[Ferdi265]

Interestingly, bisecting wlroots instead of sway, I found that exact commit (swaywm/wlroots#1611) to be the first commit that causes this bug.

Maybe I saw a similar issue weeks ago that had a different cause and was since fixed, and this is a regression caused by the change in wroots?

[emersion]

Ugh. Then this is an xwayland bug? It should definitely use xdg-output information.

[Ferdi265]

I found the bug in Xwayland:

Xwayland uses both wl_output and xdg_output listeners to determine information about the outputs (xdg_output is only used when the wayland compositor supports it). Before applying the changes, it checks if the other of the two events has already happened. It will only trigger an apply when both events happen.

With latest wlroots, this doesn't happen any more when moving an output, since the position in wl_output stays at 0,0, while the logical position in xdg_output changes, meaning only one of the events is triggered.

The checks in question:

• https://github.com/mirror/xserver/blob/9c7ebf259f49f5e63906f572a1101747ac023b72/hw/xwayland/xwayland-output.c#L318
• https://github.com/mirror/xserver/blob/9c7ebf259f49f5e63906f572a1101747ac023b72/hw/xwayland/xwayland-output.c#L276

the fix is to just to remove both of these ifs and clean up the (now no longer needed) wl_output_done and xdg_output_done flags.

[Ferdi265]

I submitted the patch to the Xorg-devel mailing list, it hasn't appeared in the public archive yet for some reason though, so I can't link to it.

Maybe I'll fork the xserver repo and commit the patch there tomorrow.

[ascent12]

@Ferdi265 If you're not subscribed to the mailing list and try to send an email, it'll get held up for administrator approval as spam-prevention (you'd get an email back saying this). I don't know if that is even monitored or not.

I'm subscribed to that list and I haven't seen it come through yet. If you're not subscribed, you should do so and re-send your patch.

[Ferdi265]

@ascent12 that makes sense. I'll resend it today :)

[Ferdi265]

Re-sent it, here's the thread in the xorg-devel mailing list. Here is the patch on GitHub.

[emersion]

It's not clear whether there is a good Xwayland fix for this bug.

[emersion]

Will reply to the list in a few hours. Here are some #wayland logs in the meantime:

17:03 <emersion> hey pq, just wanted to know if you had some thoughts about the protocol issues described in https://lists.x.org/archives/xorg-devel/2019-April/058148.html
17:10 <pq> emersion, I don't have any recollection of xdg_output - do what the spec says?
17:11 <pq> if there are independent 'done' events, then handle them independently, and if something needs both, it needs to specifically wait for both and not assume one implies the other.
17:12 <emersion> so the issue is that xwayland needs to wait for both
17:12 <emersion> but doesn't know whether both will happen or not
17:12 <pq> how does it not know?
17:13 <emersion> a change in wl_output might not trigger a change in xdg_output
17:13 <emersion> and the other way around
17:13 <emersion> KDE has this issue too
17:14 <pq> and the worry is that if both actually do change, you don't want to act already when just one changed?
17:14 <emersion> exactly
17:14 <pq> sounds like a protocol design bug
17:14 <emersion> indeed
17:14 <emersion> so my idea would be to do like wl_surface.commit
17:14 <pq> however, a workaround comes to mind: roundtrip
17:15 <emersion> hmm
17:15 <pq> oh, can it still be fixed properly?
17:15 <pq> I suppose, since xdg_output is unstable still?
17:15 <ascent12> Define xdg_output to be atomically synchronised by wl_output.done events instead?
17:15 <emersion> pq: the idea would be to make wl_output.done atomically apply the wl_output state, including add-on objects state
17:16 <emersion> ie. including xdg_output state
17:16 <pq> emersion, yes, that is a good idea.
17:16 <emersion> okay, thanks
17:17 <pq> also because wl_output.done without any other messages does not do anything.
17:17 <pq> so it's safe to send
17:17 <emersion> aye

[emersion]

https://lists.freedesktop.org/archives/wayland-devel/2019-April/040505.html

[emersion]

Can you try swaywm/wlroots#1674?

[Ferdi265]

will try this with unpatched Xwayland