b79eaf1184
wl_display_flush() can fail with EAGAIN and Xwayland would make this a fatal error. When this happens, it means that Xwayland has flooded the Wayland file descriptor, either because the Wayland compositor cannot cope or more likely because of a deadlock situation where the Wayland compositor is blocking, waiting for an X reply while Xwayland tries to write data to the Wayland file descriptor. The general consensus to avoid the deadlock is for the Wayland compositor to never issue blocking X11 roundtrips, but in practice blocking rountrips can occur in various places, including Xlib calls themselves so this is not always achievable without major surgery in the Wayland compositor/Window manager. What this patch does is to avoid dispatching to the Wayland file descriptor until it becomes available for writing again, while at the same time continue processing X11 requests to release the deadlock. This is not perfect, as there is still the possibility of another X client hammering the connection and we'll still fail writing to the Wayland connection eventually, but this improves things enough to avoid a 100% repeatable crash with vlc and gtkperf. Also, it is worth considering that window managers and Wayland compositors such as mutter already have a higher priority than other regular X clients thanks to XSyncSetPriority(), mitigating the risk. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1278159 Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763400 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com> |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| drm.xml | ||
| Makefile.am | ||
| xwayland-cursor.c | ||
| xwayland-cvt.c | ||
| xwayland-glamor-xv.c | ||
| xwayland-glamor.c | ||
| xwayland-input.c | ||
| xwayland-output.c | ||
| xwayland-shm.c | ||
| xwayland-vidmode.c | ||
| xwayland.c | ||
| xwayland.h | ||