Version
v2.25.2
Environment
OS: Debian testing
CPU: Intel Core i7-1360P
GPU 1: Intel Xe Graphics
Monitor Setup: Internal laptop monitor
What happened? What did you expect to happen?
libinput's philosophy is to offload the process of keeping track of FDs of event nodes to the program making use of libinput, by providing an instance of libinput_interface. libinput will automatically open and close event devices by using this interface. Mir implements this with its FdStore class. But the issue is that logind takes exclusive control of these event devices, and Mir fills its internal map of FDs by querying logind initially. If libinput asks for a FD, Mir will pass the same FD allocated by logind. Whenever the laptop is switched into tablet mode, evdev will suspend the trackpad, keyboard and trackpoint, which will cause libinput to call FdStore for closing the FD. I assume Mir developers figured out that you cannot close an FD allocated by logind, so all Mir does is remove the reference to the FD from its internal map. However, when you switch back to notebook mode, libinput will try to resume the devices it suspended, which makes it call FdStore to obtain an FD.
Now in normal circumstances you would just open the file again and pass an FD, but since logind has exclusive control over the event device, you can't do that. Moreover logind's concept of "paused" devices is vastly different from libinput's concept, which causes this issue to happen in the first place. If logind was correctly pausing and resuming devices, Mir would automatically refill its internal map of FDs with the resumed devices, as the logind_console class holds a list of acquired devices that it uses to fill the FdStore. Now in that video I made Mir not remove the FD from its map, however for e.g. the vt_console provider, the FDs are owned by Mir itself, so we'll have to close them. Now I don't really know how to go around this, so I figured I'd drop this here
Reproduction steps
It can be reproduced by sending a lid event or tablet-switch event to libinput, which causes it to suspend keyboard and trackpad.
Relevant log output
Version
v2.25.2
Environment
OS: Debian testing
CPU: Intel Core i7-1360P
GPU 1: Intel Xe Graphics
Monitor Setup: Internal laptop monitor
What happened? What did you expect to happen?
libinput's philosophy is to offload the process of keeping track of FDs of event nodes to the program making use of libinput, by providing an instance of libinput_interface. libinput will automatically open and close event devices by using this interface. Mir implements this with its FdStore class. But the issue is that logind takes exclusive control of these event devices, and Mir fills its internal map of FDs by querying logind initially. If libinput asks for a FD, Mir will pass the same FD allocated by logind. Whenever the laptop is switched into tablet mode, evdev will suspend the trackpad, keyboard and trackpoint, which will cause libinput to call FdStore for closing the FD. I assume Mir developers figured out that you cannot close an FD allocated by logind, so all Mir does is remove the reference to the FD from its internal map. However, when you switch back to notebook mode, libinput will try to resume the devices it suspended, which makes it call FdStore to obtain an FD.
Now in normal circumstances you would just open the file again and pass an FD, but since logind has exclusive control over the event device, you can't do that. Moreover logind's concept of "paused" devices is vastly different from libinput's concept, which causes this issue to happen in the first place. If logind was correctly pausing and resuming devices, Mir would automatically refill its internal map of FDs with the resumed devices, as the logind_console class holds a list of acquired devices that it uses to fill the FdStore. Now in that video I made Mir not remove the FD from its map, however for e.g. the vt_console provider, the FDs are owned by Mir itself, so we'll have to close them. Now I don't really know how to go around this, so I figured I'd drop this here
Reproduction steps
It can be reproduced by sending a lid event or tablet-switch event to libinput, which causes it to suspend keyboard and trackpad.
Relevant log output