-
Notifications
You must be signed in to change notification settings - Fork 2
No input driver specified, ignoring this device. #1
Comments
Please download and build a current version of https://github.com/DIGImend/usbhid-dump Then make sure that running |
I'm receiving the output. |
Receiving output on Arch (x64, 4.3.12, MATE) and still no cursor movement. |
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. |
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.
I created a gist with usbhid-dump data from my GT-191, but with the debug level set to 5. |
For me, the call to read never returns. I added strace output for the kamvas.py and for usbhid-dump to my gist. |
This hack within a hack is working for me. |
@johnp789, Works for me too, on Arch. I got 2 screens to work by modifying my values in offsettest.sh to
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 Although after updating my system, the Digimend driver now gives me |
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 Meanwhile, as a quick fix, the following script works for me. You will need to have a current build of #!/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 |
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 |
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. ) |
@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 @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. |
I tried it on linux mint 18 and it worked . thank you very much |
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 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! |
@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. |
@benthor Thank you very much for this simple, yet very effective driver. Device: Huion Kamvas GT 191 v2 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. |
@vvcb What kind of problems/errors did you get? If you open an issue on gitlab, I will look for a solution. |
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. |
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! |
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?
The text was updated successfully, but these errors were encountered: