Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1358816 - Only one stylus button recognized on ThinkPad Yoga 260
Summary: Only one stylus button recognized on ThinkPad Yoga 260
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-wacom
Version: 24
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-21 14:24 UTC by Steven D.
Modified: 2016-10-07 16:59 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-07 16:41:20 UTC


Attachments (Terms of Use)
evemu-record on top button (working) (deleted)
2016-07-22 03:42 UTC, Steven D.
no flags Details
evemu-record on bottom button (not working) (deleted)
2016-07-22 03:43 UTC, Steven D.
no flags Details
hid-recorder output corresponding to three press-release cycles of non-functional button (deleted)
2016-09-01 15:45 UTC, Steven D.
no flags Details

Description Steven D. 2016-07-21 14:24:15 UTC
Description of problem:
Only one of the two buttons on the ThinkPad Yoga 260 active pen is recognized by the system. The bottom button is not recognized. `xev` seems to return no events for the button.


How reproducible:
Always

Steps to Reproduce:
Press bottom button of pen

Actual results:
Nothing happens

Expected results:
Button should be recognized by system

Additional info:
`lsusb`: Bus 001 Device 005: ID 056a:5044 Wacom Co., Ltd

Comment 1 Peter Hutterer 2016-07-22 01:47:48 UTC
record the device with evemu-record and attach the output here please. both button events, thanks.

Comment 2 Steven D. 2016-07-22 03:42:54 UTC
Created attachment 1182689 [details]
evemu-record on top button (working)

Three press-and-release cycles

Comment 3 Steven D. 2016-07-22 03:43:53 UTC
Created attachment 1182690 [details]
evemu-record on bottom button (not working)

Corresponds to three press-and-release cycles

Comment 4 Steven D. 2016-07-22 03:46:17 UTC
Attached as requested. Seems the bottom button is detected at least! Thanks Peter.

Comment 5 Steven D. 2016-08-29 15:10:27 UTC
Peter, 

Is there any other way I can be of assistance in resolving this issue? Just let me know.

Comment 6 Peter Hutterer 2016-08-29 20:59:04 UTC
looks like a kernel issue, BTN_STYLUS is reported, BTN_STYLUS2 is missing in action.

Comment 7 Benjamin Tissoires 2016-08-31 06:49:29 UTC
Could you attach the hid-recorder (package hid-replay) output of the stylus when pressing the failing button?

This way, we will see if the stylus actually sends the buttons and where the kernel driver fails.

Comment 8 Steven D. 2016-09-01 15:45:37 UTC
Created attachment 1196885 [details]
hid-recorder output corresponding to three press-release cycles of non-functional button

As requested

Comment 9 Benjamin Tissoires 2016-09-05 15:53:57 UTC
Thanks for the logs. It looks like the bottom button is acting like a modifier on the tip switch. If you press it while touching the surface with the tip, we receive an "invert" event meaning that the tool is pressed upside down.

This is common for the Surface line, but not so for Wacom. There is an other collection of input reports in the device that seems really close to the one you are using. Maybe if we switch the device to report the other collection we will get the classical buttons.

I'll ask Wacom about that.

Comment 10 Benjamin Tissoires 2016-10-07 16:41:20 UTC
Looks like I forgot to update the bug after Wacom's answer. Sorry for that.

So basically, it looks like this is the expected behavior (by design) and so there is not much we can do from our side. We tend to stick to the design, and in that case, it might not be that convenient for you :(

Closing the bug given that o extra step will be taken upstream for it unfortunately.

Comment 11 Steven D. 2016-10-07 16:49:37 UTC
It makes sense that it's a modifier and shoukd stay that way. In this case, is the issue that Gnome isnt letting me assign an action to the back of the pen, for example? In that case I could submit a bug for Gnome?

Comment 12 Benjamin Tissoires 2016-10-07 16:59:05 UTC
(In reply to Steven D. from comment #11)
> It makes sense that it's a modifier and shoukd stay that way. In this case,
> is the issue that Gnome isnt letting me assign an action to the back of the
> pen, for example? In that case I could submit a bug for Gnome?

Feel free to submit a bug for Gnome to enhance support of these type of pens. Please use the Gnome bugzilla, not the Red Hat one, or your request will probably get ignored.


Note You need to log in before you can comment on or make changes to this bug.