From: "Michel Dänzer" <michel@daenzer.net>
To: Pekka Paalanen <ppaalanen@gmail.com>,
Hans de Goede <hdegoede@redhat.com>
Cc: "Jonas Ådahl" <jadahl@redhat.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: Atomic KMS API lacks the ability to set cursor hot-spot coordinates
Date: Thu, 19 Mar 2020 14:51:41 +0100 [thread overview]
Message-ID: <c7a98456-d4fc-e4d2-640f-d70a35619445@daenzer.net> (raw)
In-Reply-To: <20200319145440.51773af8@eldfell.localdomain>
-----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@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?
> 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.
- --
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXnN45gAKCRBaga+Oatuy
AEMOAJsEtOvBJIA6CGHOmwrp7SFd9M3o2wCfcCs7lCrCNsHxAels/4YUXm5FJas=
=FfIQ
-----END PGP SIGNATURE-----
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-03-19 13:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 14:28 Atomic KMS API lacks the ability to set cursor hot-spot coordinates Hans de Goede
2020-03-18 14:38 ` Simon Ser
2020-03-18 15:04 ` Hans de Goede
2020-03-18 15:22 ` Simon Ser
2020-03-19 11:35 ` Michel Dänzer
2020-03-19 11:52 ` Hans de Goede
2020-03-19 12:54 ` Pekka Paalanen
2020-03-19 13:51 ` Michel Dänzer [this message]
2020-03-19 14:48 ` Pekka Paalanen
2020-03-19 15:01 ` Hans de Goede
2020-03-19 9:57 ` Pekka Paalanen
2020-03-19 10:00 ` Simon Ser
2020-03-18 14:39 ` Hans de Goede
2020-03-18 15:09 ` Daniel Vetter
2020-03-18 22:20 ` Hans de Goede
2020-03-19 10:00 ` Pekka Paalanen
2020-03-19 11:49 ` Hans de Goede
2020-03-19 12:58 ` Pekka Paalanen
2020-03-19 13:16 ` Daniel Vetter
2020-03-19 13:24 ` Simon Ser
2020-03-19 14:30 ` Hans de Goede
2020-03-19 15:16 ` Pekka Paalanen
2020-03-19 18:18 ` Hans de Goede
2020-03-19 20:14 ` Simon Ser
2020-03-19 20:49 ` Hans de Goede
2020-03-19 21:07 ` Simon Ser
2020-03-19 22:57 ` Thomas Hellström (VMware)
2020-03-20 9:13 ` Pekka Paalanen
2020-03-20 10:59 ` Thomas Hellström (VMware)
2020-03-20 11:27 ` Simon Ser
2020-03-20 11:47 ` Thomas Hellström (VMware)
2020-03-21 8:56 ` Thomas Hellström (VMware)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c7a98456-d4fc-e4d2-640f-d70a35619445@daenzer.net \
--to=michel@daenzer.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=jadahl@redhat.com \
--cc=ppaalanen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox