Fix initial rendering and mouse scaling #140
Conversation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
3 issues found across 2 files
Prompt for AI agents (all 3 issues)
Understand the root cause of the following 3 issues and fix them.
<file name="backend/linux_input.c">
<violation number="1" location="backend/linux_input.c:88">
This hard-codes the absolute-axis range to 32767, so devices with different ABS_X maxima end up with wildly mis-scaled coordinates (e.g., 0–4095 devices only move the cursor across ~12% of the screen). Please scale using the device’s actual ABS info instead of a fixed constant.</violation>
<violation number="2" location="backend/linux_input.c:96">
Scaling ABS_Y by a hard-coded 32767 fails on devices whose reported ABS_Y range is smaller or larger, causing the cursor to stick to the top/bottom of the screen. Please derive the scale factor from the device’s actual ABS info.</violation>
</file>
<file name="backend/fbdev.c">
<violation number="1" location="backend/fbdev.c:208">
Using a static first_run flag here makes the initial damage run only once per process; if the fbdev backend is torn down and reinitialized, the new screen never gets its startup damage and renders blank until user input. Please store this flag in the per-context state instead of a function-static boolean.</violation>
</file>
React with 👍 or 👎 to teach cubic. Mention @cubic-dev-ai to give feedback, ask questions, or re-run the review.
This replaces hard-coded 32767 with device-specific absolute axis ranges queried via EVIOCGABS ioctl. This fixes coordinate scaling for devices with different ABS_X/ABS_Y maxima. It moves first_run flag to twin_fbdev_t structure to support proper reinitialization when backend is torn down and recreated, preventing blank screens on subsequent initializations. Close #62
|
Next weekend, I will verify the latest patch on the Raspberry Pi to ensure that its behavior meets expectations. |
|
The following shows the verification result of the Framebuffer backend on the Raspberry Pi 3. After applying commit 58b8504, the cursor behavior is consistent with that on origin/main. origin/main origin.main.mp458b8504.mp4The virtual machine installation had repeatedly failed before, and I currently don’t have a VM environment available for verification. |
This commit addresses critical issues in absolute coordinate handling and adds smoothing support for touch/stylus input devices. Critical fixes: - Fix ABS scaling to properly handle non-zero minimum values (e.g., stylus devices with range [-2048, 2047]) - Use correct formula: scaled = ((value - min) * (size - 1)) / (max - min) - Fix fd check to accept valid fd=0 (changed from fd > 0 to fd >= 0) - Add range validation to prevent division by zero Input smoothing enhancements: - Add configurable weighted moving average smoothing - Default weight of 3 provides ~50% jitter reduction - Can be disabled at compile time (weight=0) or overridden via CFLAGS - Uses 64-bit intermediates to prevent integer overflow
|
@huaxinliao, Recent change ("Fix ABS coordinate scaling and add input smoothing" addresses critical issues in absolute coordinate handling and adds smoothing support for touch/stylus input devices. Please validate in Raspberry Pi or similar environments. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Touchscreens with smaller ABS ranges (e.g., 0-4095) were ignored due to code only updated when device range exceeded the default 32767 range. This fix ensures devices with smaller ranges like [0, 4095] are properly recognized and used for coordinate scaling, instead of being stuck with the default [0, 32767] range that causes coordinates to collapse near the origin.
The patch “Fix ABS coordinate scaling and add input smoothing” should also account for device reconnections, as smoothing isn’t reinitialized after a hotplug. |
Previously, smoothing state persisted across device hotplug events, causing coordinate jumps when devices were reconnected. Changes: - Track device list changes (additions or removals) - Reset smooth_initialized flag when device list changes - Prevents coordinate jumps from stale smoothing state
See if "Reset input smoothing on device hotplug" works for you. |
Thanks. |
|
This patch primarily verifies whether cursor jitter has been reduced. 6f611f5.mp4This patch primarily verifies whether the behavior remains consistent before and after the hotplug process. 721bb44.mp4 |
|
Thank @huaxinliao for validations. |
This commit adds first-run damage marking to ensure screen content is rendered on startup instead of remaining blank until user interaction. For mouse coordinate scaling, this scales EV_ABS coordinates from the device range (0-32767) to actual screen resolution for correct cursor positioning in touchscreen environments.
Close #62
Summary by cubic
Fix blank initial screen by marking full-screen damage on first run, and scale EV_ABS touch/mouse coordinates to the display resolution for accurate cursor placement.