On Mon, Feb 11, 2008 at 11:20:03AM +0000, Stefano Stabellini wrote:
> the qemu vnc server changes its internal colour depth based on the
> client request. This way just one colour conversion is done: the one in
> vga_template.h, from the guest colour depth and the vnc server internal
> colour depth.
>
> This patch is meant to remove this colour conversion to improve
> performances. It accomplishes the goal making the qemu internal colour
> depth always the same as the guest colour depth.
> The basic idea is that the vnc client is the one that should do the
> colour conversion, if necessary. In general it should accept the pixel
> format suggested by the server during the initial negotiation. This
> behaviour can be set in most vnc clients (vncviewer included).
>
> If the guest changes colour depth, the qemu vnc server changes colour
> depth too and notifies the client. The problem is that the vnc protocol
> doesn't provide a message from the server to the client to ask for a
> colour depth change. So what I am doing is either:
>
> 1) quietly starting to do the conversion on vnc server (not gaining any
> performances here);
This should be the default behaviour
> 2) closing the vnc connection with the client, so the client can
> reconnect and choose the new pixel format.
This is evil. If we need a way to notify the client of colour depth
changes, then we should define an official VNC extension for this
that clients can implement. cf the desktop-resize extension
So, if the client supports the extension use that to notify, otherwise
fallback to doing server-side conversions.
> By default I am doing 1), however the second choice can be enabled
> passing the -vnc-switch-bpp command line option.
Don't add more command line options - the existing -vnc flag already
has the ability to take multiple flags in the format:
-vnc hostname:display,flag,flag,flag,flag
eg
-vnc localhost:1,passwd,tls
> A last note: to get most out of this patch it is best to set Windows to
> 16 bit colour depth, because the 24 bit mode is 24 bit depth and 24 bpp,
> meaning no alpha channel. The vnc protocol doesn't support 24 bpp, only
> 32 bpp, so this conversion is unavoidable.
>
> Comments and critics are welcome.
Please send this to qemu-devel - we should not be introducing yet more
xen-specific forks to the QEMU code we have - it is a maintainance
disaster already with the number of patches we have.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home