Hi Mark,
On 4/15/20 7:14 PM, Mark Pearson wrote:
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
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
