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

Ouverte
  • Quelque chose ne va pas ?
#4,384 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
52/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Calme
Stack technique
linux, rust
Domaine
desktop

Piste de recherche

Commencez par reproduire le problème avec le Flatpak de bureau Graphite et comparez la gestion des entrées basée sur CEF pour les événements de tablette en mode absolu et relatif, en utilisant les détails de l’investigation et #2535 comme contexte. N’inspectez preferences.ron que si nécessaire afin de maintenir disable_ui_acceleration séparé de ce bug ; le travail est considéré comme terminé lorsque les événements ButtonPress et ButtonRelease du stylet en mode absolu fonctionnent dans l’UI et le viewport sans provoquer de régression pour les entrées de la souris ou du mode relatif.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Rust
Étoiles
27.8k
Forks
1.3k
Merge moyen
10 h 53 min
PR mergées (30 j)
195

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

  • Aucun Dockerfile ni fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de GraphiteEditor/Graphite

Toutes les issues de GraphiteEditor/Graphite

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.