CONFLUXIS Signal into static.
← back

Terminal-first Linux on a rugged tablet

Toughpad · 2026-05-09

Walkthrough companion to "Sway" over on confluxys.com — that piece is the read on what shifted underneath the platform; this one is the configuration, the layer set, and the seams. Read either first.

The gap nobody fills

If you go looking for "Linux on a tablet" today, you find two camps.

The first is mobile-Linux-as-smartphone: Phosh, Plasma Mobile, Mobian, postmarketOS-default. These are GNOME and KDE squeezed into phone-shaped UX — big touch targets, app-grid launchers, swipe gestures, virtual keyboards optimised for typing prose into chat apps. They're real, they work, and they are not what I wanted.

The second is Sxmo — the suckless mobile project. Sxmo is dwm or Sway, st or foot, dmenu menus, three-button-and-chord control, terminal-first by design. It is exactly what I wanted in spirit. It is also, almost entirely, an ARM-and-phone project: PinePhone, PineTab, Librem 5. There are community packages on Arch and Void, but nothing turn-key for x86 Debian, and nothing that knows about rugged industrial tablets.

Between these two camps is a gap. Nobody has written down, as a coherent working build, what a terminal-first touch UX on x86 Debian actually looks like. This post is what I built and what I learned about that gap.

The hardware

A Panasonic Toughpad FZ-G1 mk1. Ivy Bridge i5, 8 GB, 10.1" 1920×1200, Wacom digitiser, USB capacitive touch, an actual physical hardware-button row, and a magnesium-alloy chassis you could (allegedly) drive over. I bought mine secondhand for about the price of a nice mechanical keyboard. There is a healthy resale market for these — they were specced for fleet use in warehouses, ambulances, and military procurement, and now there's a long tail of working units that nobody wants for their original purpose.

The FZ-G1 is unusual hardware in two relevant ways. First, it's x86 — so none of the ARM-based mobile-Linux distros apply directly. Second, it has a pile of HID-class IIO sensors (accelerometer, gyro, magnetometer, ambient light, inclinometer, rotation vector) all exposed cleanly under /sys/bus/iio/devices/. The kernel handles them via standard hid_sensor_* modules and the Panasonic-specific hotkey/LED bits via panasonic_laptop. There is nothing exotic to build, no out-of-tree drivers, no DKMS. From Linux's perspective it is a perfectly ordinary laptop that happens to have a touchscreen and no keyboard.

That last sentence is more important than it sounds. It means everything that makes this a tablet — and not just a small laptop — is in userspace. Which means the work is configuration, not engineering.

The stack

The base is Debian 13 (trixie) with stock APT sources — main, security, updates, non-free-firmware for the Intel and Realtek bits. No third-party repos. No held packages. No custom kernel.

The desktop layer is:

Layer Tool
Compositor Sway (Wayland)
Status bar Waybar
Terminal foot
Launcher wmenu (wmenu-run, bound to Mod+d)
Idle / DPMS swayidle (inline in sway config)
Audio pipewire + wireplumber
Login greetd
On-screen keyboard wvkbd-mobintl
Prompt starship

If you've used any modern Wayland-only sway setup, none of this is news. The interesting parts are the small set of decisions that make it work as a tablet.

The five decisions that matter

Most of the build is uncontroversial. Five choices are worth calling out because each took some experimenting to get right.

1. Output scale, not resolution

output eDP-1 scale 1.5

The native panel is 1920×1200 on a 10.1" surface. Native is unusable for finger interaction. scale 1.5 gives a logical 1280×800 — readable text, button-sized buttons, and Wayland still composites the pixel-true output, so nothing looks blurry the way DPI-doubled X11 used to. This is the entire "high-DPI handling" story on Wayland and it is wonderful compared to fighting Xft.dpi and per-app font sizes.

2. Touch and Wacom both map_to_output eDP-1

input "*Wacom*"   { map_to_output eDP-1 }
input type:touch  { map_to_output eDP-1 }

This sounds trivial and is the single most important line in the whole config. It tells the compositor "wherever this output is, that is where the digitiser lives" — which means rotation Just Works. When the output flips to transform 90, both the stylus and the finger track the panel automatically. No xinput tricks, no calibration, no separate rotation hooks for the input devices. The output transform is the source of truth and everything else follows.

3. wvkbd-mobintl with the right layer set

exec wvkbd-mobintl --hidden -L 230 -l landscape,landscapespecial,nav,full,special

Three things matter here. First, wvkbd-mobintl, not the default wvkbd — the mobintl build is the one with proper layer-switching and international layouts. Second, --hidden at session start: the keyboard is running but invisible until summoned, so it doesn't steal half your screen during boot. Third, the layer set — landscape,landscapespecial,nav,full,special. This is the part you cannot get from any documentation; you have to try them. nav gives you arrow keys, page up/down, home/end. full gives you function keys and a QWERTY-with-modifiers layout that actually fits over a terminal. special gives you punctuation that shells eat for breakfast — pipe, redirect, backtick, brace pairs. landscapespecial is the same in landscape geometry.

If you skip the nav and special layers, you cannot meaningfully use vim or a shell from the OSK. With them, you can.

4. Mod+o → SIGRTMIN to wvkbd

bindsym $mod+o exec pkill -RTMIN wvkbd-mobintl

wvkbd-mobintl toggles its own visibility on SIGRTMIN. This is the idiomatic show/hide pattern and it's faster and more reliable than spawning/killing the process. With this binding, the on-screen keyboard becomes a transient thing you flick on for a sentence and dismiss — the way a software keyboard on a phone works, except triggered by an explicit user intent rather than a focus-tracking heuristic.

5. nmtui and nmcli over a GUI

bindsym $mod+n exec foot -e nmtui

Network management in a terminal. This is the philosophical core of the whole build. The standard "Linux tablet" answer to "join a wifi network" is a system tray icon and a clickable picker. The terminal-first answer is Mod+n → ncurses → enter password → done. It is faster. It is scriptable. It does not require a 200-MB GNOME panel to display six SSIDs.

The same pattern applies through the rest of the build. Brightness is brightnessctl set ±5% bound to the hardware keys. Audio is wpctl set-volume. Rotation is a 12-line shell script that toggles swaymsg output eDP-1 transform. Everything is a CLI tool you can invoke from a keybind, a Waybar button, a script, or a foot session. There is no GUI-only path to anything important.

What this is not

I want to be honest about what's missing, because the gaps are as informative as the wins.

There is no auto-rotation. Rotation is a manual cycle-rotation script or a Waybar button. The IIO accelerometer is sitting right there at /sys/bus/iio/devices/iio:device0 exposing perfectly clean data, and gluing it to swaymsg output eDP-1 transform would be a 20-line shell loop. I haven't written it, because I rotate the screen maybe twice a day and the manual toggle is fine. But for a tablet you actually swing around in your hands, the daemon is the obvious next step.

There is no integrated stylus pressure curve or button remapping. The Wacom digitiser's tip works. Its barrel buttons are unmapped. For drawing this would matter; for shell-and-text use it doesn't.

There is no smartphone-style swipe-from-edge gestures. Sway doesn't have them, and I haven't tried to add them via libinput-gestures. I find keybinds-via-OSK-modifiers more reliable than gestures anyway, but if you've internalised iOS muscle memory this will feel sparse.

The waybar layout is not Sxmo. Sxmo's killer feature is its menu-everything pattern: every system action is a bemenu invocation generated by a shell script, and you build muscle memory around the hierarchy of menus. Waybar gives you a bar with buttons, which is more "compact desktop" than "phone-style menu OS." Sxmo's menu repo is well worth reading and is on my list to crib from.

Why share this

Sway's documentation tells you exactly how each directive works. The Sxmo wiki tells you what a phone-shaped Linux UX looks like. Nothing in between walks you through what a coherent terminal-first touch workflow on x86 Debian actually looks like — what the wvkbd layer set should be, how to tie SIGRTMIN to a keybind, why map_to_output eDP-1 is the critical line, what scale factor lands on a 10" 16:10 panel. Those are the choices that took me a couple of days to converge on, and writing them down lets the next person skip that part.

The hardware audience is small. Other Toughpad owners. Surface Go users who want something other than GNOME. Latitude Rugged owners. Sxmo-curious people on x86. Tinkerers who saw a beat-up FZ-G1 on eBay for €120 and thought "I bet I could…" Probably dozens of people, not thousands. But those dozens currently have nothing to read, and the cost of writing it down once is low.

The bigger pattern

This setup works because Wayland has, quietly, finally made "compositor-as-source-of-truth" real. Output transforms now actually rotate input mappings. Output scale now actually works without per-app font fights. wvkbd is a real protocol-native virtual keyboard, not an X11 hack with extra steps. swayidle handles DPMS and suspend without needing a desktop-environment-sized session manager. brightnessctl talks to the kernel without needing a polkit rule per app.

Each of those used to be a research project on X11. On modern Wayland they're individually trivial, and the whole point of this post is that when you stack the trivial parts in the right order you get a usable tablet that fits in your head. No sed-the-Xorg-config rituals, no suid-helper-binary for backlight, no mystery DBus services. Just sway, some configs, and a couple of one-liner scripts.

That is the actual shift, and it's why this kind of build is interesting now in a way it wouldn't have been five years ago. Not because the FZ-G1 is special, but because the floor under it has finally come up.

Resources

Companion dotfiles bundle (sway config, rotation script, waybar, foot, starship, the bashrc additions): repo coming soon — link will appear here once published.

If you build something similar — same philosophy, different hardware — I'd genuinely like to hear about it.