Hi, > -----Original Message----- > From: Hans de Goede <hdegoede@xxxxxxxxxx> > 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@xxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
