Hi all, 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); 2) closing the vnc connection with the client, so the client can reconnect and choose the new pixel format. By default I am doing 1), however the second choice can be enabled passing the -vnc-switch-bpp command line option. In order to do the colour conversion on the vnc server I had to improve the colour conversion code already in place because it only supported conversions from 32 bpp. The patch adds colour conversion code that support conversions from any resolution to any resolution. 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. Best Regards, Stefano Stabellini _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> The basic idea is that the vnc client is the one that should do the > colour conversion, if necessary.What impact, if any, does this have on the bandwidth required for the VNC connection? I''ve been using VNC to access HVM Xen clients over a 512k link lately and it''s only barely acceptable. My color level is set to ''Low (64 Colors)''. If the client is doing the conversion then doesn''t this mean that the server has to transmit 16/24/32 bits of color information to the client, rather than 6? Or more likely, maybe I don''t understand the implications of your patch :) James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper wrote:>> The basic idea is that the vnc client is the one that should do the >> colour conversion, if necessary. > > What impact, if any, does this have on the bandwidth required for the > VNC connection? I''ve been using VNC to access HVM Xen clients over a > 512k link lately and it''s only barely acceptable. My color level is set > to ''Low (64 Colors)''. If the client is doing the conversion then doesn''t > this mean that the server has to transmit 16/24/32 bits of color > information to the client, rather than 6? > > Or more likely, maybe I don''t understand the implications of your patch > :) >It is the opposite :) Now most vnc clients run on 32 bpp display, so they automatically ask for 32 bpp connections to the server, even if the guest is using 16 bpp. This is a waste of bandwidth. Using my patch together with the right configuration of your vnc client you can just use the bandwidth needed to preserve the colour depth resolution of the guest and nothing more. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange wrote:>> 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.This is a good idea, I just hope it won''t take ages to be accepted. I''ll work on this.>> 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,tlsanother good suggestion, I''ll modify the patch to use this.> > 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. >Yeah I know, but sending patches to qemu-devel is like &>/dev/null _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Feb 11, 2008 at 03:18:59PM +0000, Stefano Stabellini wrote:> Daniel P. Berrange wrote: > >>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. > > This is a good idea, I just hope it won''t take ages to be accepted. > I''ll work on this.There''s not really any formal process for VNC extensions. You pretty much just post to the vnc mailing list & propose what you want to do and unless its absolutely insane you should get given a psuedo encoding number reasonably quickly. Getting it implement in clients is more fun - but feel free to propose patches to the gtk-vnc mailing list - we aim to be broad compatability with as many servers as possible & are particularly interested in stuff that is useful to virtualization. Also send ideas for the protocol extension there & we can give feedback on how well it''ll work from the client POV.> >>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 > > another good suggestion, I''ll modify the patch to use this.Great, thanks.> >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. > > > > Yeah I know, but sending patches to qemu-devel is like &>/dev/nullYes it can be - you may not get it mereged quickly, but there are quite a few people who are knowledgable about the VNC server (who don''t read xen-devel) & might give useful feedback. Regards, 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@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange wrote:> On Mon, Feb 11, 2008 at 03:18:59PM +0000, Stefano Stabellini wrote: >>> So, if the client supports the extension use that to notify, otherwise >>> fallback to doing server-side conversions. >> This is a good idea, I just hope it won''t take ages to be accepted. >> I''ll work on this. > > There''s not really any formal process for VNC extensions. You pretty > much just post to the vnc mailing list & propose what you want to do > and unless its absolutely insane you should get given a psuedo encoding > number reasonably quickly.We can use the existing space for gtk-vnc although VMware actually already has an extension to support server initiated pixel format changes. See http://wiki.multimedia.cx/index.php?title=VMNC The extension is VMVi (display mode change). I would much rather just implement that in QEMU and in gtk-vnc. This would also count in my mind as finally fixing SetPixelFormat since a client could rely on getting the DisplayModeChange message before the server starts using the new pixel format.> Getting it implement in clients is more fun - but feel free to propose > patches to the gtk-vnc mailing list - we aim to be broad compatability > with as many servers as possible & are particularly interested in stuff > that is useful to virtualization. Also send ideas for the protocol > extension there & we can give feedback on how well it''ll work from > the client POV.Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori wrote:> We can use the existing space for gtk-vnc although VMware actually > already has an extension to support server initiated pixel format > changes. See http://wiki.multimedia.cx/index.php?title=VMNC > > The extension is VMVi (display mode change). I would much rather just > implement that in QEMU and in gtk-vnc. > > This would also count in my mind as finally fixing SetPixelFormat since > a client could rely on getting the DisplayModeChange message before the > server starts using the new pixel format.I have given a look at WMVi: the message format is fine as it is identical to the PIXEL_FORMAT part of the ServerInit message. However I couldn''t see the pseudo encoding number or any client side implementation. I think they used WMVi as part of their format to record AVI videos and not as a VNC protocol extension. We can use the message format they proposed, but we need also a proper pseudo encoding number. Then we''ll send "DisplayModeChange" messages as 1 rectangle framebuffer updates. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini wrote:> Anthony Liguori wrote: >> We can use the existing space for gtk-vnc although VMware actually >> already has an extension to support server initiated pixel format >> changes. See http://wiki.multimedia.cx/index.php?title=VMNC >> >> The extension is VMVi (display mode change). I would much rather >> just implement that in QEMU and in gtk-vnc. >> >> This would also count in my mind as finally fixing SetPixelFormat >> since a client could rely on getting the DisplayModeChange message >> before the server starts using the new pixel format. > > I have given a look at WMVi: the message format is fine as it is > identical to the PIXEL_FORMAT part of the ServerInit message. > However I couldn''t see the pseudo encoding number or any client side > implementation. > I think they used WMVi as part of their format to record AVI videos > and not as a VNC protocol extension. > > We can use the message format they proposed, but we need also a proper > pseudo encoding number. > Then we''ll send "DisplayModeChange" messages as 1 rectangle > framebuffer updates. 0x574D5669The encoding number they use is 0x574D5669 and it is registered in the latest RFB spec. Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori wrote:> The encoding number they use is 0x574D5669 and it is registered in the > latest RFB spec. >Thanks for looking it up. I''ll post the updated patch soon. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel