Created attachment 130039 [details] xorg log I have three of them which don't work, but which work fine using xf86-input-evdev: Genius G-Pen F610 (relabeled Waltop), G-Pen 560 (relabeled Aiptek), and Trust TB-5300 (relabeled UC-Logic). lsusb: Bus 002 Device 027: ID 172f:0031 Waltop International Corp. Slim Tablet 12.1" Bus 002 Device 025: ID 5543:0004 UC-Logic Technology Corp. Tablet WP5540U Bus 002 Device 026: ID 0458:5003 KYE Systems Corp. (Mouse Systems) G-pen 560 Tablet Xorg log: [154887.435] (EE) libinput bug: Device 'UC-LOGIC Tablet WP5540U Pen' does not meet tablet criteria. Ignoring this device. [154887.585] (EE) libinput bug: Device 'WALTOP International Corp. Slim Tablet' does not meet tablet criteria. Ignoring this device. [154887.624] (EE) libinput bug: Device 'Aiptek' does not meet tablet criteria. Ignoring this device. I'll attach the log. I'm on Arch Linux with extra/libinput 1.6.2-1 [installed] extra/xf86-input-libinput 0.24.0-1 (xorg-drivers) [installed]
I should really expand that error message... Meanwhile, please attach an evemu-describe of each device so I can check what's missing.
Created attachment 130084 [details] evemu-describe
Created attachment 130085 [details] evemu-describe Genius-GPen560.txt
Created attachment 130086 [details] evemu-describe Genius-GPenF610.txt
The issues are: * UC-Logic: doesn't have BTN_TOOL_PEN, we'd have to work around this but this is something that may be addressed by the digimend project, have you checked there? * Aiptek and Waltop: missing resolutions for x/y, that's easy to add with a hwdb entry, find and look at 60-evdev.hwdb and the instructions at the top on how to add one. That's something we should add to systemd instead of libinput so it's available everywhere. I just hope those things use vid/pid numbers correctly instead of just reusing them.
ping?
I didn't figure out this hwdb/modalias mess yet. $ find /sys | grep modalias | grep 5543 /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.2/2-1.1.2:1.0/0003:5543:0004.0026/modalias /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.2/2-1.1.2:1.0/0003:5543:0004.0026/input/input74/modalias /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.2/2-1.1.2:1.0/0003:5543:0004.0026/input/input75/modalias $ cat /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.2/2-1.1.2:1.0/0003:5543:0004.0026/modalias hid:b0003g0000v00005543p00000004 $ systemd-hwdb query b0003g0000v00005543p00000004 <nothing> (tried a few more variations too) Now I see a few existing rules in /usr/lib/udev/hwdb.d/60-evdev.hwdb have stuff like # Macbook2,1 (late 2006), single-button touchpad evdev:input:b0003v05ACp021B* (and even more of them are based on DMI, that's irrelevant here, right?) so I'm guessing b0003 is a specific bus, but that doesn't make sense to specify for a pluggable USB device. So maybe I need to write a rule something like # Trust TB-5300 tablet evdev:input:v5543p0004* EVDEV_ABS_00=256:1471:12 EVDEV_ABS_01=256:831:12 but don't have much of an idea what numbers to put there yet. As for digimend, I hadn't heard of it until now.
OK so digimend has uclogic-tools. $ sudo uclogic-probe 2 45 | uclogic-decode Manufacturer: UC-LOGIC Product: Tablet WP5540U Max X: 11000 Max Y: 8000 Max pressure: 1023 Resolution: 2000 Internal model: F203 Buttons status: F203
for a device that's not built-in, you'd use the input modalias, not the DMI. And for USB devices you usually only need to care about the vendor and product-id, for example: > evdev:input:b0003v05ACp021B* bustype 0003 is USB (see linux/input.h), 05AC is Apple and 021B is the product ID. In your case, this should be b0003v5543p0004 I'm not too familiar with digmend either because I usually don't do kernel stuff but check for the project history if there's hints on how to patch the kernel for your device. Or check the kernel history for anything uc-logic/digmend-related that enables event codes, that would be a good point to start.
I didn't get back to it yet. It doesn't really matter to me - I'm not a regular tablet user. I just have those tablets at the office to test Qt with them occasionally, to try to stave off regressions. This isn't a regression as long as people keep using evdev for now; it's just an obstacle for libinput, right? And if some distro switches to using libinput by default at some point, and then these tablets don't work in Qt applications (like Krita) anymore, we'll probably be hearing about it.
as I said, the aiptek and the waltop ones are easy enough to fix with hwdb entries. Since I don't have those devices, I need you to add those entries, I cannot test them.
As per comment 12, I can't fix this, sorry
I have a Trust TB-4200 Wireless Scroll Tablet, which according to Journal output seems to be an Aiptek device: ří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. And I'm happy to provide any data needed for the device to be added to hwdb so that it works with Libinput (currently fails with (EE) Aiptek: (EE) libinput bug: device does not meet tablet criteria. Ignoring this device.). Just need some pointers how to do that. Thanks in advance! :)
Martin: best to file a new bug, attach an evemu-describe of the device and we can fix it from there.
(In reply to Peter Hutterer from comment #16) > Martin: best to file a new bug, attach an evemu-describe of the device and > we can fix it from there. OK, filled bug 103476. :)
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.