From: Daniel Vetter <daniel@ffwll.ch>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Benjamin Berg <bberg@redhat.com>, David Airlie <airlied@linux.ie>,
Christian Kellner <ckellner@redhat.com>,
Javier Martinez Canillas <javierm@redhat.com>,
Hans de Goede <hdegoede@redhat.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Nitin Joshi1 <njoshi1@lenovo.com>,
Rajat Jain <rajatja@google.com>,
Mark Pearson <mpearson@lenovo.com>
Subject: Re: RFC: Drm-connector properties managed by another driver / privacy screen support
Date: Fri, 17 Apr 2020 16:18:51 +0200 [thread overview]
Message-ID: <CAKMK7uHKXTqwvyr3ocU4N+kpAnUBBZTjULSofqjP+0PcvGcFNQ@mail.gmail.com> (raw)
In-Reply-To: <87k12e2uoa.fsf@intel.com>
On Fri, Apr 17, 2020 at 1:55 PM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Fri, 17 Apr 2020, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > On Wed, 15 Apr 2020 17:40:46 +0200
> > Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> Hi,
> >>
> >> On 4/15/20 5:28 PM, Jani Nikula wrote:
> >> > On Wed, 15 Apr 2020, Hans de Goede <hdegoede@redhat.com> wrote:
> >> >> ii. Currently the "privacy-screen" property added by Rajat's
> >> >> patch-set is an enum with 2 possible values:
> >> >> "Enabled"
> >> >> "Disabled"
> >> >>
> >> >> We could add a third value "Not Available", which would be the
> >> >> default and then for internal panels always add the property
> >> >> so that we avoid the problem that detecting if the laptop has
> >> >> an internal privacy screen needs to be done before the connector
> >> >> is registered. Then we can add some hooks which allow an
> >> >> lcdshadow-driver to register itself against a connector later
> >> >> (which is non trivial wrt probe order, but lets ignore that for now).
> >> >
> >> > I regret dropping the ball on Rajat's series (sorry!).
> >> >
> >> > I do think having the connector property for this is the way to go.
> >>
> >> I 100% agree.
> >>
> >> > Even
> >> > if we couldn't necessarily figure out all the details on the kernel
> >> > internal connections, can we settle on the property though, so we could
> >> > move forward with Rajat's series?
> >>
> >> Yes please, this will also allow us to move forward with userspace
> >> support even if for testing that we do some hacks for the kernel's
> >> internal connections for now.
> >>
> >> > Moreover, do we actually need two properties, one which could indicate
> >> > userspace's desire for the property, and another that tells the hardware
> >> > state?
> >>
> >> No I do not think so. I would expect there to just be one property,
> >> I guess that if the state is (partly) firmware controlled then there
> >> might be a race, but we will need a notification mechanism (*) for
> >> firmware triggered state changes anyways, so shortly after loosing
> >> the race userspace will process the notification and it will know
> >> about it.
> >>
> >> One thing which might be useful is a way to signal that the property
> >> is read-only in case we ever hit hw where that is the case.
> >>
> >> > I'd so very much like to have no in-kernel/in-firmware shortcuts
> >> > to enable/disable the privacy screen, and instead have any hardware
> >> > buttons just be events that the userspace could react to. However I
> >> > don't think that'll be the case unfortunately.
> >>
> >> In my experience with keyboard-backlight support, we will (unfortunately)
> >> see a mix and in some case we will get a notification that the firmware
> >> has adjusted the state, rather then just getting a keypress and
> >> dealing with that ourselves. In some cases we may even be able to
> >> choose, so the fw will deal with it by default but we can ask it
> >> to just send a key-press. But I do believe that we can *not* expect
> >> that we will always just get a keypress for userspace to deal with.
> >
> > Hi,
> >
> > let's think about how userspace uses atomic KMS UAPI. The simplest way
> > to use atomic correctly is that userspace will for every update send the
> > full, complete set of all properties that exist, both known and unknown
> > to userspace (to recover from temporarily VT-switching to another KMS
> > program that changes unknown properties). Attempting to track which
> > properties already have their correct values in the kernel is extra
> > work for just extra bugs.
> >
> > Assuming the property is userspace-writable: if kernel goes and
> > changes the property value on its own, it will very likely be just
> > overwritten by userspace right after if userspace does not manage to
> > process the uevent first. If that happens and userspace later
> > processes the uevent, userspace queries the kernel for the current
> > proprerty state which is now what userspace wrote, not what firmware
> > set.
> >
> > Therefore you end up with the firmware hotkey working only randomly.
> >
> > It would be much better to have the hotkey events delivered to
> > userspace so that userspace can control the privacy screen and
> > everything will be reliable, both the hotkeys and any GUI for it.
>
> I'd like this too. However I fear this is out of our control, and OEMs
> have and will anyway fiddle with the privacy screen directly no matter
> what we say, and we can't prevent that. From their POV it's easier for
> them to do their value-add in components they have total control over. I
> emphatize with that view, even if it's counter-productive from the Linux
> ecosystem POV.
>
> So we'll just have to deal with it.
>
> > The other reliable option is that userspace must never be able to
> > change privacy screen state, only the hardware hotkeys can.
>
> That, in turn, discourages anyone from doing the right thing, and blocks
> us from adding any nice additional features for privacy screens that
> only the userspace is capable of managing. For example, controlling
> privacy screen based on content, which seems like an obvious feature.
>
> I suppose rf-kill is a bit similar.
>
> You'd have a userspace controlled property to state what the userspace
> wants, and a kernel controlled property to show the hardware
> state. Userspace can ask for one or the other, and usually this happens,
> but the hardware hotkey bypasses the whole thing.
>
> It's not perfect. But I think just one property changed nilly-willy by
> both the kernel and userspace (especially when it's really not in the
> kernel's full control either) is going to be a PITA.
Yeah that's what we've done in other cases where both kernel and
userspace can change stuff. These where just tri-states, but this here
sounds like we need all for, so best to just have 2 properties.
-Daniel
>
> BR,
> Jani.
>
>
>
> >
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >> *) Some udev event I guess, I sorta assume there already is a
> >> notification mechanism for property change notifications ?
> >
> > Yes, such mechanism has been discussed before, see the thread containing
> > https://lists.freedesktop.org/archives/dri-devel/2019-May/217588.html
> >
> > TL;DR: the mechanism exists and is called the hotplug event. But the
> > problem with the hotplug event is that it carries no information about
> > what changed, so userspace is forced re-discover everything about the
> > DRM device. That thread discusses extending the hotplug event to be
> > able to signal changes in individual properties rather than "something
> > maybe changed, you figure out what".
> >
> >
> > Thanks,
> > pq
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-04-17 14:19 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 9:42 RFC: Drm-connector properties managed by another driver / privacy screen support Hans de Goede
2020-04-15 9:52 ` Daniel Vetter
2020-04-15 10:11 ` Hans de Goede
2020-04-15 10:22 ` Daniel Vetter
2020-04-15 11:39 ` Hans de Goede
2020-04-15 11:56 ` Hans de Goede
2020-04-15 12:01 ` Daniel Vetter
2020-04-15 13:02 ` Hans de Goede
2020-04-15 17:54 ` Daniel Vetter
2020-04-15 18:19 ` Hans de Goede
2020-04-15 18:29 ` Daniel Vetter
2020-04-15 19:50 ` Hans de Goede
2020-04-16 6:46 ` Daniel Vetter
2020-04-15 15:28 ` Jani Nikula
2020-04-15 15:40 ` Hans de Goede
2020-04-15 17:14 ` [External] " Mark Pearson
2020-04-15 18:06 ` Hans de Goede
2020-04-15 19:20 ` Rajat Jain
2020-04-15 21:10 ` Jani Nikula
2020-04-15 21:21 ` Hans de Goede
2020-04-15 21:51 ` [External] " Mark Pearson
2020-04-17 9:05 ` Pekka Paalanen
2020-04-17 9:02 ` Pekka Paalanen
2020-04-17 11:55 ` Jani Nikula
2020-04-17 14:18 ` Daniel Vetter [this message]
2020-04-17 14:54 ` Benjamin Berg
2020-04-21 12:37 ` Hans de Goede
2020-04-21 12:40 ` Daniel Vetter
2020-04-21 14:46 ` Pekka Paalanen
2020-04-23 18:21 ` Rajat Jain
2020-04-24 7:40 ` Pekka Paalanen
2020-04-24 8:24 ` Hans de Goede
2020-04-24 9:08 ` Pekka Paalanen
2020-04-24 10:32 ` Hans de Goede
2020-04-17 14:17 ` Daniel Vetter
2020-04-20 8:27 ` Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support) Pekka Paalanen
2020-04-20 10:04 ` Pekka Paalanen
2020-04-20 10:18 ` Simon Ser
2020-04-21 12:15 ` Daniel Vetter
2020-04-21 14:33 ` Pekka Paalanen
2020-04-21 14:39 ` Simon Ser
2020-04-23 15:01 ` Daniel Vetter
2020-04-24 8:32 ` Pekka Paalanen
2020-04-28 14:51 ` Daniel Vetter
2020-04-29 10:07 ` Pekka Paalanen
2020-04-30 13:53 ` Daniel Vetter
2020-05-04 9:49 ` Pekka Paalanen
2020-05-04 11:00 ` Daniel Vetter
2020-05-04 12:22 ` Pekka Paalanen
2020-05-05 8:48 ` Daniel Vetter
2020-05-07 9:03 ` Pekka Paalanen
2020-04-20 10:15 ` Simon Ser
2020-04-20 12:22 ` Pekka Paalanen
2020-04-20 12:33 ` Simon Ser
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=CAKMK7uHKXTqwvyr3ocU4N+kpAnUBBZTjULSofqjP+0PcvGcFNQ@mail.gmail.com \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=bberg@redhat.com \
--cc=ckellner@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=jani.nikula@linux.intel.com \
--cc=javierm@redhat.com \
--cc=mpearson@lenovo.com \
--cc=njoshi1@lenovo.com \
--cc=rajatja@google.com \
--cc=tzimmermann@suse.de \
/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).