[External] Re: RFC: Drm-connector properties managed by another driver / privacy screen support

[Mark Pearson]

Hi,

> -----Original Message-----
> From: Hans de Goede <hdegoede at redhat.com>
> Sent: Wednesday, April 15, 2020 11:41 AM
> On 4/15/20 5:28 PM, Jani Nikula wrote:
> > On Wed, 15 Apr 2020, Hans de Goede <hdegoede at redhat.com> wrote:
> > 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.
> 
Afraid, the "hotkeys" control for ePrivacy (Fn+D I believe) is very unlikely 
to change - Windows uses it as well...
We can do notification of any hotkey presses to update the DRM layer (and
userspace) if that helps