XP-Pen Arist 15.6 Pro Support #291
Conversation
|
Heey, very nice work, Matthew!
Since it's that big, could you also put probing in a separate function, like it's done with
From the traces, configuration descriptors, and report descriptors, I see that the request and the response you're dealing with are simply output/input reports being sent/received on interface 2. BTW, what happens if you don't send that, what's the difference? And speaking about crazy things, do you think you could contribute your tablet diagnostics to the tablets repo?
I would check there is no setting in the windows driver to increase the resolution, and you're using the latest driver, and then see what the actual reported coordinate is. If the tablet works normally in Windows, then dividing the coordinate extent by the active area extent in inches would produce the actual resolution. I don't think your tablet is defective. Maybe marketing is just "exaggerating things slightly".
Didn't review the report descriptors properly yet, but I generally just copy something close from my own descriptors and modify.
Never really bothered about it, and never had a problem with buttons, but maybe something else is wrong? Anyway, the HID spec says:
Push/pop should work as well.
Take a look at the Huion button pad report descriptor. These are made to produce BTN_0-BTN_9 and then BTN_A, BTN_B, BTN_C, and so on, IIRC. This way the Wacom driver would handle and allow remapping them (e.g. with xsetwacom). The wheel needs to report as a relative or an absolute wheel (for the Wacom driver, again). Take a look at the Ugee G5 report descriptor for example.
I find it strange that the Windows driver doesn't support tilt. Windows users are their primary customers, and XP-Pen advertises tilt support. Could you check again, and also see how the pen position behaves at those extreme angles, with tilt support or not? I don't know how extreme those angles are, and I'm not an artist, so I don't know if this kind of input is even useful. It could be that the tablet has this kind of reporting problem and the windows driver works it around somehow, but I wouldn't bet on it. In general at large angles position reporting breaks down, the question is which angles are those for your tablet.
Weeell, it's still very much a UC-Logic tablet, and I'll be OK with including it, especially if we manage to simplify it. I can't stop you from making a separate driver, but I would like a review from upstream first before including such a driver into digimend-kernel-drivers.
Hmm, it shouldn't be calling the pad "Pen", something is fishy. We can take a look at this later.
Huh, does it really need to configure the device for calibration? I would have thought host-side scaling would be enough. There's xinput-calibrator, BTW, maybe it can help.
Thanks a lot, very nice work! |
|
BTW, could it be that calibration is enabling the full resolution? |
Could be, I was doing diagnostics on it this last weekend. I'm on "vacation" the rest of July though, so I won't be around to do hardware testing till August. I should have all the changes in and the tablet info prepared the first weekend next month though. |
|
Sounds good! No problem at all. I'm taking a vacation too, BTW. |
|
Back from vacation so Ima work to wrap this up this week.
The interface doesn't work without that magic packet. ✓ Tablet info pull request made.
I'll get access to a non-VM Windows install this week to run more tests on and see if I can't get the resolution to full.
A lot of their reviewers actually bring it up as a problem. Heres one example, but it seems fairly consistent across reviewers. Maybe they left it out to keep a market for their larger, more expensive devices?
That seems like it would be extremely ugly to have the params init not actually initialize the interface - you would have a one-off event containing the response packet which would just be an extra conditional in every event parse to check for. And its really only that if that packet is received in proper form than the interface is active - you won't get anything until its sent otherwise from interface 2. In practice if the init fails then nothing is ever received anyway and the tablet does nothing - the only reason to verify the response is for correctness' sake and because it could theoretically let you retry the init packet until it works (or maybe fall back to the bizarre default interfaces?). Everything else is mostly on hold until after I can see what the display settings do under a probe on an actual Windows machine. Once I get those diagnostics (tomorrow, I hope!) I'll post the revised patch. |
|
Got to that legitimate Windows machine to test the tablet on, albeit the results aren't that interesting - here are all the Wireshark captures doing various things (the tablet is on bus 1.3.3). The display calibration isn't using the USB interface at all and seems to just do Windows display manager color adjustment / rotation / etc. Resolution never changes, tilt doesn't follow (as expected), and theres no magic sauce here to change behavior or make anything work. In particular, the "corners" test was done after a reboot and all the knobs I could tweak were tweaked and the tablet still only reports coordinates at a resolution of 35689x20598. So either this specific unit is running at half resolution or the marketing is just bunk. I'll get the base patch into a mergable state as soon as I am able, and I'll split out the activation packet config and tilt support into their own separate commits. |
Korvox
force-pushed
the
master
branch
3 times, most recently
from
00cc524
to
a2ebbb6
Compare
|
Finally got some time to clean this up, I rebased to two commits for now (I have the tilt stuff in a branch I'll fix up once this is merged). Its in two commits because no matter what I try I cannot get the tablet buttons to show up if I write their report descriptor as buttons and not as keys. Several other tablets do use keypads for their pad buttons, but they only have up to 8 of them and use Leftcontrol to Right GUI at the end of the key space. This thing has 10 buttons and my attempt to have the "wheel" be a relative control just had me getting irq status -75 which seems the input subsystem doesn't like treating buttons as relative values. So it looks proper to treat the two wheel buttons as, well, buttons. Or keys. But not as a relative control. Which then begets the question of what keys buttons 9 and 10 would be if the de facto strategy is to use the 8 buttons at the end of the non-reserved keyspace, and the two keys preceding them are... also reserved. I only have a Huion tablet that uses the keypad behavior to inspect locally so the first commit is what I assume the button style is "supposed" to look like while the second is what I'm actually using to test the thing because I actually get working buttons that way. So feel free to merge the first commit alone. Its passing Travis, what else needs doing? Edit: I have tilt compensation on a branch in my fork here |
|
Hi @Korvox , I was testing your fork and can confirm the pen nib is aligned with the cursor and the tilt seems to be working fine, I can even configure the mapping, calibration and pen pressure through the KDE Graphic Tablet configuration GUI, however I can't get the keys to work using the keypad code nor using the button code from your first commit ( I tried using the KDE gui and the xsetwacom command). Am I missing something? Does it need to add anything to the xorg conf file? |
|
Same on my end trying out the wacom driver, but I've been mostly developing it on libinput where the function keys variant works. I based the report descriptor off the already existing ones so I'm wondering what both drivers aren't liking about having button maps because xinput reports no buttons under any driver (including evdev, which should at least recognize a keyboard). I'm wondering if it might have something to do with this tablets ids not showing up in any of the udev tables. This did lead me to test out the tilt behavior again after calibrating on wacom properly and realizing that I need to account for the rotation of the pen in the tilt calculation, basically the offset given the two angles is length = height * tan(∠x), width = height * tan(∠y), d = sqrt(8) / 4, x = ± length * d, y = ± height * d for any time where both angles are > 0. I'll update the patch tomorrow though since I just spent two hours using matplotlib and hand math to find the intersections of an elipse and line because I fail to realize the Internet exists. Though if I may ask a favor can you post your uclogic-probe results? I just want to verify XP-Pen is really advertising this tablet as being double its actual resolution. Though if the tilt support was working with the hardcoded dimensions that probably already tells me the answer... Edit: I lied and fixed the tilt support instead of going to bed. Its 3:30am. Do try it out though and see if its as accurate as its coming up on my end! The only real variable thing I want to check for is sensor height - its hard to accurately gauge how high above the tablet surface the pen actually tracks at, I'm currently using 1.8mm in my script that generates the tangent table. Edit 2: The buttons should be working under wacom now, it seems to really want a report descriptor with a top level keypad usage. Still need to figure out the button mapping on libinput but thats not much of a blocker. As it is its looking pretty close to merge ready for the full version with tilt included, just let me know when you want to actually do the merge and I'll squash the branch onto my master. I'll do one more optimization pass on the tilt handling before that, there are a lot of unnecessary variables / possibly excess branching. |
|
Here is the output from uclogic-probe, however in the terminal I get "Failed to get string descriptor 0xC8: Input/Output Error" at the end and the tablet gets disconnected. I was using the code from your last commit on the tilt branch, however the keys still didn't work. |
|
Its incomplete because its not a real uclogic device. Looks like your tablet has the exact same resolution so its good to know its just bizarrely arbitrary dimensions (though its not that arbitrary, 34419x19461 gives it 100 pixels per mm). So XP-Pen is just falsely advertising? It also shouldn't be totally crashing - one of the string descriptor queries puts it in a legacy emulation mode that makes it show up with usb id 28bd:1227 as a mouse and keyboard:
I did a few more cleanups I force pushed to my branch recently, but when I run it under the wacom driver I see two devices:
If its still not working for you as of my latest changes it might be down to udev / x / wacom versioning. |
|
Thanks for the explanations @Korvox, the usb id changed to 28bd:1227 after the uclogic probe crash. It seems that everything is working now, even the keys and the tilt (or at least from what I can see), first I was trying on Manjaro with kernel 5.2 and I couldn't get it to work, but it is working great on Debian with kernel 4.19, not really sure if that has something to do with it. The only thing I can't get to work is the keys configuration from the KDE GUI, but it's not really a problem since it can be done through xsetwacom (leaving it here in case someone runs need the buttons numbers): #tested in krita #scroll wheel buttons KP_Add and KP_Subtract to zoom in and out using numpad keys #last 4 button |
|
@lambferatu if you (or anyone else that happens to have one of these) find the tilt accuracy is even slightly off I'd ask that you tweak the tangent table the tilt function uses to see if you can't get it more accurate. I measured it to 1.8mm but thats just through guesswork. This is the script I use to generate it, just change the value of height. #!/usr/bin/env python
import math
# height in millimeters
height = 1.8
# pixels per mm
resolution = 100
max = 64;
if __name__ == '__main__':
for i in range(1, max + 1):
droop = height - (i * height / (4 * max))
print(round(math.tan(math.radians(i)) * droop * resolution), ',', sep='', end=' ')Edit: @spbnick doodled with the full tilt supported version all weekend, probably makes sense to squash this down to two commits (tablet and tilt) and just merge both at once since everything is working. |
|
Figured out it takes a hwdb entry for the pad for it to be recognized under libinput. This entry works, and when this gets merged I'll send it upstream hwdb. |
|
I'd like to test and give feedback, but I may not be smart enough. Installed modified digimend kernel drivers, created file /usr/lib/udev/hwdb.d/90-pentablet.hwdb with the lines above, rebooted, opened kde settings => hardware => input devices => graphic tablet, and found nothing detected. xinput shows 3 versions of ugee, and everything works as before digimend install. Which is to say, under opensuse Tumbleweed with kernel 5.3.6, the buttons and dial all work, as does pressure and tilt sensitivity (though not degree of tilt), though no mapping is possible, either of the buttons or of the pen, so it only works right when set to mirror the primary display with the same resolution. -GEF |
|
@gefagan KDE's KCM is only for xf86-input-wacom. You'd have to force the wacom driver with an xinput conf like this: The 3 versions of UGEE would be the pad, pen, and tablet device that libinput generates. If possible, run Otherwise check your usb ids to make sure they match |
|
That was quick! Thanks for yur work on this, Korvox. libinput record generated a lot of paragraphs like this:
This was while I was trying my calligraphy hand in inkscape. How long a file do you need? GEF |
|
@gefagan Thats the pen interface, record the pad and just press the 10 buttons on the tablet body. One of my primary reasons for doing all the custom report descriptors was because the included ones generated garbage key events. Additionally, just for curiosity, run uclogic-probe and post the results. I'm still baffled XP-Pen is advertising a tablet that really only has half the resolution it claims to. |
|
clarification: libinput gives me 4 choices, as follow: /dev/input/event14: UGTABLET 15.6 inch PenDisplay Mouse The only one that generates anything interesting is the event16. |
|
Okay, there's a lot here, so elipsises represent the bits I snipped for clarity. I pressed the express keys in order, and after the 4th, turned the dial clockwise and then counterclockwise. Key 7 interrupted the command, so I issued it again and pressed 8, then each of the buttons on the pen: [code]
|
|
Your results are accurate to what I've seen - the default keyboard interface generates garbage key events and codes. I'm pretty sure its designed for coverage to use as an early boot device keyboard so that if you smash all the buttons one of them will probably do something you want. |
|
standby, had to find a version of libusbx before I could make uclogic-tools install, and now I have to figure out how to use it. |
|
Is this what you wer asking for? purplebox:/home/gef # uclogic-probe 001 004 |
OK, no show. lsmod|grep 090d yields nada. So that means I didn't install patched driver correctly, eh? What I did was unzip into /opt, change to that directory, opened a terminal and typed make dkms_install, yielding a string of output that mostly said it's installing nothing because my kernel already has stuff, but I can override by specifying --force. So, "make dkms_install --force" is the wrong syntax. Do you know where the switch goes? |
|
"Meanwhile, to fix the issues, you can apply these yourself, or execute the following command: sudo sed -i Be aware that the operation of the above command is inexact, and might not work, or might break DKMS. " Worked for me, however I still don't have any output from lsmod that looks like 090d. |
|
@gefagan lsmod would have hid_uclogic in it, not the actual vendor ids - the point is that if your vendor ids match (they do) and you have the modified driver available via dkms (you should) it would show up with the tablet attached because the kernel would load the hid_uclogic driver for the device. Also that uclogic-probe seems incomplete, it only has the manufacturer and product. It should print several lines pf additional hex with a leading S. Also note that uclogic-probe can bork the tablet - the device node can change, the name, the usb ids, etc. It queries a few magic numbers that put the tablet in compatibility modes that don't work. But the first run freshly attached should work (and if the tablet gets borked just replug it). |
Any chance this could be more than temporary? The first time I ran uclogic-probe, I did get a bit more output, but I wasn't sure I'd tested the right thing so I moved it to a different usb port, checked what changed, and probed that. Since then, re-plug, re-boot, reboot tablet with long wait, no different tha what I posted. Also, tablet doesn't work anymore. Vendor-supplied driver says it's disconnected, both in linux and win10 vbox, both this laptop and another that I haven't been experimenting on. lsmod | grep uclogic returns naught. Thanks Korvox for quick and frequent replies, and for your effort to make a better driver for my tablet than the vendor will supply. Beer money's about all I can afford, so lemme know where/how best to send it. It's midnight my time, think I'll turn in and hope this works tomorrow night. See you here with my results. -GEF |
|
Y'know, the driver from xp-pen does a passable job with the buttons, but it doesn't support tilt. Is it possible to run that driver for the buttons but overrider it to use digimend for the stylus? |
|
I could update my branch to make sure the buttons still work on top of the latest upstream, but I've been using the buttons on and off fine for the better part of a year now. Just remember that a lot of programs won't "handle" the buttons right without some kind of input system level configuration. XInput / Libinput / etc will call them Tablet Pad Button events and at least Qt doesn't recognize them as generic buttons. They show up like this: I am currently trying to fix this on the side. I've been working on a KCM to configure libinput tablets over here that will handle mapping the buttons to normal keys on X and Wayland. Eventually. Only just started working on it again after a work related hiatus recently. If you have Firefox you can test if they work without configuration. The top 3 should act like mouse buttons by default. Not sure if its specific to their input handling or its generic over GTK. |
|
Thanks Korvox. I totally understand a work-related hiatus. Buttons worked fine for me until kernel 5.3.12; presently on 5.6.8. In general I find fewer problems with rolling than point release, because any problems that show up get fixed fast. Given a choice between buttons (vendor driver) and tilt (digimend), for now I'll take tilt (for calligraphy) and reach over to my keyboard for ctrl-z. Or maybe I'll map ctrl-z to one of the stylus buttons because they work fine. That said, I really like the way the Windows driver supports cycling through multiple functions for the dial, and I'm thinking that could be replicated with a bash script. Frex, sometmes zooming is useful, sometimes a scroll wheel is useful, and for animation if I ever get into that, I've heard recommendations that the scroll wheel should be mapped to move through the timeline. |
|
Wow I'm now finally able to use PEN and PAD and also to map the buttons :)
|
|
Hello ! I have an XP-Pen artist 12 Pro which seems to be very close to the XP-Pen artist 15.6 Pro (size change but pad buttons seem to be the same). I also saw in config.xml of XP-Pen linux driver (pentablet) that options for the 12 Pro are the same of 15.6 Pro (they are under the item)... Could you give guidelines to be able to make it works with your experience of 15.6 Pro on this thread : (I'm on archlinux and I can give you as many infos as you need on the precedent thread...). |
|
Sorry for multiple posts but this driver does it still works on 5.6.x kernel ? I tried it on my XP PEN Artist 12 Pro (after many adaptations/tries) without any success (on kernels 5.6.13 and 5.6.14 now). I'm getting I would like to know if you have the same problem on your Artist 15.6 Pro (with 5.6.x kernel). Thanks. |
|
I got some requests through the grapevine to rebase this off master. Since I heard no real complaints about the tilt handling I just merged it all into one commit. Also changed the name of Edit: Realized testing that tilt compensation was never being run due to changes in control flow of uclogic_raw_event so I just moved it where it works and force pushed the fix. Its a bit ugly there, but it can't move into uclogic_raw_event_pen because it needs to check against vid / pid in hdev. |
Korvox
force-pushed
the
master
branch
2 times, most recently
from
983af0d
to
7df6ea2
Compare
|
Heya, I'm trying to get my 15.6 work, though I can't seem to get the pad keys to show up under xinput list. Is there something I'm doing wrong? Also what is the UI utility used here? #291 (comment) |
|
Hi there. I own a XP-Pen Artist 13.3 Pro, but as I'm not exactly a developer I don't really know how to get it working based upon your PR. Here is the uclogic-probe output I get from it: |
|
@alfazaz has been trying to get the 12 working with some complications and might be able to help on that. Either way you'd want a separate issue for it. |
|
@Korvox @thecookie94 I tried many things (see #351) but without success... I don't know where is the little difference between XP-Pen Artist 15.6 Pro and XP-Pen Artist 12 Pro and how to find and correct it. I don't know if XP-Pen Artist 13.3 Pro will be easier than 12 Pro to make it work well like 15.6 Pro. I think a "universal" driver may be possible for all XP-Pen Artist Pro but I'm not competent to make it. :-( |
|
Hi @Korvox ! I've been banging my head against trying to get my Artist 15.6 Pro working for a week or so now. Using your fork and the hwdb entry, I've got the stylus upper button (right click) working finally, but all of the frame buttons no longer do anything. Interestingly, if I run 'evtest', the button presses are still reported (this is the first button): Do you have any advice here? Thanks so much for all of your work on this! In the end I think I could deal with not having the pad buttons as long as the right click works, and I have you to thank for that! |
|
Do you have any advice here?
Personally I've found the vendor driver works great since November
Message ID: ***@***.***>
|
|
I don't actually have the tablet at the moment to check, make sure you follow Peter's instructions on updating hwdb: https://who-t.blogspot.com/2019/02/adding-entries-to-udev-hwdb.html I know some people have missed steps so they never get mapped, if they show up in evdev than the kernel driver is working properly. If that doesn't work, try branch #557 it has additional work in it that I haven't reviewed it a while but might correct some bugs. |
|
Hi! Is the development for the 15.6 pro still alive? |
|
This driver works, Digimend never merged it and nobody has tried getting it merged in the kernel directly. |
|
Oh well that's a shame. Hopefully at some point it can be merged. For now I use the driver compiled from master and it seems to work except for the tablet side buttons and key mapping in the Kde panel. |
Edit: July 2020
Adds support for the XP-Pen Artist 15.6 Pro. Just rebased the patch off master again so its up to date. Adds tilt support. Squashed to one commit.
For anyone coming here just to get the working driver, make sure to read #291 (comment) for the hwdb entry required to make the pad buttons work.