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.