Skip to content

Restore display orientation after Windows resume - #1069

Open
MrSoichi wants to merge 1 commit into
mathoudebine:mainfrom
Mugen-Art-Lab:fix/windows-resume-orientation
Open

Restore display orientation after Windows resume#1069
MrSoichi wants to merge 1 commit into
mathoudebine:mainfrom
Mugen-Art-Lab:fix/windows-resume-orientation

Conversation

@MrSoichi

Copy link
Copy Markdown

Summary

On Windows, some displays can lose their configured orientation after sleep or hibernation and resume in the default orientation.

This was reproduced on a Turing Smart Screen 3.5" Rev. A using reversed portrait orientation.

The Windows resume handler currently calls display.turn_on(), but orientation is only configured separately during initial display initialization. Rev. A also sends SetOrientation() directly to the serial port instead of serializing it with the normal display command queue.

This PR:

  • restores the configured orientation whenever the display is turned back on;
  • queues the Rev. A orientation command with the other display commands;
  • waits briefly for the USB/serial device to settle after Windows resume;
  • lets pending queued writes finish before restoring the display state;
  • redraws the static theme content after recovery.

Reproduction

Before this change:

  1. Configure the display to use reversed portrait orientation.
  2. Start the monitor normally and verify the orientation is correct.
  3. Put Windows into sleep/hibernate.
  4. Resume Windows.

On affected resumes, the display controller can return in its default orientation while the monitoring process continues running. On Rev. A, restoring orientation immediately during resume can also race with queued display updates.

Why

After hibernation, the LCD controller may return to its default orientation while the application itself continues running.

Sending the orientation command immediately during resume can also race with queued redraw/sensor updates on Rev. A.

Serializing the orientation command and allowing the USB endpoint/queue to settle before redraw makes the resume sequence deterministic.

Hardware validation

Tested by Mugen Art Lab on:

  • Turing Smart Screen 3.5"
  • Hardware revision A
  • Windows
  • reversed portrait orientation (DISPLAY_REVERSE: true)

The final recovery sequence was exercised through repeated real-world hibernate/resume cycles, including multi-hour hibernation periods. Orientation, background/static content and live sensor updates recovered correctly after resume.

The final test run completed 6 consecutive long hibernate/resume cycles without an orientation failure or incomplete redraw.

Notes

The change is intentionally limited to resume/orientation recovery and does not modify theme configuration or sensor logic.

Comment thread library/display.py

# The LCD controller may lose its configured orientation during sleep/hibernate.
orientation = _get_theme_orientation()
logger.info("Restoring display orientation: %s" % orientation.name)

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'Restoring display orientation' log is confusing when turn_on() is called at program startup, since it is not really restoring the setting but rather applying it for the first time.
I think it is not necessary to have a log here at all.
Same for the comment l. 142 that speaks of a specific case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants