All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: dri-devel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	martijn@brixit.nl, Caleb Connolly <caleb@connolly.tech>,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: Display notch support
Date: Wed, 28 Apr 2021 14:01:36 +0200	[thread overview]
Message-ID: <YIlOoHcPyk91Pone@phenom.ffwll.local> (raw)
In-Reply-To: <20210428104403.1e49f270@eldfell>

On Wed, Apr 28, 2021 at 10:44:03AM +0300, Pekka Paalanen wrote:
> On Wed, 28 Apr 2021 07:21:28 +0000
> Simon Ser <contact@emersion.fr> 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 [1] 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.
> > 
> > [1]: https://developer.android.com/reference/android/view/DisplayCutout
> 
> Hi,
> 
> 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
> store?

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
for output.

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
> information?
> 
> 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?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  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

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=YIlOoHcPyk91Pone@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.