[External] Re: RFC: Drm-connector properties managed by another driver / privacy screen support
Hans de Goede
hdegoede at redhat.com
Wed Apr 15 18:06:51 UTC 2020
Hi Mark,
On 4/15/20 7:14 PM, Mark Pearson wrote:
> 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
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
More information about the dri-devel
mailing list