Atomic KMS API lacks the ability to set cursor hot-spot coordinates

[Hans de Goede]

Hi,

On 3/19/20 3:48 PM, Pekka Paalanen wrote:
> On Thu, 19 Mar 2020 14:51:41 +0100
> Michel Dänzer <michel at daenzer.net> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 2020-03-19 1:54 p.m., Pekka Paalanen wrote:
>>> On Thu, 19 Mar 2020 12:52:14 +0100 Hans de Goede
>>> <hdegoede at redhat.com> wrote:
>>>> On 3/19/20 12:35 PM, Michel Dänzer wrote:
>>>>> On 2020-03-18 4:22 p.m., Simon Ser wrote:
>>>>>>>
>>>>>>> On 3/18/20 3:38 PM, Simon Ser wrote:
>>>>>>>>   
>>>>>>>>> 1) Letting the VM-viewer window-system draw the cursor
>>>>>>>>> as it normally would draw it.
>>>>>>>>
>>>>>>>> Why is this important? Can't the VM viewer hide the
>>>>>>>> cursor and use a sub-surface to manually draw the cursor
>>>>>>>> plane configured by the guest?
>>>>>>>
>>>>>>> Because then moving the cursor as seen by the user requires
>>>>>>> a round trip through the VM and that adds latency, esp.
>>>>>>> when the VM viewer is viewing a VM which is running
>>>>>>> somewhere else over the network.
>>>>>>
>>>>>> The video output has latency anyway.
>>>>>
>>>>> Sounds like you've never tried the two different modes
>>>>> yourself? :) IME it makes a big difference even with a local
>>>>> VM. Even very little latency can make the cursor feel awkward,
>>>>> like it's being held back by a rubber band or something.
>>>>
>>>> Right not to mention that the latency may be variable, so the
>>>> cursor moves in a jittery fashion instead of having it move
>>>> smoothly matching the smooth way a user normally moves the
>>>> mouse.
>>>>
>>>> This totally wrecks hand-eye coordination and is just plain
>>>> awefull.
>>>
>>> I have experienced it, and while it is painful, I prefer that pain
>>> over the pain of accidentally clicking something that was not
>>> transmitted to the remote display yet.
>>
>> Unless you mean clicking something while the cursor is moving, not
>> sure how seamless vs not affects this, since the delay of something
>> appearing on the remote display should be the same in both cases?
> 
> How do you know if the cursor is still moving or not, if you don't see
> the real cursor but only the fake cursor?
> 
> I move the mouse, then it takes 0.1 - 10 seconds for the real cursor
> to reach where I moved it. Only after that I see what the motion
> caused. Then I can do the next thing.
> 
> The mouse motion / cursor response gives me continuous feedback, so
> that I don't run too far ahead of the remote end.
> 
>>> Therefore I think the best user experience is to use both types of
>>> cursor at the same time: the remote desktop or VM viewer paints
>>> the local cursor as an aid, like a phantom, and the cursor from
>>> inside the VM is also visible with the latency it naturally has.
>>> That means I could actually see that the screen has caught up with
>>> my motions before I click something.
>>
>> I'd expect that to result in "duplicate cursor" bug reports — I'd
>> certainly consider it a bug with my user hat on.
> 
> The point is to make the phantom cursor look like a phantom cursor, so
> it cannot be mistaken as the real cursor. It doesn't even need to use
> the same cursor image as the real cursor, it could be just a
> translucent spot.

I think you are trying to fix a non existing problem here, accept
for say a game of whack a mode, the target which the user is trying
to hit is typically static and the VM will receive and process the
coordinates where the user stops the motion, before it will receive
and process the click. So unless say an icon on a toolbar for some
reason is a moving target there is no problem here.

Regards,

Hans