XP-Pen Deco Pro SM, Artist 12, 13.3, 15.6 and 22R Pro Support #557
Conversation
|
I tested these changes on my XP-Pen 13.3 Pro to see if at least the pen would work and it doesn't. Moving the pen around results in input irq status -75 received so for the 13.3 Pro the report descriptor for the stylus is wrong. |
|
Putting information that I dig up about this tablet here: https://github.com/kurikaesu/DIGImend-research/blob/main/xp-pen-22r-pro.md Also digging up info on my Artist 13.3 Pro here: https://github.com/kurikaesu/DIGImend-research/blob/main/xp-pen-13.3-pro.md |
|
Trying to create a manual report descriptor for the frame keys referring to the usb packet dumps I made but not having much luck. So far there are no IRQ errors in dmesg and the 6th button on the right reports |
|
Using the bit of research I posted above I found what was different on the 13.3 pro. The stylus now works on the 13.3 pro with pressure sensitivity and I would guess tilt support. |
kurikaesu
changed the title
|
With that last commit it appears that the 13.3 pro's frame / express keys are now working correctly. |
|
Just checked out my Art Deco Pro and it looks like it may be almost identical in implementation as the 13.3 pro. It might be more close to the implementation in #291 actually. |
|
The last commit enabled the stylus on the Deco Pro SM. Creating hwdb rule in Then executing a I suspect the the Deco Pro SM express keys will also start working if the appropriate hwdb entry is created. Another problem that I don't know how to deal with right now is that there may be only 10 buttons actually defined: For the Artist 22R Pro which has 20 buttons and 2 dials with 4 "buttons" (left & right turns emit buttons) I don't know if these can actually be properly mapped. The Deco Pro SM also has the touch-pad in the dial that also functions as a second dial which brings the total buttons on it to 12. Maybe these dials can be somehow mapped to the StripLeftUp/Down and StripRightUp/Down? |
|
After messing around with things more on my Artist 22R Pro, I've been able to do the following: Assigned named buttons to the right side express keys and both dials: Then using Key Mapper: https://github.com/sezanzeb/key-mapper Still a work-around but its better than nothing. If there was a way to map the express keys to the wacom driver button 4, 5, 6, etc. which don't seem to correspond to anything then I would definitely like to know. |
|
@kurikaesu Wacom buttons 4-7 are reserved and cannot be mapped to the express keys. From the digimend readme: |
|
Oh I see! Thanks for the clarification 😃 The 22R Pro's dials don't send a "key-up/stop rotate" state unlike the 13.3 pro so |
|
Added this to my This enables the Deco Pro SM: The Deco Pro SM dials have the same behavior as the Artist 22R Pro so its probably not a good idea to bind a shortcut to them right now. |
|
If you ever want to get these patches properly merged into mainline along with mine, hit me up some time, I think we have to bypass Digimend. And tilt support works? I assume the chip is accounting for the tilt in the reported coordinates? Lucky, I guess they learned from the 15.6 that tilt reporting angle but not just hardware-side including that in the position reporting just sucked. We also might be able to get the Artist 12 Pro included if @alfazaz's work in #351 is applicable. |
|
@Korvox I also have some code on my machine for the Star 06 (There is currently pen support but no frame button support, that tablet also needs a "key packet" sent to it) based on your patches, but I was sort of waiting until your patch got merged into DIGImend before posting. The init packet uses a different value than your parch and this patch, (0x02b002 and then 0s instead of 0x02b004), so I wonder if we should make that init function more general to handle more tablets. Otherwise, we'll probably have a lot of long functions with similar code. I think I saw another uclogic (non XP-Pen) tablet that I suspect also needs an init packet (it reported keyboard events on the frame butttons) but I think it had a different number of interfaces and thus such an init packet would need to be sent to a different endpoint |
|
@Korvox I haven't tested tilt yet since I don't have a tool test it with nor do I know how to set up tilt in Krita. Definitely keen on getting these changes all through to mainline once I can deal with the frame dials. @nic3-14159 if you fork this repository and push your changes to a branch, link it here and I can also take a look at it and see how we can merge it all together. |
|
@Korvox @kurikaesu I'm assuming mainline is referring to the kernel tree? If so, I feel like we should communicate our intentions to @spbnick before trying to bypass DIGImend. Just to avoid any confusion if he is pushing changes in the future. |
|
Last commit changes the Deco Pro's dial to emulate a Wheel (0x38) which overcomes the not resetting state back to 0 issue. Unfortunately we can only have 1 wheel in the report ID so the inner touch dial is now a Dial (0x37). Both of the dials emit -1 (or -2 for some reason) and 1 indicating positive and negative however I don't think Dial can be bound by Key Mapper for example since it has no idea what a Dial is. Not too sure if dials can also be udev/hwdb rebound to something else either. |
|
@nic3-14159 Agreed, for now I'm just happy enough to have my hardware work in Linux. |
|
Looked through #351. The 12 Pro and the 13.3 Pro are identical. Committed the hardware ID to my fork & branch to enable it. |
|
@kurikaesu Your commit for the 12 Pro works for me... I think it solves #351. Thanks ! |
Krita natively uses tilt, you can verify its present at least with libinput via Besides the packet function taking different magic values, is there anything else to be made generic? I rebased and amended my branch with what should be something to just base all other devices off of. Of course timing is funny, I won't have my a156p back to make sure there are no regressions for a week. |
|
@kurikaesu @Korvox I saw that tilt also works on my 12 Pro with your work. :-) |
|
@Korvox I think the interface that should be used to send the init packet and receive reports might need to be general. As I've said before, I think there are other tablets that I suspect need an init packet which seem to have a different number of interfaces (not 100% sure though). I'll see if I can dig up relevant issues. I don't believe they were XP-Pen though, so it is possible that they require many other changes. But so far, all XP-Pen tablets I've seen use interface 2. I'll also have to check my Star 06 code does anything majorly different in the params init function. (I currently don't have access to my main system, so I'll post my code and check some other things later) |
|
@Korvox Found it, the Star G960 (#446) reports keyboard events for the frame and has an OUT endpoint on interface 1 (only 2 interfaces). The HID descriptor on interface 1 also appears to be very similar to the interface 2 descriptors on tablets known to need the init packet. All of these are characteristic of tablets needing the init packet, so it does appear that the code needs to support different interfaces in order to support that tablet. |
|
Last commit makes at least the left dial on the 22R Pro usable. @nic3-14159 I should be able to handle the G960, just need to update the python script to inject the key on interface 1 and dump the packets that way. I'll make a comment in #446 with the updated script. As far as different activation keys are concerned, I originally thought my 22R would have a different key so I wrote the function calls with passing of a custom key in mind. I can certainly re-do this, just need to know the second activation key to handle. |
|
Just tested Key-Mapper which I mentioned above: https://github.com/sezanzeb/key-mapper This means for both the Artist 22R Pro and Deco Pro SM all controls are now mappable in Linux! |
kurikaesu
changed the title
|
@Korvox @nic3-14159 I'm about ready to squash all of my commits. Secondly, is Digimend actually dormant again? I saw a post back in 2016 or 17 saying Digimend was being abandoned but then another post in 2018 that said it is being brought back alive. However there hasn't been any merges from PRs in a while now. @spbnick ? |
|
@kurikaesu I'm personally don't have a problem with you squashing your commits, as they don't really interfere with anything I have. You did pull in support for the 15.6, so you may want to coordinate with Korvox. There was also another commit in #291 to add the interface endpoint address as an argument to the new params init function, so you may want to pull that in as well. |
Each persons work can just be a separate commit. My work is the oldest so just base your commits off mine. |
|
Squashed my commits. |
|
It be squashed |
|
Rebased on top of your commits onto a new branch here: https://github.com/kurikaesu/digimend-kernel-drivers/tree/xppen-artist22r-pro-rebased Once your PR is merged then I'll do another rebase and pull it into this PR. |
|
After testing my changes the past few days there is something different with the Art Deco Pro. While the report descriptors appear to be correct and all functions work, the tablet itself does not immediately start working when plugged in. I have to use the dumper tool to sort of activate the tablet after which it will work fine until I disconnect and plug it in again. I'm guessing there is a piece of the handshake puzzle missing in the digimend driver that the dumper does |
|
Deco pro M has different product id: EDIT: i've tested driver with substituted id, and everything works. |
I have same problem, and just doing |
|
Thanks for reporting the ID. I've added it into my PR as one of the supported devices. When using libinput it is normal for it to be unbound since the pads buttons are just "button_0", "button_1" etc. The "button_0", "button_1"... unbound libinput gives you full flexibility at the cost of having no default bindings as I haven't provided any. Dumper tool I am talking about is usbhid-dump: https://github.com/DIGImend/usbhid-dump Ideally the driver should not have to be unloaded in order for the tablet to work when plugged in (this is what modprobe -r does) |
|
Latest commit fixes the deco pro small (and probably medium) on-connect issues. The tablet for whatever reason sends through a blank message on Report ID 1 and report ID 6 before switching over to using the unified interface. This causes the driver to block receiving new messages until the interface is reset by either using a tool to forcefully detach and claim the device and release it or other methods. Implementing the report descriptors for interface 0 which receives the report id 1 and 6 fixes the connection issues. This means that the tablet should start working on plug in without having to do any fiddling around (other than of course making sure to bind all of the buttons and wheel). There is also something that has changed recently and I don't know why but the touch-dial on the Deco Pro is now reporting as a mouse input on interface 0 (even if we use the key to get all the stylus movements, buttons and dial reporting on interface 2). Very odd! I tested this behavior before my most recent commit so the changes I added didn't introduce this weird behavior. |
|
For those who come here and have an Artist 22R Pro, consider testing out my userland drivers here: https://github.com/kurikaesu/xp-pen-userland It comes with a configuration gui here: https://github.com/kurikaesu/xp-pen-userland-config-util I'll add support for all of the devices listed in this PR in my userland drivers as time goes on. |
|
Thanks in advance for your work for the artist 12 pro which I will be able to test when it will be released. |
|
I have just added support for the Artist 12 Pro and the 24 Pro but I can't test them since I don't own either product. |
|
So what i have found out: When you hover with pen then both wheels don't work, it is like if touch arbitration is in place, really annoying. Wheels don't work while using wacom driver, but when you press pads many times very fast - physical dial starts working, while touch dial doesn't. Not sure what is going. By default udev assigns (supposed to match only *Pad) then pads start emitting events, and wheels stop working. |
|
The Deco Pro is pretty special in how it functions behind the scenes. It appears there is an on-device bit that can be set by the official driver. I haven't captured the bit yet, just tested the effects of switching it around. The process I went through was: Just for reference, interface 1 is 0x00. When <X> is set to "mouse", outputs come out of interface 2 (0x01) and produce X, Y coordinates: When <X> is set to "roller", then it still outputs from interface 2 (0x01) but emulates the scroll wheel: When <X> is set to "customized" then it will output from interface 3 (0x02) and share the same bitmap field as the dial: If you haven't used the tablet with the official drivers yet and changed the default behavior then the tablet will probably be in mouse mode. Since mouse mode and roller mode share the same interface, we would have to have bytes 3 to 7 all mapped in the resource descriptor. If you are using the code before beb79ff then whenever you use the touch pad it will likely be sending a message through interface 2 which the driver up until the above commit doesn't read. Since it doesn't parse it the whole device "hangs" while it waits for something to parse the message. The above commit will interpret the message as mouse movements but that isn't mapped to anything and its unlikely the wacom driver will know what to do with it either. I'm not providing a fix for this in this DIGImend PR, just writing out research notes and explanations. |
|
Just finished adding support for the Deco Pro SM and MD (MD is unconfirmed, someone please test). Configuration GUI also supports setting up the bindings but again, if the touch-pad is not set to customized then the touch pad binding will not be in effect. |
I figured it out, it is a problem with libinput, it doesn't handle EV_REL events for tablet pad, you can see it when you run |
Adds support for the XP-PEN Artist 22R Pro in uclogic, including the stylus, frame and pen pressure support. I did not do the research for this hardware, or the original patch - that work has been done by Aren Villanueva. For some reason they decided not to merge it. My changes include remapping the stupid amount of tablet frame buttons, cleaning up the code to match kernel style, and other small stuff. The tablet is (almost) fully functional even when uclogic doesn't handle it. Without initialization, the tablet has some sort of "basic driverless mode" that allows the tablet frame buttons to have some default keys associated with them (CTRL-S, CTRL-Z, that kind of stuff), but unfortunately the stylus pen semi-works. While pressure sensitivity works, only one stylus button functions correctly. Since the initialization process differs for Pro series tablets, the new function uclogic_params_init_ugee_xppen_pro had to be introduced. I also added USB HID IDs for this tablet too, but it's classified under the UGEE vendor ID. One of the more strange things I had to do is figure out a way to remap the buttons since there are 20 of them in total, and of course there are more buttons than there are BTN constants defined for us. When running without uclogic, it starts at BTN_0, ends at BTN_8 and the tablet starts reporting nonsensical keycodes so just leaving it alone isn't an option. I'm testing this under a libinput system, which has a list of buttons it considers "tablet pad buttons" which are notably BTN_0, BTN_1, so on and some gamepad/joystick buttons. So I created a new array called uclogic_extra_input_mapping for 20 working inputs. Another weird feature of this tablet is the second dial, which the original patchset introduced a new uclogic_frame param to handle since it seems it throws both dials values into one byte. The left wheel is considered EV_WHEEL and the other, EV_HWHEEL which seems fine to me. I also added the new param to the debug messages too. Link: DIGImend/digimend-kernel-drivers#557 Signed-off-by: Joshua Goins <[email protected]>
Adds some support for the XP-Pen Artist 22R Pro.
I used a bunch of code from PR #291 to get the digitizer/stylus working however the frame buttons are not configured correctly.
Some of the buttons will respond to touches but they do not have unique codes being emitted.
Left button 8 and right button 6 for example emit the key 123 which on my system increases sound volume.
There is still a bunch of test rdescs that I wrote for interfaces 0 and 1 but those interfaces will result in the buttons emitting their default hard coded keyboard keycodes. They will be removed in future.