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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 3/19/20 3:48 PM, Pekka Paalanen wrote:
On Thu, 19 Mar 2020 14:51:41 +0100
Michel Dänzer <michel@xxxxxxxxxxx> 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@xxxxxxxxxx> 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

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux