Arch Linux runs well on tablet hardware, from Pine64's PineTab2 with its 64-bit quad-core 1.8 GHz ARM Cortex A-55 to the Samsung Galaxy Note 10.1 (2014 Edition). Pick a device with mainline kernel support, then plan to configure the input stack by hand. Every dead gesture, jumpy stylus, or rotation that never fires is a misconfigured input pipeline, not a lost cause. Before you copy a config off a forum, read what the kernel actually reports with libinput debug-events and udevadm info.

Arch Linux has shipped since 2002, and its no-defaults approach is exactly why it suits a tablet. Nothing is configured for you, so nothing hides the failure. The whole point is that you can see the pipeline end to end. So fix the symptom by finding where the device drops, not by pasting values someone else guessed at.

How the kernel input subsystem actually sees your tablet

Three layers sit between the glass and your application. The kernel driver enumerates the hardware and exposes it as an evdev device under /dev/input/eventN. Then libinput reads those raw events, applies quirks, and hands clean pointer and touch data to the compositor. Finally the compositor (Wayland) or Xorg maps that to windows.

Most "my stylus is broken" reports die in the first layer. If the kernel never enumerated the pen as a distinct device, no libinput config saves you. So you diagnose from the bottom. Confirm evdev sees the device, confirm libinput reads it, then blame the compositor last. That order saves you an hour of editing files the problem never touched.

The mistake I see most is starting at the top. Someone edits a compositor gesture binding when dmesg already said the touchscreen driver failed to probe. Read the ring buffer first.

Verify stylus and touch are enumerated before you configure anything

Run this first: libinput debug-events --show-keycodes. Touch the screen, use the pen, lift it. If events stream for each, the hardware and kernel are fine and your problem is configuration. If nothing appears, the device is not enumerated and you go one layer down.

Identify the exact device with udevadm info:

udevadm info --query=all --name=/dev/input/event5

That prints the vendor and product IDs, the device name, and the udev properties libinput matches against. Write those IDs down. Every quirk and hwdb rule keys off them, so a wrong ID is why your config gets ignored.

Then filter the kernel log for the probe:

dmesg -T | grep -iE 'input|hid|wacom|elan|goodix'

Goodix and Elan are the common touchscreen controllers on convertibles. dmesg tells you whether the driver bound at all. If you see a probe error there, the fix is a driver or firmware problem, not a libinput one. When a driver refuses to load cleanly, sometimes the sane move is to blacklist a conflicting kernel module and let the right one bind.

Why libinput config fails silently, and how to fix it right

A dropped libinput setting almost always means your match rule is wrong, not your values. libinput reads device-specific quirks from .quirks files, usually under /usr/share/libinput/ and /etc/libinput/. Each file matches on vendor, product, or device name. If the match misses, libinput ignores the whole block and never tells you.

Check what libinput actually applied:

libinput list-devices

That prints each device's capabilities and the current settings libinput chose. If your custom value is not there, the match failed. Compare the MatchVendor and MatchProduct in your quirks file against the hex IDs from udevadm info. One transposed digit and the rule is dead.

For device properties, udev's hardware database (hwdb) is the other layer. Add a rule, then rebuild and reload:

sudo systemd-hwdb update
sudo udevadm trigger

Here is what trips people up. Editing the file is not enough. hwdb is a compiled binary database, so without the update step your edit does nothing and you conclude libinput is broken. It is not. You just never loaded the change.

Installing Wacom support without fighting libinput

Install libwacom before anything else. It is the userspace database that tells every other tool what your tablet's buttons, rings, and stylus actually are. Skip it and xf86-input-wacom, GNOME settings, and your calibration tools all guess at capabilities. Check that your device is known:

libwacom-list-local-devices

Now the real decision: libinput or the Wacom X11 driver, not both. On Wayland, libinput handles most modern pen tablets fine and there is no xf86-input-wacom to reach for. On Xorg, xf86-input-wacom exposes device-specific features libinput does not, like per-button mapping and fine pressure control. But if both drivers claim the device, you get double events and a stylus that jumps.

Diagnose the conflict from the Xorg log:

grep -iE 'wacom|libinput' /var/log/Xorg.0.log

If you see both drivers bind the same event node, that is your bug. The fix is a match rule in /etc/X11/xorg.conf.d/ that assigns the pen to exactly one driver. Do not run both and hope. Pick the driver that exposes the feature you need and exclude the other.

Automatic rotation by reading what the sensor daemon exposes

Install iio-sensor-proxy and query it before you write a single rotation rule. It reads the accelerometer and publishes orientation over D-Bus, so you never poke raw /sys sensor files. Confirm it sees your accelerometer:

monitor-sensor

Rotate the tablet. If the reported orientation changes, the sensor works and the daemon is the authoritative source. If nothing changes, your firmware may not expose the IIO accelerometer, and no rotation daemon fixes that.

The brittle approach I see everywhere is a pile of hand-written udev rules watching /sys paths. Skip it. On GNOME and KDE the compositor already listens to iio-sensor-proxy and rotates for you. On a minimal setup like Sway, you write a small script that reads monitor-sensor output and calls swaymsg output ... transform.

Rotate the display and the input matrix together. If you rotate only the screen, the touch coordinates stay in landscape and every tap lands in the wrong place. That mismatch is the single most common rotation complaint, and it is always a forgotten input transform.

Remap hardware buttons by tracing the real event codes

Do not assume a button's keycode. Trace it. Run evtest, pick the device, and press the physical button:

sudo evtest /dev/input/event6

The output prints the exact event type and code the kernel emits. That tells you whether the button sends a key, a switch, or nothing at all. Half the "button does not work" cases are a button that emits no event because the driver never mapped it. evtest proves that in five seconds.

Once you have the real code, remap it in the right place. For a keycode remap, write a hwdb rule keyed on the device ID and the scancode from evtest. For launching commands, xbindkeys on X11 or a compositor binding on Wayland is cleaner. What you never do is guess the code from a spec sheet, because the firmware often relabels buttons and the sheet lies.

Tune pressure curves and aspect ratio so the stylus feels right

Validate the full pen pipeline in Xournal++ first. Draw with light and heavy pressure, tilt the pen, flip to the eraser. If pressure, tilt, and eraser all register, your stylus stack is healthy and any remaining weirdness is calibration, not driver. If pressure is flat or the eraser does nothing, go back and check enumeration before touching curves.

On xf86-input-wacom you set the pressure curve with xsetwacom:

xsetwacom set "<device name>" PressureCurve "0 0 100 100"

Those four numbers are control points from soft to firm. Bezier them toward the low end for a lighter touch. On libinput there is no per-curve knob, which is one reason people still reach for the Wacom driver on Xorg.

Aspect ratio is the other gotcha. If your tablet's active area does not match the screen shape, circles come out as ovals. You must map the tablet area to the screen with the correct ratio, not stretch it edge to edge. On Wacom, set the Area to match the display's aspect. Get this wrong and every diagonal line drifts, which no pressure tuning will ever fix.

Picking an on-screen keyboard that matches your compositor's protocol

Use Maliit on Wayland. It integrates through the compositor's input-method protocol without the shims other keyboards need. That protocol match is the whole game, and it is where most on-screen keyboard failures come from.

Three protocols are in play. Older Wayland input methods use input-method-v1, modern text entry uses text-input-v3, and X11 keyboards like onboard bypass all of it. If your keyboard speaks one protocol and your compositor speaks another, the keyboard opens and types into nothing. There is no error, just dead keystrokes.

So check your compositor's protocol support first, then pick the keyboard that matches. Choosing by feature list instead of protocol is how you end up with a pretty keyboard that inputs nothing.

Why tablet-mode detection fails on convertibles

Tablet mode rides on a single kernel switch, SW_TABLET_MODE. When you fold a convertible, firmware is supposed to assert that switch, the kernel emits it as an evdev switch event, and logind flips the session to tablet mode. Confirm the switch exists:

sudo evtest /dev/input/event3

Fold and unfold. If SW_TABLET_MODE toggles, detection works and you wire your UI to it. If it never fires, the firmware is not asserting the switch, and that is the failure nobody mentions. No udev rule invents an event the hardware refuses to send.

When the switch is missing, your only real options are a vendor-specific ACPI driver that maps the fold event, or accepting that mode detection will not work on that model. Check dmesg for the driver that owns the lid and hinge sensors. If a recent kernel update broke a previously working switch, that is a regression, and the fastest confirmation is to roll back the kernel and test the fold again.

Scoping tablet input per application without global bleed

Keep creative-tool settings out of your global config. If you set an aggressive pressure curve or a cropped tablet area globally, every application inherits it, and your file manager gets a stylus that behaves like it is in Krita. Scope the settings instead.

On xf86-input-wacom, match on the tool type. The stylus, eraser, and pad are separate devices to xsetwacom, so you tune each without touching the others. For per-application behavior, drive xsetwacom from the application's own launch script or a window-focus hook, then restore defaults on exit. That keeps the mapping alive only while the app runs.

The clean pattern is a small wrapper. Launch the creative tool through a script that sets the area and curve, runs the app, and resets on close. No global file edits, no config bleed between tools. When something misbehaves later, you know exactly which script set it, instead of hunting a stray value in a shared config.

FAQ

Does an Arch tablet work better on Wayland or Xorg?
Wayland for daily use, Xorg only when you need a Wacom feature libinput cannot expose. Wayland handles touch, gestures, and rotation more cleanly through the compositor. But xf86-input-wacom still owns fine pressure curves and per-button pad mapping, so a serious artist on Xorg has a reason to stay there.

Why does my touchscreen work in the installer but not after reboot?
The installer runs a generic kernel with broad driver support, and your installed system may be missing the module or firmware for your touch controller. Check dmesg for a failed Goodix or Elan probe, then confirm the matching firmware package is installed. If the driver needs a config option your kernel lacks, you may have to enable the missing kernel option and rebuild.

My stylus works but palm rejection does not. Where do I fix it?
Palm rejection lives in libinput, and it needs the touchscreen and pen to be recognized as related devices. Run libinput list-devices and check the touchscreen reports the correct size. A wrong or missing device dimension in the libwacom or hwdb data breaks the rejection math, so fix the device description before touching anything else.

Can I use an external drawing tablet on the same setup?
Yes, and the same diagnostics apply. Plug it in, run libinput debug-events, and confirm it enumerates as its own pen device. External Wacom units are usually better supported than built-in convertible digitizers, because their vendor and product IDs are well known to libwacom.

How do I stop rotation from lagging or firing at the wrong angle?
Lag is almost always a polling script sleeping too long between monitor-sensor reads, and wrong angles come from mapping the sensor orientation to the display transform incorrectly. Verify each orientation with monitor-sensor by hand, then map each reported value to the matching display and input transform. Do not trust a copied lookup table; sensor mounting differs per model.

Related: Linux on Surface Book: Install the Right Kernel First