Re: [Qemu-devel] [RfC PATCH] vnc: rich cursor support.

[Gerd Hoffmann <kraxel@redhat.com>]

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