[PATCH v14 41/41] compositor-drm: Support modifiers with GBM
Daniel Stone
daniel at fooishbar.org
Thu Jul 5 16:45:31 UTC 2018
Hi Pekka,
On Tue, 30 Jan 2018 at 09:58, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 20 Dec 2017 12:26:58 +0000
> Daniel Stone <daniels at collabora.com> wrote:
> > + for (i = 0; i < plane->count_formats; i++) {
> > + if (plane->formats[i].format == output->gbm_format)
>
> Here it is output->gbm_format...
>
> > + break;
> > + }
> > +
> > + if (i == plane->count_formats) {
> > + /* XXX: better error message */
> > + weston_log("can't use format for output\n");
>
> XXX :-)
>
> Maybe I could add name strings to the pixel format list and a helper
> that would be safe for arbitrary and even invalid format codes for
> turning a format into pretty string.
>
> Should this fall back to the fallback format as well?
We shouldn't fall back to the fallback format. For XRGB, the format is
ARGB, which will enable alpha blending. Maybe we could try doing so in
a separate patch, if we know we always set solid alpha channels, but
...
> > - output->gbm_surface = gbm_surface_create(b->gbm,
> > - output->base.current_mode->width,
> > - output->base.current_mode->height,
> > - format[0],
> > - GBM_BO_USE_SCANOUT |
> > - GBM_BO_USE_RENDERING);
> > if (!output->gbm_surface) {
> > weston_log("failed to create gbm surface\n");
> > return -1;
>
> This is not new in this patch, but the GBM surface is created with
> gbm_format, but the EGLConfig may be chosen by gbm_format or its
> fallback format. If it picks with the fallback format, do we have a
> problem?
It's not a problem that I know of, since the formats are chosen to be
completely interchangeable. Mesa at least will happily render to the
other format, and I believe this is also true of other
implementations.
Cheers,
Daniel
More information about the wayland-devel
mailing list