HDK2 hardware-related issue: too bright of screen can cause signal droop and perceived video loss

[rpavlik]

Simplest way to reproduce, assuming Notepad on your system is a primarily white window.

• put HDK2 into extended mode.
• Open notepad in a small window, and drag it (mostly) on to the HDK display.
• Observe it looks fine.
• Maximize the notepad window, which will maximize on the HDK display.
• Observe the screen will flicker through just a horizontal band of the display (as if it unexpectedly lost HDMI input and panels didn't respond quick enough) to black and the USB serial console will report video signal lost and the subsequent (required?) reset of the Toshiba chip.

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

[rpavlik]

Apparently slightly large white windows cause more complex artifacts/signal degradation before a full drop

• this video (stuck in a zip so GitHub would deal with it) was recorded at 15FPS, so none of the effects you're seeing are beat effects or similar (since it's a tidy factor of 90hz)

hdk2-brightness-crash.zip

[rpavlik]

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