[GH-ISSUE #437] Pen/tablet (stylus) input not delivered to apps inside Wolf containers #274

New issue

Open

opened 2026-10-15 12:59:10 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:59:10 +00:00

Owner

Originally created by @jebbster88 on GitHub (Jun 20, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/437

Summary

Stylus/pen input from a tablet (e.g. Samsung S-Pen, drawing tablet) reaches the host but never makes it into the application running inside a Wolf container. Mouse, keyboard, and gamepad input work. The virtual pen device is created and mounted correctly inside the container — the events just don't arrive at the app. Reproduced independently by at least two users.

Environment

Wolf (streaming via Moonlight)
Apps tested: XFCE + Krita, Steam container, Wolf-UI
Pen hardware: drawing tablet / Samsung S-Pen over Moonlight

Steps to reproduce

Connect to a Wolf session over Moonlight.
Launch an app that accepts pen input (e.g. XFCE + Krita).
Use the stylus on the tablet.

Observed behavior

The app ignores the pen entirely.
/dev/input/ inside the container is sparse compared to the host, and (in one report) doesn't even exist until a gamepad is used, after which it appears with only event27 and js0.
Without a udev rule like SUBSYSTEMS=="input", ATTRS{name}=="Wolf (virtual) pen tablet", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9", using the pen moves the mouse on the host desktop instead.
With or without that udev rule, no pen input reaches wolf-ui or the Steam container.
The pen device node only appears once Moonlight connects (e.g. /dev/input/event29).

Expected behavior

Pen/stylus events should be delivered to the application inside the container.

Logs

With WOLF_LOG_LEVEL=DEBUG, the following is logged the moment the stylus touches the tablet (present with or without the udev rule), showing the device being created and the node being made:

DEBUG | [INPUT] Creating new pen tablet
DEBUG | received hot-plug device event
DEBUG | [DOCKER] Plugging device from queue in session: <id>
DEBUG | [DOCKER] Writing hwdb file: /etc/wolf/<id>/Wolf UI/udev/data/c13:93
DEBUG | [DOCKER] Executing command: mkdir -p /dev/input && mknod /dev/input/event29 c 13 93 && chmod 777 /dev/input/event29 && fake-udev -m <...>

So device creation/mounting appears to succeed; the failure is downstream.

Suspected root cause (assessment, not confirmed)

⚠️ This is a working hypothesis, not a verified diagnosis.

The pen device is created and mounted correctly, but gst-wayland-display only implements mouse/keyboard/touch. wayland-info in wolf-ui shows no zwp_tablet_manager_v2, so pen events have no path into the compositor regardless of the udev/seat setup. Adding support would require implementing the tablet protocol in the compositor (Smithay has the primitives) plus a pen event type on the Wolf side.

Originally created by @jebbster88 on GitHub (Jun 20, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/437 ## Summary Stylus/pen input from a tablet (e.g. Samsung S-Pen, drawing tablet) reaches the host but never makes it into the application running inside a Wolf container. Mouse, keyboard, and gamepad input work. The virtual pen device *is* created and mounted correctly inside the container — the events just don't arrive at the app. Reproduced independently by at least two users. ## Environment - Wolf (streaming via Moonlight) - Apps tested: XFCE + Krita, Steam container, Wolf-UI - Pen hardware: drawing tablet / Samsung S-Pen over Moonlight ## Steps to reproduce 1. Connect to a Wolf session over Moonlight. 2. Launch an app that accepts pen input (e.g. XFCE + Krita). 3. Use the stylus on the tablet. ## Observed behavior - The app ignores the pen entirely. - `/dev/input/` inside the container is sparse compared to the host, and (in one report) doesn't even exist until a gamepad is used, after which it appears with only `event27` and `js0`. - Without a udev rule like `SUBSYSTEMS=="input", ATTRS{name}=="Wolf (virtual) pen tablet", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"`, using the pen moves the mouse on the **host** desktop instead. - **With or without** that udev rule, no pen input reaches wolf-ui or the Steam container. - The pen device node only appears once Moonlight connects (e.g. `/dev/input/event29`). ## Expected behavior Pen/stylus events should be delivered to the application inside the container. ## Logs With `WOLF_LOG_LEVEL=DEBUG`, the following is logged the moment the stylus touches the tablet (present with or without the udev rule), showing the device being created and the node being made: ``` DEBUG | [INPUT] Creating new pen tablet DEBUG | received hot-plug device event DEBUG | [DOCKER] Plugging device from queue in session: <id> DEBUG | [DOCKER] Writing hwdb file: /etc/wolf/<id>/Wolf UI/udev/data/c13:93 DEBUG | [DOCKER] Executing command: mkdir -p /dev/input && mknod /dev/input/event29 c 13 93 && chmod 777 /dev/input/event29 && fake-udev -m <...> ``` So device creation/mounting appears to succeed; the failure is downstream. ## Suspected root cause (assessment, not confirmed) > ⚠️ *This is a working hypothesis, not a verified diagnosis.* The pen device is created and mounted correctly, but `gst-wayland-display` only implements mouse/keyboard/touch. `wayland-info` in wolf-ui shows **no `zwp_tablet_manager_v2`**, so pen events have no path into the compositor regardless of the udev/seat setup. Adding support would require implementing the tablet protocol in the compositor (Smithay has the primitives) plus a pen event type on the Wolf side.