WRITTEN_BY David REVOY -
-
33 comments
With mascot of:
- Mastodon, https://joinmastodon.org/
- Pleroma-tan of Pleroma, https://pleroma.social/,
- Ai of Misskey https://misskey-hub.net/,
- Lemmy https://join-lemmy.org
- Sepia of https://joinpeertube.org/,
- sloth mascot by Anna Abramek for https://gotosocial.org,
- Fediverse logo (but shaped like a tree with many nodes)
Done on paper with pencil and with a bit of watercolor while traveling in family.
WRITTEN_BY David REVOY -
-
9 comments
💜 Framasoft does so many things in sync with my values that I'm always so proud when I do illustrations for them.
Check out their campaign page to end 2023 (and support them if you can); it's presented as a 2D character selection of a fighter video game and it was really fun to draw all the characters and monsters:
https://soutenir.framasoft.org/en/
[Sources files here](https://www.peppercarrot.com/en/artworks/framasoft.html)
WRITTEN_BY David REVOY -
-
6 comments
Hey, earlier this week I posted a first version of the upcoming episode 39 to the development forge of the Pepper&Carrot project. It's **an important milestone** for a new episode and I'm really happy that this one finally arrived in this state!
However, the episode is far from being ready for public release. I call this version Alpha 1 because many things will change. The artwork of this 11-page episode is still undetailed and in grayscale; it's **an intermediate step** in the production. Dialogue and storytelling will also be improved.
If you're not afraid of spoilers and want to contribute, I'm **currently collecting feedback** on the story, and I've written more about it in the dedicated discussion here:
**https://framagit.org/peppercarrot/webcomics/-/issues/254 **
Feel free to jump in, it's an open webcomic project! Just don't expect any major progress on the repository until the beginning of 2024: I'm currently on a family vacation for the holiday season.
I estimate I'll need about 160 hours to finish this episode, so I'm optimistic for **a release by the end of January** if all goes well.
What's next? Here are the main next steps in the development of a new episode:
- Alpha: Fixing the storytelling, the ease of reading it, the info given by the dialogue. Make sure the comic "works".
- Beta FR: Improve the dialog, simplify the sentences or make them easier to read. Also correct spelling and punctuation.
- Beta EN: Translation of the French version.
- Beta ready for translation: Opening the translation to all other 66 languages of the project before the release.
... and of course parallel to all these steps, the coloring and painting of the pages.
_Screenshot on top: Four panels of episode 39 Alpha 1, grayscale, painted in Krita 5.2.2appimage on Fedora Linux 39 KDE, the files are tiled on a 1080p display, the one of my laptop while traveling._
WRITTEN_BY David REVOY -
-
186 comments
The recent excitement surrounding Thread's arrival on the Fediverse is concerning. To understand why this is not a good idea, consider their economic interest in harvesting data, their poor moderation, and their manipulations. Nothing good can come from their federation. Don't roll out the red carpet for them.
[Artwork source here](https://www.peppercarrot.com/en/viewer/misc__2023-12-14_Don-t-roll-out-the-red-carpet-for-them_by-David-Revoy.html)
WRITTEN_BY David REVOY -
-
27 comments
My version of the character Ada from "Ada & Zangemann", a Creative Commons license (BY-SA) book for children and a funny story about Free/Libre and Open-Source. It's written by Matthias Kirschner and illustrated by Sandra Brandstätter. It is great to see new characters in the Free Culture, especially because Ada is so cool.
You can find it printed in English, French, German, Italian → https://fsfe.org/activities/ada-zangemann/
[Source file here](https://www.peppercarrot.com/en/viewer/misc__2023-12-03_Ada-and-Zangemann_by-David-Revoy.html)
WRITTEN_BY David REVOY -
-
64 comments
_Picture above: concept art for episode 39 (click to enlarge).
A close-up of a piece of artwork showing Wasabi, but young._
### A philosophical questioning
Recently, I've been browsing DeviantArt, ArtStation and other art platforms that have decided to empower AI artists, as if the recent and continuous [enshittification](https://en.wikipedia.org/wiki/Enshittification) of their platform wasn't strong enough.
But I have to say: AI-generated digital artworks are really improving and getting more and more things right: proportions, composition, even the number of fingers! They are getting closer and closer to complete imitations of real artists, and that is impressive in its own way.
But even if it sounds like I'm praising some aspect of AI-generated imagery, make no mistake: I'm still very much against it. I remind you that thousands of my artworks have been analysed over the last 20 years and are part of the LAION-5B database. All without my consent.
In this respect, I could ironically say that all generative AI stuff can be considered derivative of my work, even if only to a 0.00001% degree of derivation.
**All of this is really energy consuming.**
So this soup of feelings continues to influence my relationship to making new artwork, the way I approach the canvas and the way I paint.
Because it challenges some deep underlying philosophical questions:
What is human in my work?
What is my signature?
What is "I"?
To be honest, I still don't have a clear answer to these questions, but my instincts are pushing me in one direction: to show more of my brushstrokes, my hand gestures, and to avoid smoothing things out.
### Brushstrokes as a vector of identity
Let's start on the same page: I'm pretty sure that artificial intelligence art will eventually manage to parrot every artist's brushstrokes, if it hasn't already. But it could be very challenging: so far I see a lot of over-smoothed artwork, blurred or melted strokes, strokes with no start or end, and over-cleaned surfaces. Many results are devoid of personality and gesture.
That's probably why my taste for expressive brushstrokes, human gestures, has increased since my last art browsing session. Even my taste for artists who use the traditional is on the rise, and in my opinion it could even be a new trend.
But what about digital art? I think that we can still manage to express ourselves. With some artists, I'll always recognise their long brushstrokes, or their little 'loops', or their 'noise', or the way they accentuate their colours.
**Could an artist's brushstrokes convey authenticity?**
Maybe so. At least here is a hint where I can put my "human signature" in the most obvious way. Unfortunately, it is difficult for a painter to master the economy of the brush stroke. Resisting the urge to smooth a volume and 'let it go' is rarely my first reflex.
But I'm working on it, and things are starting to come together on this stylistic issue:
- My recent [pen training](https://www.davidrevoy.com/article1001/ballpoint-pen-training) sketchbook really reminded me of how I loved to crosshatch, and how those crosshatches were personal gestures.
- My [new tablet](https://www.davidrevoy.com/article1004/xppen-artist-pro-16-gen-2-review-on-gnulinux) helps me to transfer this kind of gesture to digital, thanks to the low parallax and fast response.
- Also, during the recent [exhibition of prints](https://www.davidrevoy.com/article992/large-exhibition-in-plerin-france) in giant format, I enjoyed seeing my brushwork magnified. Especially when I saw the scribbling and crosshatching done on [the Dragonfish Restaurant](https://www.davidrevoy.com/article157/texture-test-water-dragons-cooking-and-snow), a 10 year old piece, printed in large ([see zooms at 100%](https://www.davidrevoy.com/data/images/blog/2013/01/Dragonfish-restaurant_by_David_Revoy.jpg)).
So that's what I'm working on at the moment, and what kind of thought chemistry is boiling in my brain.
Do you want to know the irony of all this? These developments towards a stronger personal style in my art, though I am pained to admit it, come from the pressure of the existence of AI-generated images.
Should I be grateful for that?
[](data/images/blog/2023/2023-12-02_young-wasabi.jpg)
_Picture above: concept art for episode 39 (click to enlarge).
Artwork showing Wasabi, but young._
[Picture source here](https://www.peppercarrot.com/en/viewer/sketchbook__2023-12-02_young-wasabi_by-David-Revoy.html)
WRITTEN_BY David REVOY -
-
142 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 -
-
42 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
- **2024-09-26:** Add a X11 configuration method to get persistent mapping
- **2024-09-26:** Update eBPF HID install method (using the ./install.sh script)
- **2024-07-28:** Update eBPF HID rules comand lines.
- **2024-06-09:** Update and test on the remote control, update about the nibs after 8 month of usage.
- **2024-06-09:** Removed outdated promo code 'DAVID15' (lol) for December 2023 and link to shops.
- **2024-06-09:** Install guide added for the udev-hid-bpf rules that fix the stylus buttons and also fix tilt.
- **2024-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.
## 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 an Eraser!
Yes, this was [a known issue and a drama for me](https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help), which was [later fixed](https://www.davidrevoy.com/article1002/how-a-kernel-developer-made-my-styluses-work-again).
In short, you'll need to apply the rules contained in the [udev-hid-bpf](https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/) project. That one contains a rule to make it work again as a right click (or any button, or keypress: the key after the change will be exposed to xsetwacom for customization).
#### Newer kernel
On my [GNU/Linux installation based on Debian 12 Bookworm](https://www.davidrevoy.com/article1030/debian-12-kde-plasma-2024-install-guide), you'll need a newer kernel to load [BPF programs](https://lwn.net/Articles/970702/) with eBPF. To do this, I install the `curl` package and then the [Liquorix](https://liquorix.net/) kernel using the one-liner command line provided on their website.
Once everything is working, I like to "hold" the kernel packages [with apt](https://askubuntu.com/questions/18654/how-to-prevent-updating-of-a-specific-package). In fact, the Liquorix project updates frequently, and I prefer to keep the same kernel once everything is up and running, for stability reasons.
Don't forget to reboot after installing, be sure the new kernel is selected on the Grub menu at startup, and once in the session you can still check with a `uname -a` to be sure.
#### Loading the BPF rule
[udev-hid-bpf](https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/) is compiled using Rust, and very recent versions. It will be almost impossible to compile it with Debian 12 without having to update almost all the operating system libraries manually and one by one (trust me, I tried). Fortunately, the udev-hid-bpf provide a precompiled utility that is cross compatible to load the BPF programs.
Download the [latest package of udev-hid-bpf](https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/releases) (Packages, not source code or asset) , unpack it somewhere, then go to the directory and execute the bash script `./install.sh`
Once installed with a successful message, you can restart your system.
Your pen button should now trigger a right-click action by default.
### The Remote shortcuts
I remember being able to connect wirelessly to this device on Linux via the USB dongle (the one in the stylus box), but my device has become unpaired over time and I'm not sure how to pair it with the dongle again. In total, there are three ways to connect this device to your computer: one with a dongle (which I'm pretty sure worked and now can't), one with Bluetooth (which never worked), and one with a USB-C cable, which always works. The [official user manual](https://www.xp-pen.com/user-manual/ack05-wireless-shortcut-remote) can tell you which button to press if you want to try if pairing works on your side. For a TL:DR; it's a long press of 6 seconds on the button in the middle of the dial.
You can customize the buttons in several ways:
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: they'll have to send also two keys, and if you replace `Ctrl` with something else, it will affect all shortcut with `Ctrl`. 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)
All in all, as I said in the video, I prefer to keep my tiny yellow 8bitDo gamepad and a full keyboard access on top of my tablet. But maybe I would reconsider if this device had a simple Bluetooth support and a support of the dial with the button.
### 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._
In the middle of 2024, I switched to the standard black plastic nibs: I just took very thin sandpaper (T400 grit) and slightly flattened the tip to get more friction. This also solved the slippery surface. That's what I'm using now and it's stable: I don't see any wear on the tip after 3 months.
### Persistent cursor calibration and pen pressure
Keeping xsetwacom command line in a script executed at startup is a good method but it also has caveats: after a sleep time, the computer loose the mapping on screen, cursor calibration and pen pressure. The user has to re run the script manually (or reboot). That's why you can also save these into a X11 configuration file: this one will be persistent.
To do so, first, you need to have the cursor correctly setup via xsetwacom (using MapToOutput and Area ). We will then ask the system to translate the effect into X11 Coordinate Transformation Matrix. To do that, list the device with xinput:
```
$ xinput list
```
Then check in the returned list the ID of your stylus, mine here is 17). I'll then list the property of item 17 with this command line:
```
$ xinput list-props 17
```
This will return the the transformation matrix of the device we are looking for, it looks like that:
```
Coordinate Transformation Matrix (177): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
```
Then you can add this info to your X11 configuration file, for example mine here is in `/usr/share/X11/xorg.conf.d/60-xppen.conf` and look like that:
```
Section "InputClass"
Identifier "XP-Pen Artist Pro 16 (Gen2) Tablet"
MatchIsTablet "on"
Driver "wacom"
MatchUSBID "28bd:095b"
MatchDevicePath "/dev/input/event*"
Option "Suppress" "0"
Option "RawSample" "1"
Option "TopX" "0"
Option "TopY" "1745"
Option "BottomX" "32764"
Option "BottomY" "31050"
Option "PressCurve" "75,85,20,100"
Option "TransformationMatrix" "1 0 0 0 1 0 0 0 1"
EndSection
```
You can also see that you can put the RawSample, Suppress, PressCurve points, and Area (TopX, TopY, etc). Only customisation of the buttons cannot be applied with this method as far as I know, and you'll need to execute a set of xsetwacom command line to customise them. But it is still a quality of life to have the mapping totally persistant.
### 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 -
-
60 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
