Repository navigation
fix(mirror): forward taps to MUI devices without a touch panel - #7880
Merged
Merged
Conversation
MUI routes mirrored taps to its own virtual pointer, so an RGB565 frame accepts taps whether or not the board reports `has_touch`.
Contributor
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Set touch capability for RGB565 frames feature/settings/src/commonMain/kotlin/org/meshtastic/feature/settings/debugging/DisplayMirror.kt |
MirrorWithControls receives hasTouch = true when the device reports touch support or the current frame format is RGB565. |
Merge Risk: 
e5fe2
-
No actionable merge-blocking risk was identified.
Pre-merge checks: 
-
Check name Status Explanation Resolution Regression Coverage For Changed Behavior Missing regression coverage for the changed Compose input gate. DisplayMirrorContentnow passeshasTouch = displayInfo?.has_touch == true || currentFrame.format == MirrorFormat.RGB565at `DisplayM…Add a Compose UI regression test for a connected RGB565 frame with DisplayInfo.has_touch == false. Perform a tap and assert oneINPUT_USER_PRESStouch event with the expected device coordinates; perform a long-press and assert `INPUT_SE…-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title names the main change: taps are forwarded to MUI devices that lack a touch panel. The raw summary confirms that RGB565 frames are now treated as touch-capable regardless of displayInfo.has_t… Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Sibling Call Sites And Presence Semantics PASS. The diff changes only the tap-capability condition in DisplayMirror.kt; it does not make a field nullable, remove a zero-guard, add a presence check, or add a numeric field defaulted to0. R…Tests Prove The Path, Not The End State The pull request changes only DisplayMirror.kt; it adds no tests and modifies no test files. Therefore, no added or changed test can violate this check.Moved Code Diffed Against Its Original PASS. The PR changes one existing file with 3 insertions and 1 deletion. It adds an import, a comment, and an additional condition in DisplayMirrorContent; it does not delete or relocate a type, fun…Full details: Title check
-
Explanation
The title names the main change: taps are forwarded to MUI devices that lack a touch panel. The raw summary confirms that RGB565 frames are now treated as touch-capable regardless of displayInfo.has_touch, which matches the title's scope. The title follows the conventional commit format and is specific enough for a teammate scanning history to understand the change.
Full details: Sibling Call Sites And Presence Semantics
-
Explanation
PASS. The diff changes only the tap-capability condition in
DisplayMirror.kt; it does not make a field nullable, remove a zero-guard, add a presence check, or add a numeric field defaulted to0. Repository search found onehas_touchusage, at the updated call site. No unfixed sibling call site exists.
Full details: Moved Code Diffed Against Its Original
-
Explanation
PASS. The PR changes one existing file with 3 insertions and 1 deletion. It adds an import, a comment, and an additional condition in
DisplayMirrorContent; it does not delete or relocate a type, function, or module. The moved-code checks are therefore not applicable.
-
Full details: Regression Coverage For Changed Behavior
-
Explanation
Missing regression coverage for the changed Compose input gate.
DisplayMirrorContentnow passeshasTouch = displayInfo?.has_touch == true || currentFrame.format == MirrorFormat.RGB565atDisplayMirror.kt:184-194. This changes the Compose UI gesture path inMirrorSurface: RGB565 taps and long-presses now callsendTouch, which reaches the device input protocol throughDisplayMirrorViewModel.sendTouch. Existing tests cover RGB565 frame assembly and generic ViewModel behavior, but no test composes this path or sends a gesture. The PR also changes no test file.Resolution
Add a Compose UI regression test for a connected RGB565 frame with
DisplayInfo.has_touch == false. Perform a tap and assert oneINPUT_USER_PRESStouch event with the expected device coordinates; perform a long-press and assertINPUT_SELECT. The test must fail against the base code. Add a companion case for a non-RGB565 frame withhas_touch == falseto confirm that the existing keyboard-capture behavior remains unchanged.
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
❌ 19 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
This comment has been minimized.
This comment has been minimized.
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
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.
MUI routes mirrored taps to its own virtual pointer, so a device without a touch panel still takes them - but the Mirror tab only sent taps when
has_touchwas set, so a touchless MUI board like the MeshPager X2 got none.🐛 Bug Fixes
has_touchkeeps its proto meaning of a physical touch panel.Testing Performed
No test added - the gate sits inside the Mirror composable. Verified the MUI tap path over TCP on the Portduino rig (meshtastic/device-ui#394, meshtastic/firmware#11681).
Summary by CodeRabbit