You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fw/services/compositor: make freeze wait for in-flight display updates
compositor_freeze() only raised a flag that the KernelMain render
paths consult. It was called from the BT task by the screenshot
endpoint, which then copied the first framebuffer chunk immediately,
so a display update that had already been kicked off could still be
in flight while the screenshot read the framebuffer.
On sf32lb boards (obelix, getafix) the JDI driver converts the dirty
rows of the compositor framebuffer in-place from 2-2-2 to 3-3-2 for
the LCDC and only converts them back after the DMA completes, from a
KernelMain callback. Screenshots sampling those rows in that window
carry 3-3-2 pixels reinterpreted as GColor8: orange (0xF4) reads
back as GColorIslamicGreen (0xC8), which is the green status bar in
the report.
Turn compositor_freeze() into an asynchronous request: the freeze
takes effect on KernelMain and a callback fires there once no display
update is in progress, either straight away or from the display
update complete handler. The screenshot starts streaming from that
callback on the system task, and the ALS console command drops its
hand-rolled spin on compositor_display_update_in_progress(). Add unit
tests for both the idle and the update-in-flight cases.
Fixes FIRM-4357
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
0 commit comments