linux-kernel - Re: Linux 2.6.31-rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Aug 2009 10:12:14 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...il.com>
cc:	Zhenyu Wang <zhenyuw@...ux.intel.com>,
	Eric Anholt <eric@...olt.net>, mailing54 <mailing54@...k.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Airlie <airlied@...hat.com>,
	dri-devel@...ts.sourceforge.net, Ma Ling <ling.ma@...el.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"Zhao, Yakui" <yakui.zhao@...el.com>
Subject: Re: Linux 2.6.31-rc7

On Wed, 26 Aug 2009, Dave Airlie wrote:
> 
> 3. Here's the thing, we do detect something has changed, we detect we no
> longer have a monitor connected on the mac mini because the routing
> for the DDC pins is insane and need special treatment in the driver.

That's the second thing - DDC in general seems to be _very_ flaky on intel 
chips.

And I don't mean that in a "Mac Mini" kind of sense. I'm seeing in on 
other machines. Here's my old EeePC 701:

	[drm] Initialized drm 1.1.0 20060810
	i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
	i915 0000:00:02.0: setting latency timer to 64
	i2c-adapter i2c-1: unable to read EDID block.
	i915 0000:00:02.0: LVDS-1: no EDID data
	[drm] DAC-6: set mode 640x480 0
	i2c-adapter i2c-1: unable to read EDID block.
	i915 0000:00:02.0: LVDS-1: no EDID data
	[drm] TV-11: set mode NTSC 480i 0
	allocated 800x480 fb: 0x007df000, bo f735b540
	[drm] LVDS-8: set mode 800x480 15
	Console: switching to colour frame buffer device 100x30

and quite frankly, I suspect you've never ever actually googled for "no 
EDID data", because if you had, you'd have seen that this is quite common.

And yes, the response of KMS seems to be "ok, I failed at EDID, so I'll 
just assume something isn't there". And then usually it picks LVDS 
instead, if it finds a VBT table for it. Which happens to work fine on 
most laptops, but it's still just a random heuristic.

And yes, for all I know it's because the display really doesn't do any 
EDID.

And that really kind of is the point - it doesn't even matter whether the 
problem is the Intel driver doing something wrong on the EDID front (which 
it has done quite often - ranging from just looking at the wrong port, to 
not setting the right bits to make bit-banging i2c work AT ALL), or 
whether the problem is that the hardware is wired up oddly (Mac Mini) or 
whether it's the hardware simply not doign EDID at all (maybe my EeePC? Or 
a really old VGA monitor, or whatever).

In all three cases the end result is "no EDID", but regardless of that, 
the correct action is basically _never_ to say "ok, I'll just assume that 
the display is on connector XYZ regardless of what the state of the 
graphics chip is".

> so yes I think do better at failing is what is needed, its still
> failing but its more user friendly fail.

Yes. If something fails ("oops, I can't seem EDID for any connector"), I 
wish KMS would fail way better than just default to some crazy setup. The 
failure mode should be to at least drive whatever the BIOS enabled.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/