From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: New sysfs interface for privacy screens Date: Tue, 1 Oct 2019 18:27:10 +0200 Message-ID: <20191001162710.GB3526634@kroah.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Mat King Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, rafael@kernel.org, Ross Zwisler , Rajat Jain , Lee Jones , Daniel Thompson , Jingoo Han List-Id: dri-devel@lists.freedesktop.org On Tue, Oct 01, 2019 at 10:09:46AM -0600, Mat King 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 What is "cros_privacy" here? > Does this approach seem to be reasonable? Seems sane to me, do you have any code that implements this so we can see it? thanks, greg k-h