Created attachment 134025 [details] Relevant snippet from old xorg.log Using Fedora 26, package: libinput-1.8.0-2.fc26.src.rpm Nvidia proprietary drivers, so using X11, also. My graphics tablet originally totally failed to work, detected but wouldn't respond at all. Xorg logs showed that libinput was finding it, having a bit of trouble, and then give up trying to load it. After some help in #fedora, I've created a file at "/etc/X11/xorg.conf.d/52-tablet.conf" to force the use of the xf86-input-evdev driver for the graphic tablet's chipset, which does perfectly! I now just use xinput to calibrate the use to one of my screens. But indeed, the issue is libinput doesn't handle my graphics tablet properly. I'm happy to provide any requested logs or test patches, whatevs yo. Attached is an old xorg log snippet from when the tablet did nothing. The tablet chipset is "UC-LOGIC Tablet WP5540U". The actual model is a "TB-5300 Slimline Design Tablet".
Add the sudo evemu-record output of one short pen stroke please, thanks.
Created attachment 134036 [details] sudo evemu-record when working under evdev
Created attachment 134037 [details] sudo evemu-record when not working under libinput
I'm not sure if it makes a meaningful difference, so I've added the sudo evemu-record output of a short stroke when the tablet is using evdev and when using libinput.
evemu records kernel events, so it doesn't matter which driver you use. Issue here is that the tablet doesn't have BTN_TOOL_PEN set (it should when it's a tablet) and libinput requires this to use it as a tablet. That's too common for the UC Logic devices, so I think I'm going to have to fix this in libinput once and for all...
Alright, sounds promising. If I can help any further with logs or testing patches, I'll happily do so.
There's a test branch avaialable here, please give that one a try, thanks: https://github.com/whot/libinput/tree/wip/huion-dwh69-fdo97771
Built it, installed it, restarted, verified it. It seems to have made a difference, as per new xorg log, but the tablet still does nothing.
Created attachment 134156 [details] Xorg log with libinput patch installed.
Created attachment 134157 [details] Xorg log with libinput patch installed Seems that was the incorrect log. Attached is relevant one.
Created attachment 134158 [details] Xorg log with libinput patch installed Okay. This is 100% definitely the correct one, dangit.
run sudo ./builddir/libinput-debug-events --verbose after building it (with meson builddir) and attach the output here. The xorg log doesn't tell us much why it fails, debugging should happen with libinput-debug-events because if that one works, then xorg will work too. And you don't have to reboot or restart X for that.
Created attachment 134175 [details] Output of sudo ./builddir/libinput-debug-events --verbose
Neat. I'm not sure if I'm being stupid here and doing something very wrong, or what, but that log doesn't appear to give any new information to my untrained eyes. See attached.
I should also note, I did again attempt to do a simple stroke with the tablet during the debug command, with no response. Mouse/keyboard/etc events were logged fine.
still says: "event3 - UC-LOGIC Tablet WP5540U Pen: libinput bug: device does not meet tablet criteria. Ignoring this device." Did you build the right branch? Because if I run your evemu device with that branch locally I only get a warning about the tablet being unknown to libwacom.
Created attachment 134191 [details] Output of sudo ./builddir/libinput-debug-events --verbose
Huh, I must've done something stupid. I downloaded, doubly making sure it was the right branch, and did the command again, and the tablet worked! Pressure 'n everything, hurrah!
https://lists.freedesktop.org/archives/wayland-devel/2017-September/035005.html
commit 0ac868143a55c7b2700f90e6420cd2233404e19e Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Mon Sep 11 10:32:42 2017 +1000 tablet: support tablet devices without BTN_TOOL_PEN
*** Bug 103395 has been marked as a duplicate of this bug. ***
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.