Summary
XTEINK_X4_PRO's viewableInsets in BoardConfig.h ({top:9, right:7, bottom:3, left:7}) appear to significantly overestimate the X4 Pro's real bezel overlap. A rough on-device photo measurement suggests the true overlap is close to 0px on all four edges, not up to 9px.
Background
Investigating crosspoint-reader#3017 (progress bar thickness setting ignored in landscape), the root cause traced back to getOrientedViewableTRBL() rotating viewableInsets per reading orientation. In landscape, the logical "bottom" margin becomes the physical right inset (7px), while portrait correctly uses the physical bottom inset (3px). Consumers that extend UI elements to the true screen edge by this margin (e.g. crosspoint-reader's status-bar progress bar) end up with an orientation-dependent visual thickness as a side effect.
The code comment on the X4 Pro's insets already flags this as untrusted data:
"7px is the empirically-tuned side inset that keeps an edge-hugging scroll indicator visible (was the firmware's hardcoded X4 Pro scrollbar inset); top/bottom keep the X4 historical values pending measurement."
i.e. right/left (7) were tuned for scrollbar visibility, not measured as real bezel overlap, and top/bottom are inherited from the base X4 (a different panel/enclosure) rather than measured on the X4 Pro itself.
What I measured
Built a throwaway diagnostic firmware (boots straight into a full-screen pixel ruler drawn in the native Portrait frame — the frame viewableInsets is documented as being measured in) and photographed the result on a physical X4 Pro, zoomed into each edge.
At every edge (top, right, bottom, left), the tick marks and border outline are visible with no perceptible gap before the physical bezel begins — inconsistent with anywhere near 9px/7px/3px/7px of real overlap. At the zoom level used, even a 3-4px gap would have been clearly visible as blank white space between the last tick and the bezel; none was seen.
I can share the photos/crops if useful, though the measurement precision from a phone photo is probably only good to ±1-2px — good enough to say "the current values are much too large," not precise enough to hand you exact replacement numbers.
Suggested next step
Someone with the physical hardware (and ideally calipers, or a more controlled macro shot with a ruler in frame) re-measures the X4 Pro's actual bezel overlap on all four edges and updates XTEINK_X4_PRO.viewableInsets accordingly. Given the scrollbar-visibility need that originally drove the right/left value, it might be worth splitting "bezel overlap" and "scrollbar clearance" into separate fields if they're expected to differ, rather than reusing one struct for both purposes.
Happy to help re-test once new values are proposed — I've got the diagnostic ruler firmware already built for this device.
Summary
XTEINK_X4_PRO'sviewableInsetsinBoardConfig.h({top:9, right:7, bottom:3, left:7}) appear to significantly overestimate the X4 Pro's real bezel overlap. A rough on-device photo measurement suggests the true overlap is close to 0px on all four edges, not up to 9px.Background
Investigating crosspoint-reader#3017 (progress bar thickness setting ignored in landscape), the root cause traced back to
getOrientedViewableTRBL()rotatingviewableInsetsper reading orientation. In landscape, the logical "bottom" margin becomes the physical right inset (7px), while portrait correctly uses the physical bottom inset (3px). Consumers that extend UI elements to the true screen edge by this margin (e.g. crosspoint-reader's status-bar progress bar) end up with an orientation-dependent visual thickness as a side effect.The code comment on the X4 Pro's insets already flags this as untrusted data:
i.e.
right/left(7) were tuned for scrollbar visibility, not measured as real bezel overlap, andtop/bottomare inherited from the base X4 (a different panel/enclosure) rather than measured on the X4 Pro itself.What I measured
Built a throwaway diagnostic firmware (boots straight into a full-screen pixel ruler drawn in the native Portrait frame — the frame
viewableInsetsis documented as being measured in) and photographed the result on a physical X4 Pro, zoomed into each edge.At every edge (top, right, bottom, left), the tick marks and border outline are visible with no perceptible gap before the physical bezel begins — inconsistent with anywhere near 9px/7px/3px/7px of real overlap. At the zoom level used, even a 3-4px gap would have been clearly visible as blank white space between the last tick and the bezel; none was seen.
I can share the photos/crops if useful, though the measurement precision from a phone photo is probably only good to ±1-2px — good enough to say "the current values are much too large," not precise enough to hand you exact replacement numbers.
Suggested next step
Someone with the physical hardware (and ideally calipers, or a more controlled macro shot with a ruler in frame) re-measures the X4 Pro's actual bezel overlap on all four edges and updates
XTEINK_X4_PRO.viewableInsetsaccordingly. Given the scrollbar-visibility need that originally drove theright/leftvalue, it might be worth splitting "bezel overlap" and "scrollbar clearance" into separate fields if they're expected to differ, rather than reusing one struct for both purposes.Happy to help re-test once new values are proposed — I've got the diagnostic ruler firmware already built for this device.