GNOME Bugzilla – Bug 658602
tablet rotation doesn't work
Last modified: 2015-02-04 17:55:46 UTC
I talked to Luke Macken who said that the touchpad rotation functionality should have landed in recent Fedora 16 builds. We made a live USB stick of the latest F16 nightly (Sep 7 2011) because we wanted to test it out. We tried it out on my Lenovo x61 wacom-based tablet. When we pressed the 'toolbox' hw button, nothing happens. (In Fedora 15, this button had triggered a screen lock.) When we pressed the 'tablet rotate' hw button, we get the 'touchpad disabled' OSD icon like so: http://farm7.static.flickr.com/6201/6128329586_e913ee015b.jpg The x61 doesn't actually have a touchpad, and I don't think touchpad isn't really related to screen rotation. This seems to be a bug so I hope this report is useful.
Sorry, I'm stupid, I meant tablet screen rotation, not touchpad rotation.
We have rotation support for tablets with an accelerometer, nothing else. And we don't know how to rotate wacom touchscreens (because it clashes with the user preferences in the Wacom panel). I would need to know what keysym the "toolbox" button produces (eg. the output of xev when that button is pressed). What is it supposed to do anyway? As for the "tablet rotate" button, it's badly setup in the kernel. You can work around that in udev (I'm guessing it's supposed to generate "XF86RotateWindows" instead).
Hi Bastien, when I rotated the tablet with the F16 nightly, it definitely didn't respond but I don't know if I had to enable the accelerometer first or what. when I run xev and press the 'toolbox' button in it, I get the following output in F15: FocusIn event, serial 29, synthetic NO, window 0x3400001, mode NotifyGrab, detail NotifyPointer KeymapNotify event, serial 29, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 FocusOut event, serial 29, synthetic NO, window 0x3400001, mode NotifyUngrab, detail NotifyPointer As for what the button is intended to do, it seems it's meant to bring up a tablet-specific preferences panel (I guess the Wacom panel?) Thanks for the hint on the tablet rotate button. Hope this is helpful.
Looks like something is already catching that button. Could you try disabling the media-keys plugin: gsettings set org.gnome.settings-daemon.plugins.media-keys active false and retrying with xev. We can easily make it launch the wacom panel, though it isn't exactly great for wacom touchscreen right now.
When I go to gnome-control-center and try to use the 'toolbox' button as a shortcut for anything, it lists the keypress as being 'Screensaver.' Every time I press it, even using xev or evtest, the button locks the screen but the screen lock shortcut in gnome-control-center is set to ctrl+alt+L, *not* 'Screensaver'. Even if I kill gnome-settings-daemon, the toolbox button brings up the screensaver. I went so far as to go into /usr/libexec, rename gnome-settings-daemon to gnome-settings-daemon-foo, kill -9 by pid number gnome-settings-daemon, and try to get the key in xev again, without luck. I killed gnome-screensaver, and pressing the button doesn't bring up the screen lock anymore, but I still can't get the screenpress from xev. After all the above xev gives me this with the toolbox button press: FocusIn event, serial 31, synthetic NO, window 0xa00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 31, synthetic NO, window 0x0, keys: 4294967214 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 MotionNotify event, serial 31, synthetic NO, window 0xa00001, root 0xae, subw 0x0, time 9464202, (68,95), root:(71,248), state 0x0, is_hint 0, same_screen YES Any other ideas? Something besides gnome-settings-daemon must be grabbing the key?
Not sure if this bug stands or is reproducible anymore, but if not even evtest on a tty sees the keypress, there's quite likely messages in dmesg about unknown keycodes having been pressed, in that case that's udev's hwdb setting an incomplete/incorrect keymap for that model. Also, note this keystroke runs through the "Thinkpad Extra Buttons" device, so evtest should be run on it.
The easiest to get those working is to capture the output of "evtest" (you'll need to run it as root, and select the correct device). That will allow us to find whether the keys are sending out the correct keycodes. If they're not correct, fixing them would involve modifying 60-keyboard.hwdb in systemd/udev. There's a list of hardware keys in: http://www.thinkwiki.org/wiki/Tablet_Hardware_Buttons#Linux_Support (I wouldn't follow any of the instructions in there, unless you want to break your system)
FWIW: thinkpad-scripts make more things work for me: https://github.com/martin-ueding/thinkpad-scripts I see it installs /lib/udev/hwdb.d/90-X2x0T-keyboard.hwdb: https://github.com/martin-ueding/thinkpad-scripts/blob/master/90-X2x0T-keyboard.hwdb
(In reply to comment #8) > FWIW: thinkpad-scripts make more things work for me: > https://github.com/martin-ueding/thinkpad-scripts > > I see it installs /lib/udev/hwdb.d/90-X2x0T-keyboard.hwdb: > https://github.com/martin-ueding/thinkpad-scripts/blob/master/90-X2x0T-keyboard.hwdb If that's all it takes, this should probably go into udev/systemd rather than in a third-party repo. Most of the rest of the stuff seems to be if you're running XFCE, or another "barebones" desktop.
What more information is required here? It might be nice to make the toolbox button act like the Logo key (since that is not available when the laptop is in tablet mode) and make the screen rotation button work as expected.
(In reply to comment #10) > What more information is required here? It might be nice to make the toolbox > button act like the Logo key (since that is not available when the laptop is in > tablet mode) and make the screen rotation button work as expected. 1) Making sure the kernel actually sends events 2) Finding out what those events are For making the toolbox button work differently in tablet mode and in laptop mode, you'd probably need to fix gnome-shell's D-Bus API (that particular one might already work), and add support for it in gnome-settings-daemon's media-keys plugin. I don't know what the screen rotation button is supposed to do. It would certainly be much easier to do all that if the person doing the work had access to the hardware.
I verified with evtest that the events were being emitted. I think this is accurate http://www.thinkwiki.org/wiki/Tablet_Hardware_Buttons#Linux_Support . If you want access to the hardware let me know. I can let you log in or just send it to you.
(In reply to comment #12) > I verified with evtest that the events were being emitted. I think this is > accurate http://www.thinkwiki.org/wiki/Tablet_Hardware_Buttons#Linux_Support . > If you want access to the hardware let me know. I can let you log in or just > send it to you. I can't do anything with scancodes. The kernel changes those scancodes to keycodes. I need to know the keycodes (which you can capture with evtest) to know what those would correspond to in X11 keysyms. Apart from the toolbox button which can allow us to go in/out of the overview, what was the other button (the "rotation" button) for?
Created attachment 290541 [details] [review] media-keys: Add support for the "toolbox" key The toolbox key on ThinkPad tablet-laptops is the button that's the closest to a "vendor" button. Map it to toggling in/out of the overview.
Note that the shell's OverviewActive property is broken right now.
Created attachment 290559 [details] [review] 60-keyboard.hwdb patch This seems to work on my IBM X41 Tablet.
Comment on attachment 290541 [details] [review] media-keys: Add support for the "toolbox" key XF86Tools is already used in actual keyboard keys, to launch the settings. Instead, we should just map that button to the left windows button at the udev level, and be done with it.
Comment on attachment 290559 [details] [review] 60-keyboard.hwdb patch Marking as obsolete as this particular patch is now upstream.
(In reply to comment #17) > (From update of attachment 290541 [details] [review]) > XF86Tools is already used in actual keyboard keys, to launch the settings. > > Instead, we should just map that button to the left windows button at the udev > level, and be done with it. Posted at: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/27892 Nothing else to do on the gnome-settings-daemon side, so closing this bug.