Open rpavlik opened 7 years ago
Apparently slightly large white windows cause more complex artifacts/signal degradation before a full drop
Hmm - these images don't show the perceived brightness variation as well as I'd like. Taken with a professional global-shutter camera (same as above), again from a 15fps feed.
Original (after power cycle)
after #sd5188
after #sd51ff
again
Simplest way to reproduce, assuming Notepad on your system is a primarily white window.
Has also been seen in bright demos, primarily in extended mode (however, we have not evaluated if brightness/gamma behavior is the same between extended and direct mode on NVIDIA)
DSI command 0x51 controls brightness on this panel (and the last part of the vendor-provided init sequence is 0x51 0xff - max brightness). In modern firmwares,
#sdxxyy
allows you to send DSI command xx with parameter yy (both hex) via serial, so#sd51yy
lets you set brightness to yy. However, adjustment does not appear to be entirely repeatable: the screen looks dimmer after#sd5188
then#sd51ff
even though it should be the same as immediately after display reset. Under the hypothesis that it was a power-related issue, a variety of lower brightness values were tested, but this non-repeatable aspect of the display brightness control made testing more difficult, as even#sd51ff
is dim enough (if preceded by another value) for the reset/signal loss to not be triggered.May need insight from display vendor or EE involved in power supplies to fully resolve this in a non-hacky way. The hacky workaround would be to add a sequence like (0x51, 0x88), (0x51, 0xff) in the startup sequence. Inserting a (0x51, 0x88) before the existing (0x51, 0xff) in the init sequence might even work - this has not been tested.
cc @VRguy @russell-taylor