benthor / HuionKamvasGT191LinuxDriver

Working user space evdev driver for Huion Kamvas GT-191 for Linux
MIT License
26 stars 2 forks source link

No input driver specified, ignoring this device. #1

Open eefeef opened 7 years ago

eefeef commented 7 years ago

Hello Benthor, thanks for sharing your drivers! I tried them on Ubuntu and Debian unsuccessfully, I'm getting the same log. I guess i need to setup xorg.conf differently, do you have any ideas how i should do it?

[ 5007.170] (II) config/udev: Adding input device kamvas-pen (/dev/input/mouse2) [ 5007.170] (II) No input driver specified, ignoring this device. [ 5007.170] (II) This device may have been added with another device file. [ 5007.221] (II) config/udev: Adding input device kamvas-pen (/dev/input/event19) [ 5007.222] () kamvas-pen: Applying InputClass "evdev tablet catchall" [ 5007.222] () kamvas-pen: Applying InputClass "libinput tablet catchall" [ 5007.222] () kamvas-pen: Applying InputClass "evdev tablet catchall" [ 5007.222] (II) LoadModule: "evdev" [ 5007.222] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 5007.222] (II) Module evdev: vendor="X.Org Foundation" [ 5007.222] compiled for 1.19.1, module version = 2.10.5 [ 5007.222] Module class: X.Org XInput Driver [ 5007.222] ABI class: X.Org XInput driver, version 24.1 [ 5007.222] (II) Using input driver 'evdev' for 'kamvas-pen' [ 5007.222] () kamvas-pen: always reports core events [ 5007.222] () evdev: kamvas-pen: Device: "/dev/input/event19" [ 5007.222] (--) evdev: kamvas-pen: Vendor 0x1 Product 0x1 [ 5007.222] (--) evdev: kamvas-pen: Found absolute axes [ 5007.222] (--) evdev: kamvas-pen: Found x and y absolute axes [ 5007.222] (--) evdev: kamvas-pen: Found absolute tablet. [ 5007.222] (II) evdev: kamvas-pen: Configuring as tablet [ 5007.222] () evdev: kamvas-pen: YAxisMapping: buttons 4 and 5 [ 5007.222] () evdev: kamvas-pen: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [ 5007.222] () Option "config_info" "udev:/sys/devices/virtual/input/input23/event19" [ 5007.222] (II) XINPUT: Adding extended input device "kamvas-pen" (type: TABLET, id 14) [ 5007.222] (II) evdev: kamvas-pen: initialized for absolute axes. [ 5007.222] () kamvas-pen: (accel) keeping acceleration scheme 1 [ 5007.223] () kamvas-pen: (accel) acceleration profile 0 [ 5007.223] () kamvas-pen: (accel) acceleration factor: 2.000 [ 5007.223] () kamvas-pen: (accel) acceleration threshold: 4 [ 5112.596] (II) config/udev: removing device kamvas-pen [ 5112.625] (II) evdev: kamvas-pen: Close [ 5112.625] (II) UnloadModule: "evdev"

benthor commented 7 years ago

Please download and build a current version of https://github.com/DIGImend/usbhid-dump

Then make sure that running sudo usbhid-dump -es -m 256c:006e and drawing with the stylus on the screen produces output. If this works, the problem may indeed be in my code.

eefeef commented 7 years ago

I'm receiving the output. I tried it in Arch as well but it's not working. Are any DIGImend packages required?

ntcrotser commented 7 years ago

Receiving output on Arch (x64, 4.3.12, MATE) and still no cursor movement.

insomniacUNDERSCORElemon commented 7 years ago

Unfortunately I'm having the same issue as the others.

I've tried different drivers (digimend and wacom), different conf file setups, even a different version of xf86-input-evdev (also, so much restarting). It just doesn't work. Except for with usbhid-dump.

I'm using Antergos, up-to-date. Kernel 4.13.12-1, xf86-input-evdev 2.10.5-1. Yes, using X11 (tried on LXQt, Plasma, and KDE/Openbox).


Assuming there is something going wrong here user-side, maybe more diagnostic checks+echos should be added if that is possible.

johnp789 commented 7 years ago

I'm another person who just got a GT-191, and I'm not getting cursor movement with this driver. usbhid-dump outputs lots of lines like the following when I draw on the screen, but my cursor doesn't move. I'm happy to help troubleshoot---just tell me what information to supply.

003:004:001:STREAM             1512254129.637360
 0A 80 EA 5A D2 6B 00 00

I created a gist with usbhid-dump data from my GT-191, but with the debug level set to 5.

johnp789 commented 6 years ago

For me, the call to read never returns.

I added strace output for the kamvas.py and for usbhid-dump to my gist.

johnp789 commented 6 years ago

This hack within a hack is working for me.

insomniacUNDERSCORElemon commented 6 years ago

@johnp789, Works for me too, on Arch.

I got 2 screens to work by modifying my values in offsettest.sh to

C0=0.5 C2=1.0 C1=0 C3=0

but then again, my other display is 1080p and to the right of my Huion. Note that the first 4 lines do nothing since benthor did not make them determine the values of C0-4. Eg something like C0=1920 / (1920 + $W)


Although after updating my system, the Digimend driver now gives me hid_uclogic: disagrees about version of symbol module_layout rather than the title of this issue. Though it no longer loads, so would likely return to that if it did.

benthor commented 6 years ago

All right, I've been able to reproduce the issue most people seem to be having. Following a cold reboot, my driver stopped working for me as well.

It turns out that during development, I frequently relied on the uclogic-tools for debugging.

It turns out that running uclogic-probe on the device is required at least once (per boot) to properly initialize it. Adding the same functionality to my driver is on the agenda for a future release.

Meanwhile, as a quick fix, the following script works for me. You will need to have a current build of uclogic-probe (and, optionally uclogic-decode) from the uclogic-tools in your PATH and maybe adjust the DRIVER location, depending on where you put this script:

#!/usr/bin/env bash
# Adjust this as needed
DRIVER="HuionKamvasGT191LinuxDriver/kamvas.py"

T="256c:006e"
BUS=$(lsusb | grep "$T" | sed -e 's|Bus \([0-9]*\) Device \([0-9]*\):.*$|\1|g')
DEV=$(lsusb | grep "$T" | sed -e 's|Bus \([0-9]*\) Device \([0-9]*\):.*$|\2|g')

sudo rmmod hid_uclogic
sudo modprobe uinput
sudo uclogic-probe $BUS $DEV | uclogic-decode
sleep 3 # wait until device is released again
sudo python3 $DRIVER
TheJackiMonster commented 6 years ago

Thanks really much for publishing this short driver. Today I got my new device and it worked very fine.

After that I started to put the necessary code from uclogic and this project together but just using c, because I had some performance-issues in Krita. I have finished the first try and completed all features equivalent to your python code but the cursor is still following the pen more than being it.

Maybe anyone has some more knowledge about this, but for example in Xournal the movement is just perfect.

PS: Here's my code so far... https://github.com/TheJackiMonster/HuionGT191LinuxDriver

TheJackiMonster commented 6 years ago

I have nearly finished an accurate driver. It solves the problem with 2 monitors in just 1 xscreen via searching for the correct device and its bounds with Xrandr and the EDID. Also I added to emit the events from buttons only once they change state, so any software won't receive blinking events in a row or multi-clicks.. ^^

I setup a udev-rule to allow a general user to execute the driver (which can changed for specific groups of course) but I would like to have a clean automatic execution of my driver by that rule. The problem with it is that when I launch the driver directly it doesn't get access to the usb-device that early and if I wait via sleep etc. udev cancels the call or something.

So.. does anyone know how to setup a call of the program automaticly when I plug in the device via usb? ( That would actually complete everything I would like to have in my driver except fixing bugs if something comes up. )

insomniacUNDERSCORElemon commented 6 years ago

@benthor I I'm not sure if I'm alone in this, but your fixes+directions didn't seem to work for me. Plus I'm fairly sure I had already used uclogic-probe on the older version.

@TheJackiMonster have you seen the high-resolution Huion tablets pull request on the master DIGImend branch? It'll be more helpful to everyone if you could contribute to that and make sure it is up to spbnick's requirements so it can be accepted.

I'm assuming that covers the 191 at least, although Huion is sort of a mess with the USBID being the same for all of their devices. I'm not sure how different each tablet actually is. Like how the 191 has its pen detection in an area larger than the display (did you fix that in your driver TheJackiMonster?) which causes the pen to be more inaccurate as you get closer to one of the edges.

Orientation and button customization (particularly as set from a GUI) is another thing I wonder about.

DiaaShalash commented 6 years ago

I tried it on linux mint 18 and it worked . I have it running now with dual monitor setup.

thank you very much

wilcook commented 6 years ago

I can't get this fix to work for me. I run Arch also, and --

when I run: sudo uclogic-probe $BUS $DEV | uclogic-decode I get: Failed to get manufacturer string descriptor: Pipe error

I did test to make sure that the pen use is being recorded by running "sudo usbhid-dump -es -m 256c:006e" and that worked just fine.

If anyone has any ideas it would be greatly appreciated. Thanks!

insomniacUNDERSCORElemon commented 6 years ago

@wilcook Have you tried the newer Digimend driver? Those work for me. Might not be perfect yet (eg margins not being accounted for properly) but it should work as well as this (or at least johnp789's hack).

Also note for Digimend's installation, follow it to the letter. Apparently uninstalling old stuff and restarting is not good enough, you need to actually unload the modules.

vvcb commented 5 years ago

@benthor Thank you very much for this simple, yet very effective driver.

Device: Huion Kamvas GT 191 v2 OS: Lubuntu 18.04 Display setup: VGA external monitor connected to laptop as a single display. Have not tried dual monitor setup. Status: Works without any major issues. No lag/misalignment. Very rare crashes fixed by reconnecting device and rerunning script (aging hardware being taxed to failure).

Digimend V9 (https://github.com/DIGImend/digimend-kernel-drivers/releases/tag/v9) did not work for me. I was unable to compile @TheJackiMonster's driver before the urge to play with the new toy took over.

TheJackiMonster commented 5 years ago

@vvcb What kind of problems/errors did you get? If you open an issue on gitlab, I will look for a solution.

wwklnd commented 5 years ago

I just tried running @benthor 's quick fix on my Kamvas Pro 13 (which has very similar specs), and while the usbhid-dump output shows up when I hold the pen close to the screen, no drivers seem to work for me. Here, I get the same issue as @wilcook with the pipe error. :(

wwklnd commented 5 years ago

Okay, I uninstalled the uclogic-tools package I had installed from the Arch User Repository and instead compiled the latest version from source, which solved the pipe error. The pen display still isn't working properly, but that issue was apparently fixed in a new version of uclogic-tools.

BugHunterPhilosopher commented 5 years ago

Benthor: with your patch from 12 Dec 2017 it works flawlessly on my wife's Debian Stretch box!

Thanks a lot, congratulations and keep up the good work!