From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LqUH4-00084R-7y
	for qemu-devel@nongnu.org; Sun, 05 Apr 2009 11:28:42 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LqUGz-00083L-FV
	for qemu-devel@nongnu.org; Sun, 05 Apr 2009 11:28:41 -0400
Received: from [199.232.76.173] (port=59433 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LqUGz-00083G-9d
	for qemu-devel@nongnu.org; Sun, 05 Apr 2009 11:28:37 -0400
Received: from mx2.redhat.com ([66.187.237.31]:39444)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1LqUGy-0006IL-QY
	for qemu-devel@nongnu.org; Sun, 05 Apr 2009 11:28:37 -0400
Message-ID: <49D8CE22.4080209@redhat.com>
Date: Sun, 05 Apr 2009 18:28:34 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH] Fix display breakage when resizing the
	screen
References: <1238842115-31236-1-git-send-email-avi@redhat.com>
	<49D8B5C2.4090901@codemonkey.ws>
In-Reply-To: <49D8B5C2.4090901@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: kvm@vger.kernel.org

Anthony Liguori wrote:
> Avi Kivity wrote:
>> When the vga resolution changes, a new display surface is not allocated
>> immediately; instead that is deferred until the next update.  However,
>> if we're running without a display client attached, that won't happen
>> and the next bitblt is likely to cause a segfault by overflowing the
>> display surface.
>>
>> Fix by reallocating the display immediately when the resolution changes.
>>
>> Tested with (Windows|Linux) x (cirrus|std) x (curses|sdl).
>>
>> Signed-off-by: Avi Kivity <avi@redhat.com
>
> This patch breaks VC switching with -curses.
>

Can someone explain what DisplaySurface::width means when using curses?

It is initialized to a pixel value:

   ds->surface = qemu_create_displaysurface_from(640, 400, 0, 0, 
(uint8_t*) screen);

then read in from the current surface:

static void curses_resize(DisplayState *ds)
{
    if (ds_get_width(ds) == gwidth && ds_get_height(ds) == gheight)
        return;

    gwidth = ds_get_width(ds);
    gheight = ds_get_height(ds);

    curses_calc_pad();
    ds->surface->width = width * FONT_WIDTH;
    ds->surface->height = height * FONT_HEIGHT;
}

But curses_calc_pad() does

static void curses_calc_pad(void)
{
    if (is_fixedsize_console()) {
        width = gwidth;
        height = gheight;
    } else {
        width = COLS;
        height = LINES;
    }

If !is_fixedsize_console(), then the global width takes on a character 
cell count, later multiplied by FONT_WIDTH to become a pixel value 
again.  But if is_fixedsize_console() is true (which happens to be the 
case here), then the global width is a pixel value (from gwidth), and 
when multiplied by FONT_WIDTH it becomes nonsense.  Repeated calls to 
curses_resize() will inflate the value to hell.

-- 
error compiling committee.c: too many arguments to function