Created attachment 131317 [details]
Outputs of a few commands
I'm running libinput 1.6.3 on Ubuntu 17.04. I noticed that Xorg does not detect the SW_TABLET_MODE event.
In fact, libinput doesn't seem to either. While evtest and evemu correctly report all the events, libinput-debug-events does not.
I attached a couple command outputs to show this.
The computer is a Lenovo ThinkPad X1 Yoga 1st gen, the device in question, as you'll able to see in the logs, is "ThinkPad Extra Buttons".
yeah, that code is simply missing right now. I assume there's code in the DE that handles it?
Relevant gnome-settings-demon bug: https://bugzilla.gnome.org/show_bug.cgi?id=740037
Which links to bug #86223 but that one only merged the switch interface, not the tablet mode code.
Relevant mutter bug:https://bugzilla.gnome.org/show_bug.cgi?id=744036
Looks like everyone is waiting for libinput, sorry about that.
Created attachment 131376 [details]
evemu recording from attachment 131317 [details]
branch for testing: https://github.com/whot/libinput/tree/wip/sw-tablet-mode
patches for review on the list: https://lists.freedesktop.org/archives/wayland-devel/2017-May/034120.html
I guess this needs testing. Is it okay if I cherry pick the patches and apply them to Ubuntu's source package to minimize incompatibilities?
should work, should even be ABI compatible (run-time anyway) if you have to remove it later (at least until we introduce some new switch that has the same value)
Davide - you got any status update for me here? What part of the DE handles the tablet mode anyway?
Created attachment 133629 [details]
Sorry I forgot about this. I'll set a reminder for next week to test it.
I don't know about what part of the DE handles it, I'm sure there are apps
(Onboard) that detect it and change their behavior accordingly.
On Fri, Aug 18, 2017 at 12:55 AM <firstname.lastname@example.org> wrote:
> *Comment # 7 <https://bugs.freedesktop.org/show_bug.cgi?id=101008#c7> on
> bug 101008 <https://bugs.freedesktop.org/show_bug.cgi?id=101008> from Peter
> Hutterer <email@example.com> *
> Davide - you got any status update for me here? What part of the DE handles the
> tablet mode anyway?
> You are receiving this mail because:
> - You are on the CC list for the bug.
> - You reported the bug.
what do you mean by "apps (Onboard)"? libinput only passes this on to the wayland compositor, nothing else would have access to it. So unless some compositor takes that switch event and sends it to a client (there's no public wayland protocol for that btw) no app can see it.
Unless you're using libinput in a direct context for some custom software, but that's not the case based on comment #0
I'm going to test the patch now. Sorry for the delay, I've been quite busy.
> what do you mean by "apps (Onboard)"? libinput only passes this on to the
> wayland compositor, nothing else would have access to it. So unless some
> compositor takes that switch event and sends it to a client (there's no
> public wayland protocol for that btw) no app can see it.
I'm not sure what happens under the hood, but Onboard has a setting regarding SW_TABLET_MODE. Maybe it works on Xorg only (which is what I mainly use by the way, I sometimes need to run GUI programs as root).
Here's a screenshot of Onboard settings: https://s26.postimg.org/5lv8bi7dl/Screenshot_from_2017-09-01_14-12-54.png
Okay, I replayed changes from your GitHub repository into Ubuntu's sources and built it. Basically nothing changed. 'libinput debug-events' shows nothing.
Evtest still shows the switch event.
- Add detection based on acpid reporting the SW_TABLET_MODE switch
So you need acpid running, and the code in question connects to /var/run/acpid.socket (see class AcpidListener). Didn't chase it down past that, but it means this is completely independent on libinput and I doubt onboard would use libinput anyway. Really this should be a compositor-wide state exposed via e.g. dbus or whatever.
That aside, this will get added as part of bug 102408 because that's a real use-case that we need to fix.
> So you need acpid running, and the code in question connects to /var/run/acpid.socket (see class AcpidListener).
Mmh that's weird because I have both acpid running and the socket.
I'll look at that at some point.
Let me know if you need me to test anything else.
By the way I still think application/shells may want to use SW_TABLET_MODE if that's possible (e.g change user interface based on that)
"may want to use" - if I could remove all the features I implemented in various software over the years and that never got used by anyone, things would be a lot easier to maintain ;)
Author: Peter Hutterer <firstname.lastname@example.org>
Date: Fri Apr 21 17:52:37 2017 +1000
Add support for SW_TABLET_MODE
Created attachment 138170 [details]
New events recording
I kind of forgot of this issue, but recently installed Arch Linux (libinput 1.10.3) and noticed that not only tablet mode is handled for the most parts, but that it's also somehow detecting tablet mode "correctly" (i.e. on my computer, tablet mode used to be triggered only when the laptop display was rotated completely, touching the back of the computer. It's now triggered as soon as it's past 180°).
I noticed the following issues on my computer, however:
- When tablet mode is ON, the trackpoint is disabled; the touchpad is not.
- My computer has a convenient volume rocker on the side and a Super button right under the touchscreen. When tablet mode is ON, they're disabled.
Notice that my computer physically blocks the keyboard past 180°, so there's no need to disable keyboard input in this particular model.
I recorded an event log. I only pressed the side and touchscreen buttons on this test, and as you can see they only work when it's not in tablet mode.
Created attachment 138171 [details]
Touchpad events recording
This log is for the touchpad that doesn't get disabled.
Davide, can I have separate bugs for those please, the code that originally fixed this is still there so I guess some kernel changes are the cause here.
> It's now triggered as soon as it's past 180°
fwiw, this is not something libinput controls, we merely get the message from the kernel but we don't know when that is generated. So great if it works better, but you probably have to thank the kernel developers for that :)
For the touchpad issue, I'll need the libinput debug-events --verbose output, thanks. The volume/keyboard thing is related to Bug 103749
Created attachment 138191 [details]
Touchpad events recording (verbose)
Okay, this is `debug-events --verbose` with some touchpad actions in tablet mode.
I'll subscribe to the other bug for the volume buttons issue.
By the way, the tablet mode triggering issue has been fixed in the thinkpad_acpi kernel module, indeed: