From: Pekka Paalanen <ppaalanen@gmail.com>
To: Zack Rusin <zackr@vmware.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
David Airlie <airlied@linux.ie>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Gurchetan Singh <gurchetansingh@chromium.org>,
Martin Krastev <krastevm@vmware.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
wayland-devel <wayland-devel@lists.freedesktop.org>,
Maaz Mombasawala <mombasawalam@vmware.com>
Subject: Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
Date: Mon, 6 Jun 2022 12:13:27 +0300 [thread overview]
Message-ID: <20220606121327.5dba8381@eldfell> (raw)
In-Reply-To: <06E05345-758E-456A-803D-B50978A935CA@vmware.com>
[-- Attachment #1: Type: text/plain, Size: 3816 bytes --]
On Fri, 3 Jun 2022 14:38:54 +0000
Zack Rusin <zackr@vmware.com> wrote:
> > On Jun 3, 2022, at 10:32 AM, Simon Ser <contact@emersion.fr> wrote:
> >
> > ⚠ External Email
> >
> > On Friday, June 3rd, 2022 at 16:27, Zack Rusin <zackr@vmware.com> wrote:
> >
> >>> In particular: since the driver will ignore the KMS cursor plane
> >>> position set by user-space, I don't think it's okay to just expose
> >>> without opt-in from user-space (e.g. with a DRM_CLIENT_CAP).
> >>>
> >>> cc wayland-devel and Pekka for user-space feedback.
> >>
> >> I think Thomas expressed our concerns and reasons why those wouldn’t
> >> work for us back then. Is there something else you’d like to add?
> >
> > I disagreed, and I don't understand Thomas' reasoning.
> >
> > KMS clients will need an update to work correctly. Adding a new prop
> > without a cap leaves existing KMS clients broken. Adding a cap allows
> > both existing KMS clients and updated KMS clients to work correctly.
>
> I’m not sure what you mean here. They are broken right now. That’s
> what we’re fixing. That’s the reason why the virtualized drivers are
> on deny-lists for all atomic kms. So nothing needs to be updated. If
Hi Zack,
please, stop removing all email quoting level indicators, you have been
doing that a lot in your more recent replies. It makes reading the
emails really difficult, and I had to stop trying to make sense of the
latest emails.
It is really unfortunate that display servers have driver deny-lists
indeed. All the bug reports they got from being broken should have been
denied and forwarded to the respective drivers instead for breaking the
KMS UAPI. OTOH, I understand that some userspace projects do not want
to stop because of few broken but popular drivers.
> you have a kms client that was using virtualized drivers with atomic
> kms then mouse clicks never worked correctly. So, yes, clients need
> to set cursor hotspot if they want mouse to work correctly with
> virtualized drivers.
I'm very much agreeing with Simon. He has made similar questions and
comments that occurred to me.
Reading as much of the discussion between Simon and Zack as I could, it
seems every time Simon gets to the point, Zack hops to a completely
different use case to make Simon's argument no longer apply.
Like, root-window-less per-window remoting through KMS? How is that even
possible?
> >>> On Thursday, June 2nd, 2022 at 17:42, Zack Rusin zack@kde.org wrote:
> >>>
> >>>> - all userspace code needs to hardcore a list of drivers which require
> >>>> hotspots because there's no way to query from drm "does this driver
> >>>> require hotspot"
> >>>
> >>> Can you elaborate? I'm not sure I understand what you mean here.
> >>
> >> Only some drivers require informations about cursor hotspot, user space
> >> currently has no way of figuring out which ones are those, i.e. amdgpu
> >> doesn’t care about hotspots, qxl does so when running on qxl without
> >> properly set cursor hotspot atomic kms will result in a desktop where
> >> mouse clicks have incorrect coordinates.
> >>
> >> There’s no way to differentiate between drivers that do not care about
> >> cursor hotspots and ones that absolutely require it.
> >
> > Only VM drivers should expose the hotspot properties. Real drivers like
> > amdgpu must not expose it.
>
> Yes, that’s what I said. There’s no way to differentiate between
> amdgpu that doesn’t have those properties and virtio_gpu driver from
> a kernel before hotspot properties were added.
Why would userspace want to tell the difference between a driver that
truly does not need those properties, and a driver that did not add
those properties *yet*?
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-06-06 9:13 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-02 15:42 [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS Zack Rusin
2022-06-02 15:42 ` [PATCH 1/6] drm/atomic: Add support for mouse hotspots Zack Rusin
2022-06-02 15:42 ` [PATCH 2/6] drm/vmwgfx: Create mouse hotspot properties on cursor planes Zack Rusin
2022-06-03 13:11 ` Martin Krastev (VMware)
2022-06-02 15:42 ` [PATCH 3/6] drm/qxl: " Zack Rusin
2022-06-02 22:05 ` kernel test robot
2022-06-02 23:26 ` kernel test robot
2022-06-02 15:42 ` [PATCH 4/6] drm/vboxvideo: " Zack Rusin
2022-06-02 15:42 ` [PATCH 5/6] drm/virtio: " Zack Rusin
2022-06-02 15:42 ` [PATCH 6/6] drm: Remove legacy cursor hotspot code Zack Rusin
2022-06-03 10:28 ` [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS Gerd Hoffmann
2022-06-03 14:43 ` Zack Rusin
2022-06-03 14:14 ` Simon Ser
2022-06-03 14:27 ` Zack Rusin
2022-06-03 14:32 ` Simon Ser
2022-06-03 14:38 ` Zack Rusin
2022-06-03 14:56 ` Simon Ser
2022-06-03 15:17 ` Zack Rusin
2022-06-03 15:22 ` Simon Ser
2022-06-03 15:32 ` Zack Rusin
2022-06-03 15:49 ` Simon Ser
2022-06-03 18:31 ` Zack Rusin
2022-06-05 7:30 ` Simon Ser
2022-06-05 15:47 ` Zack Rusin
2022-06-05 16:26 ` Simon Ser
2022-06-05 18:16 ` Zack Rusin
2022-06-06 8:11 ` Simon Ser
2022-06-04 21:19 ` Hans de Goede
2022-06-05 7:34 ` Simon Ser
2022-06-07 11:25 ` Gerd Hoffmann
2022-06-06 9:13 ` Pekka Paalanen [this message]
2022-06-07 8:07 ` Pekka Paalanen
2022-06-07 14:30 ` Gerd Hoffmann
2022-06-08 7:53 ` Pekka Paalanen
2022-06-08 14:52 ` Gerd Hoffmann
2022-06-07 17:50 ` Zack Rusin
2022-06-08 7:53 ` Pekka Paalanen
2022-06-09 19:39 ` Zack Rusin
2022-06-10 7:49 ` Pekka Paalanen
2022-06-10 8:22 ` Jonas Ådahl
2022-06-10 8:54 ` Simon Ser
2022-06-10 9:01 ` Daniel Vetter
2022-06-10 8:41 ` Daniel Vetter
2022-06-10 8:56 ` Pekka Paalanen
2022-06-10 8:59 ` Daniel Vetter
2022-06-10 12:03 ` Gerd Hoffmann
2022-06-10 14:24 ` Zack Rusin
2022-06-13 7:33 ` Pekka Paalanen
2022-06-13 13:14 ` Zack Rusin
2022-06-13 14:25 ` Pekka Paalanen
2022-06-13 14:54 ` Zack Rusin
2022-06-14 7:36 ` Pekka Paalanen
2022-06-14 14:40 ` Zack Rusin
2022-06-14 14:54 ` Daniel Stone
2023-06-09 15:20 ` Albert Esteve
2023-06-21 7:10 ` Javier Martinez Canillas
2023-06-22 4:29 ` Zack Rusin
2023-06-22 6:20 ` Javier Martinez Canillas
2022-06-10 9:15 ` Simon Ser
2022-06-10 9:49 ` Daniel Vetter
2022-06-10 12:36 ` Gerd Hoffmann
2022-06-10 12:53 ` Simon Ser
2022-06-11 15:34 ` Hans de Goede
2022-06-13 7:45 ` Pekka Paalanen
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=20220606121327.5dba8381@eldfell \
--to=ppaalanen@gmail.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=hdegoede@redhat.com \
--cc=krastevm@vmware.com \
--cc=kraxel@redhat.com \
--cc=mombasawalam@vmware.com \
--cc=tzimmermann@suse.de \
--cc=wayland-devel@lists.freedesktop.org \
--cc=zackr@vmware.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;
as well as URLs for NNTP newsgroup(s).