Bug 1249089 - Intuos 5 Small correctly recognized, but no touch in xsetwacom
Summary: Intuos 5 Small correctly recognized, but no touch in xsetwacom
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: libwacom
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-31 13:20 UTC by Alberto Ferrante
Modified: 2015-08-05 23:52 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-05 23:52:21 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Alberto Ferrante 2015-07-31 13:20:21 UTC
Description of problem:
The tablet is correctly recognized, but the touch functionality, that is present in the tablet, is not listed by xsetwacomtablet. This prevents from configuring touch.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. connect a Wacom Intuos 5 Small
2. Type xsetwacom --list devices

Actual results:
The result is as follows:
Wacom Intuos5 touch S Pen stylus        id: 12  type: STYLUS    
Wacom Intuos5 touch S Pen eraser        id: 13  type: ERASER    
Wacom Intuos5 touch S Pen cursor        id: 14  type: CURSOR    
Wacom Intuos5 touch S Pad pad           id: 17  type: PAD

The touch feature works normally, but it cannot be configured
dmesg shows an output that looks correct when the device is connected:
[  397.976418] usb 1-8: new full-speed USB device number 11 using xhci_hcd
[  398.142535] usb 1-8: New USB device found, idVendor=056a, idProduct=0026
[  398.142537] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  398.142538] usb 1-8: Product: Intuos5 touch S
[  398.142539] usb 1-8: Manufacturer: Wacom Co.,Ltd.
[  398.145043] input: Wacom Intuos5 touch S Pen as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:056A:0026.000F/input/input52
[  398.145211] input: Wacom Intuos5 touch S Pad as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:056A:0026.000F/input/input53
[  403.144989] wacom 0003:056A:0026.000F: hidraw8: USB HID v1.10 Mouse [Wacom Co.,Ltd. Intuos5 touch S] on usb-0000:00:14.0-8/input0
[  403.146081] input: Wacom Intuos5 touch S Finger as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.1/0003:056A:0026.0010/input/input54
[  403.146277] wacom 0003:056A:0026.0010: hidraw9: USB HID v1.10 Device [Wacom Co.,Ltd. Intuos5 touch S] on usb-0000:00:14.0-8/input1

Expected results:
Wacom Intuos5 touch S Pad pad           id: 17  type: PAD       
Wacom Intuos5 touch S Pen stylus        id: 18  type: STYLUS    
Wacom Intuos5 touch S Pen eraser        id: 19  type: ERASER    
Wacom Intuos5 touch S Pen cursor        id: 20  type: CURSOR    
Wacom Intuos5 touch S Finger touch      id: 21  type: TOUCH
(obtained on another PC running Fedora 21)

Additional info:
On the same PC, updated from F21 to F22 the tablet was recognized just fine. After a clean install of F22 the problem appeared.

Comment 1 Alberto Ferrante 2015-07-31 13:43:59 UTC
I have just discovered that the touch functionality is identified as a touchpad device and can be controlled in "input devices -> touchpad

Comment 2 Peter Hutterer 2015-08-04 02:11:34 UTC
out of interest, which configuration are you missing?

the change is caused by the new default input driver (libinput) which handles touchpad devices now too. Previously, the wacom xorg.conf.d snippet would override the default synaptics driver config, the new libinput overrides this again and assigns itself to touchpads. Whether that's a bug largely depends on what you need from the tablet :)

Comment 3 Alberto Ferrante 2015-08-04 08:42:31 UTC
Well, what I am missing is the possibility to switch touch off! It is really annoying when you want to use the tablet with the pen. As a touchpad device, not all the times I can switch it off (sometimes I have the option, sometimes not, but even if I have it not all the times it works), especially when I use it with the wireless adapter and not with the USB cable.

I perceive it as a bug, as it breaks the behavior of the device (i.e., one device, settings in two different places, handled in different ways).

Comment 4 Peter Hutterer 2015-08-05 06:18:30 UTC
fwiw, if you're using xsetwacom to turn it off on demand, you can use xinput as well

xinput disable "the device name"
xinput enable "the device name"

Were you relying on automatic touch/pen arbitration or always manually triggered?

Comment 5 Benjamin Tissoires 2015-08-05 15:41:33 UTC
(In reply to Alberto Ferrante from comment #3)
> Well, what I am missing is the possibility to switch touch off! It is really
> annoying when you want to use the tablet with the pen. As a touchpad device,
> not all the times I can switch it off (sometimes I have the option,
> sometimes not, but even if I have it not all the times it works), especially
> when I use it with the wireless adapter and not with the USB cable.

I am not sure about your point. The kernel does reject events coming from the touchpad as soon as the pen gets in proximity of the sensor. So normally, you should never have to disable the touch part of the tablet while using the pen.
(tested with and without the wireless adapter).

Comment 6 Alberto Ferrante 2015-08-05 23:17:27 UTC
Sorry if I wasn't clear enough. The proximity sensor seems to work well, but sometimes the touch (that I do not use anyway) causes some problems: while my hand is still on the tablet, it may happen that I rise the pen too much and this makes the tabled generate quite a number of events (since my whole hand is there) with pretty unpredictable results. So, it seems to work as intended, but it is just not for me...

Thanks for the suggestion about xinput: it works pretty well and I have already integrated it in my tablet setup script (that should execute automatically, if and when Plasma 5 gets back Wacom events).

Comment 7 Peter Hutterer 2015-08-05 23:52:21 UTC
better touch arbitration is something we have on the list, but it'll require libinput to handle graphics tablets (which is in the works). for now I suggest staying with the xinput solution, it does the same as your old xsetwacom script, it's driver-independent and looks like you didn't need anything more specific anyway.

so I'm closing this bug as WORKSFORME for now, eventually the workaround won't be necessary but probably not before F23 is out.

Upstream bug is https://bugs.freedesktop.org/show_bug.cgi?id=89426


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