GNOME Bugzilla – Bug 679077
The buttons mapping on the pad are lost as soon as left-handed is set/unset
Last modified: 2012-07-02 17:02:20 UTC
On a tablet with a pad device, changing the left-handed settings causes all buttons on the pad to stop working.
Created attachment 217549 [details] [review] Proposed patch Proposed fix, rotation does (and should) not apply to the pad device.
Review of attachment 217549 [details] [review]: ACK, but this patch just works around it - what actually unsets the buttons when the rotation is triggered?
(In reply to comment #2) > Review of attachment 217549 [details] [review]: > > ACK, but this patch just works around it - what actually unsets the buttons > when the rotation is triggered? g-s-d doesn't seem to be the problem here, I disabled all but the Wacom plugin and the buttons are still reset when changing orientation of the tablet, so that rules out all other plugins (including the mouse plugin).
Can we get some detail on why this patch is rejected now although it was previously approved in comment #2?
It wasn't approved, Peter reviewed it. I'd rather the driver was fixed instead.
Note that patch is probably still needed also because Peter posted a patch on Linuxwacom-devel to remove the rotation property on the pad, so without this patch g-s-d would try to set a non-existing property.
Then a comment to that effect in the patch would be appreciated.
Comment on attachment 217549 [details] [review] Proposed patch Don't forget to change the commit message to match the effects with Peter's patch.
Thanks, committed with the following message instead: wacom: do not rotate pad devices as the rotation property is to be removed on pad devices in the driver. https://bugzilla.gnome.org/show_bug.cgi?id=679077
(In reply to comment #5) > I'd rather the driver was fixed instead. The driver sends the same button numbers regardless of rotation. These events are grabbed by g-s-d and converted to XTest key events, respective to their mapping, so if that mapping is lost, it's somewhere inside g-s-d.
(In reply to comment #10) > (In reply to comment #5) > > I'd rather the driver was fixed instead. > > The driver sends the same button numbers regardless of rotation. These events > are grabbed by g-s-d and converted to XTest key events, respective to their > mapping, so if that mapping is lost, it's somewhere inside g-s-d. Err nope, I am really not seeing this in the code. Button mapping is set in reset_pad_buttons() which calls XSetDeviceButtonMapping() reset_pad_buttons() is called on pad devices from set_wacom_settings() set_wacom_settings() is called from device_added_cb() which is the callback for newly added devices. The call stack is as follow: device_added_cb() +-> set_wacom_settings() +-> reset_pad_buttons() +-> XSetDeviceButtonMapping() Reverting this patch from attachment 217549 [details] [review] and running gnome-settings-daemon within gdb with a breakpoint on XSetDeviceButtonMapping() shows that XSetDeviceButtonMapping() is not called from g-s-d (from any plugin) while rotation is applied yet the button mapping is lost.
Actually it seems g-s-d loses the passive grab it installed on the root win for those buttons.
Debugging from the XServer shows the passive grab is lost because the device is closed: Breakpoint 3, DeletePassiveGrab (value=0x1df8050, id=1105199549) at grabs.c:314 314 { (gdb) bt
+ Trace 230461
Argh, the CSS in bugzilla.gnome.org is hiding most of my previous comment 13 ... What that comment was saying is that the passive grab is removed because the device is closed by gnome-settings-daemon and the device is closed from wacom_set_property()
(In reply to comment #14) > Argh, the CSS in bugzilla.gnome.org is hiding most of my previous comment 13 Click on the link, and you'll get the full trace, eg. https://bugzilla.gnome.org/page.cgi?id=trace.html&trace_id=230461 > What that comment was saying is that the passive grab is removed because the > device is closed by gnome-settings-daemon and the device is closed from > wacom_set_property()