Hi Mark,
On 4/15/20 7:14 PM, Mark Pearson wrote:
Hi,
-----Original Message----- From: Hans de Goede hdegoede@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@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
We are not asking for changing the hotkey, what we would like is for the hotkey to only send a notification that it was pressed and for it to not actually do anything with the ePrivacy screen state. This does not need to be it defaults behavior, but we would like to be able to ask the firmware to not act on it itself, just like we can already disable the firmware/embedded controller responding to e.g. brightness up/down key presses itself.
Regards,
Hans