From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O8v2R-0004eX-KI for qemu-devel@nongnu.org; Mon, 03 May 2010 08:46:19 -0400 Received: from [140.186.70.92] (port=50335 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O8v2P-0004eP-8O for qemu-devel@nongnu.org; Mon, 03 May 2010 08:46:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O8v2M-0004gf-ST for qemu-devel@nongnu.org; Mon, 03 May 2010 08:46:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31464) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O8v2M-0004gR-Ih for qemu-devel@nongnu.org; Mon, 03 May 2010 08:46:14 -0400 Message-ID: <4BDEC58F.4060607@redhat.com> Date: Mon, 03 May 2010 14:46:07 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RfC PATCH] vnc: rich cursor support. References: <1272887953-28305-1-git-send-email-kraxel@redhat.com> <4BDEBF89.9020702@codemonkey.ws> In-Reply-To: <4BDEBF89.9020702@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On 05/03/10 14:20, Anthony Liguori wrote: > On 05/03/2010 06:59 AM, Gerd Hoffmann wrote: >> Hi, >> >> Simple patch. Difficuilt matter. Not really sure where to go from >> here ... > > It'll be a complicated patch :-) I looked at this a while ago and there > are a few gotchas. Yea, /me isn't surprised after digging there. >> SDL can only handle 1bit (black/white) mouse cursors (with mask) > > I personally don't think we should even bother with anything other than > ARGB cursors. Not enough things render 1bit cursors via hardware in my > experience. qemu doesn't need to care how it is actually rendered, that job is offloaded anyway ;) I'm more concerned about network bandwith and host cpu usage. Using ARGB everythere will result in 1bit -> ARGB -> 1bit conversion in several cases. Changing the mouse pointer doesn't happen *that* frequently though, so I think there is no point in being worried too much. Except maybe for animated pointers ... Long-term ARGB cursors will be the only thing used, and limiting cursors to just that single format will certainly simplify all the cursor handling. >> I've seen vmware vga send only 1bit cursors (with mask, winxp guest), >> althougth it seems to be designed to support colored pointers too. > > VMware VGA sends full ARGB cursors. That's what you get by default when > you use vmware-vga and X. Didn't try X11, but windows xp vmware vga driver *does* send 1bit cursors. > The key problem with VNC is that it has no notion of disabling cursor > offload. This means that when the guest tries to disable it (like via a > reset cycle), we have to make sure to send a NULL cursor to avoid the > cursor being rendered. Easy. > This effectively disables any attempt by the client to draw a double > cursor though. This isn't nice indeed. >> I think we should put everything into a QEMUCursor struct, so we don't >> have to pass tons of parameters to the ->cursor_define() callback. > > Agreed. Good. >> Does it make sense to reuse "struct PixelFormat" for the cursor? I tend >> to think not. I expect we'll see three different cases be used in >> practice: >> >> (1) 1-bit image (and mask). >> (2) Same pixelformat as DisplayState (and mask). >> (3) 32bit RGB + alpha. > > I think always making a cursor 32bit ARGB would be reasonable. Let the > backend sort things out. Since we have the PixelFormat structures, it's > easy enough to add a routine to convert between formats. Or use existing ones such as vnc_convert_pixels(). Makes sense. >> I think we also better allow only certain sizes. Minimum requirement >> should be that the width is a multiple of 8. Handling bitmasks just >> become too ugly without that. I'd tend to go further even and allow >> only 32x32 and 64x64 mouse pointers. Maybe 48x48 too. > > I'm not sure it's necessary to be so restrictive. If you assume ARGB, > then masking isn't an issue. For the backends it might be in case they have to convert the alpha channel to a mask. cheers, Gerd