dri-devel Archive on lore.kernel.org
 help / color / Atom feed
From: Simon Ser <contact@emersion.fr>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Daniel Vetter" <daniel.vetter@intel.com>,
	"Marek Olšák" <maraeo@gmail.com>,
	"Juston Li" <juston.li@intel.com>,
	"Daniel Stone" <daniels@collabora.com>,
	"DRI Development" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/doc: Document that modifiers are always required for fb
Date: Wed, 02 Sep 2020 14:59:49 +0000
Message-ID: <55Yt-xRb-j_BnxyoixpIT6a4aOd2-SMetoyIVRBwOBFc98R5A3-gAcYcFo5Sjj-7TcvLdy3669gwn5eCOoOi85A2MlZaUwqpQETei77426A=@emersion.fr> (raw)
In-Reply-To: <CAKMK7uGs2vQNf1+=4spQV4aCncOPE4+E7g95xqZ7kcD8pp5bTg@mail.gmail.com>

On Wednesday, September 2, 2020 4:29 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> On Wed, Sep 2, 2020 at 2:49 PM Simon Ser contact@emersion.fr wrote:
>
> > On Wednesday, September 2, 2020 2:44 PM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
> >
> > > > I suppose something similar happens in user-space: gbm_bo_create
> > > > without modifiers needs to properly set the implicit modifier, ie.
> > > > gbm_bo_get_modifier needs to return the effective modifier. Is this
> > > > something already documented?
> > >
> > > I don't think that happens, but it has come up in discussions. It's
> > > kinda different scenario though: getfb2 is for cross-compositor stuff,
> > > enabling smooth transitions at boot-up and when switching. So you have
> > > a legit reason for mixing modifier-aware userspace with
> > > non-modifier-aware userspace. And the modifier-aware userspace would
> > > like that everything works with modifiers consistently, including
> > > getfb2. But gbm is just within a single process, and that should
> > > either run all with modifiers, or not at all, since these worlds just
> > > dont mix well. Hence I'm not seeing much use for that, -modesetting
> > > being a confused mess nonwithstanding :-)
> >
> > Well… There's also the case where some legacy Wayland client talks to a
> > modifier-aware compositor. gbm_bo_import would be called without a
> > modifier, but the compositor expects gbm_bo_get_modifier to work.
> > Also, wlroots will call gbm_bo_create without a modifier to only let
> > the driver pick "safe" modifiers in case passing the full list of
> > modifiers results in a black screen. Later on wlroots will call
> > gbm_bo_get_modifier to figure out what modifier the driver picked.
>
> gbm_bo_import is a different thing from gbm_bo_create. Former I agree
> should figure out the right modifiers (and I think it does that, at
> least on intel mesa). For gbm_bo_create I'm not sure we should/need to
> require that.

I guess the compositor will just forward the value returned by
gbm_bo_get_modifier in any case, so returning INVALID would be fine
too (to mean "implicit modifier").

In both the create and import cases, other metadata like pitches and
offsets should be correctly set I think?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 10:24 Daniel Vetter
2020-09-02 11:02 ` Pekka Paalanen
2020-09-02 11:15   ` Daniel Vetter
2020-09-02 11:34     ` Pekka Paalanen
2020-09-02 12:40 ` Simon Ser
2020-09-02 12:44   ` Daniel Vetter
2020-09-02 12:49     ` Simon Ser
2020-09-02 12:56       ` Daniel Stone
2020-09-02 14:29       ` Bas Nieuwenhuizen
2020-09-02 14:29       ` Daniel Vetter
2020-09-02 14:59         ` Simon Ser [this message]
2020-09-07  8:31           ` Daniel Vetter
2020-09-07  8:37             ` Simon Ser
2020-09-07  8:41               ` Daniel Vetter
2020-09-07  9:07                 ` Pekka Paalanen
2020-09-07 13:51                   ` Daniel Vetter
2020-09-17 16:47 Daniel Vetter
2020-09-17 17:24 ` Bas Nieuwenhuizen
2020-09-23 15:53   ` Daniel Vetter

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='55Yt-xRb-j_BnxyoixpIT6a4aOd2-SMetoyIVRBwOBFc98R5A3-gAcYcFo5Sjj-7TcvLdy3669gwn5eCOoOi85A2MlZaUwqpQETei77426A=@emersion.fr' \
    --to=contact@emersion.fr \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=juston.li@intel.com \
    --cc=maraeo@gmail.com \
    /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

dri-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dri-devel/0 dri-devel/git/0.git
	git clone --mirror https://lore.kernel.org/dri-devel/1 dri-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dri-devel dri-devel/ https://lore.kernel.org/dri-devel \
		dri-devel@lists.freedesktop.org
	public-inbox-index dri-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.freedesktop.lists.dri-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git