Screen corruption waking from screen blank if no monitor present

[Tobin Davis]

My test environment has a standard HDMI switch to go between several test platforms. On this system, if it doesn't detect the edid data when waking, it restores the screen in 640x480 resolution and appears as a corrupted screen. Allowing the system to go blank again and ensuring the switch is set to it recovers ok.

This is logged in the dmesg log file.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-omap4 2.6.35.903.5
ProcVersionSignature: User Name 2.6.35-903.12-omap4 2.6.35.3
Uname: Linux 2.6.35-903-omap4 armv7l
Architecture: armel
Date: Tue Sep 21 13:47:38 2010
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: linux-meta-ti-omap4

[Ricardo Salveti (rsalveti)]

@Tobin: are you sure you faced this issue with the dmesg you post at comment #2? Here the HDMI code is probing the EDID correctly 2 times, and setting your resolution as 1440x900.

This issue happens because of the new size_notify API added by Rob Clark with latest merge. With the latest API every time the hdmi driver wakes up it'll try to probe the EDID again (in case you switched monitors), and if it finds a different resolution, it'll set the new size at the framebuffer driver. While this feature works correctly for the framebuffer driver, the X11 fbdev doesn't support it, and will continue using the resolution it got when starting X11.

If you restart X11 you'll see that it'll work again with the proper resolution.

[Ricardo Salveti (rsalveti)]

And 640x480 is the default resolution when it can't probe the EDID.

[Tobin Davis (gruemaster)]

Attached is the edid output when the system returns from blank screen if the hdmi switch is on a different system. This causes screen corruption in X, and makes it completely unusable.

[Lee Jones (lag)]

Have you spoken to Rob Clark and pointed him to this bug?

If Rob can't help you, try Mythri PK.

[Lee Jones (lag)]

Tobin, is this issue sorted yet, or is it on going?

[Lee Jones (lag)]

Nothing heard. I'm going to assume this is no longer an issue.

[Tobin Davis (gruemaster)]

This bug hasn't been touched. I can still fully reproduce it and have shown it to TI devs during the rally.

Changing back to confirmed.

[Ricardo Salveti (rsalveti)]

This needs to be addressed with the new development targeting kernel 2.6.38, as TI will rewrite the whole driver again. Don't think it's worthy to fix the current driver.

[Lee Jones (lag)]

I'm inclined to agree with Ricardo.

Changing to "won't fix".