linux-kernel - Re: [RFC] enhancing the kernel's graphics subsystem

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]

Message-Id: <200705221636.20848.jbarnes@virtuousgeek.org>
Date:	Tue, 22 May 2007 16:36:20 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	dri-devel@...ts.sourceforge.net,
	Jesse Barnes <jesse.barnes@...el.com>,
	James Simmons <jsimmons@...tafluge.infradead.org>,
	Dave Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
	"Antonino A. Daplas" <adaplas@...il.com>
Subject: Re: [RFC] enhancing the kernel's graphics subsystem

On Tuesday, May 22, 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote:
> > The current code does its best to figure out what modes are available
> > and tries to pick a good one for each display.  It sounds like you're
> > mainly concerned with the actual mode picking, not the mode and output
> > detection and enumeration?  If so, that's a pretty easy change to
> > make.  But if you're also worried about the kernel building mode
> > lists, then we'll have bigger changes to make...
>
> I'm worried that the EDID we get from the monitor is bogus and needs to
> be overriden.
>
> Now, if the kernel builds a mode list, that's find if we have a call to
> "feed" it with a replacement one later on from userland.
>
> In addition, there are all those monitors that cannot be probed (no
> DDC/EDID) and for which only userland can reasonably provide a mode or a
> mode list.

Yeah, we already have a call to add modes to the kernel's list, so we 
should be covered.

> So it's a bit of both :-) Building an "initial" mode list from the EDID
> might be fair enough if we can replace it soon enough, but we still need
> to be very conservative about whatever boot mode we choose.

Right.

> > I'm not really sure how much of a problem broken EDIDs will be.  The X
> > server only has a few quirks for broken EDIDs now, nothing major
> > afaict, and apparently the FB layer already has some code for handling
> > EDID quirks, so I don't think that'll be our biggest problem.  So far,
> > it looks like handling laptop panels is a bit trickier (at least for
> > Intel chips)...
>
> Well, I've seen my share of broken EDID.. Last time I looked at Darwin,
> I think I saw Apple maintaining a fairly huge database of EDID
> replacements in userland...

Interesting... I wonder how the distro monitor databases compare.

Jesse


-
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/