On Wayland it shows a message that no touchpad is connected. Would it be possible on X to determine if a to-be-connected touchpad would use libinput or Xlib (although the use case is pretty rare of a detechable touchpad)?
Roman, with this patch the box with 'No touchpad found' is shown under X11, too:
Since I'm not the author of the code my intention was to fix the bug with as little side effects as possible. In Plasma 5.15 the code created a TouchpadConfigXlib instance in case there was no touchpad, so that's what I went with here. If the user plugs in a device later, it looks like that should trigger XlibBackend::devicePlugged() which will reset the mode to the correct mode (see findTouchpad()). The next time the KCM touchpad is opened it should then show the correct set of (activated) controls.
Yea, didn't mean this patch shouldn't go in. Was just some contemplating on what's the strategy moving forward.
If the user plugs in a device later, it looks like that should trigger XlibBackend::devicePlugged() which will reset the mode to the correct mode (see findTouchpad()). The next time the KCM touchpad is opened it should then show the correct set of (activated) controls.
Ok, that would be even better. Only drawback is then that it shows the "wrong" interface in case libinput is used until a touchpad is plugged, but that's such an uncommon case that I don't think we should invest much more time into it. On the other side since libinput is the default backend in the future it might make more sense to show the libinput one per default if no touchpad is plugged in. Would this also be possible or is the current X libinput backend missing this funcitonality? At least from user perspective it could be confusing to see the non-default backend on the workstation without touchpad and something completely different on his laptop.
I think one could set m_plugin to "TouchpadConfigLibinput(this, backend)" (as would be the case with a libinput touchpad). I just tried that, this produces the following result:
That doesn't look right to me? Maybe because TouchpadConfigContainer::kcmInit() is a no-op (first because the mode is Unset, so neither of the two if branches triggers, but even if that is fixed it's a noop because m_device is null in the xlibbackend).
- Controls not disabled
- "Two-finger-tap" radio buttons are missing their labels
- Middle-click label missing its radio buttons
And then of course, unrelated to this patch or bug, is https://bugs.kde.org/show_bug.cgi?id=407464
Yes, thats it. I think the libinput widget depends on the specifics of the device (of which there is none)? I would go with the version I initially proposed personally (at least for now).
Yes, let's do that. Add a comment to the code that we fallback to evdev for now if no touchpad is connected and we want to show instead libinput in the future when the issues have been resolved.