On 04/03/13 12:13, Damian, Alexandru wrote:
> It fixes my test case, that is starting up with 32 bits depth console and
> then switching to 16 bits depth -
> since the depth is cached, xf64-video-vmware gets 565-weight but 32 bit
> depth, and refuses to start.
Jan's case is booting with vesafb @ 1
Something like this, please comment, not ready to submit.
From: Alexandru DAMIAN
Date: Wed, 3 Apr 2013 13:43:31 +0300
Subject: [PATCH] qemu console: Add depth preservation on allocation
Since there are multiple bit depths supported for consoles,
we must preserve the depth when creating new cons
It fixes my test case, that is starting up with 32 bits depth console and
then switching to 16 bits depth -
since the depth is cached, xf64-video-vmware gets 565-weight but 32 bit
depth, and refuses to start.
There is another similar bug I'm tackling now - when the window resizes,
qemu_console_res
On 03/29/13 17:28, Alex DAMIAN wrote:
> From: Alexandru DAMIAN
>
> Do not cache depth and bypp information in the device state.
>
> This resolves a bug where Xorg video-vmare driver refuses
> to start up because the depth value read is the one cached from the
> device start (default 32 from ui/c
From: Alexandru DAMIAN
Do not cache depth and bypp information in the device state.
This resolves a bug where Xorg video-vmare driver refuses
to start up because the depth value read is the one cached from the
device start (default 32 from ui/console.c) and it is not consistent
with the graphica
