From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6E08C2BA19 for ; Wed, 15 Apr 2020 15:28:31 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A31002076A for ; Wed, 15 Apr 2020 15:28:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A31002076A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 330F16EA11; Wed, 15 Apr 2020 15:28:31 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3C9626EA11 for ; Wed, 15 Apr 2020 15:28:30 +0000 (UTC) IronPort-SDR: T6b2I0+1uij6R0fGvc/dtc+Sg5QVwsZqox34uOK1nJMRopRUptr70tWQzVd7uS2G128KVtoZ9j mttujm+LLdKA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2020 08:28:29 -0700 IronPort-SDR: XslvWqVCu6w9juW1Z31kpHkk+UOJCAbQSPgr9OWSXF2Vpfr9Gymw2Z+Qcl6NpYRH1w43HumraX 6w3RRuvV0Blg== X-IronPort-AV: E=Sophos;i="5.72,387,1580803200"; d="scan'208";a="427468375" Received: from ssolodk-mobl1.ccr.corp.intel.com (HELO localhost) ([10.252.48.37]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2020 08:28:24 -0700 From: Jani Nikula To: Hans de Goede , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter Subject: Re: RFC: Drm-connector properties managed by another driver / privacy screen support In-Reply-To: <783240e9-e8d1-fc28-6c11-14c8f8e35cfa@redhat.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <783240e9-e8d1-fc28-6c11-14c8f8e35cfa@redhat.com> Date: Wed, 15 Apr 2020 18:28:21 +0300 Message-ID: <87tv1k4vl6.fsf@intel.com> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Benjamin Berg , Christian Kellner , Javier Martinez Canillas , "dri-devel@lists.freedesktop.org" , Nitin Joshi1 , Rajat Jain , Mark Pearson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, 15 Apr 2020, Hans de Goede wrote: > ii. Currently the "privacy-screen" property added by Rajat's > patch-set is an enum with 2 possible values: > "Enabled" > "Disabled" > > We could add a third value "Not Available", which would be the > default and then for internal panels always add the property > so that we avoid the problem that detecting if the laptop has > an internal privacy screen needs to be done before the connector > is registered. Then we can add some hooks which allow an > lcdshadow-driver to register itself against a connector later > (which is non trivial wrt probe order, but lets ignore that for now). I regret dropping the ball on Rajat's series (sorry!). I do think having the connector property for this is the way to go. Even if we couldn't necessarily figure out all the details on the kernel internal connections, can we settle on the property though, so we could move forward with Rajat's series? Moreover, do we actually need two properties, one which could indicate userspace's desire for the property, and another that tells the hardware state? I'd so very much like to have no in-kernel/in-firmware shortcuts to enable/disable the privacy screen, and instead have any hardware buttons just be events that the userspace could react to. However I don't think that'll be the case unfortunately. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel