GNOME Bugzilla – Bug 756272
Alt-tab does not switch focus correctly between XWayland and Wayland
Last modified: 2016-08-03 02:57:08 UTC
If you switch quickly (before gnome-shell has a chance to show the switcher and take the active grab) from an Xwayland app to a native Wayland (gtk3) client using the keybinding, sometimes the Xwayland app will stay focused, although it will now be below the native client. I suspect it might be a race in how we process the FocusIn events from XWayland. It doesn't happen between two clients of the same type, and it doesn't happen in the opposite direction (native to XWayland). Also, the stacking is always correct, as far as I can see.
I dug into this and it comes down to libinput/evdev events having timestamps from a MONOTONIC clock while xwayland uses MONOTONIC_COARSE. Basically, the key event timestamp mutter gets from the kernel and ends up in the XSetInputFocus() call is ahead of the timestamp xwayland gets as currentTimestamp and thus we hit this path in dix/events.c:SetInputFocus() if ((CompareTimeStamps(time, currentTime) == LATER) || (CompareTimeStamps(time, focus->time) == EARLIER)) return Success; The kernel doesn't support using MONOTONIC_COARSE for evdev event timestamps but forcing xwayland to use plain MONOTONIC makes the issue go away AFAICT. Peter Hutterer says libinput really wants MONOTONIC anyway since some hardware has pretty high sampling rates which the COARSE clocks might not have enough resolution for. So perhaps the best fix for this is to change xwayland to use MONOTONIC too ?
There's a few other solutions: 1. The X server shouldn't reject events later currentTime plus a jiffy. 2. evdev also reports events with jiffy granularity. 3. We just patch the X server to use MONOTONIC instead of MONOTONIC_COARSE -- I've had a local patch for this for around a year. I also wonder if we can round to jiffy granularity in userspace as well.
FWIW, rounding to jiffy granularity in userspace (maybe right after we get the value from evdev) seems more robust to me. I understand that some applications want high resolution timestamps, but using them for focus stealing prevention seems just calling for subtle bugs.
I'm quite sure the kernel reports ns to jiffies in any robust manner, though. It depends on CONFIG_HZ, which the kernel doesn't export in any way. Supposedly, it's sysconf(_SC_CLK_TCK);, but that seems to be hardcoded to return 100 under glibc.
Well, we can just make it a configure parameter, and then tell distros to build the kernel, Xorg, and the shell with the same value or stuff breaks. Or we can grep /boot/config-$(uname -r) CONFIG_HZ Or we can assume HZ=1000 (it can't be higher than that), and round to 2 milliseconds. Which is almost the same as not rounding, if timestamps are milliseconds anyway.
Oh. I just found clock_getres. I think that should work fine on CLOCK_MONOTONIC_COARSE. (There is no guarantee that the kernel config is installed at that location -- it's definitely not on OSTree systems or our ARM system)
Ok, so what's going to be the fix here? Do we need to round in mutter or in Xwayland too? And why do we need to round at all, if Xwayland timestamps are 1ms granularity, and so is MONOTONIC_COARSE (according to clock_getres)?
*** Bug 758603 has been marked as a duplicate of this bug. ***
Jonas, since you've just looked at timestamp issues; mind giving this a look too ?
Created attachment 323468 [details] [review] xwayland: Force CLOCK_MONOTONIC usage Force Xwayland to use CLOCK_MONOTONIC for its timestamp. This avoids various race conditions when a timestamp from i.e. evdev is newer than a later retrieved timestamp in the X server.
I think the by far most reasonable thing is to use CLOCK_MONOTONIC in the X server. I sent a patch making that possible: https://lists.freedesktop.org/archives/xorg-devel/2016-March/049015.html
*** Bug 763966 has been marked as a duplicate of this bug. ***
This patch perfectly fixed this issue for me.
Patch has been merged upstream in Xwayland some time ago.
(In reply to Olivier Fourdan from comment #14) > Patch has been merged upstream in Xwayland some time ago. indeed
(In reply to Rui Matos from comment #15) > (In reply to Olivier Fourdan from comment #14) > > Patch has been merged upstream in Xwayland some time ago. > > indeed It is to be released with xorg-x11-server (xwayland) 1.19.x, right? This should be noted here in case somebody runs into this bug again (I do, regularly, on Fedora 24) and wonders why the bug is closed although it isn't fixed yet.
Jonas, do you know if the patch was merged? The last message I saw on the xorg mailing list was your v2 patch.
(In reply to Stephen from comment #17) > Jonas, do you know if the patch was merged? The last message I saw on the > xorg mailing list was your v2 patch. It was merged, but AFAICS there has been no release since.