Another attempt to add XP-Pen Deco MW with 3 modes

[tysontan]

Another attempt to add support for XP-Pen Deco MW with its USB/Bluetooth/Dongle modes. The device is mostly functional currently, but it still lacks a side button and possibly other features.

Since my current device is from a later production run, I've collected the sysinfo again, just in case.

The git-update.sh script failed to generate a .tablet file with the following message:

WARNING: Multiple pen devices found.
NOTE: Unable to parse HID data. Skipping creation of libwacom tablet definition.

I modified the existing xp-pen-deco-mw.tablet file from libwacom's data directory.

I have no idea what I'm doing here. I was unable to find information about how to manually create a .tablet file from scratch. Please guide me through what I need to do to make the side buttons on this device to finally work.

I have a few other devices at hand that partially works but with different degrees of missing features, mostly missing a side button. Hopefully with your help I can get those devices working as well.

[tysontan]

I have captured sysinfo for these devices:

XP-Pen Deco MW (USB)

XP-Pen Deco MW (Bluetooth)

XP-Pen Deco MW (Dongle)

Huion Inspiroy Frego S (L310) USB Mode

Huion Inspiroy Frego S (L310) Bluetooth Mode

Wacom One Pen tablet small (CTC4110WL) (USB)

Wacom One Pen tablet small (CTC4110WL) (Bluetooth)

I was unable to use gen-libwacom.sh or git-update.sh to generate any .tablet file.

I used the command like:

./git-update.sh sysinfo.KXEyHk9ujj.tar.gz --url=linuxwacom/wacom-hid-descriptors#571 --oem=GMKtec

It always returns with some error message like:

NOTE: Pen device is not a Wacom sensor. Tablet definition cannot be auto-generated.
NOTE: Unable to parse HID data. Skipping creation of libwacom tablet definition.

But Wacom One Pen tablet small is obviously a wacom device. I'm in a total lost right now.

[tysontan]

Currently:

XP-Pen Deco MW
Already in libwacom/wacom-hid-descriptors, can control cursor, but:

1. Missing one of the two pen buttons.
2. Right click-and-hold, the selection area is different than the cursor position.
3. Bluetooth mode has almost zero vertical range.

Huion Inspiroy Frego S (L310)
Not in libwacom/wacom-hid-descriptors, mostly functional, but:

1. Missing one of the two pen buttons.

Wacom One Pen tablet small
Already in libwacom/wacom-hid-descriptors, mostly functional, but:

1. Missing one of the two pen buttons.
2. Device freezes after OS restart, requires replugging.

[whot]

Unfortunately much of the documentation is outdated or stale and needs updating, but ETIME for everything here.

There's a bit more info on the wiki but that too is likely outdated. There's the data/wacom.example file which describes every key but realistically what you do is the best approach: find a similar device and modify it.

[whot]

looks like these three files all have the same device match? If it's the same device and the only difference is the device match you can have them in one .tablet file and do it like this:

DeviceMatch=usb|28bd|0936;bluetooth|28bd|0936;

The rest looks correct though I think the .svg file is missing?

[tysontan]

In that case, I will just remove the 3 new file I added, then append my information into the existing XP-Pen Deco MW .tablet file:
https://github.com/linuxwacom/libwacom/blob/master/data/xp-pen-deco-mw.tablet

It has a existing svg, too:
Layout=xp-pen-deco-mw.svg

However, I do have questions about the SVG:

1. Do we generate one using some script, or just draw one with inkscape?
2. Is the SVG only for human, or it must follow a machine-readable format?
3. Do we still need to draw the ASCII version like what is in the data/wacom.example file?

Also, using this one for example:
https://github.com/linuxwacom/libwacom/blob/master/data/xp-pen-deco-mw.tablet

How do I find information for each of the parameters?

[whot]

Do we generate one using some script, or just draw one with inkscape?

Historically I think the most common approach was to take an existing similar file and copy/modify it.

Is the SVG only for human, or it must follow a machine-readable format?

It has some requirements for ids and classes (which is why it's best to copy an existing file). There is a CI test that will shout at you when you're missing some features but the summary is that e.g. the svg-thing that describes the dial need to have id="Dial" class="Dial TouchDial", the leader lines to that dial need to have LeaderDialCW and LeaderDialCCW. Buttons need id="ButtonA" class="A Button" and the respective leader lines. It's not complicated once you understand it but its' a bit annoying to edit from scratch.

Do we still need to draw the ASCII version like what is in the data/wacom.example file?

Yes please, 99% the developers look at the tablet file only so being able to quickly verify the intended layout of the tablet is quite useful.

How do I find information for each of the parameters?

width/height -> ruler :) Or check what it says on the box.
Modelname you can probably leave out on XP-Pen devices, that's mostly for wacom where the Intuos Pro can be a PTH-123 and both names are used. That's not really the case for XP Pen devices.

The others are I think documented enough in the wacom.example file.

[whot]

Missing one of the two pen buttons.

If it's an eraser button (like most devices have these days) then that's correct from libwacom's POV, that button behaves like an eraser and would have to be mapped in software (e.g. libinput).

Device freezes after OS restart, requires replugging.

kernel issue, libwacom is just that text file and C API around that text file.

[tysontan]

OpenTabletDriver can handle the eraser mode button correctly, and CTC4110WL doesn't freeze with it. So I just wonder if there is anything on our side that can be done. But if not, that's fine.

[whot]

OpenTabletDriver can handle the eraser mode button correctly, and CTC4110WL doesn't freeze with it. So I just wonder if there is anything on our side that can be done. But if not, that's fine.

The normal stack goes like this:

device -> [HID] -> kernel hid-stack -> kernel input stack -> evdev || libinput -> ...

where || marks the kernel-userspace boundary and HID is the device protocol (ignoring usb/bluetooth).

The OpenTabletDriver goes like this:

device -> [HID] -> kernel hid-stack -> kernel input stack -> evdev || [Device ignored by libinput]
               \-> kernel hidraw || OpenTabletDriver daemon --+
                                                              |
                    +-----------------------------------------+
                    v
                    kernel uinput -> kernel input stack -> evdev || libinput -> ...

IOW you have the normal device ignored by a udev rule the OTD installs and instead the OTD daemon creates a uinput device which is then used as tablet device by libinput. So every event goes into userspace, back into the kernel, then into userspace via an emulated device.

Any configuration via OTD is handled in the daemon, it changes the events that get written into the uinput device. That's why it can do things the rest of userspace doesn't support and/or apply configurations without the rest of userspace knowing.

It's a very different approach. I kinda wish all the OTD device support was ported into the kernel (or udev-hid-bpf) but ETIME on my side for this (and I wouldn't have the devices to test anyway).

Anyway - if the device freezes or generally doesn't work there's a good chance there is a missing kernel hack to workaround whatever issues the device has. These days udev-hid-bpf is the fastest and most convenient way to deal with that, if you open an issue there we can help you try identify what's going on.

[whot]

This LGTM if adding the bluetooth pid is all that's needed. Are you happy merging this or do you need to edit something else?

[tysontan]

Thanks for the explanation. Please merge if you consider them useful, and feel free to close this request if not.

I don't think I have the expertise to contribute to this project, unfortunately. I thought I can help by making some of my unused devices work under Linux before selling them. But since it's impossible to make them fully operational with the current framework, I'll just leave them there.

[whot]

I've used my maintainer superpowers to squash the commits together into one so we can get this merged, thanks!

[tysontan]

Thank you, Peter! :)