Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp4704888ybp; Mon, 7 Oct 2019 12:33:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqyI8PKopFGkEGb+MsXTAextL74z0WjzEuRTJ7E0qIqBi4VP79ow3fSR/d61o5jRsS6T3DiT X-Received: by 2002:a17:906:4a17:: with SMTP id w23mr16979510eju.324.1570476824753; Mon, 07 Oct 2019 12:33:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570476824; cv=none; d=google.com; s=arc-20160816; b=r4Exzr05AsQpeVugWnUwC9Xt1Qczcw3IfskvBnHFReld/lHfxVEf5aSds7VQ9nCKmy 4RSlKu3igJ/4P7nBECam7LT5H9pPt3ys4ijkxUhIkIBA5ow/2yBrYJXh1EL/7iRwqEs6 /5BUEEEflMRNn/utR8I+Ya4msHYAPutVRhKBO98D/tRLFJyjmqccN3Jpngx3BXfADK9l oStdD4hUzQytQgmSF3tBUZ1iWd7FxJ+fCbfA78SYakVuVxY+XZwNpc+TPZ8bzghZn0Mz 7NyiCwaMZl41BmCXvvDMxf+aEFe8NAQi9e+RaxpmBwOGlniAb/Q7pvPnNBuHnh+/6WHC 7Ygg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=6janG/twynO5N6RLQTcAa8FnjT+uKYqGn399L8c11Xw=; b=xhyiuZIZ6bXgQtQTrKKVKDI6W/2YndKwBd3KBXHKXTSWieR4fbzANLOisvw4OsAysO FIxXy3UmTu+uO3S7MKjrnK/qTVb2l+8KtoUCVulIhcBxrxghtbOZmhrWcYRGiAT7V09K SeEzCDShE8L40WkYoDAjtYPbP8q8tDsX3rLmQx3qR9XeGairYTFYZ2qphuhF//H8ZsIu Rn1T2YjEVa8WHiKPP1Qgk+lwvPUNh/C+dNP4Yx3is3EjIoJpBIiXRvjgLn/DZrEKq4Av B0sKs1snu/B9WlDusJL/rHLvFlpSCTzA+9pnKSsZ54XRXtXidL23cUPs+0B7usZ+R1jP rF5w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IKWapvpN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h43si8711567ede.142.2019.10.07.12.33.21; Mon, 07 Oct 2019 12:33:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IKWapvpN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729419AbfJGTbs (ORCPT + 99 others); Mon, 7 Oct 2019 15:31:48 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:35257 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728187AbfJGTbs (ORCPT ); Mon, 7 Oct 2019 15:31:48 -0400 Received: by mail-lj1-f196.google.com with SMTP id m7so14971965lji.2 for ; Mon, 07 Oct 2019 12:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6janG/twynO5N6RLQTcAa8FnjT+uKYqGn399L8c11Xw=; b=IKWapvpNRq1xHEY7GPQfDPs22GMw9wvc21ZN5KRGPv/xYt3khp+SeCRMoM/fSpVKpB 4tXNJ8F0RIfSv24JeUQuNX6XWMz8Y65ue+gViSckr3CFvIDPdF++OXJLaYQfPy9D2jh5 TcqoFXRmbAK5Im/RmfuUsP5p0U6Z1RC2fgyC/biZl9Ao8jKUK6AKUF7OQVtB4X+W/TNA TMz2qnQlwqKynTBphxbH7vLfktSjT3VswEyLc57z+aX2gm6OMLZy6N3XV1Pf6cPRC9ew Ht9mtRDe2oFMFBITKZqXJW9BGSw+6Sd/Rz1dFtOPX5RXGw1yID007FMGGshWsGwW7+RJ lYXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6janG/twynO5N6RLQTcAa8FnjT+uKYqGn399L8c11Xw=; b=a3K7NrlmQVUF46WRet2kL4FF5cZyIrLoc9jFO0QP/OVZY8SrKlEaokbKvTC3hONyNK mJ/PMaswDGtx5HKJiQHHAfRQ1YbWkyzMoGtd2zNoTXLgaFNz3mjQy3bufJUZFuQ3Wdk6 5lwUMRV+ev+SW638UKVNUFcfz4O7kfxeFMxZn+lG95Yu15byEpG+Ahbl5w93enNdY4DN y7+5s6o5HgBgP8zrptl2qAH0ivPAt/BuqygYGSpuyTVRIziZjTev0On+90o+o+INAHMz QBRf6tOKZI3hvTBMOBBmNeAjeEOokgvQXRqs3fNpxO5lhyj4byyNJ64FNoZZmrf7PELI 3mYQ== X-Gm-Message-State: APjAAAWNZJWsrurMjiUpYB+zzH2DD+UzcKL1akt/zqXnKsz+yRDbokhZ fHi9g1zqizDbli0GALErxm6injv9WkbK4Onvnt2a2A== X-Received: by 2002:a2e:2e13:: with SMTP id u19mr17510537lju.112.1570476704924; Mon, 07 Oct 2019 12:31:44 -0700 (PDT) MIME-Version: 1.0 References: <87h84rbile.fsf@intel.com> <20191002102428.zaid63hp6wpd7w34@holly.lan> <8736gbbf2b.fsf@intel.com> <87h84q9pcj.fsf@intel.com> In-Reply-To: From: Rajat Jain Date: Mon, 7 Oct 2019 12:31:08 -0700 Message-ID: Subject: Re: New sysfs interface for privacy screens To: Mat King Cc: Sean Paul , Jani Nikula , Daniel Thompson , Linux Kernel Mailing List , dri-devel , "Rafael J. Wysocki" , Greg KH , Ross Zwisler , Jingoo Han , Lee Jones , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , David Airlie , Daniel Vetter , Alexander Schremmer , Andy Shevchenko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 7, 2019 at 9:19 AM Mat King wrote: > > On Mon, Oct 7, 2019 at 7:09 AM Sean Paul wrote: > > > > On Thu, Oct 3, 2019 at 3:57 PM Mat King wrote: > > > > > > On Thu, Oct 3, 2019 at 2:59 AM Jani Nikula wrote: > > > > > > > > On Wed, 02 Oct 2019, Mat King wrote: > > > > > On Wed, Oct 2, 2019 at 4:46 AM Jani Nikula wrote: > > > > >> > > > > >> On Wed, 02 Oct 2019, Daniel Thompson wrote: > > > > >> > On Wed, Oct 02, 2019 at 12:30:05PM +0300, Jani Nikula wrote: > > > > >> >> On Tue, 01 Oct 2019, Mat King wrote: > > > > >> >> > Resending in plain text mode > > > > /snip > > > > > > > > So my proposal would now be to add a new standard property to > > > drm_connector called "privacy_screen" this property would be an enum > > > which can take one of three values. > > > > > > PRIVACY_UNSUPPORTED - Privacy is not available for this connector > > > PRIVACY_DISABLED - Privacy is available but turned off > > > PRIVACY_ENABLED - Privacy is available and turned on > > > > Agree with Jani, use the property presence to determine if it's supported > > That makes sense; just to confirm can a property be added or removed > after the connector is registered? > > > > > > > > > When the connector is initized the privacy screen property is set to > > > PRIVACY_UNSUPPORTED and cannot be changed unless a drm_privacy_screen > > > is registered to the connector. drm_privacy_screen will look something > > > like > > > > > > struct drm_privacy_screen_ops { > > > int (*get_privacy_state)(struct drm_privacy_screen *); > > > int (*set_privacy_state)(struct drm_privacy_screen *, int); > > > } > > > > > > struct drm_privacy_screen { > > > /* The privacy screen device */ > > > struct device *dev; > > > > > > /* The connector that the privacy screen is attached */ > > > struct drm_connector *connector; > > > > > > /* Ops to get and set the privacy screen state */ > > > struct drm_privacy_screen_ops *ops; > > > > > > /* The current state of the privacy screen */ > > > int state; > > > } > > > > > > Privacy screen device drivers will call a function to register the > > > privacy screen with the connector. > > > > Do we actually need dedicated drivers for privacy screen? It seems > > like something that is panel-specific hardware, so I'd suggest just > > using the panel driver. > > The privacy screen is physically part of the display but the control > interface, at least in all current use cases, is ACPI. Is there a way > to control an ACPI device with the panel driver? I feel that doing it in a dedicated driver has the advantage that if we can standardise the control interface, it can be used across different panels. So a new panel can be supported using the existing driver by merely instantiating the right ACPI HID "privacy screen" device as a child device of the parent display / panel device. This parent-child relation would also give the kernel the connection needed about "which display does this privacy screen attach to". In future,if non-x86 platforms need the feature using a different control interface (say via a GPIO driver), the privacy screen driver can be updated to support that also. Thanks, Rajat > > > > > Sean > > > > > > > > int drm_privacy_screen_register(struct drm_privacy_screen_ops *ops, > > > struct device *dev, struct drm_connector *); > > > > > > Calling this will set a new field on the connector "struct > > > drm_privacy_screen *privacy_screen" and change the value of the > > > property to ops->get_privacy_state(). When > > > drm_mode_connector_set_obj_prop() is called with the > > > privacy_screen_proptery if a privacy_screen is registered to the > > > connector the ops->set_privacy_state() will be called with the new > > > value. > > > > > > Setting of this property (and all drm properties) is done in user > > > space using ioctrl. > > > > > > Registering the privacy screen with a connector may be tricky because > > > the driver for the privacy screen will need to be able to identify > > > which connector it belongs to and we will have to deal with connectors > > > being added both before and after the privacy screen device is added > > > by it's driver. > > > > > > How does that sound? I will work on a patch if that all sounds about right. > > > > > > One question I still have is there a way to not accept a value that is > > > passed to drm_mode_connector_set_obj_prop()? In this case if a privacy > > > screen is not registered the property must stay PRIVACY_UNSUPPORTED > > > and if a privacy screen is registered then PRIVACY_UNSUPPORTED must > > > never be set.