When a fullscreen wayland client (gnome-shell, retroarch) freezes, the system stops receivng input at all. The num lock wouldn't turn off or on anymore, systemd wouldn't receive the panic button combination, and the Linux kernel wouldn't respond to direct system reqs. Even if the client freezes, systemd and the kernel should still be able to listen to keyboard requests in case something goes wrong. It should be worth noting that once the wayland client recovers, the keyboard input would resume as if nothing happened. User case 1: Gnome-music froze in a gnome-wayland session. The entire system just froze until gnome-shell decided to ask whether or not the unresponsive window should be terminated. Once gnome-shell decided to make that inquiry, input was functional again. User Case 2: Retroarch was started as a direct wayland client. The user was not added to the input group. Input froze and the system had to be restarted physically. If retroarch was started within a gnome-wayland session, it would not receive input but gnome-shell still did. Additional information: Using Arch Linux x86_64 Libinput 1.6.0 Wayland 1.12.0.-1 Kernel: 4.9.6-1 systemd: 232-8 GNOME: 3.22.2 User added to Input group.
The Wayland protocol itself does not implement raw input-handling behaviour. It sounds like you are asking for Mutter (the base of GNOME Shell) to have slightly smarter input handling, and also asking that the kernel continues to handle SysRq keys in situations it currently doesn't. (As an aside, I'm fairly surprised that things like Alt-Tab or pressing the Windows key to get the window-switcher view didn't work when GNOME Music hung, given that there are no client-exclusive keyboard grab modes, and I've never seen those fail even with hung clients ... ?)
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. 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 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. 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). 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.
(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.
Thanks for taking the time to explain things properly. I filed bug reports to the Kernel and GNOME bugzillas (https://bugzilla.kernel.org/show_bug.cgi?id=193841 https://bugzilla.gnome.org/show_bug.cgi?id=778091)
No problem, thanks very much for going through it! Hope it all works out. :)
The kernel does handle SysRq directly, however if input device (keyboard) is "grabbed" by userspace, then it will not be included in SysRq handling. Does anyone (gnome shell, etc) issue EVIOCGRAB?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.