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

Offen
  • Stimmt etwas nicht?
#4,384 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
52/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
linux, rust
Bereich
desktop

Rechercherichtung

Beginne damit, das Problem mit dem Graphite desktop Flatpak nachzustellen und die CEF-basierte Eingabeverarbeitung für Tablet-Ereignisse im absoluten und relativen Modus zu vergleichen, wobei die Untersuchungsdetails und #2535 als Kontext dienen. Untersuche preferences.ron nur bei Bedarf, um disable_ui_acceleration von diesem Bug getrennt zu halten; als erledigt gilt die Aufgabe, wenn absolute-mode pen ButtonPress- und ButtonRelease-Ereignisse in der UI und im Viewport funktionieren, ohne Maus- oder relative-mode-Eingaben zu beeinträchtigen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
Rust
Sterne
27.8k
Forks
1.3k
Ø Merge
10 Std. 53 Min.
Gemergte PRs (30 T.)
195

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus GraphiteEditor/Graphite

Alle Issues in GraphiteEditor/Graphite

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.