Menu
▾
▴
1 Attachments
#335 Wacom HID 4822 and Wacom HID 4824 touchscreens behave like mouse (no pitch to zoom, no gestures, so scrolling, etc.) and report non-existing battery
Dell XPS 12 9250:
~$ xsetwacom --list
Wacom HID 4822 Pen stylus id: 10 type: STYLUS
Wacom HID 4822 Finger touch id: 11 type: TOUCH
Wacom HID 4822 Pen eraser id: 17 type: ERASER
Dell Venue 8 Pro 5855:
~$ xsetwacom --list
Wacom HID 4824 Pen stylus id: 7 type: STYLUS
Wacom HID 4824 Finger touch id: 8 type: TOUCH
Wacom HID 4824 Pen eraser id: 13 type: ERASER
Both touchscreens behave like mouse (no pitch to zoom, no gestures, so scrolling, etc.) and report non-existing battery.
Logs from Dell XPS 12 9250 as attached.
xinput test-xi2 --root "Wacom HID 4822 Finger touch"
Xorg log.
Firstly, it looks like we've never seen either of these Dell systems before. Would you mind running our sysinfo.sh script on each and uploading the results?
Next, it looks like both of these tablets use Wacom's battery-powered "AES" pen technology. The battery status that is reported should indicate the state of the pen's internal battery. Some AES pens use user-replaceable AAAA batteries while others use "supercapacitors" that can be recharged by placing them in the tablet's pen holder for a few seconds. I dont' see any kind of pen holder in the photos I can see online, so I assume they use the AAAA variety...
Finally, looking through your log from "xinput test-xi2", it does appear that gestures are being activated. There are a series of "RawButtonPress" and "RawButtonRelease" events for mouse button 4, which corresponds to "mousewheel up" (which should cause most applications to scroll up). All touch gestures are "faked" keyboard/mouse events (scrolling events send mousewheel up/down; zoom events send CTRL+mousewheel events).
What applications have you tried scrolling in? What distribution are you using, and what desktop environment is in use? I should note that if you're trying to use your distribution's built-in gesture support (e.g. Ubuntu and GNOME recongize some 3- and 4-finger gestures), the default driver configuration will prevent these from working. For the moment though, I assume you're talking about regular scroll and zoom gestures as supported by our driver...
Dell XPS 12 9250
Tested distributions is Ubuntu Gnome 16.10 and 17.04.
Tested application is Opera web-browser, where zoom and scroll gestures works fine with Silead and Goodix touchscreen drivers.
Dell Venue 8 Pro 5855
Another tested application: Gnome Maps.
UPD. I tested Gnome Maps with Synaptics touchscreen and fine that pinch-to-zoon is unsupported by application. So in case of Gnome Maps this is not driver issue.
Last edit: RunetMember 2017-04-02
I tested wacom driver with "Gesture" "off".
On Dell 9250 with Wacom HID 4822 this lead to expected behaviour - now all gestures working with Gnome Shell, Opera and other applications.
On Dell 5855 with Wacom HID 4824 disabling Gestures allowed me to scroll pages with one finger in Opera, but gestures with two (or more) fingers still doesn't work (so no pinch-to-zoom) anywhere.
Moreover, attempt to use four-finger gesture with Wacom HID 4824 seems like put driver to semi-broken state - one finger scrolling stop working, only tap and drag gestures continue to working.
I attached log with attempt to pinch-to-zoon (Opera gesture) then attempt to four-finger workspace switch (Gnome Shell gesture) and then one finger scrolling (Opera gesture).
Please let me know if I need to register separate issue about driver defaults for Wacom HID 4822/4824 tablet's touchscreens - as far I know "Gesture" "off" is what expected by applications (applications gestures works only if raw data passed by the driver) and by user - in my opinion user expect from tablet PC touchscreen driver behaviour which is natural for this class of devices. Default to "Gesture" "on" is probably good idea for devices with integrated display made by Wacom. But default to "Gesture" "on" for tablet PC probably not so good idea.
How Wacom driver behave with other tablet PC devices that is already in database?
Also, please let me know if need to register separate issue about Wacom HID 4824 problems?
Last edit: RunetMember 2017-04-02
Thanks for the logs. Looking into them, it appears that there aren't any multitouch events actually being sent. Since the code in the X driver which handles the "Gesture" "off" case is so simple, I'm suspicious of an issue with the kernel driver. Between 4.10 (used by your 9250) and 4.11 (used by your 5855) there were some changes to add support for the touchpad on the new Intuos Pro. Its possible that the new code has caused a regression in tablet PC support.
To get a bit more information, please install the
evemu-toolspackage on your Dell 5855 and also follow the instructions at https://bentiss.github.io/hid-replay-docs/ to install the hid-replay tool suite. Once that's done, please download and run the script at https://gist.github.com/jigpu/b7b47e4bede584cec8562f666fd84af4 as root. The script will ask you to select an ID number: enter that of the touchscreen. Next, repeat the one / two / four / one finger gesture test that you did earlier. Afterwards, press CTRL+C to stop the capture and upload the results.With regard to changing the default setting of the "Gesture" property, we'll probably need to start some discussion about that. You're absolutely correct that "off" produces behavior more in line with how touchscreens typically work. The reason for "on" being the default is that Linux has historically had pretty poor touch support and we wanted to offer the ability to perform simple drag/scroll/zoom operations to applications that only understood basic keyboard & mouse events. Now that more applications and desktops are able to understand XI2 multitouch events, perhaps its time to investigate just how widespread the support is and determine if we want to change the default. That, or we may want to encourge projects like GNOME which have better multitouch support to turn our gestures "off" on their own -- it might be a good comprimise if things dont' seem quite widespread enough...
Couple of news to share:
On Dell 9250 two times I was able to put driver into state when one finger scrolling stop working, only tap and drag gestures continue to working. That was with Linux 4.10.6
On Dell 5855 I was able to get pinch-to-zoom working three times, two of them while logs recording. That was with Linux 4.11rc4 from Intel's drm-tip (drm-tip usage required to get display working).
I done logs recording. In the recording I launch Opera, open web-site, trying to pinch-to-zoom (two attempts were successfull and the rest is not, as you can see) then attemtp to switch workspaces with four-finger gesture (unsuccessful, but for some reason this one attempt wasn't enough to put driver into semi-broken state, so few attempts has been made; usually one or two attempt is always enough) and then attempt for one finger scroll (which is stop working).
In separate bugreport or in mail-list?
Last edit: RunetMember 2017-04-04
Regarding discussing a change to the "Gesture" default, I'd suggest bringing it up on the mailinglist. It tends to get more eyeballs than the bug tracker.
As for the bug...
After combing through the data you've provided, It looks like both of these devices (and several others, upon review) have bugs in their HID descriptors, causing the kernel to behave incorrectly when processing events. Specifically, it looks like Wacom forgot to set the range of values that should be accepted for the "Contact identifier". As far as the kernel can tell, the only valid identifiers are "0" or "1". Coupled with the fact that the ID of the first touch is "1", things can go screwy as soon as a second finger goes down.
Until recently, our driver didn't validate that values from the hardware were within the valid range. It would just use the values as-is. This was changed by commit 60a221869803 (part of Linux 4.11) since we were seeing that some hardware was sending invalid out-of-range values. The HID specification says that values outside of the valid range may be ignored in some circumstances, so we added the logic to do so.
Probably the easiest thing to do would be to have the kernel allow out-of-range identifiers, but I'm not sure if upstream would accept that as a reasonable fix or not. I'll try to think of some alternate solutions and get this fixed as soon as possible.
I've just pushed a branch to my Github which should fix this for you. Please follow the input-wacom instructions, except replacing the instructions in the "Download" section with the following (you may need to install 'git' from your package manager):
$ git clone https://github.com/jigpu/input-wacom -b fix/contactid $ cd input-wacomFollow the rest of the instructions for configuring/compiling/installing/loading the driver as normal. Let me know if the updated driver seems to work properly (as with your 9250, you may need to turn "Gesture" "off" in the X driver for the time being). If not, please ensure that the output of
cat /sys/module/wacom*/versioncontains the following output:v2.00-0.35.0.1.g2565d79-- if not, it means that the replacement driver has not loaded for some reason.I assume that you as developer could better describe whole idea. If possible, could you please start thread on mail-list? I will subcribe and comment, if it will be necessary.
Thank you for working on this! :)
I installed this version (and verified /sys/module/wacom/version) on both 9250 and 5855 (because on 9250 with Linux 4.10 driver sometimes also get into semi-broken state) but so far tested only 5855. Results:
Last edit: RunetMember 2017-04-14
I am drafing an email to start the discussion and will let you know when its posted :)
Looking at your logs, it appears that the driver is still getting confused by the multitouch input. I don't see the same behavior when replaying them locally using my Github branch, however. All the events are reported up to userspace correctly and I see the e.g. pinch-zoom events in Chrome.
Can you double-check that the output of
cat /sys/module/wacom*/versioncontains the following output:v2.00-0.35.0.1.g2565d79? It very much sounds like the updated driver hasn't been loaded. You might try rebooting, verifying the "cat" output, and then testing again.Okay.
Sure, there is output from Dell 9250:
And there is output from Dell 5855:
For me it's seems like with this build of the driver it became harder to put driver into semi-broken state on Dell 5855 (previously it was easy to do so with two finger gestures, now it's harder to do with two finger gestures, but three-four finger gestures still allow me to reproduce this issue easily).
Just wondering, if you are aware SourceFourge Bugtracker seems like very broken? It's silently ignore new messages, and silently ignore edits. To post this whole post I have to post short message, then edit it, then edit once again (only little changes was accepted and applied, big changes is ignored and post remain unchanged) few times like that. My previous post was also written in two-three steps (for example I wasn't able to attach files on posting new message, only post it without text and then edit to add attachment).
Last edit: RunetMember 2017-04-18
I took another look at the code I wrong and realized I had made a mistake... I've pushed an update to github; run the following commands to get the updated code:
$ cd input-wacom $ git remote update $ git pullAfterwards, re-do the build/install/load steps. The output of
cat /sys/module/wacom*/versionshould bev2.00-0.35.0.2.gc7571eeif the updated code was sucessfully loaded.As for SourceForge, I'm aware of its behavior with regards to silent edits but not the other problems you've encountered... SF can be a little flaky at times though, so I wouldn't be entirely surprised :(
Good news! Seems like new driver version is actually fixes this bug. So far I wouldn't able to put driver in semi-broken state and all gestures I have tried is working. To be 100% sure I will test it for few days to confirm that driver never fail anymore, and will let you know.
If there will be no issues after this testing, what is the future fate of this code? Will it be accepted by upstream, and if yes - is there any chances of getting this into 4.12?
Last edit: RunetMember 2017-04-19
Good to hear that the revised version seems to be working :) Normally I'd wait for you to finish your testing before submitting the fix upstream, but in this particular instance I'm going to submit it ASAP. The change I'm making is to some code introduced in 4.11-rc1, so I really want to make sure Linus pulls it into his final release of 4.11 which is expected this Sunday. It looks like this bug will likely impact most tablet PCs that were sold in the past few years, so things might be ugly if 4.11 is released without this fix...
If your testing reveals additional issues, I can submit fixes targeted at 4.12. If they're severe enough, I can also CC them to the "stable" mailinglist where they'll be considered for inclusion in one of the 4.11.x updates.
Fix accepted into Jiri's tree (upstream) as part of the
for-4.11/upstream-fixesbranch as commit6f107fa.Fix submitted to stable@vger.kernel.org (my last post appears to have been incorrect; the buggy commit first appeared in Linux 4.10-rc1, not 4.11-rc1).
Fix accepted into input-wacom tree as part of the
jiri/for-4.11branch as commit14f16ed.Fix merged into input-wacom tree as part of the
jiri/for-4.12branch as commitee0655d.Fix backported into input-wacom tree as part of the
masterbranch as commit5d1f1c8,Seven hours of testing, so far I wasn't able to reproduce this issue.
Thanks for information about commits!
Last edit: RunetMember 2017-04-20
FYI, I've started the gesture discussion thread on the linuxwacom-discuss mailinglist as requested. The subject line is "Changing default 'Gesture' setting?". I'm interested in seeing the responses :)
On Dell 5855 driver get into semi-broken state again today. This could be related to the fact that on previous testing I didn't suspend tablet even once, but today I suspend/wakeup it many times, and end up with this state again.
So, do I need to fill separate issue about suspend/wakeup? So far this is only difference I can remember, however this difference could be just coincidence.
Last edit: RunetMember 2017-04-22
I have to say that issue I get today on Dell 5855 is different from issue I have before because pinch-to-zoom is still recognized (not always, but most of the attempts works) and probably three and four gestures also works, but I didn't check that (will check next time). What stop working is scrolling with one finger.
On Dell 9250 I also get this issue few hours ago (scrolling with one finger stop working while pinch-to-zoom works) and this one was not suspend/wakeup even once, so seems like this issue is unrelated to suspend/wakeup.