Restore display orientation after Windows resume

[MrSoichi]

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.

[MrSoichi]

Quick update before merge: during continued hardware testing I found a rare long-hibernation resume case that I want to investigate before this PR is merged.

After a ~26 hour hibernation, the display orientation and static content recovered correctly, and most live stats continued updating. However, CPU percentage and CPU frequency did not resume drawing and remained blank for more than an hour, while CPU temperature, GPU, RAM, network and disk stats continued working.

The resume log itself looked normal and contained no COM/serial errors.

I don't yet know whether this is caused by the changes in this PR or whether the new resume sequence is exposing an existing scheduler/LibreHardwareMonitor issue. I'd prefer to investigate and validate this case before merging.

Please hold off on merging for now. I'll update the PR once I have identified the cause and tested the fix.

[MrSoichi]

Follow-up after extended testing:

I kept the diagnostic build running continuously from Aug 30 through Sep 6 and exercised 55 hibernate/resume cycles without restarting the application.

This included:

• about 119 hours total spent in hibernation;
• multiple 6–12 hour hibernation periods;
• one hibernation lasting about 20.5 hours.

All 55 resume sequences completed successfully. I did not reproduce the previous CPU percentage/frequency issue again, and the diagnostic build recorded no scheduler exceptions, NaN sensor failures, serial errors, COM errors or queue timeouts.

I also observed one resume where the display briefly woke in its default orientation before the configured reversed portrait orientation was reapplied automatically. The recovery completed correctly without any user interaction, which confirms the original orientation-resume case in practice.

At this point I’m satisfied with the hardware validation and consider the PR ready for review again.