#321 Second stylus button doesn't work with tablets based on Wacom Feel IT Technologies
Hello,
I already posted this bug on kernel bugzilla, but I think I can get more specific information on what I should do next.
To make it short, I bought a Fujitsu tablet with one-button stylus, and Fujitsu tablet driver is installed on that tablet. I later bought a "Fujitsu Digitizer pen T5000" with two buttons and eraser, sold from Fujitsu. With driver provided by Wacom, the second button works on Windows.
Now, the second button doesn't work on Linux.
My tablet (QH55/M) is based on "Wacom Feel IT Technologies".
Here's partial list of tablets based on WFITT.
So, Microsoft Surface Pro 2 for example, can also handle second button I belive.
I noticed HID descriptor of this tablet is weird. In Report ID 2, there's no Usage 0x5a (Barrel switch 2) but 0x00 (undefined). So I created a patch to see both of them identical. And now the second button works as a BTN_STYLUS2.
I'd like someone confirm the second button actually work on WFITT tablet, and implement this feature on mainline kernel. Apparently my patch needs improvement. What should I do next?
Thanks for the report. After looking through the HID descriptors I've collected from a few other tablets, I agree that this might affect many more devices than just yours. Although it looks like the 0x000D0000 usage is only used for the secondary barrel switch (well, aside from numerous "Feature" uses as well) I'm a little hesitant to say that we should use it as an indicator since Wacom could use it to mean other things in the future. I'd almost rather just have the barrel switch usage enable both BTN_STYLUS and BTN_STYLUS2 since there are very few devices I can think of which can only report a single side switch. Alternatively, we could try to see if the 0x00 appears where we would expect a 0x5a (since the layout of that first byte doesn't really change) or if the report layout matches that of other known-bad reports.
I'll see if I can get my hands on an affected tablet, though I think your diagnosis is sound :)
I've encountered the same problem on a cheap 2016 tablet called "Cube i7 Stylus" with the Top Barrel Button of a 2 button stylus (UP-911E-02DD) not working. It shows up in xsetwacom, I can -get and -set its parameter, but it has no action either way. Same pen works fine on Thinkpad X201T and X230T.
xsetwacom --list devices
Wacom HID 104 Pen stylus id:13 type: STYLUS
Wacom HID 104 Pen eraser id:16 type: ERASER
Anything I can do to assist you, please tell me.
Jason, sorry for the late reply. Actually, I have no idea how I should fix this issue. I did my best to make this hack, but I'm no kernel developer. Will you make a patch for me?
Tyson, will you post HID report descriptor? Here's how to dump it.
1. cat /proc/bus/input/devices
2. search for WACOM Pen device and copy "Sysfs". cd to two level up from the /sys/path/to/Sysfs. In my case, 'cd /sys/devices/platform/80860F41:05/i2c-5/i2c-WCOM0007:00/0018:056A:0124.0003'
3. You see 'report_descriptor' there. Please post this file.
4. (Optional but preferrable) Build https://github.com/DIGImend/hidrd and run 'hidrd-convert -o code report_descriptor' to parse it's content.
Besides, do X201W and X230T run linux? If not, please tell us.
Hi Masanori san,
The following are my report following your instruction:
cat /proc/bus/input/devices
I: Bus=0018 Vendor=056a Product=0104 Version=0100
N: Name="Wacom HID 104 Pen"
P: Phys=i2c-WCOM4002:01
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-WCOM4002:01/0018:056A:0104.0002/input/input12
U: Uniq=
H: Handlers=mouse0 event12
B: PROP=2
B: EV=b
B: KEY=c03 0 0 0 0 0
B: ABS=1000003
hidrd-convert -o code report_descriptor
0x05, 0x0D, / Usage Page (Digitizer), /
0x09, 0x02, / Usage (Pen), /
0xA1, 0x01, / Collection (Application), /
0x85, 0x02, / Report ID (2), /
0x09, 0x20, / Usage (Stylus), /
0xA1, 0x00, / Collection (Physical), /
0x09, 0x42, / Usage (Tip Switch), /
0x09, 0x44, / Usage (Barrel Switch), /
0x09, 0x45, / Usage (Eraser), /
0x09, 0x3C, / Usage (Invert), /
0x09, 0x00, / Usage (00h), /
0x09, 0x32, / Usage (In Range), /
0x15, 0x00, / Logical Minimum (0), /
0x25, 0x01, / Logical Maximum (1), /
0x75, 0x01, / Report Size (1), /
0x95, 0x06, / Report Count (6), /
0x81, 0x02, / Input (Variable), /
0x95, 0x02, / Report Count (2), /
0x81, 0x03, / Input (Constant, Variable), /
0x05, 0x01, / Usage Page (Desktop), /
0x09, 0x30, / Usage (X), /
0x26, 0xB0, 0x5B, / Logical Maximum (23472), /
0x46, 0xB0, 0x5B, / Physical Maximum (23472), /
0x65, 0x11, / Unit (Centimeter), /
0x55, 0x0D, / Unit Exponent (13), /
0x75, 0x10, / Report Size (16), /
0x95, 0x01, / Report Count (1), /
0x81, 0x02, / Input (Variable), /
0x09, 0x31, / Usage (Y), /
0x26, 0x93, 0x33, / Logical Maximum (13203), /
0x46, 0x93, 0x33, / Physical Maximum (13203), /
0x81, 0x02, / Input (Variable), /
0x45, 0x00, / Physical Maximum (0), /
0x65, 0x00, / Unit, /
0x55, 0x00, / Unit Exponent (0), /
0x05, 0x0D, / Usage Page (Digitizer), /
0x09, 0x30, / Usage (Tip Pressure), /
0x26, 0xFF, 0x03, / Logical Maximum (1023), /
0x81, 0x02, / Input (Variable), /
0xC0, / End Collection, /
0x09, 0x00, / Usage (00h), /
0x75, 0x08, / Report Size (8), /
0x26, 0xFF, 0x00, / Logical Maximum (255), /
0xB1, 0x12, / Feature (Variable, Non Linear), /
0x85, 0x03, / Report ID (3), /
0x09, 0x00, / Usage (00h), /
0x95, 0x10, / Report Count (16), /
0xB1, 0x12, / Feature (Variable, Non Linear), /
0x85, 0x04, / Report ID (4), /
0x09, 0x00, / Usage (00h), /
0xB1, 0x02, / Feature (Variable), /
0x85, 0x05, / Report ID (5), /
0x09, 0x00, / Usage (00h), /
0x95, 0x04, / Report Count (4), /
0xB1, 0x02, / Feature (Variable), /
0x85, 0x06, / Report ID (6), /
0x09, 0x00, / Usage (00h), /
0x95, 0x24, / Report Count (36), /
0xB1, 0x02, / Feature (Variable), /
0x85, 0x07, / Report ID (7), /
0x09, 0x00, / Usage (00h), /
0x95, 0x49, / Report Count (73), /
0xB1, 0x02, / Feature (Variable), /
0x85, 0x08, / Report ID (8), /
0x09, 0x00, / Usage (00h), /
0x95, 0x03, / Report Count (3), /
0xB1, 0x02, / Feature (Variable), /
0xC0 / End Collection /
Thinkpad X201T and X230T works under many Linux distributions since 2012. My 2-buttons pen worked fine on both of them. Ubuntu distros disable Hover Click by default. I have to use the following command to make them normal again:
xsetwacom --set "Wacom HID 104 Pen stylus" TabletPCButton off
Other distros like Manjaro handles everything just like Windows with Wacom Feel Driver installed.
I should also mention that on Ubuntu 14.04 to 16.04, Gnome Control Center >> Wacom Tablet >> Map Buttons does not receive button input from any Wacom tablets (although it detects and shows them). I have to use the following command to make them work:
gsettings set org.gnome.settings-daemon.plugins.gsdwacom active false
gsettings set org.gnome.settings-daemon.plugins.gsdwacom active true
Now you can Map buttons. However it'll stuck and block off all input of the system if you accidentally clicked tablet buttons when it awaits keyboard input to be assigned.
Tyson,
Your detailed report enlightened me. Now I'll post my result.
Also, I'll attach evtest result to show what is happening.
Well, my guess is only "Pen"s on i2c bus are affected by this issue. By the word "Pen" I mean device on the computer side.
Tyson, will you post above 3 result on X201T and evtest on Cube i7 to make things crystal clear? If my guess is right, evtest result on X201T contains BTN_STYLUS2 although that on Cube i7 doesn't.
Hi Masanori,
I tried to follow your instructions on all X201T, X230T and Cubei7. Everything went well except I couldn't obtain X201T's report_descriptor file. It seems X201T's Wacom device has completely different /sys/devices/... folder structure. I will attach its folders as a zip, maybe you can find something useful out of it.
I will also attach the each device's full evtest log and original report_descriptor files (if available) , pretty much everything I collected is inside that zip file. Hope it helps!
X201T cat /proc/bus/input/devices:
X230T cat /proc/bus/input/devices:
Cube i7 Stylus cat /proc/bus/input/devices:
X201T hidrd-convert -o code report_descriptor
X230T hidrd-convert -o code report_descriptor
Cube i7 Stylus hidrd-convert -o code report_descriptor
X201T evtest:
X230T evtest:
Cube i7 Stylus evtest:
Tyson Tan, Do any of those devices use a Wacom sensor for the touch device? If so, I'd appreciate if you could provide information on those as well, especially the report_descriptor file. The X201T, X230, and Cube i7 are all missing from the wacom-hid-descriptors repository which I use to figure out if kernel changes we make are compatible with existing tablets.
Hi Jason,
Only X230T has Wacom touch device. Cube i7 Stylus uses Fujitsu touchscreen. I will post everything I've found about X230T here. I hope they helps.
cat
report_descriptor
evtest
Thanks for the reminder about this bug. I've attached a patch that I think might do the trick, but I don't have any way to test it. If either of you could try checking out the "master" branch of input-wacom and applying/compiling/installing I'd love to know if it works.
Alternatively, you could use the hid-recorder tool to capture the raw hardware events that are sent by your tablet, which I can then replay these and see if they actually enable the BTN_STYLU2 event properly. Just run
hid-recorder > /tmp/logand choose your pen input device (if it isn't obvious which to choose, just run it once for each device, saving the results to e.g. /tmp/log.0, /tmp/log.1, etc.). Once its running, bring the pen into prox, press the lower switch, then the upper switch, and then remove the pen from prox. Finally, press CTRL+C to quit recording and attach the result for me to review.Tyson Tan, thank you for your info! It's great to know this is not just for me. But I'm afraid I can't do anything about this.
Hi, Jason
Thank you for writing a patch for me. But unfortunately your patch doesn't work. I added some code to yours to see what's wrong.
if (features->type == HID_GENERIC && usage->hid == 0x000D0000 && field->application == HID_DG_PEN && field->physical == HID_DG_STYLUS) { hid_info(wacom->hdev, "got inside\n"); struct hid_report *r = field->report; int i = field->index; hid_info(wacom->hdev, "%d\n", i); if (i-4 >= 0 && i+1 < HID_MAX_FIELDS) { hid_info(wacom->hdev, "passed index range check\n"); if (r->field[i-4]->usage->hid == HID_DG_TIPSWITCH && r->field[i-3]->usage->hid == HID_DG_BARRELSWITCH && r->field[i-2]->usage->hid == HID_DG_ERASER && r->field[i-1]->usage->hid == HID_DG_INVERT && r->field[i+1]->usage->hid == HID_DG_INRANGE) { hid_info(wacom->hdev, "got deep inside\n"); usage->hid = HID_DG_BARRELSWITCH2; } } }And this outputs following dmesg.
Hope this helps.
Last edit: Masanori SUTO 2016-09-20
Here's report_descriptors of QH55/M.
This tablet has touch input as well, so I think this helps development too.
Last edit: Masanori SUTO 2016-09-20
Thanks for testing the patch out. I have an updated version for you to try which will hopefully do the trick.
Hi Jason,
I used your patch on Ubuntu's Linux source package, version 4.4.0-38-generic_4.4.0-38.57. It worked! Thank you very much! :D
Now, are there any more tests I should run at this point? Or do we call it a day?
Also, when do we expect to see this patch land on Long Term Support Linux kernels, where non-tech users enjoy the benefit? The problem resides within kernel, too bad we can't just simply upgrade libwacom or xf86-input-wacom to do the trick.
Or is there a way to push this patch to Debian or Ubuntu, so athey can patch it before the official kernel catch up?
This patch works perfectly! The "Wacom HID 124 Pen" device reports BTN_STYLUS2 and it actually works. Thank you Jason!
Thanks for the feedback -- I'll see about getting the patch integrated upstream.
Unfortunately, its not likely that this patch would actually arrive in a kernel or distribution for quite some time. Even if this patch were accepted upstream without question (which is not guaranteed) it would likely be slated for the 4.9 kernel which isn't expected to be generally available until December and may take many more months to be picked up by distributions. LTS and distribution kernels aren't likely to pick up the patch either since they are very conservative and will typically only add fixes for panics and severe regressions.
The best course of action is to wait for the patch to land in "input-wacom". Its much easier to build and install than a full kernel and will provide a way for you to enjoy the benefits of the patch while waiting for the patch to make its way through the upstream and distribution processes. I'll post back when the patch has been added to input-wacom; this normally isn't too long after we receive word that the patch has been accepted upstream.
It seems like this patch didn't make it to 4.9? For whatever reason, the second button started working in Xournal for me (but I don't see anything with e.g. xev) since upgrading to 4.9 :)
Interesting that its started working for you after upgrading to 4.9. You're correct -- the patch that I posted above did not make it into 4.9, although it has been pulled by Linus into his 4.10 tree. I completley forgot to update this bug after the pull...
Fixed upstream by commit 6005a13. Expected release: Linux 4.10.
Fixed in input-wacom by commits 0c73651 (import) and 0838341(backport). Expected release: input-wacom 0.33.0
"Fix available in Linux 4.10 and input-wacom 0.33.0"