Re: [PATCH 0/2] Input: Add keycodes for electronic privacy screen on/off an use these in dell-wmi

[Hans de Goede <hansg@kernel.org>]

Hi,

On 22-Oct-25 10:24 PM, Dmitry Torokhov wrote:
> On Wed, Oct 22, 2025 at 09:15:35PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 22-Oct-25 8:40 PM, Dmitry Torokhov wrote:
>>> On Wed, Oct 22, 2025 at 08:24:46PM +0200, Hans de Goede wrote:
>>>> Hi Dmitry,
>>>>
>>>> On 22-Oct-25 7:54 PM, Dmitry Torokhov wrote:
>>>>> Hi Hans,
>>>>>
>>>>> On Mon, Oct 20, 2025 at 05:23:29PM +0200, Hans de Goede wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Here is a patch series for adding support for the electronic privacy screen
>>>>>> on/off events send on e.g. Dell Latitude 7300 models.
>>>>>>
>>>>>> On these laptops the firmware does not allow querying the presence nor
>>>>>> the status of the eprivacy screen at boot. This makes it impossible to
>>>>>> implement the drm connector eprivacy properties API (1) since drm objects
>>>>>> do not allow adding new properties after creation and the presence of
>>>>>> the eprivacy cannot be detected at boot.
>>>>>>
>>>>>> So instead this series adds 2 evdev keycodes for eprivacy screen on + off
>>>>>> and modifies the dell-wmi driver to use these, so that we can still
>>>>>> propagate these events to userspace for e.g. a DE to show an OSD.
>>>>>>
>>>>>> Dmitry, can we get your ack for the addition of the 2 new keycodes?
>>>>>> I think it will be easiest if Ilpo merges the entire series through
>>>>>> the pdx86 tree with your ack for the keycodes.
>>>>>
>>>>> Yes, that should be fine, although I wonder if this is best modeled as a
>>>>> pair of keys or a single switch? I know we have touchpad on/off but I
>>>>> wonder if it was the best option... Probably more convenient at some
>>>>> point if it was done through the atkbd.
>>>>
>>>> EV_SW has the same problem as the drm property API. The mere presence
>>>> of advertising a new SW_PRIVACY_SCREEN capability on an /dev/input/event#
>>>> node would convey to userspace that there is an eprivacy-screen and we
>>>> also would need to know the initial state (on/off) for using an EV_SW
>>>> for this and we know neither presence nor status before hand (1).
>>>
>>> How is this different form presence of KEY_PRIVACY_SCREEN_ON/OFF? They
>>> also imply that there is a privacy screen.
>>
>> I've never seen userspace change behavior depending on which keycodes
>> are advertised as possibly being send by a device.
> 
> On Chrome OS we are trying to go by what peripherals report, but I can
> see that it might not work for a generic Linux distro.
> 
>>
>> Typically userspace does not care of the initial state of keys (it
>> assumes they all start unpressed), where as for switches the initial
>> state matters and we cannot query the initial state here.
>>
>>> If we really do not know if there is functionality present or not maybe
>>> you can register a 2nd input device for the privacy switch upon
>>> receiving the first event for it?
>>
>> Yes that is one of the hacks which we use for SW_TABLET_MODE, but
>> I do really see this as a hack and I would like to avoid this if
>> possible.
>>
>>>> The real issue is that the firmware does not tell us if there is
>>>> an eprivacy screen. As mentioned the first time we find out is when
>>>> the eprivacy screen gets toggled on or off.
>>>>
>>>> We are having similar issues with SW_TABLET_MODE which userspace
>>>> uses to e.g. show / not show an on screen keyboard when a text
>>>> entry field is focussed. So the mere presence of SW_TABLET_MODE
>>>> can influence userspace without ever sending any events and we
>>>> have all kind of special handling in various foo-laptop and
>>>> intel-vbtn, etc. drivers for this, which I would like to avoid
>>>> here.
>>>
>>> Probably have a similar solution: delay registration of corresponding
>>> input device until you know the existence/state?
>>
>> Right that is already done in some cases. What complicates things
>> wrt SW_TABLET_MODE is that we would like to have it present as soon
>> as the driver probes so that a 2-in-1 which is booted in tablet mode
>> behaves correctly from the start. Most of the firmware APIs for
>> SW_TABLET_MODE support getting the initial state, but their implementation
>> can be unreliable. So we only fallback to the delayed registration
>> for known unreliable models, which requires quirks...
>>
>> This is getting a bit offtopic but it does show why I'm not in
>> favor of using EV_SW style input-devices when there is no reliable
>> initial state.
>>
>>>> So having ON / OFF EV_KEY events which we only generate when
>>>> there is an actual eprivacy on/off event are by far the most KISS
>>>> and fool proof solution.
>>>
>>> This assumes you assign special meaning to it (i.e. pretend that it is
>>> not really there until you see events).
>>
>> As I see it there are 2 cases:
>>
>> 1. We can query the presence and status of the eprivacy screen at
>> boot, this would map nicely to a SW_EPRIVACY_SCREEN, but we already
>> have the drm properties API for this and this was put in DRM because
>> this ties the privacy screen to a specific output which is useful
>> to know.
>>
>> 2. The first thing we findout / hear about an eprivacy screen is
>> a eprivacy on/off hotkey press. Notice the "hotkey" there iow
>> this event gets send as the result of a key-press event.
>>
>> For 2. I think that just modelling this as the key events which
>> these also happen to actually be is much simpler then dynamically
>> registering a second input device on the first such a key press
>>
>> and I also think that the userspace side will be simpler with
>> just key-press events rather then having to deal with the dynamic
>> second device registration + reading an EV_SW .
> 
> OK, I agree that if you have a reliable way of querying the state you
> can simply go with the DRM properties solution.
> 
> Since this keys are in effect notification only, not something that
> userspace needs to actively handle, I don't suppose you can add another
> state to the DRM privacy-screen hw-state: "unknown" and update it when  
> the state becomes known?

That would break existing userspace consumers of the API and this is
not just about not being able to query the initial state it is also
about not being able to query if there the eprivacy screen option is
installed at all. The presence of the drm-properties currently lets
to userspace that there is an eprivacy screen present and e.g. will
make gnome-control-center show a toggle to turn it on/off IIRC.

Regards,

Hans