Re: [PATCH] ui/cocoa: Support hardware cursor interface

[Akihiko Odaki <akihiko.odaki@gmail.com>]

On 2022/10/30 19:12, Elliot Nunn wrote:
> Akihiko,
> 
> Sounds like you've done a lot of work on ui/cocoa, with the goal of
> improving the experience with modern Linux guests. My goal is to improve
> the experience with antiquated Mac OS 9 guests.
> 
>> My patch has been only tested with recent Linux, but it certainly should
>> be ensured that it works well for old systems when upstreaming.
>>
>> First I'd like to know what display device you use. It looks like
>> dpy_mouse_set is used only by ati-vga, vhost-user-gpu, virtio-gpu, and
>> vmware.
> 
> I was using my own hardware cursor patches to the VGA device, but now I am
> using virtio-gpu. My Mac OS 9 driver for virtio-gpu is in progress.

Interesting, but I'm worried that your driver may be not performant 
enough to drive dpy_mouse_set. Does your driver provide hardware cursor 
as smooth as software cursor? If not, the proper way to fix the problem 
is to fix your driver. Strictly speaking, ignoring dpy_mouse_set and 
using the input information directly violates the semantics and should 
be avoided if possible. That said, if your driver already does the best 
to the extent what Mac OS 9 allows and you want even better, it can be a 
worthwhile option.

> 
>>> 1. In absolute pointing mode, re-enable Cocoa's cursor and let the host
>>> OS move it according to user input.
>>> 2. Keep the cursor sprite, but move it according to Cocoa's mouse
>>> movement events instead of dpy_mouse_set events.
>>
>> Also, can you give reasoning while 2 is preferred? 1 would allow to
>> exploit the hardware's feature for cursor composition, resulting in
>> smoother experience and a bit less power consumption. But there may be
>> complications it can cause so I have not decided which one is the better
>> yet.
> 
> Mainly that it would simplify the code. OTOH, if we expect the guest to
> use the hardware cursor facility, then it's only fair that the host does
> the same. I'm open to either option. We should probably try both.

Regarding the code complexity, option  2 can be still the better option 
because option 1 requires additional code to pass the input information 
to the cursor composition code. But it is just a possibility and I guess 
we will not know which is the better unless we implement them as you say.

> 
>>> And I didn't realise that you had added VirGL support to cocoa.m. Well
>>> done! Is it on track for release?
>>> My patch should be withdrawn from consideration, in favour of a future
>>> solution that does not use cursor warping.
>>
>> I'm not really pushing my changes hard so it's kind of stale. Perhaps it
>> is better to rewrite the cursor composition patch in a way that does not
>> depend on the Virgl patch. I'm also aware that the cursor composition
>> using Core Graphics is somewhat laggy so it may be better to rewrite it
>> using subview, Core Animation, Metal, or something else. But I have not
>> done that yet.
> 
> Is there some Cocoa-native way of compositing within the window, that
> will work with or without a GL surface? Subviews sound appropriate.

I'm for subview because we can retain the current implementation using 
[-NSView drawRect:] for the screen output in this way. The current 
implementation using Core Graphics or OpenGL for cursor composition 
should be avoided as Core Graphics cannot accelerate it with GPU and 
OpenGL requires the deprecated CGL or an external library like ANGLE.

Regards,
Akihiko Odaki

> 
> Not that I have any influence, but I think your virgl patch is an
> excellent contribution and should go upstream.
> 
> Thanks again,
> 
> Elliot