[Wayland-bugs] [Bug 99645] Input Stops When Wayland Client Freezes

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99645

--- Comment #3 from Daniel Stone <daniel at fooishbar.org> ---
(In reply to Antoine Saroufim from comment #2)
> It's not just Mutter. Retroarch can run on Wayland directly without an
> intermediary client (it acts as its own client) and it displayed the same
> behavior too.

Wayland is not (for all but the most pedantic definitions) a piece of software;
it is a protocol. Mutter 'running directly on Wayland' means that Mutter is
using Clutter and Cogl to drive GBM/EGL/GLES for rendering, controlling KMS
directly through ioctls/libdrm, and handling input directly using libinput. The
fact that it is also a Wayland server does not affect how this operates.

Similarly, it seems that retroarch does exactly that, and Wayland is _not_
involved. In this case (running without a Wayland server), that makes RetroArch
a DRM/KMS client.

> When it couldn't grab the input, nothing else did and the
> system stopped receiving input altogether. What I'm trying to say is that
> one system component or the other should always be ready to grab the input
> if the Wayland client releases it

The compositor, be it Mutter, RetroArch, or whatever, is in total and ultimate
control of input. It receives input (through evdev directly or via libinput),
and processes each and every single event, regardless of whether or not a
client is fullscreen. Whatever is receiving the events from the kernel has the
opportunity to decide how to route every single event: the client does _not_
have a direct bypass path.

> or at least always be ready to respond to
> certain keyboard configurations such as the panic button combination
> (control + alt + delete pressed repeatedly) to rescue the system.

Yep. Everyone who handles input should have this.

> With X, it
> was possible to kill the X server and force it to restart by hitting a
> certain keyboard combination (control alt backspace if enabled).

Funnily enough, there were many situations in which this didn't actually work.

> I understand that the Wayland protocol itself might not be the right component
> to handle such a situation but I am not entirely sure who should. The
> kernel? systemd? Libinput? The wayland clients themselves? I'm not entirely
> sure where to take this issue up and that's why I brought it here.

The kernel handles SysRq directly, so if that doesn't work, then it is
unequivocally a kernel bug. Whoever handles the low-level display (Mutter when
running natively, RetroArch when running directly on DRM/KMS and not via
Wayland, etc - the lowest component before you hit the kernel) also handles the
input, so they are the ones who need to ensure they're responsive to Alt-Tab or
other combinations which would allow you to break away.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20170202/d0f75a8e/attachment.html>