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

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.

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.