Bug 86861

Summary:	[rv6xx] When using a hardware KVM switch between computers EDID sometimes not detected/display goes fuzzy
Product:	DRI	Reporter:	Shawn Starr <shawn.starr>
Component:	DRM/Radeon	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED NOTOURBUG	QA Contact:
Severity:	normal
Priority:	medium
Version:	XOrg git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Shawn Starr 2014-11-29 21:31:27 UTC

kernel: 3.17.2-300.fc21.x86_6

I've noticed sometimes when using my KVM Switch when switching to the laptop. I get fuzzy text in console w/ KMS on.

if I start X, the fuzzy display continues, a full reboot resets the display properly.

Caught an error this time (maybe just as it was about to detect the EDID of display)

[ 5877.852952] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130
[ 5877.860547] Raw EDID:
[ 5877.862264]          00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
[ 5877.865817]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5877.867201]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5877.870127]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5877.871706]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5877.874040]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5877.875309]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5877.876593]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5877.880376] [drm:radeon_vga_detect] *ERROR* VGA-1: probed a monitor but no|invalid EDID

KVM switch model: ATEN CS-1734A (Firmware: V4.2.417 not upgraded since purchase)

The actual EDID of the display (from Xorg log):

[   416.432] (II) RADEON(0): EDID (in hex):
[   416.432] (II) RADEON(0):    00ffffffffffff00320c00f200000000
[   416.432] (II) RADEON(0):    0011010380211578eaba709859528c28
[   416.432] (II) RADEON(0):    2550542108008180a940010101010101
[   416.432] (II) RADEON(0):    010101010101e33a805a70b032401e1e
[   416.432] (II) RADEON(0):    13004bcf100000190000000000000000
[   416.432] (II) RADEON(0):    00000000000000000000000000fe0058
[   416.432] (II) RADEON(0):    55333031043135345755310a000000fe
[   416.432] (II) RADEON(0):    00283e4c53739bbaff02010a202000aa

Comment 1 Christian König 2014-11-30 13:03:30 UTC

Sounds like just another buggy KVM switch to me.

The basic problem is that the I²C used to read the EDID assumes that you only have two endpoints on the wire - the display and the gfx hardware. So properly designed KVM switches have an micro-controller which fetches the EDID from the monitor on connect and forwards the EDID to each connected system if requested. Otherwise you run into problems when by pure coincident two systems try to fetch the EDID at the same time.

Without the EDID the gfx hardware has no idea what resolutions the display can handle and most likely doesn't choose the optimal one. Easiest workaround is manually set the necessary resolution for the display.

Comment 2 Shawn Starr 2014-11-30 19:21:33 UTC

The newer firmware updates don't address VGA EDID detection, at least the documentation doesn't list this.

One thought though, we don't cache the EDID information if it was previously detected? If you switch the screen, does that effectively mean the cable is disconnected on the other computer?

Comment 3 Alex Deucher 2014-12-01 02:34:25 UTC

(In reply to Shawn Starr from comment #2)
> The newer firmware updates don't address VGA EDID detection, at least the
> documentation doesn't list this.
> 
> One thought though, we don't cache the EDID information if it was previously
> detected? If you switch the screen, does that effectively mean the cable is
> disconnected on the other computer?

For analog displays like VGA, the drm core polls every 10 seconds or so to see if the monitor is still there since the older analog connctors like VGA do not support hotplug like digital connectors like DVI or HDMI do.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.