[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190111155416.otv563wki5rzhp4u@flea>
Date: Fri, 11 Jan 2019 16:54:16 +0100
From: Maxime Ripard <maxime.ripard@...tlin.com>
To: Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Eric Anholt <eric@...olt.net>, Sean Paul <sean@...rly.run>,
David Airlie <airlied@...ux.ie>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH] drm: Auto-set allow_fb_modifiers when given modifiers at
plane init
On Mon, Jan 07, 2019 at 11:49:16AM +0100, Daniel Vetter wrote:
> On Fri, Jan 04, 2019 at 09:56:10AM +0100, Paul Kocialkowski wrote:
> > When drivers pass non-empty lists of modifiers for initializing their
> > planes, we can infer that they allow framebuffer modifiers and set the
> > driver's allow_fb_modifiers mode config element.
> >
> > In case the allow_fb_modifiers element was not set (some drivers tend
> > to set them after registering planes), the modifiers will still be
> > registered but won't be available to userspace unless the flag is set
> > later. However in that case, the IN_FORMATS blob won't be created.
> >
> > In order to avoid this case and generally reduce the trouble associated
> > with the flag, always set allow_fb_modifiers when a non-empty list of
> > format modifiers is passed at plane init.
> >
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@...tlin.com>
>
> The automatic primary plane drm_crtc_init() creates doesn't set this, so
> looks correct in all cases.
>
> Reviewed-by: Daniel Vetter <daniel.vetter@...ll.ch>
>
> (boolin.com has a bunch of drm-misc committers, so I'll leave pushing to
> them).
Applied,
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists