Bug 103476 - RFE: libinput: Add support for Trust TB-4200 Wireless Scroll Tablet (Aiptek based)
Summary: RFE: libinput: Add support for Trust TB-4200 Wireless Scroll Tablet (Aiptek b...
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium major
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 104911
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-27 02:00 UTC by Martin Kolman
Modified: 2018-02-16 00:06 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
evemu-describe output (4.46 KB, text/plain)
2018-01-18 00:46 UTC, Martin Kolman
Details
journal output of connecting the aiptek tablet with the aparently matching hwdb entry (4.43 KB, text/plain)
2018-01-18 10:08 UTC, Martin Kolman
Details
evemu-describe output for the aiptek tablet with the aparently matching hwdb entry (4.53 KB, text/plain)
2018-01-18 10:09 UTC, Martin Kolman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Kolman 2017-10-27 02:00:55 UTC
I've recently got this tablet, but it doesn't seem to work with libinput:


říj 26 01:26:19 localhost.localdomain kernel: usb 1-1.2: new low-speed USB device number 9 using ehci-pci
říj 26 01:26:19 localhost.localdomain kernel: usb 1-1.2: New USB device found, idVendor=08ca, idProduct=0010
říj 26 01:26:19 localhost.localdomain kernel: usb 1-1.2: New USB device strings: Mfr=1, Product=3, SerialNumber=0
říj 26 01:26:19 localhost.localdomain kernel: usb 1-1.2: Product: USB Tablet Series Version 1.05
říj 26 01:26:19 localhost.localdomain kernel: usb 1-1.2: Manufacturer: AIPTEK International Inc.


But accordingly to bug 100043 support could be added via a hwdb entry & evemu-describe output should be provided. So here it is:


$ sudo evemu-describe 
Available devices:
/dev/input/event0:	Lid Switch
/dev/input/event1:	Sleep Button
/dev/input/event2:	Power Button
/dev/input/event3:	AT Translated Set 2 keyboard
/dev/input/event4:	Logitech USB Laser Mouse
/dev/input/event5:	Logitech USB Receiver
/dev/input/event6:	Logitech USB Receiver
/dev/input/event7:	SynPS/2 Synaptics TouchPad
/dev/input/event8:	Video Bus
/dev/input/event9:	Video Bus
/dev/input/event10:	TPPS/2 IBM TrackPoint
/dev/input/event11:	ThinkPad Extra Buttons
/dev/input/event12:	HDA Intel PCH Mic
/dev/input/event13:	HDA Intel PCH Dock Mic
/dev/input/event14:	HDA Intel PCH Dock Headphone
/dev/input/event15:	HDA Intel PCH Headphone
/dev/input/event16:	Integrated Camera: Integrated C
/dev/input/event17:	Aiptek
Select the device event number [0-17]: 17      
# EVEMU 1.3
# Kernel: 4.13.5-200.fc26.x86_64
# DMI: dmi:bvnLENOVO:bvr8AET65WW(1.45):bd05/14/2015:svnLENOVO:pn42404GG:pvrThinkPadT520:rvnLENOVO:rn42404GG:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
# Input device name: "Aiptek"
# Input device ID: bus 0x03 vendor 0x8ca product 0x10 version 0x105
# Supported events:
#   Event type 0 (EV_SYN)
#     Event code 0 (SYN_REPORT)
#     Event code 1 (SYN_CONFIG)
#     Event code 2 (SYN_MT_REPORT)
#     Event code 3 (SYN_DROPPED)
#     Event code 4 ((null))
#     Event code 5 ((null))
#     Event code 6 ((null))
#     Event code 7 ((null))
#     Event code 8 ((null))
#     Event code 9 ((null))
#     Event code 10 ((null))
#     Event code 11 ((null))
#     Event code 12 ((null))
#     Event code 13 ((null))
#     Event code 14 ((null))
#     Event code 15 (SYN_MAX)
#   Event type 1 (EV_KEY)
#     Event code 1 (KEY_ESC)
#     Event code 59 (KEY_F1)
#     Event code 60 (KEY_F2)
#     Event code 61 (KEY_F3)
#     Event code 62 (KEY_F4)
#     Event code 63 (KEY_F5)
#     Event code 64 (KEY_F6)
#     Event code 65 (KEY_F7)
#     Event code 66 (KEY_F8)
#     Event code 67 (KEY_F9)
#     Event code 68 (KEY_F10)
#     Event code 87 (KEY_F11)
#     Event code 88 (KEY_F12)
#     Event code 128 (KEY_STOP)
#     Event code 129 (KEY_AGAIN)
#     Event code 130 (KEY_PROPS)
#     Event code 131 (KEY_UNDO)
#     Event code 132 (KEY_FRONT)
#     Event code 133 (KEY_COPY)
#     Event code 134 (KEY_OPEN)
#     Event code 135 (KEY_PASTE)
#     Event code 183 (KEY_F13)
#     Event code 184 (KEY_F14)
#     Event code 185 (KEY_F15)
#     Event code 186 (KEY_F16)
#     Event code 187 (KEY_F17)
#     Event code 188 (KEY_F18)
#     Event code 189 (KEY_F19)
#     Event code 190 (KEY_F20)
#     Event code 191 (KEY_F21)
#     Event code 192 (KEY_F22)
#     Event code 193 (KEY_F23)
#     Event code 194 (KEY_F24)
#     Event code 272 (BTN_LEFT)
#     Event code 273 (BTN_RIGHT)
#     Event code 274 (BTN_MIDDLE)
#     Event code 320 (BTN_TOOL_PEN)
#     Event code 321 (BTN_TOOL_RUBBER)
#     Event code 322 (BTN_TOOL_BRUSH)
#     Event code 323 (BTN_TOOL_PENCIL)
#     Event code 324 (BTN_TOOL_AIRBRUSH)
#     Event code 326 (BTN_TOOL_MOUSE)
#     Event code 327 (BTN_TOOL_LENS)
#     Event code 330 (BTN_TOUCH)
#     Event code 331 (BTN_STYLUS)
#     Event code 332 (BTN_STYLUS2)
#   Event type 2 (EV_REL)
#     Event code 0 (REL_X)
#     Event code 1 (REL_Y)
#     Event code 8 (REL_WHEEL)
#   Event type 3 (EV_ABS)
#     Event code 0 (ABS_X)
#       Value        0
#       Min          0
#       Max       5999
#       Fuzz         0
#       Flat         0
#       Resolution   0
#     Event code 1 (ABS_Y)
#       Value        0
#       Min          0
#       Max       4499
#       Fuzz         0
#       Flat         0
#       Resolution   0
#     Event code 8 (ABS_WHEEL)
#       Value        0
#       Min          0
#       Max       1023
#       Fuzz         0
#       Flat         0
#       Resolution   0
#     Event code 24 (ABS_PRESSURE)
#       Value        0
#       Min          0
#       Max        511
#       Fuzz         0
#       Flat         0
#       Resolution   0
#     Event code 26 (ABS_TILT_X)
#       Value        0
#       Min       -128
#       Max        127
#       Fuzz         0
#       Flat         0
#       Resolution   0
#     Event code 27 (ABS_TILT_Y)
#       Value        0
#       Min       -128
#       Max        127
#       Fuzz         0
#       Flat         0
#       Resolution   0
#     Event code 40 (ABS_MISC)
#       Value        0
#       Min          0
#       Max          0
#       Fuzz         0
#       Flat         0
#       Resolution   0
#   Event type 4 (EV_MSC)
#     Event code 0 (MSC_SERIAL)
# Properties:
N: Aiptek
I: 0003 08ca 0010 0105
P: 00 00 00 00 00 00 00 00
B: 00 0b 00 00 00 00 00 00 00
B: 01 02 00 00 00 00 00 00 f8
B: 01 1f 00 80 01 00 00 00 00
B: 01 ff 00 00 00 00 00 80 ff
B: 01 07 00 00 00 00 00 00 00
B: 01 00 00 07 00 00 00 00 00
B: 01 df 1c 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 02 03 01 00 00 00 00 00 00
B: 03 03 01 00 0d 00 01 00 00
B: 04 01 00 00 00 00 00 00 00
B: 05 00 00 00 00 00 00 00 00
B: 11 00 00 00 00 00 00 00 00
B: 12 00 00 00 00 00 00 00 00
B: 14 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
A: 00 0 5999 0 0 0
A: 01 0 4499 0 0 0
A: 08 0 1023 0 0 0
A: 18 0 511 0 0 0
A: 1a -128 127 0 0 0
A: 1b -128 127 0 0 0
A: 28 0 0 0 0 0

Plese let me know if you need any more data and/or testing! :)
Comment 1 Peter Hutterer 2017-10-27 02:29:58 UTC
What's the physical size of the sensor area? We need to add an 60-evdev.hwdb entry in systemd for the resolution on the x/y axes, that's probably enough to make it work.
Comment 2 Martin Kolman 2017-10-27 09:53:33 UTC
The product description (https://www.trust.com/en/product/14070-wireless-scroll-tablet-tb-4200) says:

"A4+ (228 x 304 mm)"

And my measurements & testing confirm that value.

BTW, there is some sort of "touch buttons" above the active area, but they don't seem to do anything when clicked by the stylus or by a finger.
Comment 3 Peter Hutterer 2017-10-29 22:14:52 UTC
They might be hidden in some vendor-specific hid protocol. Grab https://bentiss.github.io/hid-replay-docs/ and run hid-recorder on the device, attach the output here. We can have a look at it then to see if there's anything interesting.

For the size: locate 60-evdev.hwdb on your machine and read the comments at the top, they have the description on how to fix the x/y axis range by adding a custom resolution. will look similar to the other entries with EVDEV_ABS_00=::r and EVDEV_ABS_001=::r, where r is the resolution for the respective axis. The axis ranges are 6000/4500, divide that by the respective sizes and you have the resolution.
Comment 4 Peter Hutterer 2017-11-15 04:16:49 UTC
ping?
Comment 5 Martin Kolman 2017-11-15 09:05:32 UTC
(In reply to Peter Hutterer from comment #4)
> ping?

Sorry, I was quite busy so far, but I should be able to take a look at it on Friday. :)
Comment 6 Martin Kolman 2017-11-18 01:53:13 UTC
(In reply to Martin Kolman from comment #5)
> (In reply to Peter Hutterer from comment #4)
> > ping?
> 
> Sorry, I was quite busy so far, but I should be able to take a look at it on
> Friday. :)

Didn't get to it today in the end - will try to look at in on Tuesday. :)
Comment 7 Martin Kolman 2017-11-20 23:22:38 UTC
(In reply to Peter Hutterer from comment #3)
> They might be hidden in some vendor-specific hid protocol. Grab
> https://bentiss.github.io/hid-replay-docs/ and run hid-recorder on the
> device, attach the output here. We can have a look at it then to see if
> there's anything interesting.
The hid-recorder utility (running as root) doesn't seem to see the device. It does see my Logitech Wave wireless keyboard if it is connected (as 3 separate devices), but if I disconnect the receiver & connect the tablet it doesn't detect anything and writes usage instructions instead.


> 
> For the size: locate 60-evdev.hwdb on your machine and read the comments at
> the top, they have the description on how to fix the x/y axis range by
> adding a custom resolution. will look similar to the other entries with
> EVDEV_ABS_00=::r and EVDEV_ABS_001=::r, where r is the resolution for the
> respective axis. The axis ranges are 6000/4500, divide that by the
> respective sizes and you have the resolution.

So, if I should divide it by the value in millimeters, this gives me:

6000 / 228 = 26,315

4500 / 304 = 14.8

Based on the hwdb docstrings & entries, that gives me a potential new entry:

#########################################
# Trust
#########################################

# Trust Wireless Scroll Tablet TB-4200
# (Aiptek based ?)
evdev:name:Aiptek
 EVDEV_ABS_00=::26
 EVDEV_ABS_01=::15


What I'm not sure about:

- did I do the rounding right ?

- is the type matching correct ? 

Based on comment, it should be:

evdev:name:<device name>:dmi:<dmi string>

I guess device name is "Aiptek" but I'm not sure what the correct "dmi string" in the evemu describe output:

# DMI: dmi:bvnLENOVO:bvr8AET65WW(1.45):bd05/14/2015:svnLENOVO:pn42404GG:pvrThinkPadT520:rvnLENOVO:rn42404GG:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable

That looks like something related to the laptop (a Lenovo ThinkPad T520) than to the tablet.


If the entry looks correct (or you have any pointers how to correct it :) ) it looks like I should be able to locally test according to the comments in the hwdb file:

# To add local entries, create a new file
#   /etc/udev/hwdb.d/61-evdev-local.hwdb
# and add your rules there. To load the new rules execute (as root):
#   systemd-hwdb update
#   udevadm trigger /dev/input/eventXX
# where /dev/input/eventXX is the device in question. If in
# doubt, simply use /dev/input/event* to reload all input rules.
Comment 8 Martin Kolman 2017-11-20 23:24:24 UTC
Also looking at it now:

6000 / 228 = 26,315

4500 / 304 = 14.8

Is this correct (dividing the big number with the short size & the small number with the long size) ? Or did I mix this up as well ? :D
Comment 9 Peter Hutterer 2017-11-22 00:37:12 UTC
the rounding is correct, you just pick the closest number. the difference is usually in the 1-3mm and there isn't anything we can do about this, such is life with integers.

the numbers you need are width/x axis range and height/y axis range. I don't know which one is the short/long size. 00 is ABS_X and 01 is ABS_Y, you can compare that with your evemu output.

for an external device, using DMI is not a good idea because it matches on the machine, not the device. So your dmi match won't work for the same device on any other host. Something like evdev:input:b0003v256Cp1234* is better, replace the v and p bits with uppercase 4-digit hex for the vendor ID and product ID (see evemu output).
Comment 10 Peter Hutterer 2017-12-18 04:58:37 UTC
ping?
Comment 11 Martin Kolman 2018-01-03 09:07:49 UTC
(In reply to Peter Hutterer from comment #10)
> ping?

Sorry, I didn't get to this during the holidays after all, but I plan to do further testing during this week or weekend. :)
Comment 12 Martin Kolman 2018-01-12 02:43:25 UTC
So I dumped the temporary xorg.conf workaround, rebooted and then created the /etc/udev/hwdb.d/61-evdev-local.hwdb file, containing:

#########################################
# Trust
#########################################

# Trust Wireless Scroll Tablet TB-4200
# (Aiptek based ?)
evdev:name:Aiptek
 EVDEV_ABS_00=::26
 EVDEV_ABS_01=::15

This seems to work! :) The tablet works in Krita once connected and seem to map to the screen correctly (click in upper corner of the tablet click in the upper corner of the screen, the sama thing for other corners). I've also tried if the size ration is set correctly and things are less clear there - I've tried tracing a 6.5 cm x 6.5 cm square in Krita and it comes out slightly wider than it is high. The number seem to have effect as when I swapped them (15 first, 26 second) the rectangle was even wider.

Attaching Journal output from the successful tablet detection:


led 12 03:20:50 localhost.localdomain kernel: usb 1-1.1: new low-speed USB device number 13 using ehci-pci
led 12 03:20:50 localhost.localdomain kernel: usb 1-1.1: New USB device found, idVendor=08ca, idProduct=0010
led 12 03:20:50 localhost.localdomain kernel: usb 1-1.1: New USB device strings: Mfr=1, Product=3, SerialNumber=0
led 12 03:20:50 localhost.localdomain kernel: usb 1-1.1: Product: USB Tablet Series Version 1.05
led 12 03:20:50 localhost.localdomain kernel: usb 1-1.1: Manufacturer: AIPTEK International Inc.
led 12 03:20:50 localhost.localdomain mtp-probe[10817]: checking bus 1, device 13: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1"
led 12 03:20:50 localhost.localdomain mtp-probe[10817]: bus: 1, device: 13 was not an MTP device
led 12 03:20:53 localhost.localdomain kernel: aiptek 1-1.1:1.0: Aiptek using 400 ms programming speed
led 12 03:20:53 localhost.localdomain kernel: input: Aiptek as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input26
led 12 03:20:53 localhost.localdomain kernel: usbcore: registered new interface driver aiptek
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) config/udev: Adding input device Aiptek (/dev/input/mouse4)
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: Applying InputClass "system-keyboard"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) No input driver specified, ignoring this device.
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) This device may have been added with another device file.
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) config/udev: Adding input device Aiptek (/dev/input/mouse4)
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (**) Aiptek: Applying InputClass "system-keyboard"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) No input driver specified, ignoring this device.
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) This device may have been added with another device file.
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) config/udev: Adding input device Aiptek (/dev/input/event18)
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: Applying InputClass "evdev pointer catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: Applying InputClass "evdev keyboard catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: Applying InputClass "evdev tablet catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: Applying InputClass "libinput pointer catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: Applying InputClass "libinput keyboard catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: Applying InputClass "libinput tablet catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: Applying InputClass "system-keyboard"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: Applying InputClass "evdev tablet catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) LoadModule: "evdev"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) config/udev: Adding input device Aiptek (/dev/input/event18)
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (**) Aiptek: Applying InputClass "evdev pointer catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (**) Aiptek: Applying InputClass "evdev keyboard catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (**) Aiptek: Applying InputClass "evdev tablet catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (**) Aiptek: Applying InputClass "libinput pointer catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (**) Aiptek: Applying InputClass "libinput keyboard catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (**) Aiptek: Applying InputClass "libinput tablet catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (**) Aiptek: Applying InputClass "system-keyboard"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (**) Aiptek: Applying InputClass "evdev tablet catchall"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) LoadModule: "evdev"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) Module evdev: vendor="X.Org Foundation"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]:         compiled for 1.19.1, module version = 2.10.5
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]:         Module class: X.Org XInput Driver
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]:         ABI class: X.Org XInput driver, version 24.1
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) Using input driver 'evdev' for 'Aiptek'
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) Module evdev: vendor="X.Org Foundation"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]:         compiled for 1.19.1, module version = 2.10.5
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]:         Module class: X.Org XInput Driver
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]:         ABI class: X.Org XInput driver, version 24.1
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) Using input driver 'evdev' for 'Aiptek'
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) systemd-logind: got fd for /dev/input/event18 13:82 fd 76 paused 0
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: always reports core events
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) evdev: Aiptek: Device: "/dev/input/event18"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (--) evdev: Aiptek: Vendor 0x8ca Product 0x10
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (--) evdev: Aiptek: Found 3 mouse buttons
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (--) evdev: Aiptek: Found scroll wheel(s)
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (--) evdev: Aiptek: Found relative axes
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (--) evdev: Aiptek: Found x and y relative axes
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (--) evdev: Aiptek: Found absolute axes
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (--) evdev: Aiptek: Found x and y absolute axes
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (--) evdev: Aiptek: Found absolute tablet.
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (--) evdev: Aiptek: Found keys
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) evdev: Aiptek: Configuring as tablet
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) evdev: Aiptek: Configuring as keyboard
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) evdev: Aiptek: Adding scrollwheel support
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) evdev: Aiptek: YAxisMapping: buttons 4 and 5
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) evdev: Aiptek: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input26/event18"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) XINPUT: Adding extended input device "Aiptek" (type: KEYBOARD, id 19)
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Option "xkb_rules" "evdev"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Option "xkb_layout" "cz,us,de"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Option "xkb_variant" ",,"
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (WW) evdev: Aiptek: touchpads, tablets and touchscreens ignore relative axes.
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (II) evdev: Aiptek: initialized for absolute axes.
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: (accel) keeping acceleration scheme 1
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: (accel) acceleration profile 0
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: (accel) acceleration factor: 2.000
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[6804]: (**) Aiptek: (accel) acceleration threshold: 4
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) systemd-logind: got fd for /dev/input/event18 13:82 fd 24 paused 1
led 12 03:20:53 localhost.localdomain /usr/libexec/gdm-x-session[1303]: (II) systemd-logind: releasing fd for 13:82


Next I'll try with the vendor and product id matching.
Comment 13 Peter Hutterer 2018-01-12 03:01:35 UTC
(In reply to Martin Kolman from comment #12)
> # (Aiptek based ?)
> evdev:name:Aiptek
>  EVDEV_ABS_00=::26
>  EVDEV_ABS_01=::15
> 
> This seems to work! :) 

easiest to verify would be to run evemu-describe and check the Resolution
value for ABS_X and ABS_Y. If it applied correctly, those should be 26 and
15, respectively.

> I've tried tracing a 6.5 cm x 6.5 cm square in Krita and it comes out
> slightly wider than it is high. The number seem to have effect as when I
> swapped them (15 first, 26 second) the rectangle was even wider.

Could be because we had to round down for 26 but up for 15 though the effect
should be minimal. And of course, if you swap the resolutions around the
result is going to be some form of garbage. The device sends the same data, but when you swap it you're saying "15 device units along the x are 1mm" which is obviously incorrect and stretches things.
Comment 14 Martin Kolman 2018-01-12 03:14:51 UTC
So evemu-describe tells me the tablet has:

Input device ID: bus 0x03 vendor 0x8ca product 0x10 version 0x105

Based on that I've changed to local hwdb entry as follows (did I convert/write the v and p values properly ?):

#########################################
# Trust
#########################################

# Trust Wireless Scroll Tablet TB-4200
# (Aiptek based ?)
evdev:input:b0003v8CAp10*
 EVDEV_ABS_00=::26
 EVDEV_ABS_01=::15

With this it seems to work the same as before, *but* it seems to work even if I remove the file or use nonsencial values after v and p. Could be that the previous name based rule persisted and is still being used ?

I'm using this to reload the local hwdb (while the tablet is discoonnected):

systemd-hwdb update
udevadm trigger /dev/input/event*

Then I attempt to connect the tablet.
Comment 15 Martin Kolman 2018-01-12 03:27:26 UTC
(In reply to Peter Hutterer from comment #13)
> (In reply to Martin Kolman from comment #12)
> > # (Aiptek based ?)
> > evdev:name:Aiptek
> >  EVDEV_ABS_00=::26
> >  EVDEV_ABS_01=::15
> > 
> > This seems to work! :) 
> 
> easiest to verify would be to run evemu-describe and check the Resolution
> value for ABS_X and ABS_Y. If it applied correctly, those should be 26 and
> 15, respectively.
Indeed! Doesn't seem to be applied:

#     Event code 0 (ABS_X)
#       Value        0
#       Min          0
#       Max       5999
#       Fuzz         0
#       Flat         0
#       Resolution   0
#     Event code 1 (ABS_Y)
#       Value        0
#       Min          0
#       Max       4499
#       Fuzz         0
#       Flat         0
#       Resolution   0

Full evemu-describe output: https://paste.fedoraproject.org/paste/DEDD69B9kEaIRCPn1Vy1uw

I've also tried to use the earlier name based matching (evdev:name:Aiptek) and the evemu-describe results are the same - Resolution is still 0.

> 
> > I've tried tracing a 6.5 cm x 6.5 cm square in Krita and it comes out
> > slightly wider than it is high. The number seem to have effect as when I
> > swapped them (15 first, 26 second) the rectangle was even wider.
> 
> Could be because we had to round down for 26 but up for 15 though the effect
> should be minimal. And of course, if you swap the resolutions around the
> result is going to be some form of garbage. The device sends the same data,
> but when you swap it you're saying "15 device units along the x are 1mm"
> which is obviously incorrect and stretches things.
Yeah, but I see it stretched *always*, not just when I switch the values. But given that based on evemu-describe it looks like the values are not being applied the even-more-stretched result with switched values could be a fluke.
Comment 16 Peter Hutterer 2018-01-12 06:36:31 UTC
(In reply to Martin Kolman from comment #15)
> Indeed! Doesn't seem to be applied:

if it isn't applied, the behaviour of the tablet does not change, any
perceived change is just an illusion. Nothing but systemd parses that property and systemd parses it to update the kernel device. So if the kernel device doesn't change, then nothing has happened and the hwdb entry just shouts into the void :)
 
> Full evemu-describe output:
> https://paste.fedoraproject.org/paste/DEDD69B9kEaIRCPn1Vy1uw

we have bugzilla attachments, please use those instead of pastebins that
randomly expire.
Comment 17 Martin Kolman 2018-01-18 00:46:29 UTC
Created attachment 136821 [details]
evemu-describe output
Comment 18 Martin Kolman 2018-01-18 00:48:29 UTC
(In reply to Peter Hutterer from comment #16)
> (In reply to Martin Kolman from comment #15)
> > Indeed! Doesn't seem to be applied:
> 
> if it isn't applied, the behaviour of the tablet does not change, any
> perceived change is just an illusion. Nothing but systemd parses that
> property and systemd parses it to update the kernel device. So if the kernel
> device doesn't change, then nothing has happened and the hwdb entry just
> shouts into the void :)
Actually, If I remove the custom hwdb entry file (/etc/udev/hwdb.d/61-evdev-local.hwdb) and reboot, the tablet is not activated at all:

(EE) Aiptek: (EE) libinput bug: device does not meet tablet criteria. Ignoring this device.

So the custom hwdb entry must have propagated and matched somehow, possibly partially. In any case I'll just a machine reboot into further testing to eliminate this in the future.

BTW, does:

evdev:input:b0003v8CAp10*

look like a correct hwdb entry header based on the evemu-describe output  
 (Input device ID: bus 0x03 vendor 0x8ca product 0x10 version 0x105) ?

Eq. did I do the conversions right ? Thanks in advance! :)

>  
> > Full evemu-describe output:
> > https://paste.fedoraproject.org/paste/DEDD69B9kEaIRCPn1Vy1uw
> 
> we have bugzilla attachments, please use those instead of pastebins that
> randomly expire.
Good point! Added the evemu-describe log as an attachment.
Comment 19 Peter Hutterer 2018-01-18 01:31:13 UTC
> evdev:input:b0003v8CAp10*

They all need to be 4-digits, so evdev:input:b0003v08CAp0010* in your case.
Comment 20 Martin Kolman 2018-01-18 02:12:52 UTC
Definitely making progress! If this is in /etc/udev/hwdb.d/61-evdev-local.hwdb:

#########################################
# Trust
#########################################

# Trust Wireless Scroll Tablet TB-4200
# (Aiptek based ?)
evdev:input:b0003v08CAp0010*
 EVDEV_ABS_00=::26
 EVDEV_ABS_01=::15

I can now reproducibly crash X on Fedora 26 just by touching the tablet with the stuylus (https://bugzilla.redhat.com/show_bug.cgi?id=1535755). :D
Comment 21 Martin Kolman 2018-01-18 02:45:04 UTC
And looks like I can crash Wayland/Gnome Shell as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1535758
Comment 22 Peter Hutterer 2018-01-18 02:53:46 UTC
does evemu-describe show the resolution correctly now? I replied on the other bug too with a needinfo
Comment 23 Martin Kolman 2018-01-18 10:08:28 UTC
Created attachment 136824 [details]
journal output of connecting the aiptek tablet with the aparently matching hwdb entry
Comment 24 Martin Kolman 2018-01-18 10:09:20 UTC
Created attachment 136825 [details]
evemu-describe output for the aiptek tablet with the aparently matching hwdb entry
Comment 25 Martin Kolman 2018-01-18 10:13:12 UTC
(In reply to Peter Hutterer from comment #22)
> does evemu-describe show the resolution correctly now? I replied on the
> other bug too with a needinfo

It does!

#   Event type 3 (EV_ABS)
#     Event code 0 (ABS_X)
#       Value        0
#       Min          0
#       Max       5999
#       Fuzz         0
#       Flat         0
#       Resolution  26
#     Event code 1 (ABS_Y)
#       Value        0
#       Min          0
#       Max       4499
#       Fuzz         0
#       Flat         0
#       Resolution  15

Full evemu-desribe output is in comment 24, journal output of plugging in the tablet in comment 23.

So I guess we might be set once the (libinput ?) crash is fixed, as the tablet seem to be recognized and the resolution setting are in effect (which I guess might fix the stretched square issues I have been seeing previously).
Comment 26 Peter Hutterer 2018-01-22 01:26:34 UTC
Looks good and seems to work fine here with libinput. Once the crash is fixed (or figured out) please prepare a pull-request for systemd to add the hwdb entry to the database. If you cc me on it (@whot) I can get it merged.

I'll leave this bug open for https://bugzilla.redhat.com/show_bug.cgi?id=1535755, once we know what causes that we can either close it or fix it.
Comment 27 Peter Hutterer 2018-02-02 02:05:09 UTC
This tablet also needs faking of BTN_TOOL_PEN devices, I filed Bug 104911 for that part so we only have one focus here.
Comment 28 Peter Hutterer 2018-02-13 08:24:34 UTC
Ok, I think this device should work with git master (582e3c00b74a1c7) now. Aside from the systemd hwdb entry (see comment 26), this is fixed now.
Comment 29 Martin Kolman 2018-02-13 12:20:41 UTC
(In reply to Peter Hutterer from comment #28)
> Ok, I think this device should work with git master (582e3c00b74a1c7) now.
> Aside from the systemd hwdb entry (see comment 26), this is fixed now.

Nice! And thanks a lot! :) I should be able to do the systemd PR during this week & I'll certainly CC you on it once it's open. :)
Comment 30 Martin Kolman 2018-02-15 23:33:59 UTC
So I've now actually tried the tablet with libinput 1.9.4 on Fedora 26 in actual drawing software.

In Krita the cursor moves both if the pen hovers over the tablet and also when I press on the pan, but never leaves a trace. Previously (eq. without the resolutition being set correctly) it was leaving a trace when I pressed on the pen.

In Mypaint the pen starts leaving a trace when I press on it and I can move the cursor around without leaving a trace by not pressing on the pen or leaving the tip slightly above the tablet.

So it doesn't seem like the "press detection" (?) is totally broken, just that Krita likely uses a different press detection than Mypaint, but something definitely changed, likely due to that libinput crash fix. 

I'll try to check if I can make Krita use a different press detection method.

I've also tried to check if the broken proportions have been fixed by setting the resolution correctly and the missmatch still seems to be there - rectangles are not rectangular and circles show up as elipses.

I'll try to play with the resolution values a bit to see if I can fix this by changing the ratio of the two values (or do you have some ponters what else to try tweeking ?).

So basically I'll look into these two issues some more before submitting the hwdb entry PR.
Comment 31 Peter Hutterer 2018-02-16 00:06:54 UTC
1.9.4 doesn't have all the patches in, only the crash fixer. You need git master for the rest


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.