]> xenbits.xensource.com Git - qemu-xen-4.1-testing.git/commit
xenfb: let xenfb_guest_copy() handle dept h=32 case
authorIan Jackson <ian.jackson@eu.citrix.com>
Tue, 14 Dec 2010 18:39:14 +0000 (18:39 +0000)
committerIan Jackson <Ian.Jackson@eu.citrix.com>
Tue, 14 Dec 2010 18:39:14 +0000 (18:39 +0000)
commitca6a9ba9ac7b76c4f4b2f711b1d6d9e7633b2ae5
tree342f50459c2e453ea3553918526b1ef659334b3b
parentdd9d12dc85dfc5f873c8d57bd42f09b81219c250
xenfb: let xenfb_guest_copy() handle dept h=32 case

In hw/xenfb.c, xenfb_guest_copy only handles xenfb->depth=8 and 24
cases, I guess it assumes in xenfb->depth=16 or 32 cases, buffer is
shared. But that's not always the case: the code path that allows us
to have a shared buffer when xenfb->depth=16 or 32 is xenfb->do_resize
set, but on a guest vnc console, when enter CTRL+ALT+2 switch to qemu
monitor console then CTRL+ALT+1 back to guest window, the
xenfb->do_resize is not set, that is, buffer is not shared, and
xenfb_guest_copy does not handle xenfb->depth=32 case, the result is:
guest screen cannot be restored.

To fix above problem, this patch does two things:

1. Set xenfb->do_resize in xenfb_invalidate so that in console switch
case, buffer is shared when xenfb->depth=16 or 32. The screen cannot
be restored bug in above description can be solved.

2. To avoid that other special cases have the same problem, it's
better to let xenfb_guest_copy handle all cases, so add processing to
xenfb->depth=16 and 32 in xenfb_guest_copy.

Signed-off-by: Chun Yan Liu <cyliu@novell.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
hw/xenfb.c