Okay, I've had about a half-dozen or so minor annoyances to contend with since I first installed Mageia 6, and for the most part, they're tolerable, but I've now run across a bug that will conceivably drive my up the wall if I don't get it sorted within the next few days. My Ace Cad USB Graphics Tablet isn't working. The driver module is loaded. Its hardware is detected, and the device appears (physically) to be functioning normally, yet the mouse pointer refuses to budge. If I plug the tablet into one of my remaining Mageia 5 machines it functions as expected, without issue, so its not the device itself, its pen's battery, or something like that at fault. Proof that its driver is installed an active: # rpm -qa *acecad* x11-driver-input-acecad-1.5.0-22.mga6 # modinfo acecad filename: /lib/modules/4.9.43-desktop-1.mga6/kernel/drivers/input/tablet/acecad.ko.xz license: GPL description: USB Acecad Flair tablet driver author: Edouard TISSERANT <edouard.tisserant@wanadoo.fr> alias: usb:v0460p0008d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0460p0004d*dc*dsc*dp*ic*isc*ip*in* depends: usbcore intree: Y vermagic: 4.9.43-desktop-1.mga6 SMP mod_unload # lsusb | grep Tablet Bus 006 Device 002: ID 0460:0004 Ace Cad Enterprise Co., Ltd Tablet (5x3.75) # lsmod | grep acecad acecad 16384 0 usbcore 245760 7 uvcvideo,usbhid,ehci_hcd,uhci_hcd,acecad,btusb,ehci_pci Unless it's a bad compiler build or something, I can't imagine what the problem is. Version-Release number of selected component (if applicable): x11-driver-input-acecad-1.5.0-22.mga6 How reproducible: Always. Steps to Reproduce: 1. Plug the Ace Cad table into a Mageia 6 machine. No worky! 2. Plug the device into a Mageia 6 machine. Works as expected.
Oh for crying out loud! Sorry about the typos. The "Steps to Reproduce", above, should read: 1. Plug the Ace Cad tablet into a Mageia 6 machine. No worky! 2. Plug the device into a Mageia *5* machine. Works as expected.
CC: (none) => johnltw
Cool and not cool. I've tried a few of the experiments suggested on this website: https://digimend.github.io/support/howto/trbl/locating_failure/ First off my tablet is surely working correctly because running the following command in konsole produces reams and reams of output that all sorts of input is being generated and detected as I move its pen: # usbhid-dump -m 0460:0004 -es Starting dumping interrupt transfer stream with 1 minute timeout. 006:002:000:STREAM 1503380149.791645 04 44 09 D5 08 00 00 006:002:000:STREAM 1503380149.799642 04 67 09 CB 08 00 00 006:002:000:STREAM 1503380149.807648 04 87 09 BB 08 00 00 ... and on and on ... Note that in producing the above output, the mouse pointer didn't budge so much as a pixel. I'm starting to wonder if Plasma 5 is intercepting the tablet's input and flushing it straight down /dev/null. At the bottom of that website's page it recommends trying things like MyPaint's input-device debugger. Well, that proved futile as MyPaint, GIMP, and Krita all completely deny the tablet's existence. Inspired by that website, I also installed the x11-driver-input-evdev and xinput packages. There was no noticeable impact from the first one but the following output from the second proved disappointing: $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech USB Receiver id=10 [slave pointer (2)] ⎜ ↳ Logitech USB Receiver id=11 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ HP Webcam id=12 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ HP WMI hotkeys id=15 [slave keyboard (3)] ↳ ENE eHome Infrared Remote Receiver id=16 [slave keyboard (3)] ↳ Logitech USB Receiver id=17 [slave keyboard (3)] The graphics tablet appears to be AWOL off this list as well. I'd like to run that evtest tool described on the webpage, but I couldn't find such a package in our repos. The closest seems to be evtest.py from either the python-evdev and python3-evdev packages but I'm not convinced that's the same tool.
Hardware: All => x86_64
For the sake of thoroughness, I'll add this: # ls -l /sys/kernel/debug/hid/ total 0 drwxr-xr-x 2 root root 0 Aug 21 19:18 0003:046D:C521.0001/ drwxr-xr-x 2 root root 0 Aug 21 19:18 0003:046D:C521.0002/ Both directories concern the Logitech USB Receiver (Vendor ID 0x046d) seen so much in the output of xinput in comment #2. So neither my tablet nor touchpad appear here, but since the touchpad works fine when enabled, I can't see their absence as being relevant.
After some more reading I've learned that all Linux distros are heading toward letting libinput take over as the one-stop shop for all HID drivers. Very well. This got me thinking there might be some sort of module conflict somewhere, so I uninstalled x11-driver-input-acecad, x11-driver-input-evdev (which I'd installed during my experiments in comment #2), and x11-driver-input-wacom (which seemed to have been installed by default). I rebooted, hoping that by leaving libinput on its own the problem might be solved, but I still had no joy with the tablet. Then I discovered this: # libinput-list-devices 1>/dev/null libinput error: event16 - libinput error: ACECAD USB Graphics Tablet : libinput error: libinput bug: device does not meet tablet criteria. Ignoring this device. Fabulous! I'll re-install x11-driver-input-acecad again, but even with that driver module plugged in, might libinput be conflicting with it and forcing the tablet to be ignored?
I didn't think to check Xorg's log. Same complaints about the tablet there too: [ 112.549] (II) config/udev: Adding input device ACECAD USB Graphics Tablet (/dev/input/mouse2) [ 112.549] (II) No input driver specified, ignoring this device. [ 112.549] (II) This device may have been added with another device file. [ 112.558] (II) config/udev: Adding input device ACECAD USB Graphics Tablet (/dev/input/event16) [ 112.558] (**) ACECAD USB Graphics Tablet : Applying InputClass "libinput tablet catchall" [ 112.558] (II) Using input driver 'libinput' for 'ACECAD USB Graphics Tablet ' [ 112.558] (**) ACECAD USB Graphics Tablet : always reports core events [ 112.558] (**) Option "Device" "/dev/input/event16" [ 112.558] (**) Option "_source" "server/udev" [ 112.560] (II) event16 - (II) ACECAD USB Graphics Tablet : (II) is tagged by udev as: Tablet [ 112.560] (EE) event16 - (EE) ACECAD USB Graphics Tablet : (EE) libinput bug: device does not meet tablet criteria. Ignoring this device. [ 112.560] (II) event16 - (II) ACECAD USB Graphics Tablet : (II) device is a tablet [ 112.568] (II) event16 - failed to create input device '/dev/input/event16'. [ 112.568] (EE) libinput: ACECAD USB Graphics Tablet : Failed to create a device for /dev/input/event16 [ 112.568] (EE) PreInit returned 2 for "ACECAD USB Graphics Tablet " [ 112.568] (II) UnloadModule: "libinput"
GOT IT WORKING!!! I followed this advice for a workaround on the U&L Sack Exchange: https://unix.stackexchange.com/questions/312050/genius-graphics-tablet-wp8060u-not-working-on-debian/334997#334997 1) Re-installed the x11-driver-input-evdev package. 2) Created file: /etc/X11/xorg.conf.d/10-evdev-tablet-catchall.conf 3) Contents of the file as given at the link above: Section "InputClass" Identifier "evdev tablet catchall" MatchIsTablet "on" MatchDevicePath "/dev/input/event*" Driver "evdev" EndSection 4) Logged out and back in to let the X server restart. As stated at that link, this is clearly a shortcoming in libinput and searching the 'Net for "libinput error: libinput bug: device does not meet tablet criteria. Ignoring this device." reveals many, many, many legacy (non-standards compliant) graphics tablets are effected well beyond my Ace Cad Flair and the other user's Genius MousePen. Peter Hutterer appears to be the developer and/or maintainer of libinput, and the following bug report is informative: https://bugs.freedesktop.org/show_bug.cgi?id=100043
Hardware: x86_64 => All
(In reply to John ten Wolde from comment #6) > GOT IT WORKING!!! Congratulations :-) > > I followed this advice for a workaround on the U&L Sack Exchange: > https://unix.stackexchange.com/questions/312050/genius-graphics-tablet- > wp8060u-not-working-on-debian/334997#334997 > > 1) Re-installed the x11-driver-input-evdev package. > > 2) Created file: /etc/X11/xorg.conf.d/10-evdev-tablet-catchall.conf > > 3) Contents of the file as given at the link above: > > Section "InputClass" > Identifier "evdev tablet catchall" > MatchIsTablet "on" > MatchDevicePath "/dev/input/event*" > Driver "evdev" > EndSection > > 4) Logged out and back in to let the X server restart. > > > As stated at that link, this is clearly a shortcoming in libinput and > searching the 'Net for "libinput error: libinput bug: device does not meet > tablet criteria. Ignoring this device." reveals many, many, many legacy > (non-standards compliant) graphics tablets are effected well beyond my Ace > Cad Flair and the other user's Genius MousePen. > > Peter Hutterer appears to be the developer and/or maintainer of libinput, > and the following bug report is informative: > https://bugs.freedesktop.org/show_bug.cgi?id=100043 Thanks, John. Assigning to the maintainer of libinput and x11-driver-input-acecad. CC'ing the Base System maintainer group for libinput and the Kernel and Drivers maintainer group for x11-driver-input-acecad
Assignee: bugsquad => thierry.vignaudSource RPM: x11-driver-input-acecad-1.5.0-22.mga6 => libinput, x11-driver-input-acecad-1.5.0-22.mga6CC: (none) => basesystem, kernel, marja11See Also: (none) => https://bugs.freedesktop.org/show_bug.cgi?id=100043
(In reply to Marja van Waes from comment #7) > (In reply to John ten Wolde from comment #6) > > GOT IT WORKING!!! > > Congratulations :-) Thanks. This issue turned out to be quite a headache and I'm amazed I managed to get it sorted all on my own and in just one sitting -- though it did keep me up *waaaaayyyyy* past my bedtime. Thanks also for passing this on to other relevant parties. Now that I've gotten some sleep I should perhaps state my conclusion that there definitely *is* a bug in libinput. Not in that it ignores non-compliant devices; I completely understand Mr. Hutterer's rationale for marking the bug report I linked in comment #6 as RESOLVED WONTFIX -- because adding routines for every corner-case device to what is intended to serve as a *generic* driver would be insane -- but a bug in that libinput *should not* summarily disable a device for which another driver is available. From what I read last night, libinput *should* instead automatically defer control of the device(s) to any other available (legacy) drivers. Examples for which I saw this mentioned included acecad, evdev, syanptics, and wacom. Meaning that Nick Bailey's xorg.conf workaround (outlined in comment #6) shouldn't be necessary at all.
This message is a reminder that Mageia 6 is end of life. Mageia stopped maintaining and issuing updates for Mageia 6. At that time this bug will be closed as OLD (EOL). Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 6's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we cannot be able to fix it before Mageia 6 was end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad
Resolution: (none) => OLDCC: (none) => ouaurelienStatus: NEW => RESOLVED