From owner-svn-src-all@FreeBSD.ORG  Tue Jan 26 15:30:27 2010
Return-Path: <owner-svn-src-all@FreeBSD.ORG>
Delivered-To: svn-src-all@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 1033)
	id A5C0A106568F; Tue, 26 Jan 2010 15:30:27 +0000 (UTC)
Date: Tue, 26 Jan 2010 15:30:27 +0000
From: Alexey Dokuchaev <danfe@FreeBSD.org>
To: Dag-Erling Sm??rgrav <des@des.no>
Message-ID: <20100126153027.GA65470@FreeBSD.org>
References: <200911032022.nA3KM96H003434@svn.freebsd.org>
	<20100125192941.GA9196@FreeBSD.org> <86ljflj798.fsf@ds4.des.no>
	<20100126142803.GA55760@FreeBSD.org> <86aaw0kjko.fsf@ds4.des.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <86aaw0kjko.fsf@ds4.des.no>
User-Agent: Mutt/1.4.2.1i
Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org,
	src-committers@freebsd.org, Jung-uk Kim <jkim@FreeBSD.org>
Subject: Re: svn commit: r198858 - in head/sys: dev/fb dev/syscons sys
X-BeenThere: svn-src-all@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SVN commit messages for the entire src tree \(except for &quot;
	user&quot; and &quot; projects&quot; \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>,
	<mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>,
	<mailto:svn-src-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 15:30:27 -0000

On Tue, Jan 26, 2010 at 03:49:11PM +0100, Dag-Erling Sm??rgrav wrote:
> Alexey Dokuchaev <danfe@FreeBSD.org> writes:
> > Considering number of recent vesa/saver breaks, I am thinking about some
> > regression test suit that could at least check for "8-bit vs. 6-bit" type
> > of things.  Is it feasible?
> 
> Not unless you can figure our a way to programmatically look at the
> screen and check that the colors aren't too dark...  IIUC, this is a
> BIOS issue, not a driver issue.

I understand; I was thinking if maybe there are some "hackish" or
indirect way to tell that BIOS is lying.

./danfe