weird Xwayland and compositor deadlock issue [WAS: [PATCH xserver v2] xwayland: handle EAGAIN and EINTR gracefully]

[Daniel Stone]

Hi,

On 17 September 2016 at 08:21, Jasper St. Pierre <jstpierre at mecheye.net> wrote:
> Daniel suggested that timestamps *should* be on the same timebase.
> Currently, they are not. X11 server timestamps are
> CLOCK_MONOTONIC_COARSE-based and are calculated at delivery time, evdev
> timestamps are CLOCK_MONOTONIC-based and are calculated at input time. This
> is why there are several focus management bugs that happen when you replace
> meta_display_get_current_time_roundtrip() with a clock_gettime().
>
> We need to fix this, otherwise we can never properly synchronize X11 event
> streams and Wayland event streams. But Xorg calls GetCurrentTimeMillis()
> literally everywhere and compares against that instead of using evdev's own
> timestamps, and I doubt we can fix that without breaking multiple, multiple
> clients.

Part of this is untrue: a779fda224 back in May made the server use
CLOCK_MONOTONIC for GetTimeInMillis, and nothing broke. Secondly, it's
not calculated at delivery (ProcessInputEvents) time, but at reception
(was-SIGIO-now-thread) time. You're right that we can't move it to the
actual event timestamps, but that's true of anything which requires a
monotonic timestamp stream in the presence of multiple devices; you'd
need to read from all devices upfront, put all their events in a list,
then sort that list by timestamp before processing it. I don't believe
anyone does that. Either way, you can never do it in the server,
because whilst Wayland restricts timestamps to being on separated
per-seat timelines, X11 requires a global and queryable time base
across multiple domains, not just input.

Anyway, point is that unless a compositor is reusing event timestamps,
it's just fine, and if it is, it's probably not doing that sort and
thus broken anyway.

Cheers,
Daniel