Build note · · By Keegan Ott · 6 min read
Use a reMarkable as a drawing tablet on Windows and Linux
The awkward part of using a reMarkable as a drawing tablet is not getting pen coordinates off the device. It is making Krita, Photoshop, or a Linux desktop believe that a normal pen tablet just appeared.
This is prior art, not a fresh discovery
The closest predecessor is Evidlo's remarkable_mouse: a reMarkable-as-graphics-tablet tool with SSH, orientation and monitor mapping, and an --evdev path for Linux pressure. Its Paper Pro issue is where the important failure mode is laid bare: the old decoder sees varying garbage event codes on the new device. This project takes its Paper Pro device-node and axis starting points from that work, then makes the 16-byte versus 24-byte event-layout split an explicit code boundary.
The idea also has older branches. rmWacomToMouse reads Wacom input on the tablet and forwards it to a PC client; its README credits remarkable_mouse and says the input codes came from libremarkable. rmTabletDriver, and its FreeCap23 fork, cover the Linux userspace-tablet direction. The Linux output code credits that work for the axis-resolution detail that lets libinput recognise a virtual device as a tablet.
So the useful claim is narrower: this is a separate .NET implementation that combines that lineage with native Windows Ink injection, Linux uinput, touch injection, reconnection cleanup, and an explicitly provisional Paper Pro profile. The source links are here because they explain where the constraints and device facts came from, not as decorative acknowledgements at the end.
The repository starts from a deliberately narrow boundary: install nothing on the tablet. Its Linux input devices already expose pen and touch events. The host opens them over SSH, interprets the byte stream, then creates the native input device that its own applications expect.
That is visible in the output implementations: WindowsInkOutput creates a synthetic pen device and sends pointer frames, while UinputOutput declares an absolute-input device and writes Linux input events. USB and Wi-Fi are only transports for SSH; the compatibility layer lives on the host.
Read the device, do not describe a gesture
The rM2 pen digitiser is an ordinary Linux input device at /dev/input/event1; the optional touchscreen is another stream at /dev/input/event2. SshTransport opens cat <devicePath> channels under one SSH client. EvdevParser reads fixed-size records from a PipeReader, then the state machines and coordinate mappers turn them into pen or touch frames.
That is more useful than translating pen motion into an application protocol. A drawing application can keep using its normal tablet path: pressure, tilt, hover, eraser state, absolute position. On Windows the output is a synthetic pen pointer. On Linux it is a direct-input virtual device. Neither side needs a plugin for a particular paint program.
Mouse emulation still exists as a Windows fallback, but it is not the interesting mode. A cursor can move. It cannot preserve the reason someone picked up a pen tablet in the first place.
The byte layout is part of the device profile
There is a trap hiding beneath the pleasant story about SSH. The stream is not a portable packet format. It is the kernel's struct input_event, and its layout depends on the tablet's userspace ABI. The reMarkable 2 is 32-bit ARM, so records are 16 bytes. The Paper Pro is 64-bit ARM, so records are 24 bytes.
Treating them as the same would not produce a slightly wrong line. It would desynchronise the parser and turn every later record into nonsense. The shared parser accepts an EvdevLayout rather than assuming one record size, and device detection probes uname -m before the streaming pipeline begins.
The Paper Pro profile makes the boundary explicit: it selects the 64-bit layout and event2/event3, while marking unverified tilt, hover, touch-axis, and palm-rejection assumptions as TODO(rmpp-phase0). The rM2 profile is based on observed hardware. Paper Pro support is experimental because it should be.
A dropped SSH session must release the pen
Input streaming fails in a particularly ugly way when cleanup is treated as an afterthought. If an SSH channel vanishes while a pen is down, a drawing app can keep a virtual stroke open. Touch contacts can get stuck too. Reconnecting successfully is not enough if the host is left believing a finger is still on the glass.
The transport owns one SSH client and one stream per device. On a reconnect it disposes the SSH commands first, waits briefly for each pump to stop, then disconnects the client. That ordering matters: a blocked read belongs to the command stream, not merely the client. TabletPipeline emits a pen-up and releases every synthetic touch contact before retrying, with delays that back off from one second to a capped thirty seconds.
Touch is not a magic modifier
The rM2 can expose two-finger touch as native touch contacts, which lets applications perform their own pinch, pan, or rotation handling. It does not mean that drawing and pinching can happen together. On the tested rM2 hardware, the firmware suppresses touch while the pen is in proximity.
The tool does not paper over that constraint with a fake combined gesture. The actual workflow is lift the pen, gesture, then resume. It is less magical in a README and much less surprising at the desk.
What I would test next
Paper Pro hardware is the obvious gap: record real pen and touch ranges, confirm proximity behaviour, and compare them with the separate profile. I would also exercise reconnects while a stroke and a multi-touch gesture are active, across USB and Wi-Fi, then inspect the target application rather than only the virtual device. Input stacks are excellent at looking correct one layer too early.
The source, releases, device notes, and diagnostics tools are in the repository. It is a small project with a refreshingly unambitious premise: the tablet already knows how to report input; the host just needs to hear it without lying about what it received.