On Wed, Oct 02, 2019 at 12:30:05PM +0300, Jani Nikula wrote: > On Tue, 01 Oct 2019, Mat King <mathewk@xxxxxxxxxx> wrote: > > Resending in plain text mode > > > > I have been looking into adding Linux support for electronic privacy > > screens which is a feature on some new laptops which is built into the > > display and allows users to turn it on instead of needing to use a > > physical privacy filter. In discussions with my colleagues the idea of > > using either /sys/class/backlight or /sys/class/leds but this new > > feature does not seem to quite fit into either of those classes. > > > > I am proposing adding a class called "privacy_screen" to interface > > with these devices. The initial API would be simple just a single > > property called "privacy_state" which when set to 1 would mean that > > privacy is enabled and 0 when privacy is disabled. > > > > Current known use cases will use ACPI _DSM in order to interface with > > the privacy screens, but this class would allow device driver authors > > to use other interfaces as well. > > > > Example: > > > > # get privacy screen state > > cat /sys/class/privacy_screen/cros_privacy/privacy_state # 1: privacy > > enabled 0: privacy disabled > > > > # set privacy enabled > > echo 1 > /sys/class/privacy_screen/cros_privacy/privacy_state > > > > Does this approach seem to be reasonable? > > What part of the userspace would be managing the privacy screen? Should > there be a connection between the display and the privacy screen that > covers the display? How would the userspace make that connection if it's > a sysfs interface? > > I don't know how the privacy screen operates, but if it draws any power, > you'll want to disable it when you switch off the display it covers. > > If the privacy screen control was part of the graphics subsystem (say, a > DRM connector property, which feels somewhat natural), I think it would > make it easier for userspace to have policies such as enabling the > privacy screen automatically depending on the content you're viewing, > but only if the content is on the display that has a privacy screen. Connectors versus sysfs came up on a backlight thread recently. Daniel Vetter wrote an excellent summary on why it has been (and still is) difficult to migrate backlight controls towards the DRM connector interface: https://lkml.org/lkml/2019/8/20/752 Many of the backlight legacy problems do not apply to privacy screens but I do suggest reading this post and some of the neighbouring parts of the thread. In particular the ACPI driver versus real driver issues Daniel mentioned could occur again. Hopefully not though, I mean how wrong can a 1-bit control go? (actually no... don't answer that). It would definitely be a shame to build up an unnecessary sysfs legacy for privacy screens so definitely worth seeing if this can use DRM connector properties. Daniel. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
