XP-Pen buttons missing from settings menu

Hey all.

After the new Plasma update to the drawing tablet settings menu I was curious about trying the built-in drivers. I quickly remembered why I had ditched them.

I’m using an XP-Pen 13.3 pro, it has a click wheel and eight face buttons that you can change using the proprietary drivers offered by XP-Pen. The only issue is that using these drivers under KDE Plasma on Wayland results in a weird bug with the cursor.

Every time I want to use the tablet to draw, I have to move my mouse cursor over to the tablets display, then pick up the pen, THEN it will track properly. If I leave my mouse cursor on my primary monitor, the tablet will track on the primary monitor and not on the tablet screen. I suspect it has something to do with KDE’s driver and the proprietary driver conflicting somehow.

However, the KDE driver won’t let me remap any of the buttons or the click-wheel. They just don’t show up as options. Not under any of the menus I can find at least.

Any help is appreciated, thanks.

hi, could you post a kinfo please?

difficult to troubleshoot without knowing what distro you’re on and version numbers and stuff like that.

Of course, here.

Thanks.

by this, did you mean you couldn’t find the tablet system settings?

just checking,

they should be in here,

are you able to find this setting by using the search function and typing tablet?

I’ve found that page, but I only have the “Display” and “Pen” tabs. No “Pad” tab. I’m able to bind the keys on the pen itself but none of the keys on the tablet itself. The options are simply missing.

Ah, dang. I have a similar problem and was thinking our problems might have been related. You may want to report it as a bug in the bug tracker. Until then, maybe someone else here can help with this issue. Sorry and good luck!

+1 with an xp-pen deco pro sw. The tablet features 8 buttons, but the “pad” tab does not show up in the settings menu.
Has a bug report been opened about this already ? (I couldn’t find it, so I might do it myself)

I don’t think so: Bug List

Afaik it only shows if libinput reports that capability. Did it work before?

It did not (or at least I think not. How would I check that ?)
But each button already had a default key (or shortcut), so I just remapped those shortcuts to that they would do something.
Button n°3 is the left alt key, and button n°1 is the b key, so I made alt+b the same as alt+tab. It is not super convenient tho.

libinput list-devices says :

Device:           UGTABLET Deco Pro SW Keyboard
Kernel:           /dev/input/event16
Group:            7
Seat:             seat0, default
Capabilities:     keyboard
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   n/a
Rotation:         0.0

and this is me pressing buttons 1, 2, 3 and 4 with libinput debug-events /dev/input/event16 :

-event16  DEVICE_ADDED                UGTABLET Deco Pro SW Keyboard     seat0 default group1  cap:k
event16  KEYBOARD_KEY                +4294967.295s     *** (-1) pressed
b event16  KEYBOARD_KEY                +0.070s  *** (-1) released
event16  KEYBOARD_KEY                +4.738s   *** (-1) pressed
e event16  KEYBOARD_KEY                +4.791s  *** (-1) released
event16  KEYBOARD_KEY                +7.190s   *** (-1) pressed
event16  KEYBOARD_KEY                +7.235s   *** (-1) released
event16  KEYBOARD_KEY                +7.973s   *** (-1) pressed
 event16  KEYBOARD_KEY                +8.040s  *** (-1) released

This sounds like the expected behavior of the “Follow Active Screen” mode. It’s a little unclear, but it sounds like it doesn’t pick up on the pen at all until you lift it again? If so, that’s a bug.

Unfortunately, the buttons and click wheel depend on kernel-level support. The click wheel won’t be configurable anyway until I add support for it in KDE Plasma, but that’s happening very soon.

I suggest using the proprietary driver (which works fine on Wayland) or checking out OpenTabletDriver to see if they support your tablet, both are good options. Just make sure to not configure those driver’s tablet devices in the KCM, or vice versa.

1 Like

This sounds like the expected behavior of the “Follow Active Screen” mode. It’s a little unclear, but it sounds like it doesn’t pick up on the pen at all until you lift it again? If so, that’s a bug.

Sorry for being unclear. The pen tracks fine, but the “follow active screen” mode is disabled. Even when using the proprietary drivers it will still use this behavior. I need to use the my mouse to move my cursor to the drawing tablet screen before I can use it, otherwise it will map the tablet’s drawing area to my other monitor. I’ve tried every setting imaginable in KDE’s settings and in the proprietary driver panel but nothing seems to fix it.

My issue was exactly that, having OpenTabletDriver blacklisted the hid_uclogic driver. Once that driver was properly loaded, the pad panel appeared and worked well (see \https://discuss.kde.org/t/xp-pen-pen-button-2-is-interpreted-as-eraser/30218/3)

Cool ! Any idea about support for a touchpad ? I think the only support I got for this was from the proprietary drivers.

That is strange, I’m not sure why that is happening but sounds like something is in conflict. I would open a bug and dump as much information in there as possible (installed software/propietary drivers, and everything else described in this thread)

Touchpad? Do you mean like the touch screen on the tablet screen itself?

No, I mean inside the physical dial wheel (in grey, Mechanic Wheel), there is a touchpad (in black, Virtual Wheel) which can act as a laptop touchpad (move mouse, click (maybe only left click, I don’t remember), and scroll)
dial wheel + touchpad