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
- Ngôn ngữ chính
- Rust
- Star
- 27.2k
- Fork
- 1.3k
- Merge trung bình
- 20 giờ 5 phút
- Pull request đã merge (30 ngày)
- 57
Mô tả
### 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.
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Hướng nghiên cứu
Bắt đầu bằng cách tái hiện vấn đề với Graphite desktop Flatpak và so sánh việc xử lý đầu vào dựa trên CEF cho các sự kiện tablet ở chế độ tuyệt đối và tương đối, sử dụng các chi tiết điều tra và #2535 làm ngữ cảnh. Chỉ kiểm tra preferences.ron khi cần thiết để giữ disable_ui_acceleration tách biệt khỏi bug này; được xem là hoàn tất khi các sự kiện ButtonPress và ButtonRelease của bút ở chế độ tuyệt đối hoạt động trong UI và viewport mà không gây hồi quy cho đầu vào chuột hoặc đầu vào ở chế độ tương đối.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- linux, rust
- Lĩnh vực
- desktop
- Loại issue
- Lỗi
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức độ hoạt động
- Ít trao đổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 52/100