HUION Kamvas Pro 22 drivers not available on DIGImend list


#64

bogdan was right, they are identical :roll_eyes: mostly.
i think we are mixing up methods from various sources here. maybe start from a clean boot and run no scripts and evaluate before


#65

Should we test it? @dglt told me that the GT191 and the GT220 are similar.


#66

But they call two kamvas.py from different locations … We have to make sure that they don’t choke something

@dglt was perfectly correct, those models are similar … but, the catch is that those that made the scripts used just a bit of different approach. This is nobody’s fault, we have just to figure out what approach is better suited in your case. My proposal was to make sure that the two aro not doing the same thing but with a slight difference.

Test them separately not one after another.


#67

i beleive both scripts/drivers work by first rmmod hid_uclogic. i think you should add that line back in and only run one of those scripts 1 time per boot as it states, and if not working, reboot and try with the other script and see if there is a difference.


#68

they are all similar, most similar to yours (gt-221 pro v2) is the gt-192 which from what i can tell is identical in every way except 2 inches smaller and 4 sections of 4 buttons, where yours has 4 sections of 5 buttons. i mentioned the gt-220 previously (which aside from similar model numbers, are not nearly as similar.
gt-220 gt-220 (one for which drivers we are trying to make work unsuccessfully)
gt-191 gt-191
HUION-KAMVAS-GT-221-Pro-8192-Levels-Pen-Tablet-Monitor-IPS-LCD-HD-Drawing-Pen-Display gt-221 (yours)
KAMVAS-PRO20 gt-192 (i am currently searching for a gt-192 solution to try)


#69

have you also tried using xf86-input-wizardpen from AUR? suppose to work with most non-wacom tablet displays/pens and mentions uc-logic compatibility, maybe install after a clean boot when the other drivers wont interfere and uc_logic is on. its think its worth a try
https://launchpad.net/wizardpen

download evtest from manjaro repo, automatically produces a list of input devices on your system, lets you choose which one to test from a numbered list (wish i found this a long time ago dealing with touchpad bs). this produces output in real time so you’ll be able to see if your pen is doing something and not applying it for whatever reason or if its just not read at all. either way its a very useful tool.
sudo pacman -S evtest
sudo evtest
do you still have the digimend drivers installed? try this test with/without. same with wizardpen drivers. try each independently and each separately . just keep track of what you have installed to avoid conflicting drivers


#70

I’ve done all what you told me to do but just running one script instead of the two similar scripts but nothing works.

I’ve also downloaded evtest and wizardpen. I do not know how wizardpen fuctions but there is the possibility in the terminal to do wizardpen-calibrate usage: wizardpen-calibrate event-device - probably /dev/input/event0.

If I do:

sudo evtest No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	Power Button
/dev/input/event1:	Sleep Button
/dev/input/event2:	Lid Switch
/dev/input/event3:	Power Button
/dev/input/event4:	AT Translated Set 2 keyboard
/dev/input/event5:	Logitech USB Optical Mouse
/dev/input/event6:	PC Speaker
/dev/input/event7:	Chicony USB2.0 Camera: Chicony 
/dev/input/event8:	Video Bus
/dev/input/event9:	SynPS/2 Synaptics TouchPad
/dev/input/event10:	HDA Digital PCBeep
/dev/input/event11:	HDA Intel PCH Mic
/dev/input/event12:	HDA Intel PCH Front Headphone
/dev/input/event13:	HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event14:	HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event15:	HDA Intel PCH HDMI/DP,pcm=8
/dev/input/event16:	kamvas-pen
Select the device event number [0-16]: 16
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1 product 0x1 version 0x3
Input device name: "kamvas-pen"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 320 (BTN_TOOL_PEN)
    Event code 330 (BTN_TOUCH)
    Event code 331 (BTN_STYLUS)
    Event code 332 (BTN_STYLUS2)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value      0
      Min        0
      Max    95352
    Event code 1 (ABS_Y)
      Value      0
      Min        0
      Max    53645
    Event code 24 (ABS_PRESSURE)
      Value      0
      Min        0
      Max     8192
  Event type 21 (EV_FF)
Properties:
Testing ... (interrupt to exit)


It is the first time that I see again the kamvas pen!! But it is not recognized if I try to draw for example in Krita and pressing ctrl=shift+t.
Note that the Testing ... (interrupt to exit) lasts very long but I have tried this function with another device (no. 8) formerly and it was the same.

If I check my history I have made

489  wizardpen-calibrate 
  490  sudo evtest
  491  lsmod
  492  sudo evtest
  493  history
  494  sudo ./start-driver.sh 
  495  history

But you should note that I have tried to stop the driver start-driver.sh by doing ctrl+Z.

Doing, we can see the pen once and not twice like at the time it was working on my computer.

xinput --list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech USB Optical Mouse              	id=11	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=13	[slave  pointer  (2)]
⎜   ↳ kamvas-pen                              	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)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=12	[slave  keyboard (3)]
    ↳ Chicony USB2.0 Camera: Chicony          	id=10	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]

Any idea @dglt @bogdancovaciu @tbg? I think we are not too far since I see again the pen.


#71

did you add the lin sudo rmmod hid_uclogic back into the uclogic-probe-run.sh? this script while almost identical includes sleep 3 allowing the device to be released before starting the kamvas.py driver. lets stick with this one, just add the line back in. lets try a couple things and if it still fails to work lets try tobias frisch’s gt-191 setup as it seems to be the general concensus of whatever i could find that regardless of its appearance is still very similar to you gt-221.

btw, do you have the wacom drivers installed? i only ask because i seen some people saying using the wacom drivers works for some models by reading input as if it was a wacom device, which it kind of is but it has a screen where you would normally just have a pad

after clean reboot
sudo ./uclogic-probe-run.sh > /dev/null 2>&1 & disown; sleep 2; exit
and then shutdown/disconnect the tablet
turn the tablet on and then reconnect it, or if thats not possible reconnect/turnon (how is it connected? what connection options do you have?)
sudo evtest
select the number for the kamvas-pen and then try using it and watch the terminal to see if using it is producing output


#72

i agree, your able to get the pen recognized which is good, now lets get it to work the way it should


#73

Yes, I have.

How can I know if they are installed? If I type wacom in pamac I see that libwacom seems to be installed since there is a green tick before it on the left.

After more than 34 minutes, it is still “testing” so I have the impression that it never goes until the end of the testing since the two time of my use of it, it was always like it.

Should I reboot my computer, since I thought that we are close to make the pen works?

The tablet is connect either by HDMI (it is the case now) or by the old blue video connexion and at the same time by a USB connexion.


#74

this could be a long shot but have you tried it using video/usb? or better yet, just try it with hdmi + usb connection and see if the pen is picked up as a usb device?? i likey this idea*****
why? because if you were using video/usb connection then video would be just video, not pen input and the usb would be for things like pen input. so using a usb + hdmi may do the same, im not sure if the hdmi connection would interfere, its worth a shot


#75

I am not sure that I understand correctly but since the beginning, I have still connected/disconnected the USB connection to the graphic tablet and have used always at the same time either the HDMI or the video connection (but most of the time the HDMI one).


#76

ok, i thought you were connected only via hdmi and i was suggesting using both hdmi/usb but i guess thats how its already connected :frowning_face: , i got overly optimistic there for a second.

ok, from what little i understand about this display/tablet , it only displays whats on your computer screen and allows you to draw over whatever is there yes? so using the pen has no effect right now on both your tablet screen and your computer screen (i know this seems obvious, im just clarifying as ive never used one before). the screen itself cannot be used without being connected to a computer correct?
if the ansers to both of those ??'s are yes then lets get back to making it works the way we were, and sorry for the misunderstanding.

im looking into other solutions in the mean time, since we are able to get the pen detected which we were not able to accomplish for the majority of this thread, we are making good progress here. your using xfce right?


#77

The pen is handled by xf86-input-wacom even tho the device ID is handled by libwacom
You could try it.


#78

@bogdancovaciu i was just reading that your manajro wiki page and i agree its worth a shot.
also what about input-wacom-dkms kernel modules. it looks as if both gnome and kde have graphical configuration utilities but not xfce, and the workaround is no longer valid to use gnome settings.
@Killi you mentioned you had libwacom installed but do you have xf86-input-wacom also?


#79

just to clarify, have you never even tried using digimend-dkms-drivers-kernel-git from the aur? if not, dont just install yet, you dont want multiple drivers fighting each other for control. just want to know to keep it in mind as a possible solution untested as of yet.

for right now since your pen is detected and we dont want to bail out of this plan of attack just yet.
sudo pacman -S xf86-input-wacom
if this makes no difference right away, reboot, make sure pen is still detected, if not lets try the digimend dkms from aur. if those do nothing, uninstall and reboot (digimend drivers are meant for non wacom graphics tablets so a quick install and attempt i think is a good idea before going much further, and uninstall if its unsuccessful) but same thing as before, install,test,reboot,test (we are looking for something that picks up the pen output, even if not well and we can work from there. sorry if i keep going one way and then another, digimend just looks promising even though your tablet is not listed by them


#80

I do not understand what happened since the time that I have posted my messages #69. I’ve just made a break and put my laptop with the connected graphic tablet in sleep and maybe as @tbg said in his post #53, it is recommended to put in a sleep mode.
Now I can draw with my pen as I want on my pad.
Now that it works, I can see in the sudo evtest that I have not interrupted since the one aforementionned listing tens of lines like these one:

Testing ... (interrupt to exit)
Event: time 1545152363.168777, type 3 (EV_ABS), code 0 (ABS_X), value 20372
Event: time 1545152363.168777, type 3 (EV_ABS), code 1 (ABS_Y), value 25955
Event: time 1545152363.168777, -------------- SYN_REPORT ------------
Event: time 1545152363.178494, type 3 (EV_ABS), code 0 (ABS_X), value 20291
Event: time 1545152363.178494, type 3 (EV_ABS), code 1 (ABS_Y), value 25903
Event: time 1545152363.178494, -------------- SYN_REPORT ------------

The next step is to know what I should do in order that it works every time.
The xinput --list result is the same than the one mentioned before.
Apparently, I have made

wizardpen-calibrate --help 
wizardpen-calibrate 
usage: wizardpen-calibrate event-device - probably /dev/input/event

later I have run the scriptsudo ./start-driver.sh then I tried to stop it by pressing on ctrl+Z in the terminal.
Then I have typed xinput --list and I have seen the kamvas-pen listed and then I made a break putting the computer (and apparently also the graphic tablet) into a sleep mode. Then I came back from my break and it worked. My question is the following: does it work thanks to wizardpen-calibrate orsudo ./start-driver.sh? Or what should be the way to make it work every time that I want to use the tablet?

Thanks once again for your patience.


#81

According to pamac, xf86-input-wacom is not installed and the pen does function now with its sensibility.


#84

According to pamac, I do not have input-wacom-dkms installed neither but the pen with its sensibility seems to work without that.

No, I do not remember that we have done “together” since the beginning of this forum page, and I have not tried by myself with this “tool”.

so it has worked just by making a break without doing sudo pacman -S xf86-input-wacom


#85

so as of right now, are you able to make it work by a combination of sleep,wake,script/driver,wizardpen,etc… GREAT!!! we now have a much smaller target to hit from here on. now we figure out which of those or what combination of those (i doubt all are necessary but who knows) so we can eliminate as many variables as possible and get this to work reliably.
since you have it working right now, test its accuracy and whatever else you think is necessary so you know if it works better or worse as we figure out the best way of making this work the way you want. one option may be more flexible, allow more option, and provide less bs than the other options.