fix: use runtime screen dimensions for Paper Pro Move (960×1696) compatibility#22
Open
mouse76229 wants to merge 4 commits into
Open
fix: use runtime screen dimensions for Paper Pro Move (960×1696) compatibility#22mouse76229 wants to merge 4 commits into
mouse76229 wants to merge 4 commits into
Conversation
The reMarkable Paper Pro Move (imx93-chiappa) reports a quill framebuffer of 960×1696, not 1620×2160. The previous hardcoded SCREEN_W/SCREEN_H constants caused content to be clipped on that device. Remove the constants from fb.rs and instead read surf.w/surf.h at runtime after Display::open(). Propagate sw/sh through plan_reply(), append_reply(), conjure(), help::show(), help::show_sleep(), help::restore_sleep(), and PenDevice (for digitizer-to-screen mapping). This makes riddle work correctly on any screen size reported by the vendor quill engine, including future reMarkable hardware revisions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
PenDevice::open() needs sw/sh, which must be defined before pen_dev is opened, not after. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
mouse76229
changed the title
The ABS_X/ABS_Y max values differ between devices: - Paper Pro: DIGI_MAX_X=11180, DIGI_MAX_Y=15340 - Paper Pro Move: DIGI_MAX_X=6760, DIGI_MAX_Y=11960 Hardcoding the Paper Pro values caused pen coordinates to map to only ~60% of the screen on the Paper Pro Move, making ink appear in the wrong position relative to the actual pen tip. Fix: call EVIOCGABS on open to read the real axis limits from the kernel driver, falling back to the Paper Pro values if the ioctl fails. The actual ranges are logged on startup for verification. Verified on Paper Pro Move: riddle: pen device /dev/input/event2 opened (grabbed: true, digi 6760x11960) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Caveat is more legible than Dancing Script while retaining a natural handwriting feel. DancingScript.ttf kept in fonts/ for easy rollback via v-dancing-script-restore tag. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On the reMarkable Paper Pro Move (imx93-chiappa, i.MX93 SoC), riddle had two bugs caused by hardcoded constants:
1. Screen dimensions (1620×2160 hardcoded)
The quill framebuffer on Paper Pro Move reports 960×1696 pixels. The hardcoded `SCREEN_W`/`SCREEN_H` caused content to be clipped and the thinking blot to appear off-screen.
2. Digitizer axis ranges (11180×15340 hardcoded)
The pen digitizer axis limits differ between devices:
With Paper Pro values hardcoded, pen coordinates on the Paper Pro Move mapped to only ~60% of the screen — ink appeared far from the actual pen tip.
Solution
Screen dimensions: Remove `SCREEN_W`/`SCREEN_H` constants from `fb.rs`. Read `surf.w`/`surf.h` at runtime after `Display::open()` and propagate through:
Digitizer ranges: Read `ABS_X`/`ABS_Y` max values at runtime via `EVIOCGABS` ioctl in `PenDevice::open()`, falling back to Paper Pro values if the ioctl fails.
Testing
Tested on a reMarkable Paper Pro Move (OS 3.27.3.0). Startup log confirms both fixes: