Bug 499807

Summary: kwin does not suspend the touchpad when the touchpad is disabled
Product: [Plasma] kwin Reporter: Werner Sembach [TUXEDO] <wse>
Component: libinputAssignee: KWin default assignee <kwin-bugs-null>
Status: CONFIRMED ---    
Severity: normal CC: nate
Priority: NOR    
Version First Reported In: 6.2.5   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: qdbus touchpad enabled
qdbus touchpad disabled

Description Werner Sembach [TUXEDO] 2025-02-11 10:47:34 UTC 
SUMMARY
Comming from here: https://gitlab.freedesktop.org/libinput/libinput/-/issues/558#note_2773967
Unlike Gnome (Wayland), Plasma (Wayland) seems to not close the respective file descriptor of the /sys/class/input/event* node when the touchpad is disabled. This is relevant for the kernel to know when the touchpad is actually in use and when it can be deactivated, safeing some battery life and triggering touchpad enabled/disabled leds.

STEPS TO REPRODUCE
1. Deactivate touchpad e.g. by using a shortcut

OBSERVED RESULT
The kernel does not see a change in the file descriptor open count.

EXPECTED RESULT
The file descriptor is closed and kernel can react to it.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.2.5
KDE Plasma Version: 6.2.5 (Wayland)
KDE Frameworks Version: 6.10.0
Qt Version: 6.8.1

ADDITIONAL INFORMATION
All my knowledge about libinput comes from the libinput issue I linked above, so please excuse some errors and vagueness and this is my guess based in this xD:
Gnome and Plasma seem to use libinput, which handles the file descriptors, differently. Especially: While switching from Plasma to a TTY libinput_suspend() and libinput_resume() seem to be called accordingly, they seem not to be called when enabling or disabling the touchpad in Plasma. From the perspective on libinput the touchpad seems to always be active.
Comment 1 Vlad Zahorodnii 2025-02-11 14:12:24 UTC 
I left a message in the upstream issue, not sure that the compositor has to close file descriptors manually. If it needs to do so though, we would need some major changes around input device tracking, which won't be great...
Comment 2 Vlad Zahorodnii 2025-02-11 14:58:09 UTC 
Can you please run

  qdbus org.kde.KWin /org/kde/KWin/InputDevice/event0 org.freedesktop.DBus.Properties.GetAll org.kde.KWin.InputDevice

where event0 is the name of the touchpad input device
Comment 3 Werner Sembach [TUXEDO] 2025-02-11 17:14:07 UTC 
Created attachment 178154 [details]
qdbus touchpad enabled
Comment 4 Werner Sembach [TUXEDO] 2025-02-11 17:14:28 UTC 
Created attachment 178155 [details]
qdbus touchpad disabled
Comment 5 Werner Sembach [TUXEDO] 2025-02-11 17:14:45 UTC 
(In reply to Vlad Zahorodnii from comment #2)
> Can you please run
> 
>   qdbus org.kde.KWin /org/kde/KWin/InputDevice/event0
> org.freedesktop.DBus.Properties.GetAll org.kde.KWin.InputDevice
> 
> where event0 is the name of the touchpad input device

ofc see attachments above
Comment 6 Vlad Zahorodnii 2025-02-11 18:22:55 UTC 
Okay,

supportsDisableEvents: true
supportsDisableEventsOnExternalMouse: true

are fine. I'm not sure what we can do on the kwin side. kwin will call libinput_device_config_send_events_set_mode() with LIBINPUT_CONFIG_SEND_EVENTS_DISABLED if a touchpad is disabled. And as I said previously, I don't think we will be able to support closing input device fds manually, it will make input device management very difficult, and maybe it's a libinput bug. If the input device file descriptor needs to be closed, libinput could do it in libinput_device_config_send_events_set_mode() while still keeping the libinput_device object alive.
Comment 7 Werner Sembach [TUXEDO] 2025-02-11 21:33:01 UTC 
(In reply to Vlad Zahorodnii from comment #6)
> Okay,
> 
> supportsDisableEvents: true
> supportsDisableEventsOnExternalMouse: true
> 
> are fine. I'm not sure what we can do on the kwin side. kwin will call
> libinput_device_config_send_events_set_mode() with
> LIBINPUT_CONFIG_SEND_EVENTS_DISABLED if a touchpad is disabled. And as I
> said previously, I don't think we will be able to support closing input
> device fds manually, it will make input device management very difficult,
> and maybe it's a libinput bug. If the input device file descriptor needs to
> be closed, libinput could do it in
> libinput_device_config_send_events_set_mode() while still keeping the
> libinput_device object alive.

New infos: I added some printf debugging to the kernel, when on desktop there are actually 2 file descriptors open for the touchpad, only one gets closed when deactivating it.

Some something else, maybe unrelated to kwin, is also listening to it?
Comment 8 Vlad Zahorodnii 2025-02-12 12:03:16 UTC 
(In reply to Werner Sembach [TUXEDO] from comment #7)
> (In reply to Vlad Zahorodnii from comment #6)
> > Okay,
> > 
> > supportsDisableEvents: true
> > supportsDisableEventsOnExternalMouse: true
> > 
> > are fine. I'm not sure what we can do on the kwin side. kwin will call
> > libinput_device_config_send_events_set_mode() with
> > LIBINPUT_CONFIG_SEND_EVENTS_DISABLED if a touchpad is disabled. And as I
> > said previously, I don't think we will be able to support closing input
> > device fds manually, it will make input device management very difficult,
> > and maybe it's a libinput bug. If the input device file descriptor needs to
> > be closed, libinput could do it in
> > libinput_device_config_send_events_set_mode() while still keeping the
> > libinput_device object alive.
> 
> New infos: I added some printf debugging to the kernel, when on desktop
> there are actually 2 file descriptors open for the touchpad, only one gets
> closed when deactivating it.
> 
> Some something else, maybe unrelated to kwin, is also listening to it?

Maybe it's logind? kwin uses it to open device files that require special privileges.