All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Simon Ser <contact@emersion.fr>, Paul Cercueil <paul@crapouillou.net>
Cc: David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	od@zcrc.me, Maxime Ripard <maxime@cerno.tech>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	stable@vger.kernel.org
Subject: Re: [PATCH] drm: DON'T require each CRTC to have a unique primary plane
Date: Tue, 30 Mar 2021 09:55:10 +0300	[thread overview]
Message-ID: <20210330095510.4c6432f7@eldfell> (raw)
In-Reply-To: <f_BApfXCctltkOAAKup7ZXRsq8N81SZgbxIEFbHWzeoKZCo8z169Bkk4DDwk9WmMNKXpyxaMQCxbWzwVMgfNav0ZYVf3s_6bXRO89LKD_AM=@emersion.fr>


[-- Attachment #1.1: Type: text/plain, Size: 1427 bytes --]

On Mon, 29 Mar 2021 15:36:27 +0000
Simon Ser <contact@emersion.fr> wrote:

> On Monday, March 29th, 2021 at 5:32 PM, Paul Cercueil <paul@crapouillou.net> wrote:
> 
> > Making the second plane an overlay would break the ABI, which is never
> > something I'm happy to do; but I'd prefer to do it now than later.  
> 
> Yeah, I wonder if some user-space depends on this behavior somehow?
> 
> > I still have concerns about the user-space being "clever" enough to
> > know it can disable the primary plane. Can e.g. wlroots handle that?  
> 
> wlroots will always pick the first primary plane, and will never use
> overlays. The plan is to use libliftoff [1] to make use of overlay
> planes. libliftoff should already support the scenario you describe.
> 
> I think Weston supports that too.

Weston supports overlays, but I don't think it will try without "the"
primary plane, IIRC. I'd need to verify.

I'm not quite sure what Weston would do with multiple primary planes.
It probably picks one for a CRTC ahead of time, and then sticks to it,
always using it.

But if Weston never worked with a driver to begin with, it also can't
regress, so you're safe.


Thanks,
pq

> 
> [1]: https://github.com/emersion/libliftoff
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Simon Ser <contact@emersion.fr>, Paul Cercueil <paul@crapouillou.net>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	od@zcrc.me, Maxime Ripard <maxime@cerno.tech>,
	stable@vger.kernel.org
Subject: Re: [PATCH] drm: DON'T require each CRTC to have a unique primary plane
Date: Tue, 30 Mar 2021 09:55:10 +0300	[thread overview]
Message-ID: <20210330095510.4c6432f7@eldfell> (raw)
In-Reply-To: <f_BApfXCctltkOAAKup7ZXRsq8N81SZgbxIEFbHWzeoKZCo8z169Bkk4DDwk9WmMNKXpyxaMQCxbWzwVMgfNav0ZYVf3s_6bXRO89LKD_AM=@emersion.fr>

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

On Mon, 29 Mar 2021 15:36:27 +0000
Simon Ser <contact@emersion.fr> wrote:

> On Monday, March 29th, 2021 at 5:32 PM, Paul Cercueil <paul@crapouillou.net> wrote:
> 
> > Making the second plane an overlay would break the ABI, which is never
> > something I'm happy to do; but I'd prefer to do it now than later.  
> 
> Yeah, I wonder if some user-space depends on this behavior somehow?
> 
> > I still have concerns about the user-space being "clever" enough to
> > know it can disable the primary plane. Can e.g. wlroots handle that?  
> 
> wlroots will always pick the first primary plane, and will never use
> overlays. The plan is to use libliftoff [1] to make use of overlay
> planes. libliftoff should already support the scenario you describe.
> 
> I think Weston supports that too.

Weston supports overlays, but I don't think it will try without "the"
primary plane, IIRC. I'd need to verify.

I'm not quite sure what Weston would do with multiple primary planes.
It probably picks one for a CRTC ahead of time, and then sticks to it,
always using it.

But if Weston never worked with a driver to begin with, it also can't
regress, so you're safe.


Thanks,
pq

> 
> [1]: https://github.com/emersion/libliftoff
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-03-30  6:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-27 11:22 [PATCH] drm: DON'T require each CRTC to have a unique primary plane Paul Cercueil
2021-03-27 11:22 ` Paul Cercueil
2021-03-27 11:24 ` Simon Ser
2021-03-27 11:24   ` Simon Ser
2021-03-27 11:26   ` Paul Cercueil
2021-03-27 11:26     ` Paul Cercueil
2021-03-29  8:15     ` Pekka Paalanen
2021-03-29  8:15       ` Pekka Paalanen
2021-03-29 11:41       ` Paul Cercueil
2021-03-29 11:41         ` Paul Cercueil
2021-03-29 14:35         ` Pekka Paalanen
2021-03-29 14:35           ` Pekka Paalanen
2021-03-29 15:21           ` Paul Cercueil
2021-03-29 15:21             ` Paul Cercueil
2021-03-29 14:07 ` Maxime Ripard
2021-03-29 14:07   ` Maxime Ripard
2021-03-29 14:11   ` Simon Ser
2021-03-29 14:11     ` Simon Ser
2021-03-29 15:32     ` Paul Cercueil
2021-03-29 15:32       ` Paul Cercueil
2021-03-29 15:36       ` Simon Ser
2021-03-29 15:36         ` Simon Ser
2021-03-30  6:55         ` Pekka Paalanen [this message]
2021-03-30  6:55           ` Pekka Paalanen
2021-03-29 15:15   ` Paul Cercueil
2021-03-29 15:15     ` Paul Cercueil
2021-03-29 15:35     ` Maxime Ripard
2021-03-29 15:35       ` Maxime Ripard
2021-03-29 15:39       ` Paul Cercueil
2021-03-29 15:39         ` Paul Cercueil
2021-03-29 15:42         ` Simon Ser
2021-03-29 15:42           ` Simon Ser
2021-03-29 16:15           ` Paul Cercueil
2021-03-29 16:15             ` Paul Cercueil

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=20210330095510.4c6432f7@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=airlied@linux.ie \
    --cc=contact@emersion.fr \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime@cerno.tech \
    --cc=od@zcrc.me \
    --cc=paul@crapouillou.net \
    --cc=stable@vger.kernel.org \
    --cc=tzimmermann@suse.de \
    /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.