dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Simon Ser <contact@emersion.fr>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: martijn@brixit.nl, Caleb Connolly <caleb@connolly.tech>,
	dri-devel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: Display notch support
Date: Wed, 28 Apr 2021 07:51:53 +0000	[thread overview]
Message-ID: <4AcLdwoiXpy0XDf-LLiXa4Fp-hDWyOm_tWMyu1nXKkg_dbDkviKcCJ-FUPJkQkiGhTFBXFlD5TFbBUyXAt0N1l548JDrrYwYkMM3eN78tlM=@emersion.fr> (raw)
In-Reply-To: <20210428104403.1e49f270@eldfell>

On Wednesday, April 28th, 2021 at 9:44 AM, Pekka Paalanen <ppaalanen@gmail.com> 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

  reply	other threads:[~2021-04-28  7:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 20:47 Display notch support Caleb Connolly
2021-04-28  7:21 ` Simon Ser
2021-04-28  7:44   ` Pekka Paalanen
2021-04-28  7:51     ` Simon Ser [this message]
2021-04-28 12:01     ` Daniel Vetter
2021-04-28 12:18       ` Jani Nikula
2021-05-03 12:13   ` Caleb Connolly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='4AcLdwoiXpy0XDf-LLiXa4Fp-hDWyOm_tWMyu1nXKkg_dbDkviKcCJ-FUPJkQkiGhTFBXFlD5TFbBUyXAt0N1l548JDrrYwYkMM3eN78tlM=@emersion.fr' \
    --to=contact@emersion.fr \
    --cc=caleb@connolly.tech \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dri-devel@vger.kernel.org \
    --cc=martijn@brixit.nl \
    --cc=ppaalanen@gmail.com \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).