Support for XP-Pen Deco mini7

[Danie10]

Website URL: https://www.xp-pen.com/product/613.html

Probe files:

descriptors.txt frame_buttons.txt hid_report_descriptors.txt pen_buttons.txt pen_coords.txt pen_pressure.txt pen_tilt.txt probe.txt

[kurikaesu]

Would you be able to reupload the probe files? The site that hosts them say they are not available.

[Lokawn]

@Danie10 I am planning on buying this tablet, can you please tell me about current support for this tablet without the digimend driver?

[MikuChan03]

Hello Senpais!

Support for this device is actually very clean, it just needs a few finishing touches! When connected, there are 3 evdev devices created: "UGTABLET 6 inch PenTablet Mouse" "UGTABLET 6 inch PenTablet Keyboard" "UGTABLET 6 inch PenTablet"

While the first one doesn't do anything, the keyboard sends the pad buttons, but not in the nice format of "button1" and "button2" and so on. Instead, we get (from the top down):

KEY_B KEY_E KEY_LEFTALT KEY_SPACE

KEY_LEFTCTRL and KEY_S with KEY_S being repeated KEY_LEFTCTRL and KEY_Z with KEY_Z being repeated KEY_LEFTCTRL and KEY_KPPLUS with KEY_KPPLUS being repeated KEY_LEFTCTRL and KEY_KPMINUS with KEY_KPMINUS being repeated

With "UGTABLET 6 inch PenTablet" we get the normal ABS_X ABS_Y ABS_TILT_X ABS_TILT_Y

Whenever the pen is in range, also BTN_TOOL_PEN is set

As for the buttons, we have ABS_PRESSURE Lower button is BTN_STYLUS Higher button is BTN_TOUCH

When using xf86-input-wacom, the pad buttons and the higher pen button don't work, the rest is hunky dory. When using xf86-input-libinput, the pad buttons work as the keys they are exported as (b, e, lalt, space and such) while the higher pen button doesn't work either. If one were to use evsieve (https://github.com/KarsMulder/evsieve), one could make a fully working tablet out of it today. Following that, I hope that mapping the exported buttons in a more standard way that is understandable to the input libraries is trivial, right? I prefer the texture of this tablet and would really like to see native adoption beside the proprietary driver xp-pen provides. If I were to pledge like a tenner and upload the probe files, would one of you senpais please kindly find the time to realize native support? I suppose it would take me many hours if I tried getting the digimend suite and doing it myself. Nevertheless, these programs are awesome and you are doing god's work! Many thanks in advance!

[nic3-14159]

@MikuChan03 Hello! Would you be able to collect and post diagnostics as described on this page? The ones posted by the original poster are no longer accessible.

Also, could you also try running this script and collect the raw input samples afterwards? Since the buttons are reporting keyboard events, it sounds like this tablet needs an initialization procedure common for newer XP-Pen tablets. The script I wrote performs this procedure and hopefully will cause the tablet to send button events in a format that is easier to support than the keyboard events it sends now.

[MikuChan03]

@nic3-14159 Will do! Here's the files without running your script with the rest to follow: descriptors.txt frame_buttons.txt hid_report_descriptors.txt pen_buttons.txt pen_coords.txt pen_pressure.txt pen_tilt.txt probe.txt

[kurikaesu]

Should you not mind using a userspace driver instead of a kernel driver, I fully support the Deco Mini 7 in my own project with full binding support: https://github.com/kurikaesu/userspace-tablet-driver-daemon

[MikuChan03]

@nic3-14159 Here is the rest and I can already tell that you did it! The frame buttons hid are nice binary numbers as opposed to the stuff from the old files. Only and this is weird, the frame buttons don't always report the same numbers. When I took a look at the reports, the same button would sometimes report different hid bits. The one I upload has it clean, but there were others. Also the evdev devices are gone after using your script, but I guess that was expected.

frame_buttons.txt pen_buttons.txt pen_coords.txt pen_pressure.txt pen_tilt.txt

Edit, also your program said:

Please hold the pen on the tablet surface while running this program.
Press Enter to continue
Trying init packet 0x02B00200000000000000:
Received 02B1020000000000FC110000
Invalid key!

Trying init packet 0x02B00400000000000000:
Received 02B1040000000000FC130000
Key is 0x02B00400000000000000, interface 2, endpoint 0x03

[MikuChan03]

@kurikaesu Thanks for your efforts! Unfortunately, my deco mini 7 doesn't even behave like the one in your repo. In https://github.com/kurikaesu/userspace-tablet-driver-daemon/blob/main/src/deco_mini7.cpp the fourth button from the button for me is KEY_LEFTCTRL and KEY_S, not Key_V Also I'm very hopeful about kernel support, but I'll keep your project in mind.

[nic3-14159]

@MikuChan03 Thanks for posting those! Just so that there is a record of it for reference, could you also post the output of my script when you run it? And I'm curious, are you able to describe the different hid bits that the same button is reporting?

[kurikaesu]

You're probably not fully understanding what my driver is doing. You can re-assign the buttons yourself using the GUI: https://github.com/kurikaesu/userspace-tablet-driver-gui

The defaults I added in the file are just the defaults that I use for all of the tablets and is based on the Artist 24 assignments.

[MikuChan03]

@nic3-14159 I'll try to establish a pattern, one sec.

[MikuChan03]

@nic3-14159 I figured it out! The values reported by usbhid-dump are 3 key presses "behind" what is actually being input. After running your program, the first 3 button presses are being reported as general pen data. Then, when pressing another button 3 times, the first 3 presses are being reported. I'll illustrate it:

1. Running your script.
2. pressing the first pad button 3 times ---> 3 hids of pen data
3. pressing the second pad button 3 times ---> 3 hids of the first button
4. pressing the third pad button 3 times ---> 3 hids of the second button
5. pressing the third pad button 3 times ---> 3 hids of the third button
6. pressing any pad button 3 times ---> 3 hids of the third button

So there is some sort of like cache? that saves 3 button presses due to the first 3 hids being of pen data? What a bother. I'll take that into consideration and clean up the second frame_buttons.txt. Also here is an example of the mixed input: frame_buttons_mixed.txt

As you can see: 02 F0 20 00 00 00 00 00 00 00 00 00 02 F0 40 00 00 00 00 00 00 00 00 00 02 F0 80 00 00 00 00 00 00 00 00 00

are missing and the first few hids are of pen data.

[MikuChan03]

Sorry for the many edits, now it's definitely correct.

[MikuChan03]

@nic3-14159 Now it's getting freaky! I just modified and compiled the digimend kernel driver and and manually sent the key your program provided as an interrupt transfer to my device on ep 3, interface 2. It does work the same as in your program and the hids are nice. Also we are one step further because the evdev devices still exist, they just don't provide anything useful. What's even more interesting is, that there is still this 3 input "delay" I have outlined earlier. Just wanted to let you know.

[MikuChan03]

@kurikaesu @nic3-14159 Hi! Since there has been a bit of a hickup in the development of this feature, I have added support myself (+wacom driver 💕). Maybe you senpais can take a look at it, so that mina-san can enjoy this tablet too \(^.^)/ Also I suppose adding support for the other newer xppen tablets won't be too diffewent?

Bye!

[kurikaesu]

Already attempted to add support for a lot of XP-Pen tablets here: https://github.com/DIGImend/digimend-kernel-drivers/pull/557

This repository hasn't had a merge since Oct 4, 2020. Neither nic or I have write permissions to DIGImend. I've closed my PR already as my userspace driver already handles what I need it to do (and also works properly in Wayland apart from Wayland desktops not having any way to properly map any tablet, including wacom, to the right screen if you have more than one)

[MikuChan03]

Are you saying this repo is dead or what? Can't we get in touch with one of the people with write access? I didn't make this because I was interested in some well defined goal, but because I wanted to contribute to what I viewed as a valuable program and the right place for leveraging the existing stack. This is horrible.

[MikuChan03]

I'm glad your driver works for you and I've already taken note of it, it just didn't sit right me that we would work around the manufacturer exporting the keys as keyboard and hiding the actual functionality in some opaque structure...