GraphiteEditor / GraphiteEditor/Graphite

Stylus/tablet click (ButtonPress) not registering in desktop (CEF) build when device uses absolute positioning — works in Relative mode, in browser, and with physical mouse

Abierto
#4,384 1 comentario 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Rust
Estrellas
27.2k
Forks
1.3k
Merge medio
20 h 5 min
PR fusionados (30 d)
57

Descripción

### Describe the Bug
On Linux (Flatpak build), a graphics tablet's pen click does not register in the desktop app's CEF-rendered UI or viewport when OpenTabletDriver is configured in **Absolute** mode (normal tablet-to-screen 1:1 mapping), even though:
- The exact same tablet/pen works correctly in the web version at https://editor.graphite.art/ (in Chromium), also in Absolute mode
- A physical USB mouse clicks normally in the desktop app
- `xdotool click 1` (synthetic XTEST click) also fails to register in the desktop app
- **Switching OpenTabletDriver to Relative mode makes clicking work correctly in the desktop app** — this isolates the bug to something specific about how absolute-positioning tablet devices are handled, since relative mode is otherwise unusable for real drawing (no 1:1 tablet-to-screen mapping)

Cursor **motion** from the tablet works perfectly in Absolute mode in the desktop app — only button press/release events fail to have any effect while in that mode.

### Environment
- OS: Void Linux, X11 (picom compositor, XFCE)
- Graphite: desktop Flatpak build (`art.graphite.Graphite`), downloaded ~July 2026
- Tablet driver: OpenTabletDriver 0.6.7 (Flatpak)
- Tablet: Huion H1161
- GPU: AMD (RADV/Mesa)

### Steps To Reproduce
1. Install OpenTabletDriver via Flatpak, configure tablet in **Absolute mode** ("Artist Mode" preset) with tip bound to Mouse Button: Left
2. Install Graphite via Flatpak
3. Launch Graphite desktop app
4. Attempt to click/draw with the stylus tip on the canvas or any UI button
5. Motion works; the click has no effect
6. Switch OpenTabletDriver to **Relative mode**, click Apply, retest — clicking now works correctly

### Investigation so far
- `xinput test-xi2` confirms the pen's `ButtonPress`/`ButtonRelease` arrive as genuine X11 core-protocol events from the same device (`OpenTabletDriver Virtual Tablet`, XI2 id 19) that generates the working motion events — not routed through the XTEST virtual pointer (id 4)
- `udevadm info` confirms the OTD virtual device is tagged `ID_INPUT_MOUSE=1`
- `libinput list-devices` shows the OTD virtual device's `Capabilities: pointer`, but its `DeviceChanged` XI2 announcement in Absolute mode includes **absolute X/Y valuators plus an XIScrollClass** (relative horizontal/vertical scroll valuators) — attributes a plain mouse does not have
- A real physical USB mouse (no absolute valuators, no scroll-class) clicks Graphite's UI/canvas without any issue in either mode
- `xdotool click 1` (XTEST-injected click) also fails silently in the desktop app while in Absolute mode
- **Confirmed:** switching the same physical tablet/driver to Relative mode (removing absolute valuators from the device's XI2 announcement) makes clicks work correctly again

This strongly suggests Graphite's CEF-embedded input handling (see #2535, the CEF-based desktop architecture) filters or mis-routes button events specifically from devices that report absolute positioning valuators, rather than a general click-handling bug — since motion, physical mouse clicks, and relative-mode tablet clicks all work fine, and only absolute-mode tablet clicks fail.

### Additional Details
- Toggling **Preferences → Render GUI on CPU** (`disable_ui_acceleration` in `preferences.ron`) fixed an unrelated issue where the GUI failed to render at all, but did not affect this click bug.
- Happy to provide further logs/testing (e.g. `libinput debug-events`, CEF verbose logging flags) if useful for triage.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Línea de trabajo

Start by reproducing the issue with the Graphite desktop Flatpak and compare CEF-based input handling for absolute- and relative-mode tablet events, using the investigation details and #2535 as context. Inspect preferences.ron only as needed to keep disable_ui_acceleration separate from this bug; done means absolute-mode pen ButtonPress and ButtonRelease events work in the UI and viewport without regressing mouse or relative-mode input.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
linux, rust
Área
desktop
Tipo de issue
Error
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Tranquilo
Claridad
Bastante claro
Aptitud para principiantes
52/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.