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 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).

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.

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.

Regards,

Hans