WRITTEN_BY David REVOY -
-
159 comments
Not because he chose a cat for his thought experiment, but because of one thing I learnt: he sexually abused children and kept a diary about it. 🤮 Src: https://en.wikipedia.org/wiki/Erwin_Schr%C3%B6dinger#Sexual_abuse
[Artwork source here](https://www.peppercarrot.com/en/viewer/misc__2023-11-26_Kicking-Erwin-Schrödinger-out-of-my-idols_by-David-Revoy.html)
WRITTEN_BY David REVOY -
-
38 comments
[youtube]gmmIwkvZagU[/youtube]
- Youtube: https://youtu.be/gmmIwkvZagU
- Peertube: https://peertube.touhoppai.moe/w/ugr5t9Wj34KmLMdazAx1CC
Here is my video review about the XPPen Artist Pro 16 (Gen 2) pen display tablet. Everything about how I feel of the hardware is on the video above.
This blog post here will list my method to install, scripts, and tweaks to install the device under a GNU/Linux operating system.
### Update
- **2023-02-06:** I found a way to setup the display/digitizer for a 16/9 ratio clone (xrandr / x11).
- **2023-12-13:** Added more info about color profile, ddcutils, thanks to the feedback of Bhoren.
- **2023-12-12:** Added a note about xsetwacom MapToOutput display name for proprietary Nvidia drivers.
- **2023-12-06:** Success with the single USB-C to USB-C cable test on GNU/Linux.
- **2023-12-04:** The white type of stylus nibs gets a small flat. I also found a secret OSD menu.
- **2023-11-30:** New settings about the Luminosity/Brightness, from 75 to 78 to get a 180cd/m².
- **2023-11-20:** Thanks [Ryuno-Ki](https://layer8.space/@RyunoKi) for pointing to me three errors and possible enhancements.
### Transcript of the video
Click here to unfold the text version of what I'm saying in the video.
## Intro
Hey, so XP-Pen sent me their latest tablet to review.
If you are not familiar with my channel, I only accept this type of review if the tablet could run on a GNU/Linux operating system with only free/libre and open source drivers.
At this stage, all the other brands usually refuse to send me a device or don't even reply.
But not XpPen.
In short, they told me that even if they didn't have a Libre driver, even if it didn't work, all I had to do was make a video of everything that went wrong.
For my part, I really liked this suggestion, and I was also seduced by the specifications of the tablet on their website.
So I took up the challenge.
The good news is: the tablet is now working on my system.
It requires some very GNU/Linux specific tweaks, but I've decided not to go into them in detail in this video.
You'll find them all in a link to a blog post in the description below the video.
This blog post will be easier for me to update.
This video will focus on showing what I think of this device.
## Unpack
So what do we have here?
It's a 16-inch tablet, not thick at all, with a Quad-HD screen inside.
Quad-HD is my favourite resolution, and this one comes in the 16:10 ratio flavour.
It's a metal chassis with very well-designed rubber feet that are easy to unfold.
You'll also find plenty of power adapters for all regions in the box.
A manual, a glove, something for cleaning, tablet cables, but also remote cables.
Speaking of the remote, here it is.
And the stylus in its case, along with extra nibs, and it contains a USB dongle to connect the remote.
This can also be connected without it, via Bluetooth, or wired directly.
I received it with this extra '3-in-1 cable' box and that's what I'll be using in this review.
It has a red USB for the power connector, a black USB for the tablet's data to your computer, an HDMI for the display and they all converge on a single USB-C for the tablet.
## Device presentation
The active surface of the device is large, larger than an A4 document or those video games, if you are more familiar with that scale.
It's also bigger than my Wacom Cintiq 13HD and about the same size as an Intuos Pro Large.
The active surface is laminated, very smooth, but not as smooth as glass, it has a slight texture, it's very fluid.
On the back, you have two USB-C inputs;
- one for the 3-in-1 cable
- and the other in case you choose a direct USB-C to USB-C.
You also have a plus and minus button for brightness and a power button.
## Colors
I really like the design once it sits on a desk, the colour are great.
But I would strongly advise any user to do a colour calibration on this device as it natively displays almost full AdobeRGB.
I limited mine to 100% sRGB and it's great.
As a result, this tablet has become my reference for checking my colours in general.
## Drawing
In terms of drawing, the device is really responsive and the lag is minimal.
It's the first time I've tested a device that feels like that and that's after 20 years of practice.
I immediately fell in love with it.
The parralax is also very low and even if it needs a bit of calibration, you won't feel much offset when drawing.
## Pressure
The pressure sensor is also very sensitive to fine brush strokes.
My first impression was that the amplitude of the pressure curve from a very light stroke to a very heavy stroke was too large.
Maybe it's my hand getting old, or maybe I'm just getting more sensitive with the years, but I had to set up a custom pressure curve: with a firm curve that quickly reaches 100% of the effect.
Then all my brushes acted the way I wanted.
## Overlay Texture
I have to admit that I initially thought the overlay texture was too slippery.
I would even describe its overlay as an 'oily' type of surface.
However, once I started using the light grey nibs rather than the standard black ones, this problem was solved for me.
These nibs have a bit more friction than the standard nibs, so I get that gentle 'shh shh shh' on the device.
After two weeks of intensive use, these nibs still haven't flattened out.
I'm curious to see how long they'll last, but for now I'm very happy with them.
## Tilt
The tilt of the tablet is also very responsive and precise for the angle.
It offers a level of brush angle control I have never seen before.
I really like what the XPPen engineers have done with the stylus in general, the precise and lag-free experience really improves the digital painting experience.
## Eraser
When you flip the stylus, you have an eraser.
Krita - the painting app I use - will change the preset, so you can put an eraser preset on it and you'll have an eraser ready to go every time you flip the pen.
This eraser brings the design of this pen closer to Wacom's, and I'm not complaining about that.
There are some slight design variations, but they're very minor.
## Remote for shortcuts
The remote for the shortcus is a completely standalone device, and you can even buy it separately.
Under GNU/Linux, everything works out of the box, except the little middle button on the dial.
All the buttons feel ok and you can customise them with a bit of efforts.
On the edges, you have a button for power on/off or Bluetooth pairing, and somewhere else, ha there, you have a USB-C connector for wired use or charging.
To be honest, it's a cool gadget.
But I prefer full access to my keyboard, or this little gamepad or keypad I customised.
## Ergonomic
As for the ergnomic, I like to use it flat with the keyboard in front.
I don't really like the built-in feet, because then you can only use the keyboard between you and the tablet, and it works, but it's just not my style and preference.
After experimenting with stacks of books, I made this little wooden easel. It is still a work in progress, but it gives me some comfort for now.
I also like the fact that I can push it onto my desk and immediately free up some space for traditional drawing or small DIY projects.
It's very good for the sketchbook training I'm doing now with ballpen point.
It's also easy to unplug it, put it on a shelf and plug it when you need it.
In my setup, I use it most of the time as both a display tablet and a regular tablet.
I've cloned my main monitor with the tablet so I can get the best of both worlds,
and I really like that because I've always struggled between a display tablet and a regular tablet.
Now I don't have to choose, it's really convenient.
## Heat
About the heat of the device, the hot spot is clearly on the top, around the USB-C connector.
It's a good design, as the palm of your hand is rarely going to be there.
A word of warning: don't set the screen to 100% brightness, as I found it too hot and difficult for my hand.
I found the 75% brightness setting to be a good compromise.
It gave me the right temperature for working.
## Conclusion
As you can guess, I have already adopted this device full time on my desk, and have been quite productive with it.
For me, it's really like having a slightly thicker Wacom Intuos Pro, but with a killer monitor built in.
My favourite combination.
How could I not love it?
For more information, you'll find a link to my technical blog post in the description about how to install this device on GNU/Linux.
You'll also find plenty of links to where you can buy the tablet, depending on your geographical location.
Just a note about that: I don't make any money from these links.
But there's a special offer until the end of November, so check it out because it's a real bargain!
Also, XpPen gave me a promo code DAVID15, which is good until Christmas.
It'll give you an extra discount.
See you later, and thanks for watching.
### Promotion by XPPen:
Black Friday period right now with a 15%
Get also an extra 15 EUR/GBP/USD/AUD/CAD discount for Artist Pro 16 (Gen 2)
Code exclusive : **DAVID15** (valid from November 24 to December 25 2023).
- USA: https://bit.ly/3R1XWZh
- UK: https://bit.ly/46U1VMR
- FR: https://bit.ly/3MFt0LJ
- DE: https://bit.ly/3ugmwMS
- ES: https://bit.ly/47ae4NK
- IT: https://bit.ly/3FYxrxh
- PT: https://bit.ly/3QCwfVu
- IE: https://bit.ly/3R93C3L
- CA: https://bit.ly/3SGgFus
- AU: https://bit.ly/3MMn3g5
(Note: I don't earn any money on this, just FYI)
## Install & Setup
### Get the USB ID identifier of the tablet
For that, plug the tablet and execute in a terminal:
```
lsusb
```
This command will list all usb connected and their ID, the name shorten list into 'ls' and 'usb'. In front of the line with the XP-Pen tablet (it can be listed as "XP-Pen [unknown]"), mine is **28bd:095b**.
### The X11 rule
Change Directory (cd) to the place where your Xorg store rules for the devices. Oh yes, I forgot to say, this guides is right now for X11; not Wayland because [it is not ready for digital painting](https://bugs.kde.org/buglist.cgi?bug_status=__open__&component=kcm_tablet&list_id=2519203&product=systemsettings) yet.
```
cd /usr/share/X11/xorg.conf.d/
```
I'll make a new rule in this directory (note it require your system root password because we are editing a system file with 'sudo') I'm using the text-editor "micro", but you can use your favorite. "nano" is often installed anywhere, but has less user-friendly keyboard shortcut and color syntax by default.
```
sudo micro 60-xppen.conf
```
We can copy/paste the paragraph under at the end of the file; if your USB identifier differs, you'll need to adjust the line starting with MatchUSBID:
```
Section "InputClass"
Identifier "XP-Pen Artist Pro 16 (Gen2) Tablet"
MatchIsTablet "on"
Driver "wacom"
MatchUSBID "28bd:095b"
MatchDevicePath "/dev/input/event*"
EndSection
```
Save and then reboot your system.
### Tablet setup with xsetwacom
At this point, you should see lines about your XPPen tablet stylus when writing in a terminal:
```
xsetwacom --list
```
Now we will create a script. It is just a series of command written line by line on a text file; so the computer will execute all of them. Each line will setup one aspect of your tablet. Line starting by character # are not read by the computer, so I added some notes to guide you in the customisation of the script. Open a non-rich text editor (eg. Micro, Kate, Geany, Gnome text also called Gedit, etc...) and copy/paste the script under:
A note for user of the proprietary Nvidia driver: the name of the display will probably differ from what you see from xrandr for the MaptoOutput [Check this](https://stackoverflow.com/questions/69255896/xsetwacom-unable-to-find-output).
```
#!/usr/bin/env bash
# Setup UGTABLET Artist Pro 16 (Gen2)
# License: CC-0/Public-Domain license
# author: deevad
# --------------------------------------
# XP-Pen Artist Pro 16 (Gen2)
# --------------------------------------
# Tablet definition
# Identifier obtained using the 'xsetwacom --list' command line
# The tablet appears after installation of the Digimend kernel driver (10 or more)
# And after creating a special rule for Xorg.
# See blog post on https://www.davidrevoy.com/index.php?tag/hardware for it.
tabletstylus="UGTABLET Artist Pro 16 (Gen2) stylus"
tableteraser="UGTABLET Artist Pro 16 (Gen2) eraser"
# Constrain stylus to use it's own monitor
# Monitor name here (output) is "HDMI-A-0". It was obtained
# using the 'xrandr' command-line. Your might
# be different.
output="HDMI-A-0"
xsetwacom --set "$tabletstylus" MapToOutput $output
xsetwacom --set "$tableteraser" MapToOutput $output
# Calibration
# Start by reseting calibration to default area
xsetwacom --set "$tabletstylus" ResetArea
# Default area is '0 0 32767 32767'
# You can obtain it with:
# xsetwacom --get "$tabletstylus" Area
# Calibrate your device manually with `xinput_calibrator` after connecting only the Xpen-Pen pro-art
# (Area is "MinX" "MinY" "MaxX" "MaxY"), then tweak manually adding or rmoving +50 here and there to obtain
# Something pleasing I found:
xsetwacom set "$tabletstylus" Area 125 45 32810 32792
xsetwacom set "$tableteraser" Area 125 45 32810 32792
# Pressure Curve:
# a web GUI is available here to tweak it https://linuxwacom.github.io/bezier.html
xsetwacom --set "$tabletstylus" PressureCurve 90 85 15 100
# Configuration data trimming and suppression
# The event of this device are not legion; better to not filter any for sensitivity
# Minimal trimming is also good.
xsetwacom --set "$tabletstylus" Suppress 0 # data pt.s filtered, default is 2, 0-100 (old 4)
xsetwacom --set "$tabletstylus" RawSample 1 # data pt.s trimmed, default is 4, 1-20 (old 1)
```
**Run it, create a start-up:**
Save it named xppen_Artist-Pro-16-Gen2.sh (you can name it the way you want, and save it where you want on your disk, using the extension .sh at the end of the file is not mandatory but will ease identifying the file as a Bash script later and also some editor might rely on that to set a correct syntax highlighting ).
To run it, after saving the file you need to give this text file execution permission. You can do so with many desktop environment by right clicking on the file, and add the "execute" permission. Another way to do it is with command line:
```
chmod +x xppen_Artist-Pro-16-Gen2.sh
```
Now, if you run:
```
./xppen_Artist-Pro-16-Gen2.sh
```
The script should run and apply your preference. If your windows environment is modern enough; you should have a setup option to add a script to the autostart (usually in Settings > Autostart). This way, the preferences will be applied each time you start your computer. You can of course change options, and execute the script as many time you want to test and adjust.
### Issue: the upper button on the stylus is another Eraser!
Yes, this was [a known issue](https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help), to fix it, you'll have to compile https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/ that contains a rule to make it work again as a right-click. You read [this blog post](https://www.davidrevoy.com/article1002/how-a-kernel-developer-made-my-styluses-work-again) to get more info about why it is like that.
### The Remote shortcuts
You can customise it with two methods.
The first one is by using [the software input-remapper](https://github.com/sezanzeb/input-remapper). You'll have all the possibilities with it (presets/macro/composed shortcuts/even sending mouse events). It's also compatible X11 and Wayland.
The second one is using a udev rule but it will be limited because each keys sending two key events will be a pain. Here is the layout under with the keycodes, and see [this blog post for the method](https://www.davidrevoy.com/article989/how-to-customise-a-usb-numeric-keypad-under-gnulinux). It's exactly the same.
[](data/images/blog/2023/2023-10-29_artist-pro-16-gen2_wireless-remote-keyboard.jpg)
### Fix the 16:10 ratio into a 16:9
[](data/images/blog/2023/2023-11-20_xppen-16artist-pro_built-in-resolution.jpg)
_The available resolutions listed by xrandr_
As you can see on the available resolution of the device, you have a list here of 16:10 ratio. It's problematic, because if you want to use this device cloned to an external monitor you'll probably have difficulties as most monitor for desktop computer in 2024 uses a 16:9 ratio.
Don't be fooled by the 16:9 ratio listed on the screenshot above ( eg. 1920x1080px); the resolution are stretched, and the display will look like stretched vertically to fill the 16:10 area ( probably a list of resolution to support classic gaming resolutions).
On my setup, I have a Philips 245E 24inch as my main display, and if I want to clone this tablet to this 16:9 quadHD 2560x1440 monitor, I have to setup the tablet in a very specific way using xrandr/X11 command lines. This setup will sacrifice a bit of the maximum height of the Artist Pro 16 Gen2 (2560x1600) to get a final work area of 2560x1440px centered vertically (with black on top and bottom, a letter box like cinema effect). But at least, you'll get a perfect clone, and also a better ratio to screen record videos and livestream.
For setting this, you'll have to make a startup script with xrandr command lines. On the example under, I have `HDMI-A-0` identifier for the plug of the Artist Pro 16 Gen2 and `DisplayPort-0` for my 24 inch Philips monitor. You can retrieve the name of your monitors with `xrandr` in a terminal.
Here is my script:
```
#! /bin/bash
# Setup xp-pen 16 pro fix screen ratio
# We setup a new mode for the 16 Pro:
xrandr --newmode "2560x1440_60.00" 312.25 2560 2752 3024 3488 1440 1443 1448 1493 -hsync +vsync
xrandr --addmode "HDMI-A-0" 2560x1440_60.00
# We apply the mode:
xrandr --output HDMI-A-0 --mode 2560x1440_60.00 --set "scaling mode" "Full aspect" --same-as DisplayPort-0
```
Once the ratio deformed, the calibration of the stylus will not match the new 16:9 restricted and centered display area. You can fix this with xsetwacom Area in your xsetwacom startup script:
```
tabletstylus="UGTABLET Artist Pro 16 (Gen2) stylus"
tableteraser="UGTABLET Artist Pro 16 (Gen2) eraser"
xsetwacom set "$tabletstylus" Area 125 1745 32810 31050
xsetwacom set "$tableteraser" Area 125 1745 32810 31050
```
### Monitor Luminosity/Brightness
In the video, I tell my sweet spot for the "Brightness" was 75 to not get the device too hot. With a Color Calibrator, I was able to measure the [candela per square metre](https://en.wikipedia.org/wiki/Candela_per_square_metre) of this setting: 170cd/m². By the end November, I pushed my device to 78, to reach 180cd/m². This change makes the device slightly warmer, but in exchange I have a luminosity similar to my two Philips 245E monitors.
### The hidden "SelfTest" built-in menu
Switch off the tablet using the power button, then hold down 'Brightness +' and press 'Power' once to enter into this mode. The Logo XPPen will be replaced by a white on black background "SelfTest" menu. I discovered this out of curiosity, as I thought the layout of the buttons was the same as on a mobile phone.
Once in this mode, pressing the power button once brings up an OSD menu on the top left, which you can navigate using the + and - buttons. The menu includes colour temperature. They all act like presets, the temperature are just labels. You can change the colour channel on each of them. You also have a factory reset. A nice touch.
[](data/images/blog/2023/2023-12-13_xppen-self-test.jpg)
_The SelfTest Menu._
### Monitor options via ddcutils.
All the options of the SelfTest secret menu, can be also controlled by software. On GNU/Linux you can access them with [this method](https://www.davidrevoy.com/article710/cintiqs-on-gnu-linux-how-to-setup-brightness-contrast-and-more). Here is the available options:
[](data/images/blog/2023/2023-11-20_xppen-16artist-pro_ddcutil-options.jpg)
The identifier is `UGD` so you can see what color preset (feature 14) is set with this command:
```
$ sudo ddcutil --mfg=UGD getvcp 14
VCP code 0x14 (Select color preset ): User 1 (0x0b), Tolerance: Unspecified (0x00)
```
#### sRGB:
This way, you can change all options. You can switch to (eg.) force to sRGB with:
```
$ sudo ddcutil --mfg=UGD setvcp 14 01
```
This sRGB is not a really good sRGB color preset. It's blueish, way to blueish. See the next chapter about the color profile I provide with it.
#### AdobeRGB:
If you want to get the AdobeRGB color mode, on this menu it looks like it is the `0b User 1` (not 100% sure). If you want to select it with ddcutil, use the syntax with an extra 0x in front or it will fail:
```
$ sudo ddcutil --mfg=UGD setvcp 14 0x0b
```
### My color setup and ICC profile
Each screen are differents and will get older differently depending of the temperature, how you use them, how they receive light of the sun, etc... That's why sharing the profile I made when mine was new will probably be inaccurate for your display. But it can help.
[Download my ICC profile here](data/images/blog/2023/2023-11-30_xppen-a16pro-180cdm-d6500-22_displaycal-brightness78.zip).
This ICC was made for the 78 Brightness value, in sRGB mode (with ddcutils see chapter above).
Gnome and KDE on X11 both have a GUI in the settings to load the ICC to your display.
If you are using another D.E. you can apply it with the `dispwin` command line tool part of the [argyllcms](http://www.argyllcms.com/) package available on most of the distro. To apply an ICC with dispwin, you'll need first to run a `dispwin --help` and dispwin will tell you the number ID of your monitor. If your XpPen monitor is number 1, it will looks like that:
```
dispwin -d 1 /home//path/to/your/directory/2023-11-30_XPPEN-A16Pro-180cdm²-D6500-2.2_DisplayCal-brightness78.icc
```
### Nibs
Here is an update on the nibs in December after a pretty intensive usage of the tablet over the last weeks, I'm starting to get a flat nib but this only raise a bit the friction and stability of the stylus and I really like the feeling. I hope this more tender type of alternative nibs will have a good duration once they reach this. I'll keep you informed.
[](data/images/blog/2023/2023-12-04_flat-nib.jpg)
_A close up on the 'white' nibs with a flat._
### The single USB-C to USB-C cable
In my review, I'm testing the device with the 3-in-1 cable, a HDMI+USB(data)+USB(power) to a single USB-C. I couldn't test the USB-C to USB-C because I didn't have one on my workstation. But on my [Yoga Thinkpad](https://www.davidrevoy.com/article976/lenovo-yoga-370-on-gnu-linux-technical-companion-article) I saw a high-speed USB-C port, so I decided to test it: and it is a success. My Fedora 38 GNU/Linux KDE automatically made everything work for the display and the tablet via this single cable. That's good if I want to take the tablet on a trip. I'm actually considering it for the holidays at the end of the year. (Note: the laptop was connected to an electrical outlet; I assume that a device of this size can drain the built-in battery very quickly).
That's all 🙂
WRITTEN_BY David REVOY -
-
26 comments
I'll be at [Capitole du Libre](https://capitoledulibre.org/) (Toulouse / France) all weekend as a regular visitor. I am not giving a talk or workshop this year: it was a personal decision to make room for others. But if you see me at someone else's conference, I'll be happy to sign your Pepper&Carrot books while we listen 😉.
I'm curious, who will be there?
link: https://capitoledulibre.org/
WRITTEN_BY David REVOY -
-
72 comments
## 🎉 🎉 🎉 Whooohooo! It works again!
Both styluses of my XPPen Artist 24 Pro and XPPen Artist 16 Pro Gen2 styluses are now usable again on newer Linux kernels.
This blog-post is a follow-up post of ["How a kernel update broke my stylus... Need help!"](https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help) published 10 days ago. Please read it if you want to know more about the problem I had with the stylus.
After this first blog post (and thanks to your comments and guidance, especially [efi@chitter.xyz](https://chitter.xyz/@efi)) I was able to [email my bug](https://lore.kernel.org/all/nycvar.YFH.7.76.2311012033290.29220@cbobk.fhfr.pm/) to experts in the area.
Then Jiri Kosina republished my email to the [mailing-list](https://lore.kernel.org/all/nycvar.YFH.7.76.2311012033290.29220@cbobk.fhfr.pm/). A big thanks to them, to Illia Ostapyshyn for the discussion, and to Benjamin Tissoires for developing a solution.
If you have the same issue with a similar device, you'll have to compile:
https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/
This solution is still W.I.P. and I still have some homework to send more data about my tablets after this blog post, but in overall I'm already using a newer kernel (Linux workstation 6.5.10-200.fc38.x86_64) and I don't have the problem with the eraser mode on the top button of my XPPen Artist 24 Pro and XPPen Artist 16 Pro Gen2 styluses. The buttons are also now perfectly customisable via `xsetwacom` CLI tool. Yay! That's why I wanted to share this blog-post as soon as possible.
On the mailing list Benjamin wrote me a detailed answer about the whole story. It's very interesting and I decided to copy and paste it here. Thanks again Benjamin! 👍
### Benjamin's detailed answer:
_(Original email [here](https://lore.kernel.org/all/CAO-hwJKttorouwM2YXReH==r0Bg5c4rAisVgnDd9iOPBjbpA3w@mail.gmail.com/).)_
Hi David,
Here is a little bit of history of why you were encountering this bug:
First, HID is a quite old protocol and has the benefit of being "plug
and play" [[0]](https://who-t.blogspot.com/2018/12/understanding-hid-report-descriptors.html) [[1]](https://docs.kernel.org/hid/hidintro.html).
But plug and play often means for a hardware maker: "let's do trial
and error until Windows seems to behave in a correct way".
In some other cases, Microsoft puts more restrictions on the HID part
(Windows 7 enforced touchscreens to follow a specific pattern, and
then Windows 8 did it for touchpads). And they also sometimes provide
a test suite that hardware makers have to pass to be "certified".
They have to pass the test suite by using the Windows provided generic
driver, but Windows also allows them to create a virtual HID device
and let a custom driver create that virtual HID device. Which means,
we sometimes have devices behaving badly but working perfectly fine on
Windows because there are bits missing in the device itself that are
fixed by adding an extra software layer. Sigh.
But I digress and we need to go back to the pen bits, and AFAIK, there
is no such test suite and certification.
So basically, hardware makers follow the empiric rule of "if Windows
is happy, I am too".
To do so, they have to use several events from HID [[2]](https://usb.org/sites/default/files/hut1_4.pdf) (quoting them):
- **Tip Switch** → A switch located at the tip of a stylus, indicating
contact of the stylus with a surface. A pen-based system or system
extension would use this switch to enable the input of handwriting or
gesture data. The system typically maps Tip Switch to a primary button
in a non-pen context.
- **In Range** → Indicates that a transducer is located within the
region where digitizing is possible. In Range is a bit quantity
- **Barrel Switch** → A non-tip button located on the barrel of a
stylus. Its function is typically mapped to a system secondary button
or to a Shift key modifier that changes the Tip Switch function from
primary button to secondary button.
- **Secondary Barrel Switch** → A second non-tip button located on the
barrel of a stylus further from the tip than the Barrel Switch. Its
function is typically mapped to a system secondary or tertiary button.
- **Eraser** → This control is used for erasing objects. Following the
metaphor of a pencil, it is typically located opposite the writing end
of a stylus. It may be a bit switch or a pressure quantity.
- **Invert** → A bit that indicates that the currently sensed position
originates from the end of a stylus opposite the tip.
I'm sure that by reading those, everybody should be able to
immediately know how to write a Pen HID device, and how the
interactions between the events should be. :) (If you are, please
contact me ASAP, we have plenty of kernel work to do).
So for years the state of pen devices in the Linux kernel was 2 fold:
- Wacom shipped an in-kernel driver for their own devices, that they
tested and that defined the de-facto "standard" in Linux
- the rest was trying to catch up by luck or with the help of projects
like DiGiMend, by relying on the generic HID processing of the Linux
kernel
However, they were no specification for how the events should come:
basically in the hid generic input processing each event was mapped to
a single input keycode and we had situations were we would get both
`BTN_TOOL_PEN` and `BTN_TOOL_ERASER` at the same time (because the `In
Range` and the `Eraser` bits were sent by the device at the same
time). Which means "hey, the user is interacting with a pen with both
the tail and the tip at the same time. Good luck with that!"
This led to a complex situation where userspace (libinput mostly) had
to do guesses on what is the intent of the user. But the problem is
that when you are in userspace, you don't know all of the events of
the device at the same time, so it was messy to deal with. Again,
Wacom devices were unaffected because they controlled all of the
stack: a kernel driver to fix/interpret their devices and a userspace
component, xf86-drv-wacom, in the X.org world.
Once, as you mentioned in your blog, Microsoft decided to use the
second barrel button as the "rubber" mode. The reason was practical:
people liked the rubber capability on the styluses, but they wanted to
have a separate button on the tail end of the styluses. And I suppose
that at the time, given that no other hardware vendors were capable of
having no-battery styluses but Wacom (IP protection and capabilities
of the hardware IIRC), you still had to put the battery somewhere. And
that tail end is convenient for storing such a battery. But that makes
it harder to have an eraser end because you need to link both ends of
the pen on the same IC, with a battery in the middle that is roughly
the same size as your pen's barrel. So having just 2 wires for the
battery allows you to have a separate bluetooth button on one end, and
the normal stylus on the other end, and keep the width of the pen
reasonable.
So that choice of using the second button as an eraser was made, and
the hardware makers followed: on the XP-Pen Artist Pro 24, the device
reports `Tip Switch`, `Barrel Switch`, `Eraser`, `In Range`.
Which is "correct" according to the HID Usage Table [[2]](https://usb.org/sites/default/files/hut1_4.pdf), but which
doesn't adhere to the recommendation Microsoft is doing [[3]](https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states): the
device should report an extra `Invert` when the pen is in range with
the intent to erase...
But you can see that XP-Pen tried to adhere to it in some ways because
if you look carefully at the events coming from the device with
hid-recorder [[4]](https://gitlab.freedesktop.org/libevdev/hid-tools), you'll notice that when you are in range of the
sensor and press this button, you'll get an extra "In Range = 0" event
to notify that you went out of proximity of the sensor.
In kernel 5.18, with commit 87562fcd1342 ("HID: input: remove the need
for HID_QUIRK_INVERT"), I tried to remove those multiple tool states
to have a straightforward state provided by the kernel that userspace
can deal with easily. However, given that there were no regression
tests at the time for generic tablets, I wrote some based on
Microsoft's recommendation [[3]](https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states) and also tested on a Huion device I
have locally. And it was working fine. But I didn't have the devices
that were not sending `Invert`, which explained why it was bogus on
those devices.
This was "fixed" in kernel 6.6 with commit 276e14e6c399 ("HID: input:
Support devices sending Eraser without Invert"). Putting quotes around
"fixed" because I'm still not happy about this patch.
But the point is, from kernel 5.18, the Pen processing in the kernel
became a state machine, which means we can not have external actors
tampering with it.
Why using the ioctl EVIOCSKEYCODE is bad to remap `Eraser` to
`BTN_STYLUS2` (through tools like evmap):
Having the ability to do something doesn't mean it's the right thing
to do. And in that case, this is definitely wrong because you have to
call the ioctl after the kernel presents the device to userspace.
Which means userspace (and the kernel) already made assumptions on the
device itself. There is a high chance libinput (or the Wacom driver)
opens the device before evmap, and that it is considering that the
device doesn't have `BTN_STYLUS2`. So sending that event would break
userspace.
And in our case here, the kernel expects some state between the input
layer and its internal HID state, and remapping that HID event to
something else confuses it.
There is another side effect of this: usually end users configuring
their devices with such tools do not report back their configuration
to the kernel community. In some cases this is valid (this is my
preference and my choice), but in other cases it's not (there is a bug
here and I'm papering over it).
So, what can be done?
Basically 2 options:
1. write a kernel patch to fix that problem once and for all
2. use the brand new HID-BPF[[5]](https://docs.kernel.org/hid/hid-bpf.html) capability introduced in kernel v6.3
and send me back the BPF program so I can eventually integrate the
source in the kernel tree itself and fix that problem once and for all
as well
For 1., you need:
- to be able to dig into the kernel code
- to be able to write a patch with the correct kernel standard (with a
regression test in `tools/testing/selftests/hid`, please)
- to be able to compile your own kernel and test it
- to be able to submit your contribution by email (I can suggest using
b4 for that, very nice tool)
- to be able to take reviews into account, and learn `git rebase -i`
to submit v2, v3, and potentially v10 or more in some complex cases
- to wait for the patch to be integrated into Linus' tree
- to wait for Greg to backport your patch into a stable kernel tree
- to wait for your distribution to pick up the stable tree with your patch
That's relatively easy, no? :)
OTOTH, we have 2.: HID-BPF [[5]](https://docs.kernel.org/hid/hid-bpf.html)
Very quickly, eBPF [[6]](https://docs.kernel.org/bpf/index.html) is a state machine inside the kernel that
allows user space to include a verified code path in the kernel to
tweak its behavior. And I adapted this for HID so you can:
- change the report descriptor of the device: this
disconnects/reconnects the device, meaning the kernel works on the new
report descriptor and is consistent with its state
- change the event flow of the device: to fix the spurious out-of-prox
event for example
- more to come
What is interesting in BPF (or eBPF), is that nowadays, libbpf
implements something named CORE (Compile Once Run Everywhere). Which
means that if I compile locally an eBPF program on my machine with my
development kernel, as long as I only use functions available from
kernel v6.3 for instance, the same compilation output (that changes
the event flow of your HID device) will work on any kernel from v6.3
unless there are some later API breakages[7].
Which means, anybody can modify the event flow of an HID device, put
the file in the filesystem, and have the device still fixed even if
they upgrade their kernel.
In the long run, I intend to include those HID-BPF fixes in the kernel
tree to centralize them, but also to be able to automatically load
them from the kernel when those devices appear.
Which means, for the reporter of such a bug you:
- can now rely on someone else to write the code, compile it and
provide the compilation result [[10]](https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/27)
- just put that result in the filesystem to have the device tested and fixed
Behind the scenes, that other knowledgeable person can take the heavy
task of submitting the kernel patch for you, but given that the code
has been tested, it's way easier to do (and to eventually re-test).
Currently, the "let's integrate that bpf program in the kernel" is not
completely done, so we use udev-hid-bpf[[8]](https://gitlab.freedesktop.org/libevdev/udev-hid-bpf)[[9]](https://libevdev.pages.freedesktop.org/udev-hid-bpf/tutorial.html) to give it a jump start.
And that's exactly what happened in your case David. Which is why I'm
so happy (also because I fixed the tools from an author I like and
already had the books at home :-P):
You want your device to be fixed now, but going through a regular
kernel patch means months before it's fixed in your distribution.
But with HID-BPF, I fixed it now, and you can safely upgrade the
kernel, because even if I do changes in the kernel, the HID-BPF fix
will still convert the device into something valid from the HID point
of view, and it has a regression test now. When your device will be
fixed in the future in the kernel, there is a high chance the `probe`
function of the HID-BPF program will say that it's not the correct
device, and so the program will not even load and rely on the fixed
kernel only. Transparently for you, without you having to change your
filesystem.
On my side, what's left to be done:
- First, I need to fix the tablets not sending the `Invert` usage.
Commit 276e14e6c399 ("HID: input: Support devices sending Eraser
without Invert") is IMO not good enough, and we might as well simply
say that if there is no `Invert` usage, we can convert the `Eraser`
usage into `Secondary Barrel Switch`
- then I need to fix the XP-Pen Artist Pro 16 gen 2 from the kernel
too, by replacing the `Eraser` usage with `Secondary Barrel Switch`.
Ideally I would just dump the HID-BPF program in the kernel, but this
is not available yet, so I'll probably write a small kernel driver
using the same code path as the HID-BPF program.
- then Peter and I need to write a more generic HID-BPF program to
convert "eraser mode buttons" into `Secondary Barrel Switch`,
basically unwinding what the hardware does. This can only happen when
libinput will be able to do the opposite transformation so we don't
regress. But we can rely on libwacom to tell us if this pen has a tail
end eraser or not, and then have userspace choose if they want the
button to be a button, or an eraser mode.
I think that's pretty much it.
Thanks for reading through everything :)
Cheers,
Benjamin
[0]. https://who-t.blogspot.com/2018/12/understanding-hid-report-descriptors.html
[1]. https://docs.kernel.org/hid/hidintro.html
[2]. https://usb.org/sites/default/files/hut1_4.pdf
[3]. https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states
[4]. https://gitlab.freedesktop.org/libevdev/hid-tools
[5]. https://docs.kernel.org/hid/hid-bpf.html
[6]. https://docs.kernel.org/bpf/index.html
[7]. but if API breakage happens, all that will happen is that the
HID-BPF program will not be loaded. No kernel crash involved.
[8]. https://gitlab.freedesktop.org/libevdev/udev-hid-bpf
[9]. https://libevdev.pages.freedesktop.org/udev-hid-bpf/tutorial.html
[10]. https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/27
WRITTEN_BY David REVOY -
-
4 comments
I'm back from the exhibition, the workshops and the signing session in Plérin, France: what an amazing trip it was! 💜 Thank you all for helping to make it such an amazing weekend. I feel 10 years younger. 😃
Photo: the signed album of [@Yahiko](https://framapiaf.org/@Yahiko) on Mastodon , thanks for sharing the photo!
WRITTEN_BY David REVOY -
-
44 comments
I'm speechless 🤯 The print at the exhibition feels so big in real. I'm super happy sitting in the corner of my illustration.
Tomorrow, signing session!
WRITTEN_BY David REVOY -
-
128 comments
### What's the problem?
In short, after a Linux kernel update (6.5.8-200.fc.x86_64 on Fedora KDE), I can't use the top button of my pen on my tablet. This is really affecting my digital painting workflow!
Right-clicking on the pen is an essential part of my workflow. Right-click on a layer in Krita to get the menu, right-click while using the Transform tool to get the transformation options, right-click on the canvas to get the pop-up palette! ...And I'm not even talking about how difficult it is to handle files and the D.E. without right-clicking.
And if that makes you smile, imagine someone hardcoding the behaviour of your main device like the right-click on your mouse or touchpad (or anything else you have been using for more than 20 years) to something completely useless, and pushing it through kernel updates. And the icing on the cake, they left you with no user tool to change it back.
That's where I am now, and you can probably understand why I decided to write a blog post about it. Because my ability to use my tablet and thus continue my webcomic Pepper&Carrot under Linux is now tied to an older kernel, 6.4.15-200.fc38.x86_64, until a kernel developer fixes this situation.
[](data/images/blog/2023/2023-11-01_linux-kernel-broke-my-stylus_grub_net.jpg)
_Grub page at startup: I now have to select the second kernel to escape the bug.._
### What happened?
**Context:** My [XPPen 24 Artist Pro](https://www.davidrevoy.com/article842/review-xp-pen-artist-24-pro-on-linux) is my [default tablet](https://framapiaf.org/@davidrevoy/111161467977046626) for productivity since April 2023. This tablet doesn't have a proper tablet driver under GNU/Linux. But it works thanks to a generic driver in the Linux kernel for the Uc-Logic/Ugee device; that is the name of the digitiser inside the tablet, the circuit board if you prefer. I also top this with some code from the [Digimend-Kernel-Module](https://github.com/DIGImend/digimend-kernel-drivers). It requires a set of X11 rules and tweaks that I document in [my review](https://www.davidrevoy.com/article842/review-xp-pen-artist-24-pro-on-linux), but once that is done, you can customise the stylus buttons using the xsetwacom command line tool.
Unfortunately, in the newer Linux kernel of my distribution (6.5.8-200.fc.x86_64), there were some new commits that affected the behaviour of this [generic hid-input.c driver](https://github.com/torvalds/linux/blob/master/drivers/hid/hid-input.c). I don't know where it came from, but it was decided to hardcode a behaviour for styluses to have an 'eraser mode' instead of a 'right-click' on the second (top) button of the stylus.
For reference, here is the default on GNU/Linux, and has been since at least 2009 when I started drawing with it:
* Button 1 (pen tip) = left mouse click; to select, to draw, etc...
* Button 2 (down, on the side of the pen) = a middle mouse button, for panning the canvas or scrolling pages.
* Button 3 (at the top of the pen) = a right click, for context menus.
[](data/images/blog/2023/2023-11-01_linux-kernel-broke-my-stylus_xp-pen-artist-pro24_net.jpg)
_The stylus of the XP-Pen Artist Pro 24, with the location of the second button underlined._
### Where did the idea come from to map an eraser mode to a stylus button?
I can only speculate about this, but as far as I know, this type of behaviour was introduced by Microsoft for their Surfaces device on Ms Windows as a probable workaround for being too cheap to put an eraser on the other end of the stylus.
These Surfaces were aimed at business people and, as you can imagine, the pen was not intended to be used for drawing, but for signing documents or annotating PDFs. A side button eraser made sense to them. But what about right-clicking, you might ask? Well, these are 'touch' devices; the user could always use their finger with a long press and trigger a contextual right-click menu.
Soon after, I think Lenovo, HP and other tablet PC manufacturers were quick to imitate this new behaviour as brave sheep, and also to save some money on making styluses without a proper eraser on the other side.
So I can understand why a kernel developer thought it would be a good idea to bring this to GNU/Linux devices. Except they didn't just add it as a feature. It was forcing the behaviour on all users of the generic driver at the lowest possible level.
So I've lost my right-click on the second button of my stylus. And my device doesn't have a "touch mode".
Worse, **ironically** it even forces this behaviour on the stylus of [my newer XPPEN 16 Artist Pro (Gen2)](https://framapiaf.org/@davidrevoy/111318263108091568) that I'm testing. Brace yourself: a stylus with a real eraser... This left me speechless.
[](data/images/blog/2023/2023-11-01_linux-kernel-broke-my-stylus_xp-pen-artist-pro-16-gen2_net.jpg)
_The bug even affects stylus with an Eraser device, as on this stylus of the XP-Pen Artist Pro 16 (Gen2)._
### Can't you just customise a button on your Linux system?
This is the best part: no, **you can't.**
Because you see, instead of just sending a single event that could later be customised by a CLI tool like xsetwacom, a desktop environment like kcm-tablet Plasma Panel, or even a udev rule; this kind of behaviour is hardcoded in, so the button sends too many events to map to anything. The button doesn't trigger a key, it switches the whole device to something else when pressed.
From my understanding; forcing this behaviour for the Uc-logic/Ugee generic tablet has been done for a long time; but a "bug" kept the stylus of my XPPEN Artist 24 Pro out of it, and [this commit probably fixed it in the worst for me.](https://github.com/torvalds/linux/commit/276e14e6c3993317257e1787e93b7166fbc30905) I now know it is there for a long time, because even with the "old" kernel, my newer XPPen 16 Pro (gen2) also reacts this way.
And no tools can fix it now. Are we doomed to have an eraser on the second key?
Or is there anything else we can do?
**Please help if you can**.
### Update:
**2023-11-09:** It works! Benjamin Tissoires made a solution. I tested it and I'm no longer locked to a kernel, [you can know more about it on the Mailing list](https://lore.kernel.org/all/7wmtNlKuYResf5cFQ7M2QTalzIUtw0I6ohvPcz69Jo1c8flezyIlnJu1IwAgXhJ-u0NlRL3IV7HnL0Kza6fVBqd7X7jhc-Z6QCi3oqHEvpY=@protonmail.com/). The solution solves the issue for the two devices I have.
**2023-11-07:** You can follow [the discussion on the Linux kernel mailing list here](https://lore.kernel.org/all/nycvar.YFH.7.76.2311012033290.29220@cbobk.fhfr.pm/).
**2023-11-01:** (Additional technical infos) Here are two evtest screenshots of the two devices with the newer kernel while performing a top button on the stylus (click to enlarge).
[](data/images/blog/2023/2023-11-01_linux-kernel-broke-my-stylus_evtest-compare.jpg)
