Why Drawing Tablet Brands Won't Collaborate on Linux FLOSS Drivers

David Revoy

As you probably already know, I regularly get in contact with drawing tablet brands for reviews on my Youtube channel. I usually agree to do detailed video test of their models (see my hardware tag) but only at two condition: test the tablet on GNU/Linux, and only use Free/Libre and Open Source software for the test, including drivers.

I do that especially for the models I find interesting, but I also do that to report all the specifications of the hardware I receive to Peter Hutterer and Benjamin Tissoire at Red Hat. This way, they can transform the specs I can dump from the tablet into a Free/Libre and Open Source high quality driver for GNU/Linux, thanks to their udev-hid-bpf project.

But my last video review was one year ago. In fact, after finding it exhausting to go through all this process (dumping specs, testing the driver, testing and get an opinion of the drawing tablet, making the video review, writing the technical blog post), I decided to set up a new strategy.

The new strategy: direct collaboration with brands

The ultimate shortcut! Get tablet brands to collaborate directly for GNU/Linux in general and share their spec with the hid/input teams. Something like what Wacom has been doing for decades.

For that, I sent many emails, because with brands like XpPen, Gaomon, Huion, I'm not in contact with the technical department, but with the marketing department. Usually, after a few emails, I get a "we'll discuss that internally and get back to you if we're interested" type of answer and nothing. So, I usually kept pushing and insisting.

Making contact with the right people

But more recently, during a discussion with Gaomon, things became more promising: they actually connected me with someone technical. Someone working at "Shenzhen Huion Trend Technology Co.,Ltd.". Huion? Hehe, not really surprising: I had long observed in my reviews that the proprietary drivers of Gaomon, XpPen, Huion and Ugee all had a similar structure in their Debian packages and were using the same tools. Now I know what brand is in charge.

So, I really felt with this technical contact I was finally reaching the right person, and not only that, but someone who could be in charge of managing the drivers for four brands! I quickly sent them all the specifications, links, and method and invited them to contact Peter Hutterer and Benjamin Tissoire.

After that, I was genuinely excited and proud of myself: things were moving in the right direction, and all this volunteer work of emails was about to be fruitful.

The answer: a polite rejection

Unfortunately, this morning I received a conclusion that contradicted my expectations. It's the marketing department at Gaomon who contacted me. Here's the relevant excerpt:

I need to apologize, as I spoke with our technical team again today, and we have decided not to move forward with the Linux driver project at this time.

We carefully reviewed the project you shared with us (https://github.com/linuxwacom/wacom-hid-descriptors). While we appreciate the initiative, we found that this is primarily a Wacom-led project, and the potential impact for GAOMON would be quite limited. Even if we added support for our devices, the system would still show the device as a GAOMON model, but the overall setup would display Wacom branding. More importantly, participating would require sharing our device specifications directly with Wacom – which is not something we can consider.

Alright.

The real problem: Wacom branding in open-source infrastructure

Now you're probably wondering why Wacom is mentioned here.

Well, because it's true: many of the repositories are named after "Wacom". It's a historical legacy on GNU/Linux. It's also a decade-long debate that these repos should be renamed differently.

For example, a repository like Libwacom contains Dell, Gaomon, HP, Huion, XpPen and more (src: https://github.com/linuxwacom/libwacom/tree/master/data), same for wacom-hid-descriptors (src: https://github.com/linuxwacom/wacom-hid-descriptors), and it's the same in many other places deep in the GNU/Linux drawing tablet driver infrastructure.

So, it's not surprising that after a careful study, my technical contact (representing many brands) decided against opening their specifications. Especially if the open-source infrastructure is branded after the industry's largest competitor. I understand their move.

Addendum: I received a comment telling me that I skipped the part of their email where they said they worry they would share their device specifications directly with Wacom. This is true, but I ignored this sentence because obtaining their device specifications is straightforward: you just need a Linux operating system and the hid-recorder utilities to do so. You can see me doing it in a video in the first post of this thread. Therefore, if an artist can do it, so can all their competitors.

What this means for linux tablet support

So I'm sad, what a wasted opportunity and time because of some bad design decision. I'm writing this so that perhaps some executives somewhere will become concerned by this situation and fund full-time developers in charge of these repositories. Because you just can't build a solid collaborative environment within infrastructure branded after the industry's largest competitor.

Moving forward: one tablet at a time

As for me, I'll return to my previous method: reviewing tablets and documenting their specifications, one by one. Unfortunately, I'm not skilled enough to code C drivers like this one and I'm not fully independent on this quest. My process require each time the avaibility of Peter and Benjamin. If the Huion H610x, the XpPen Deco 01V3, the Kamvas Pro 19, the XpPen Artist Pro 16 and 19 (and more) are compatible, it's thanks to their efforts.

I know that this process will stop the day I can't get a Free/Libre and Open-Source driver in time for making the video review, and I'll have to use the proprietary driver of the brand to finish the thing. The day this will happen, I'll probably stop doing hardware reviews...

But for now, three tablets are already in transit: two XpPen models (their high-end 27-inch and their upcoming 12-inch model) and an 11-inch Gaomon. I'll probably also write a detailed tutorial in the near future about how to report tablet specifications to the udev-hid-bpf project, like the one documented here: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/work_items/54.

That's all I can do to move the situation forward. One drawing tablet at a time.

Update: further context from Peter Hutterer

A day after this article published, Peter Hutterer, a senior software engineer at Red Hat and a maintainer of Linux's core input device handling infrastructure since decades, shared a detailed thread in the comments. His work on XInput, libwacom, tablet driver support ( and more ) means he's simply the best source of information for replying to this article and has a firsthand perspective on how these systems actually work.

That's why, with his permission, I decided to copy his thread of replies below, as they totally complete this article to understand how we ended up in this situation:

Replying here since this is repeated in multiple comments: the only two branded projects in the tablet stack are xf86-input-wacom the Xorg driver that Wacom wrote in ~2002 and has been maintaining every since. Thanks to Linux' evdev interface it's been a generic driver for at least 15 years now but it was originally a wacom hardware driver, maintained by Wacom. Anyway, this driver is going dodo with Xorg and Wayland has a neutrally-named libinput that handles all tablets.

The second "branded" component is libwacom, written originally in 2011 after a discussion between a Wacom engineer and me. We needed more information about tablet capabilities (some functionality is still only supported on Wacom devices). I think the first non-wacom devices was added in 2015 (a Huion device).

Funnily enough, if Huion/XP-Pen/Ugee/... would help with libwacom tablet files before the release of the devices, users wouldn't even know it existed.

So in both cases, it's legacy naming because Wacom wrote/helped write the code, it was wacom-specific at first before being made more generic and (co-)maintained it for years. I'm sympathetic towards the branding issue but in both of these cases it's "write the code, get the say".

As for the wacom-hid-descriptors repo: the HID report descriptor is what the device provides so the kernel driver can parse the data. Just like every other HID device. Not exactly a corporate secret.

GNOME was renamed the Wacom panel to Graphics Tablets in GNOME 48 (~1y ago). IIRC KDE renamed it for Plasma 6 (~2y ago).

So on a modern desktop, there is no visible branding anymore, on Wayland the only remaining one is libwacom that users shouldn't even be aware that it exists. All that library needs is a single text file for each tablet with "has 5 buttons, one dial, not integrated into a screen".

haha, and I just remembered another reason for the libwacom naming: apple released the ipad in 2010, after that conversations generally went like this:

I work on tablets

oh, like ipads? cool!

no, like wacom tablets

aha. ok.

Everyone knew what a wacom tablet was, people didn't know what a "graphics tablet" was (unless you told them it was a wacom tablet).

So in 2011 naming it libwacom was a much better choice for my sanity than naming it libtablet.

And the last bit of historical information: we had a lot of branded Xorg drivers because xf86-input- was the naming scheme back then (hence xf86-input-synaptics as the touchpad driver). Most were once-off copies barely maintained and little more than s/vendor/myvendor/g from some other driver. Most xorg-hosted ones were retired in 2011, evdev, synaptics and wacoms are the ones that survive to this day (because all are generic now).

Peter Hutterer (src: https://floss.social/@whot/116796298182876978 )

Thank you again Peter for your reply.