AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 11 Bitcoin

feat(core): TS7 display refresh rate scaling and configuration optimization

Public commit record

What the developer wrote

Authored by bleska

100/100 · Strong
feat(core): TS7 display refresh rate scaling and configuration optimization

In order to lower the power consumption in standard operation mode, the goal is to regulate the display refresh rate based on the current needs (animations - 60Hz, static images - 30 Hz).
- Introduction of the on-the-fly refresh rate change functionality (interrupt based).

Configuration optimizations' investigations:
- Since the display visible dimensions are 520x380 and the display controller doesn't support this resolution directly, the closest variant 520x480 is used with 50px offset. Changing the resolution used to 520x430 and shortening the HACT region by 50px effectivly increasing the blanking period.
- Using RGB565 DSI color format, changing pixel clock to 15.5 MHz, changing HFP to 20 to maintain the 60 Hz refresh rate for the new pixel clock.
- DSI lane byte clock vs LTDC pixel clock ratio (max, min) tests.
- Etc. - different configuration profiles have been tested and TS7 input power consumption measured.

Formalizing the code to official one:
- adding preprocessor definitions to panels' configuration header files
- adding ifdefs to display_driver and display_fb source files to integrate the refresh rate scaling code based on panel's used
- the refresh rate change is to be performed to high one as soon as new image is to be shown, and to the low one after a timeout expires

[no changelog]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit changes how the Trezor hardware wallet's display is driven, mainly to save battery. It adds the ability to switch between 60 Hz and 30 Hz refresh rates depending on whether the screen is showing animations or a static image. It also reorganizes display timing numbers into panel-specific configuration files. There is no direct evidence in the commit that this fixes a security vulnerability; it reads as a power-optimization and code-cleanup change.

Recommended action

Treat as a normal firmware display-driver update. No immediate security action is indicated by the supplied materials. If reviewing for product safety, validate that the new interrupt-driven refresh-rate changes and the LTDC/DSI disable-re-enable workaround do not introduce display glitches or timing regressions on the affected panel.

Security signals we found

01

No security-relevant signals found in commit message or diff.

02

Change is described by the vendor as power-consumption optimization and configuration formalization.

03

Refresh-rate scaling runs in interrupt context with IRQ locks and busy-wait timeout, which could affect real-time behavior but is not shown to be exploitable.

04

No input validation, buffer handling, cryptographic, or trust-boundary changes are present.

Risk score

Why this scored 11/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 2/15
Confidence 3/10
Evidence quality 2/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.