chromebook_gru scarlet: USB-C display output issues (visual static, duplication)

[ryjelsum]

Hi, I've recently got my hands on a gru 'scarlet' tablet ("acer chromebook tab 10", chromeos bash identifies it as 'dru-rev5') and tried out your images, and I've noticed a quirk with the DP/HDMI output, it is somewhat.. garbled.

On a 1920x1080 display, this manifests as some columns of the screen shifting around horizontally, making slight visual static.

On a 1920x1200 display, the issue is worse, with the above issues in addition to some sections of the screen being duplicated and out of order (see, duplicated mouse cursor, the distinct visible lines in the gradient)

In general, the HDMI out is also much more finicky than the 'gru-kevin' that I have, sometimes refusing to display anything at all, and the cdn-dp kernel module does not output anything indicating that there is an error. (Though honestly this part could be user error..)

This occurs both on the 6.1.51-stb-cbg+ kernel as well as the 6.6.9-stb-cbg+ kernel. This isn't a general issue with gru, I have a 'kevin' unit where the USB-C display output has worked fine using your images as I've previously popped in to say, and this doesn't seem to be a hardware issue, as the display output on this unit works perfectly fine under ChromeOS.

Again, I'd like to thank you for your work here - it's been a really useful learning tool for me, personally. :)

[hexdump0815]

maybe its worth a try if things look different if gpu accel is not enabled to figure out if its gpu or display output related?

[ryjelsum]

Disabling GPU accel does not seem to make any meaningful difference in the presence or appearance of these visual issues.

Other details

• Display protocol agnostic, occurs in X11/XFCE and wayland/sway
• Virtual console does not display on connected display at all (again, in comparison to kevin which mostly does, except for very early boot)
• Switching to virtual console from X11/Wayland's vtty with the display plugged in seems to kill all external display output until next reboot, without any indication of any errors in dmesg, looks exactly the same as when a picture appears

(My kevin has been flashed with libreboot now, so I'm assuming can't do a whole lot of comparative testing between the two with your images without re-flashing depthcharge, most of the comparisons are just going off of memory - but kevin has had very few problems for me in this regard in general)

[hexdump0815]

i have a bob and also an acer tab 10 (although i think mine is scarlet) here and will try to test those as well a bit deeper, but it will take a while until i'll get to that ... lets see if they show the same problems ... maybe your dru is different from my scarlet (hardware wise)?