From: Daniel Vetter <email@example.com>
To: Pekka Paalanen <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org,
email@example.com, Caleb Connolly <firstname.lastname@example.org>,
Subject: Re: Display notch support
Date: Wed, 28 Apr 2021 14:01:36 +0200 [thread overview]
Message-ID: <YIlOoHcPyk91Pone@phenom.ffwll.local> (raw)
On Wed, Apr 28, 2021 at 10:44:03AM +0300, Pekka Paalanen wrote:
> On Wed, 28 Apr 2021 07:21:28 +0000
> Simon Ser <email@example.com> wrote:
> > > A solution to make this configuration generic and exposed by the kernel
> > > would standardise this across Linux
> > Having a KMS property for this makes sense to me.
> > Chatting with Jani on IRC, it doesn't seem like there's any EDID or
> > DisplayID block for this.
> > Note, Android exposes a data structure  with:
> > - Margin of the cut-out for each edge of the screen
> > - One rectangle per edge describing the cut-out region
> > - Size of the curved area for each edge of a waterfall display
> > I haven't found anything describing the rounded corners of the display.
> > : https://developer.android.com/reference/android/view/DisplayCutout
> 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?
> If not, is there not a policy that DT is not a userspace configuration
If someone is sufficiently bored it would make sense to teach fbcon (but
not fbdev I guess for full sized boot splash) to avoid the edges/corners
But also fbcon/fbdev is I think finally dead on Android, so the
intersection of people who care about cut-outs and fbcon is likely 0.
Otherwise I can't think of anything.
> 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?
> 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
> Funny2 and funny3 are hypothetical but maybe not too far-fetched.
> Is there any provision for generic userspace to handle this generically?
> This seems more like a job for the hypothetical liboutput, just like
> recognising HMDs (yes, I know, kernel does that already, but there is a
> point that kernel may not want to put fbcon on a HMD).
I think the desktop linux solution would be hwdb entries, except we've
never done this for anything display related. So yeah liboutput sounds
about right for this :-)
Btw on fbcon on HMD, I thought we're already taking care of that?
Software Engineer, Intel Corporation
dri-devel mailing list
next prev parent reply other threads:[~2021-04-28 12:02 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
2021-04-28 12:01 ` Daniel Vetter [this message]
2021-04-28 12:18 ` Jani Nikula
2021-05-03 12:13 ` Caleb Connolly
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).