# OpenTabletDriver: cross-platform tablet support without a kernel driver

> A .NET daemon and three native GUIs standing in for Wacom's driver stack, with per-platform pressure caveats, three separate build pipelines, and a device-support list kept outside the code.

**OpenTabletDriver/OpenTabletDriver** — Open source, cross-platform, user-mode tablet driver

- Repository: https://github.com/OpenTabletDriver/OpenTabletDriver
- Website: https://opentabletdriver.net/
- Stars: 4,199 · Forks: 557
- Language: C#
- License: LGPL-3.0
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/opentabletdriver-opentabletdriver

## Two processes, and only one of them is required

The architecture is stated in one paragraph of the README and it is worth reading carefully. The program doing the actual tablet data handling is `OpenTabletDriver.Daemon`. The graphical frontend is a separate process called `OpenTabletDriver.UX.*`, where the suffix depends on your platform: `Wpf` on Windows, `Gtk` on Linux, `MacOS` on macOS. The README then says the daemon must be running for anything to work, that the GUI is unnecessary, and that existing settings should apply when the daemon starts. A footnote adds that you can ignore the suffix distinction entirely unless you are building from source, because only the correct variant gets shipped.

That split turns a driver into something you can run headless, and the feature list treats it as a supported configuration rather than a workaround, listing a standalone daemon for low-spec or headless systems. The same list also advertises a fully fledged console tool for quickly acquiring, changing, loading, or saving settings, with scripting support through JSON output. If you are provisioning machines rather than tuning a tablet, those two features are the interface.

The repository tree shows how one solution serves three toolkits. Alongside `OpenTabletDriver.Daemon/` and the three `OpenTabletDriver.UX.*` projects there is an `OpenTabletDriver.Desktop/` directory and three solution filters, `OpenTabletDriver.Linux.slnf`, `OpenTabletDriver.MacOS.slnf`, and `OpenTabletDriver.Windows.slnf`, each narrowing the shared `OpenTabletDriver.sln` to the projects one platform needs. There is also `OpenTabletDriver.Tests/`, `OpenTabletDriver.Benchmarks/`, a `generate-rules.sh`, a `nuget.config`, and a `global.json` that pins the SDK.

## Pressure output is where the three platforms part ways

The README's feature list contains the most consequential paragraph in the repository, and it is easy to skim past because it is formatted as nested bullets under advanced tablet feature compatibility. Pressure output works differently on every operating system. On Windows it needs the Windows Ink OpenTabletDriver plugin for Windows Ink output mode, and it also needs the VMulti system driver. On Linux it is supported natively, through an output mode called Linux Artist Mode. On macOS it is supported natively in all output modes.

If your work depends on real pressure values rather than binary tip contact, that table is the deciding fact, and it should be read before anything else on the page. It also explains the odd behaviour people hit when moving a workflow between machines: pressure is fine on a Mac, unavailable without two extra pieces on Windows, and available on Linux only if you pick the right output mode.

The 0.6.7 release confirms that the special modes are treated as a separate category rather than a default. Mouse scroll bindings arrived in that release, but the notes scope them to mouse-based output modes, written as not Linux Artist Mode and not Windows Ink. Anything a plugin can do with a scroll wheel is therefore unavailable in precisely the two modes that give you proper pressure. Pen tilt, tablet pad wheels and dials, and auxiliary or Express Keys are listed without per-platform caveats, which is a fair signal that they behave the same everywhere.

## Three build pipelines that disagree on flag spelling

Building requires the .NET 10 SDK on every platform, and the README is explicit that Linux users should install it through a package manager where possible. Everything after that diverges fast.

On Windows, `build.sh windows` produces binaries into a `bin` folder and those builds run in portable mode by default. If you lack WSL or another bash with a working dotnet install, a deprecated `build.ps1` still exists, which is a fair signal about where the project's own support attention has gone.

Linux needs libx11, libxrandr, libevdev2, and GTK+3, and `eng/bash/package.sh` is the entry point. Five package formats are officially supported:

```bash
./eng/bash/package.sh --package BinaryTarBall
./eng/bash/package.sh --package Simple
./eng/bash/package.sh --package Debian
./eng/bash/package.sh --package RedHat
./eng/bash/package.sh --package Generic
```

Two caveats are stated plainly. The generic binary tarball is designed to be extracted from the root directory, and the simple package should only be used for testing new features on existing installs because it does not install necessary system files. Separately, `./build.sh linux` writes files into `bin/` but does not include system files, so it is a development shortcut rather than a distribution.

macOS needs a newer bash and Coreutils, installable through Homebrew, and the arm64 package must be signed as of macOS 11. Signing a macOS build from Linux or Windows additionally requires `rcodesign`.

```bash
./eng/bash/package.sh --signed true --runtime osx-arm64 --package macos
```

One inconsistency is worth knowing before you run anything. The prose introduction to the macOS section uses a short flag, `-r osx-x64`, while the table of macOS formats uses the long form `--runtime osx-x64`. There is also no unsigned arm64 row in that table, which lines up with the macOS 11 signing requirement rather than contradicting it. Copy the table form rather than the prose form, since the table is what the three documented package commands share.

## v0.6.7 is the feature release, 0.6.6.x was the parser cleanup

The release history is short, three entries, and the shape of it explains how the project actually gets its hard problems solved. v0.6.7, published 2026-04-25, came after what the notes call over a half of year of development, with over 300 issues and pull requests targeted, and the notes go so far as to call it the biggest single milestone, surpassing even v0.6.0. Much of it was code quality and maintainability, and the headline feature is wheel support, from issue 3497 by Mrcubix and joha4270, extended by multi-wheel support in issue 4483 by gonX. The wheel work was a backport: Mrcubix completed an effort by joha4270 from issue 2669 on the 0.6.x branch, which is also the repository's default branch.

The two releases before it are a different kind of document, and they are more useful for judging the project than the feature release is. v0.6.6.1, from 2025-10-11, fixes underflowing pressure on some XP-Pen tablet variants and attributes the cause to an incorrect assumption in the parser. It fixes inconsistent eraser handling because some tablets, mostly Wacom, send tool state as an initial report instead of sending eraser state continuously. It fixes macOS relative mode on multi-monitor displays, described as a bug that seems to have been present since OpenTabletDriver v0.6.1. It makes Linux tool states properly unique per `SYN_REPORT`, and it restores tilt on a long list of large UC-Logic based tablets including the Artisul D16 Pro, several Gaomon models such as the GM116HD and PD2200, and Huion tablets such as the Kamvas 16 and G930L.

v0.6.6.2, from 2025-10-17, defaults processes to an empty array instead of leaving them unassigned in driver detection, which fixes a crash when exporting diagnostics with a vendor driver loaded on Linux, a regression from issue 4188. It also fixes modifier key bindings with mouse events on macOS, where modifier keys were not passing through properly, and pen button bindings that stayed stuck if the pen was removed from the tablet while holding those buttons.

Read as a set, these entries are a list of device-level misunderstandings, each naming a vendor family. That is the honest picture of what this project does: the tablet protocol layer is the hard part, and the fixes arrive one model at a time.

## Supported tablets are tracked outside the code, in two places

There is no compatibility table in the README. It links to a page on the project website for the status of all supported tablets, and points installation and troubleshooting at three wiki pages, one per platform. If you arrive from a search result asking why a tablet is not detected, that page is the first stop.

There is a second source inside the repository, and the two are not redundant. The v0.6.7 notes tell you to consult the `TABLETS.md` file for that release to determine whether your tablet is fully supported yet, and they link it at a specific commit rather than at the branch tip. That is a deliberate difference: the file at a pinned commit describes what shipped in that version, while the live website page describes current status across the moving `0.6.x` branch. When a device works on the website but not with your installed build, the pinned file is the one that explains it.

The repository also carries translations, which is unusual for driver software and suggests a user base spread across more than English-speaking markets. The README offers Korean, Spanish, Russian, Simplified Chinese, French, and German versions under `docs/`.

One number is worth setting expectations. The repository shows 4,112 stars, 535 forks, and 484 open issues. A queue that size is normal for hardware support work where each model needs its own investigation, but it means you should search the tracker before filing. The README's contributing section points at the issue tracker first for exactly that reason.

## Positioning, bindings, and the settings that persist

The mapping model is complete enough that migrating from a vendor driver is mostly a matter of re-entering numbers. Absolute cursor positioning covers the screen area and tablet area separately, center-anchored offsets, and precise area rotation. Relative cursor positioning offers per-millimetre horizontal and vertical sensitivity. Vendor driver area conversions are supported for Wacom, XP-Pen, Huion, Gaomon, and VEIKK, so an area copied from a vendor panel can be translated instead of guessed.

The binding surface is unusually wide: tip by pressure bindings, Express or Aux key bindings, pen button bindings, mouse button bindings, wheel bindings, keyboard bindings, preset bindings, and external plugin bindings. Settings persist between runs, and presets exist for quick access to prior saved configurations, which matters if you switch between a drawing setup and a desktop setup on the same tablet.

The extension story is a plugin manager that draws from a separate repository, the OpenTabletDriver Plugin-Repository, plus filters including asynchronous filters described as interpolators and additional output modes. For diagnosis there is a tablet data analyzer called the Tablet Debugger, which was reworked in issue 4434 in the v0.6.7 release, and USB Device String readings. When a tablet misbehaves, those two tools are what the project gives you to work with instead of a log window.

Automatic version update notification is on by default and can be turned off with the `--skipupdate` command line flag, which is the setting to reach for on locked-down or offline machines. There is no in-README documentation for what the plugin repository contains or how plugins are signed, so if you plan to depend on one, budget time to read that repository separately.

## Conclusion

OpenTabletDriver is worth choosing when you have a tablet that works under a vendor driver and you want pressure, tilt, and express keys to survive a move to Linux or macOS, because the .NET 10 daemon plus the plugin pipeline is the whole product and it is genuinely portable. It is a poor fit if your application depends on Windows Ink, since pressure on Windows requires the Ink plugin and the VMulti driver. Start at the Tablets page on opentabletdriver.net to confirm your model, then read TABLETS.md in the repository, because the release notes point at that file rather than restating support. The default branch is 0.6.x and the newest release is v0.6.7 from 2026-04-25, with the last push on 2026-09-18, so the daemon is still moving.

## FAQ

### How do I install the OpenTabletDriver driver on Windows?

The README does not carry the steps itself and sends Windows users to the installation page on opentabletdriver.net, alongside separate Linux and macOS pages. For source builds the documented route is the .NET 10 SDK plus `build.sh windows`, which produces portable-mode binaries into a `bin` folder.

### Is OpenTabletDriver.net safe?

opentabletdriver.net is the homepage recorded in the repository and the target of its installation and troubleshooting links, while builds are published as GitHub releases with a total download count badge in the README. Downloading a build from a third-party mirror is not something the project documents or endorses.

### Why is OpenTabletDriver not detecting my tablet?

Check the supported tablets status page first, since the README keeps no compatibility table of its own, and confirm the `OpenTabletDriver.Daemon` process is running, since nothing works without it. The Tablet Debugger and the USB Device String readings exist to narrow down whether the tablet is arriving on the bus at all.

### Why is my cursor teleporting in OpenTabletDriver?

Multi-monitor setups on macOS hit a known relative mode bug that the release notes say was present since v0.6.1 and was fixed in v0.6.6.1. Moving to that version or newer, and re-checking whether you are in relative or absolute positioning mode, addresses the common case.

## Sources

- [License: LGPL-3.0](https://github.com/OpenTabletDriver/OpenTabletDriver/blob/0.6.x/LICENSE)
- [OpenTabletDriver/OpenTabletDriver on GitHub](https://github.com/OpenTabletDriver/OpenTabletDriver)
- [Project website](https://opentabletdriver.net/)
- [README](https://github.com/OpenTabletDriver/OpenTabletDriver/blob/0.6.x/README.md)
- [Releases](https://github.com/OpenTabletDriver/OpenTabletDriver/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opentabletdriver-opentabletdriver