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! :)
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.
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.
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.
ping?
(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. :)
(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. :)
(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.
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
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).
(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. :)
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.
(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.
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.
(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.
(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.
Created attachment 136821 [details] evemu-describe output
(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.
> evdev:input:b0003v8CAp10* They all need to be 4-digits, so evdev:input:b0003v08CAp0010* in your case.
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
And looks like I can crash Wayland/Gnome Shell as well: https://bugzilla.redhat.com/show_bug.cgi?id=1535758
does evemu-describe show the resolution correctly now? I replied on the other bug too with a needinfo
Created attachment 136824 [details] journal output of connecting the aiptek tablet with the aparently matching hwdb entry
Created attachment 136825 [details] evemu-describe output for the aiptek tablet with the aparently matching hwdb entry
(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).
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.
This tablet also needs faking of BTN_TOOL_PEN devices, I filed Bug 104911 for that part so we only have one focus here.
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.
(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. :)
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.
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.