Working area of Huion driver software in Linux not working
On Kubuntu 25.04, using wayland; tablet area does not detect my screen resolution properly, resulting in the driver app thinking my screen is a 1 by 1 pixel. screenshot shows the huion app not detecting the screen resolution of my screen
(34.9 KB)
Hi, Elephantropy. Thank you for sharing your experience with your Kamvas 13 without our driver. I have forwarded your experience to our engineers for further review.
Best Regards,
HUION Customer Support
> fresh Arch (Manjaro) with Gnome my Huion 13 works well without installing Huion software through generic support of Wacom tablets
Official driver sends a message to the tablet which changes the message format the tablet sends. The fallback mode works ok if you don't mind rebinding default keys it sends, BUT the difference is that the fallback mode sends the same keys for both dials (at least in my testing) and the buttons on dials don't do anything. I don't see that official driver actually reconfigures which keys are sent by the tablet, so I'm assuming it's always the case that the fallback behavior doesn't allow separate bindings for dials. Custom protocol actually tells the official driver which dial is being turned.
Hi, Tin Švagelj. Thank you for sharing your observations. I have forwarded this to our software engineers.
Best Regards,
HUION Customer Support
The latest Ubuntu 26.04 with Gnome 50 has dropped support for X11 and moved entirely over to Wayland. Currently I am unable to upgrade to this version because I can't get any of my Huion devices working (Inspiroy Giano G930L, Kamvas Pro 24).
It seems like a lot of Linux distros are moving in this direction.
I look forward to Wayland support in the future.
Hi, Gregg Jansen van Vuren. Please try this driver version on Wayland: HuionTablet_LinuxDriver_v15.0.0.179.x86_64 (Linux Wayland). Please note of the following:
The driver already supports Wayland, but most Linux desktop environments still do not fully implement Wayland’s virtual mouse/keyboard protocols. Because of this, the pen can move the system cursor, but the Wayland compositor does not update the “real” mouse position. This causes a second cursor to appear whenever you use mouse‑related features (mouse mode, left/right click, middle click, double‑click, scroll wheel, etc.). (Reference: https://wayland.app/protocols/wlr-virtual-pointer-unstable-v1#compositor-support)
Solution:
To prevent the double‑cursor issue, all mouse‑related functions in the driver are temporarily disabled under Wayland.
Screen flashing when setting the work area
Different Linux distributions support Wayland features at different levels. Some systems cannot provide a live desktop preview, so the driver uses the system’s built‑in screenshot tool instead. When the screen changes, the work‑area preview may flash briefly, but this does not affect the actual work‑area settings or tablet performance.
The other issues (UI glitches after reboot, device not detected in the UI even though it’s connected, rotation settings not responding, etc.) are system‑side bugs that occur occasionally. They are usually fixed by closing and restarting the driver.
Feel free to share any feedback or observations after testing this driver version. Your input is extremely valuable and helps our engineering team continue improving Wayland compatibility and overall performance. We’re here to support you every step of the way.
Best Regards,
HUION Customer Support
1 person likes this
I appreciate that you’ve released a Wayland version of the driver and are continuing Linux support. However, several of the issues described appear to stem from implementation choices rather than limitations of Wayland itself.
Regarding the double-cursor behavior:
This is expected when using virtual pointer protocols. A graphics tablet is a physical input device, and modeling it as a virtual pointer prevents the compositor from handling it correctly. Wayland compositors intentionally treat virtual devices separately, which is why a second cursor appears.
It’s also important to clarify that the wlroots virtual pointer protocol is not a cross-desktop standard. It is specific to wlroots-based compositors, and there is no indication that major environments like GNOME or KDE intend to support it. Building on it therefore limits correct behavior to a subset of compositors and leads to inconsistent results by design.
In contrast, exposing the tablet via uinput as a real input device works across compositors today. This is the mechanism compositors expect and handle correctly. Using uinput allows the compositor to integrate the device natively, avoids the double-cursor issue, and provides consistent behavior across environments.
As it stands, relying on virtual pointer protocols constrains compositor behavior and leads to predictable inconsistencies, while attributing those inconsistencies to Wayland support.
Regarding screen capture and flashing:
Wayland does not allow unrestricted screenshots by design. This is a security property, not a missing feature. The intended mechanism is XDG desktop portals, which provide controlled, user-mediated access.
For a concrete example: without these restrictions, any application could take a screenshot of whatever is on your screen at any moment—such as your online banking session or a private browser tab—without your knowledge. Wayland prevents this by requiring explicit user consent through portals, and the visible feedback (such as flashing or prompts) is part of that guarantee.
The current approach of relying on system screenshot utilities is also problematic. It effectively introduces a dependency on whatever screenshot tool happens to be available in each environment. They are not guaranteed and vary widely across distributions and compositors. This creates fragmentation and forces you to account for multiple inconsistent implementations (are you really going to support all 25+ of them?). It also makes packaging more difficult, as the driver implicitly depends on external tools that are not standardized across systems.
Portals, on the other hand, provide a single, compositor-agnostic interface that is expected to be implemented across environments. They give you a raw texture, so you don't have to load various image formats (attack vector). Supporting portals means targeting one consistent API rather than many ad-hoc tools, and it aligns with the platform’s security model. Only when using that interface does it become reasonable to attribute limitations or UX issues to Wayland itself. Bypassing it shifts responsibility back onto your driver. Development of Wayland is done in the open, doing so makes you seem disingenuous. I get corporate policy, but saving face doesn't work well in FOSS space, and your Linux consumer base prefers transparency. A simple "sorry guys, Wayland is annoying and we need to do a huge rewrite of almost everything, we're doing what we can" works well enough, stays honest, and makes you more credible.
Regarding general instability (UI glitches, device detection, rotation issues):
These symptoms are consistent with a tightly coupled application where device handling, UI, and control logic are bundled together. Separating these concerns would make behavior more predictable and simplify recovery when individual components fail. "Do one thing and do it well" approach is what allows 30 year old applications to still be used on Linux and to be as stable as they are.
More broadly, the current design appears to replicate assumptions from X11 or Windows-style input handling. Wayland intentionally does not support that model, particularly around global input control and unrestricted system access. Attempting to emulate it leads to exactly the kinds of issues being reported. Aligning with Wayland’s design (real devices through uinput, privileged actions through portals, and compositor-managed behavior) would result in your driver being more stable and predictable.
Wayland does have gaps, and supporting it is not trivial (I genuinely appreciate your effort). However, the problems outlined here are largely a consequence of working against its design rather than with it. Addressing that would likely yield better results than continuing to work around compositor behavior.
I tried the new driver with the latest Ubuntu 26 today. Unfortunately it still feels buggy or not really usable. These are my findings:
Huion Tablet Software - I first need to click with the mouse inside the pressure test area, after that the stylus has focus and registers pressure info. But it stops working after a few strokes and I need to again click with mouse first to make it work.
Krita - click with mouse on the canvas drawing area and afterwards I can draw but it is not always working and sometimes requires multiple retries of mouse clicks before the stylus actually starts working, it is also very buggy and stops working after few strokes.
Gimp - this software is working reliably, I can use the stylus without needing any other interactions with the mouse. However my primary drawing application on Linux is Krita.
For now I will continue with my X11 setup and revisit this in the future.
Incidentally I discovered today that on Debian 13 using KDE Plasma or Gnome under a Wayland session I am able to use both my Huion devices (Kamvas Pro 24/Inspiroy Giano) with the OpenTabletDriver software with no problems at all.
Hi, Tin Švagelj and Gregg Jansen van Vuren. Thank you very much for taking the time to test the new Wayland driver and share your experiences. We truly appreciate your detailed feedback. We’ve forwarded all of your reports to our engineering team so they can continue improving Wayland support and overall driver stability.
Best Regards,
HUION Customer Support