Bug 21591

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.

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.

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

(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.vignaud
Source RPM: x11-driver-input-acecad-1.5.0-22.mga6 => libinput, x11-driver-input-acecad-1.5.0-22.mga6
CC: (none) => basesystem, kernel, marja11
See 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) => OLD
CC: (none) => ouaurelien
Status: NEW => RESOLVED