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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 64207C433ED for ; Wed, 28 Apr 2021 07:52:38 +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 DAE2A613FA for ; Wed, 28 Apr 2021 07:52:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAE2A613FA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=emersion.fr 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 03F7C89B3C; Wed, 28 Apr 2021 07:52:37 +0000 (UTC) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0FFAE6EAB9 for ; Wed, 28 Apr 2021 07:52:09 +0000 (UTC) Date: Wed, 28 Apr 2021 07:51:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail3; t=1619596327; bh=efd/2nn9ykE/rbPAWbcfex33rlDnAX44J757KgUg47M=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=dko6gBZ2sgL3sZfOY3vbm8MCllPGoxrR5L2WYnyXeBrIRg0qPjcjlDEmUwCaUbmKO jc7LEsRfVz7ozRiWYf7j4WGhzTwscrQlSytvG1cMBw964jnHxnrKTpe+vdKlAPKE1n +xqQxG1FZx7IN0RFuQ+/EU+h24bpDP4VMCX8mSwMpi4FK/SyP3LzjSvyon4EENeVoE JsAsEQ1LEa0/8nGko6p5zHMls2wpH82PbmY9BkrLL9BUZy+Eo+uURmkjSZfU3OFzP0 nyuGO/yMkUcy4gfsfY305afF0rdkVE6ztxma2J7iStkc4BNbP+7VaYoy4wV6luq+RG 4g63+dO737g3w== To: Pekka Paalanen From: Simon Ser Subject: Re: Display notch support Message-ID: <4AcLdwoiXpy0XDf-LLiXa4Fp-hDWyOm_tWMyu1nXKkg_dbDkviKcCJ-FUPJkQkiGhTFBXFlD5TFbBUyXAt0N1l548JDrrYwYkMM3eN78tlM=@emersion.fr> In-Reply-To: <20210428104403.1e49f270@eldfell> References: <20210428104403.1e49f270@eldfell> 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: , Reply-To: Simon Ser Cc: martijn@brixit.nl, Caleb Connolly , dri-devel@vger.kernel.org, dri-devel@lists.freedesktop.org, ~postmarketos/upstreaming@lists.sr.ht Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wednesday, April 28th, 2021 at 9:44 AM, Pekka Paalanen wrote: > I'm kind of worried whether you can design a description structure that > would be good for a long time. That list already looks quite > complicated. Add also watch-like devices with circular displays. > > Would the kernel itself use this information at all? fbcon might want to letter-box its output to make sure it's not obscured behind a cut-out area. > If not, is there not a policy that DT is not a userspace configuration > store? > > You mentioned the panel orientation property, but that is used by the > kernel for fbcon or something, is it not? Maybe as the default value > for the CRTC rotation property which actually turns the image? I wonder if fbcon uses it at all. In general CRTC rotation is not well-supported by HW drivers, at least for linear buffers. CRTC rotation is just an optimization. > Assuming that you succeed in describing these non-usable, funny > (waterfall edge), funny2 (e.g. behind a shade or filter so visible but > not normal), funny3 (e.g. phone button area with maybe tactile > markings), and normal areas, how would userspace handle this > information? > > Funny2 and funny3 are hypothetical but maybe not too far-fetched. > > Is there any provision for generic userspace to handle this generically? I think the main use-case here is make sure there's nothing important being cut out on screen. I agree we still don't know how the hw will evolve and might design an API which is too restricted. But building something that ends up too complicated and too generic wouldn't be great either. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel