From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:36224)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <john.baboval@virtualcomputer.com>)
	id 1RLypF-0004n6-AC
	for qemu-devel@nongnu.org; Thu, 03 Nov 2011 11:03:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <john.baboval@virtualcomputer.com>)
	id 1RLyp9-0008Hs-GI
	for qemu-devel@nongnu.org; Thu, 03 Nov 2011 11:03:29 -0400
Received: from server514f.exghost.com ([72.32.253.73]:1065
	helo=server514.appriver.com) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <john.baboval@virtualcomputer.com>)
	id 1RLyp9-0008HS-8X
	for qemu-devel@nongnu.org; Thu, 03 Nov 2011 11:03:23 -0400
Message-ID: <4EB2AD37.3090609@virtualcomputer.com>
Date: Thu, 03 Nov 2011 11:03:19 -0400
From: John Baboval <john.baboval@virtualcomputer.com>
MIME-Version: 1.0
References: <4EAB0169.8090408@virtualcomputer.com>
	<4EAFB49A.2040004@redhat.com>
	<2F227323-6B37-4F64-843A-91C3291A9254@virtualcomputer.com>
	<4EB024E7.8040400@redhat.com>
In-Reply-To: <4EB024E7.8040400@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 1/2] Allow 1366x768 as a valid VGA
	resolution
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org

This is a good idea. I'm going to re-work the patch, but I have a lot of 
other stuff going on too, so it may be a week or so before I get back to it.

On 11/01/2011 12:57 PM, Gerd Hoffmann wrote:
> On 11/01/11 14:39, John Baboval wrote:
>> I don't know of any reason for it.
> I'd guess it is alignment, probably not important for all color depts.
>
> Maybe it is a good idea to do all sanity checks in the
> VBE_DISPI_INDEX_ENABLE branch where the actual mode switch happens. Then
> you already know xres, yres and depth when applying the checks.  You can
> calculate the scanline length, then check the scanline alignment instead
> of being overly strict on xres in high color modes to satisfy alignment
> requirements in low color modes.
>
> You can also simply calculate how much memory the video mode needs and
> check that against the configured video ram instead of pulling xres and
> yres limits out of thin air.
>
> cheers,
>    Gerd