On Sun, 9 Jun 2024 at 11:06, Akihiko Odaki <akihiko.od...@daynix.com> wrote:
> Thanks for working on ui/cocoa, but I already have submitted a patch for > this particular problem: > https://patchew.org/QEMU/20240318-cursor-v1-0-0bbe6c382...@daynix.com/ > Sorry, I missed this patch set - thanks for bringing it to my attention. > The difference between these patches is that my patch does not use > warping at all. I thought reversing the mouse movement bias is a fragile > approach that depends on the details of how Quartz works. > Hmm. So, I agree that the relative cursor implementation with NSCursor is somewhat awkward. I'm not sure it's as fragile as you make out as the behaviour of the APIs used hasn't changed in decades and has plenty of existing software depending on it. Still, it might behave awkwardly in the context of other apps warping the cursor at the same time. I also definitely think host cursor integration is useful and valuable, at least in absolute pointing mode - for example, when the host system is itself being remote controlled, and also to avoid the cursor being cropped near the edges of the guest viewport. The CALayer based rendering makes sense to me in relative mode though. For one, it avoids the complicated event offsets. The cursor cropping actually makes sense as a visual cue when the cursor is actually constrained to the guest viewport while mouse input is grabbed. And because the guest cursor is decoupled from the host cursor even after ungrabbing, it makes sense to continue rendering it even when Qemu has relinquished the host cursor. I've therefore reworked my NSCursor code on top of your CALayer cursor and change notifier work so that the NSCursor is visible and updated with the guest's cursor image when in absolute mode, and the CALayer draws the cursor in relative mode. Because of the chain of patch dependencies I've staged it on gitlab here for initial feedback/testing/review: https://gitlab.com/pmdj/qemu-upstreaming/-/compare/master...m-cocoa-cursors-2.0?from_project_id=53960510&straight=false Let me know what you think. If we decide to go with this approach we can post our respective patches as a combined v2 patchset to the list. Incidentally, that version of my NSCursor patch includes a few refinements/fixes to the CALayer patch which I'll tease out into a separate commit, and which I'd recommend applying even if consensus settles on a CALayer-only approach. (setCursor: was rather long and messy; it also leaked a colour space object; layer and cursor objects would leak if the view was hypothetically dealloc'd) Thanks, Phil