[Mesa-dev] [PATCH v2 1/2] egl/wayland: Check queryImage return for wl_buffer

Marek Olšák maraeo at gmail.com
Wed Oct 4 11:38:19 UTC 2017

Yeah I don't have an answer to that. I think it's better to pageflip than
blit. Can Wayland reallocate the buffer to make it displayable? If not, it
may be better to create displayable buffers always.


On Oct 4, 2017 12:48 PM, "Daniel Stone" <daniel at fooishbar.org> wrote:

> Hi Marek,
> On 3 October 2017 at 17:00, Marek Olšák <maraeo at gmail.com> wrote:
> > On Mon, Oct 2, 2017 at 8:09 PM, Daniel Stone <daniel at fooishbar.org>
> wrote:
> >> Perhaps unsurprisingly, adding __DRI_IMAGE_USE_SCANOUT to
> >> src/egl/drivers/dri2/platform_wayland.c in the createImage() fallback
> >> path (i.e. not createImageWithModifiers) fixes things. That being
> >> said, Weston does do the GBM BO import with the scanout flag, which
> >> will call the DRIImage's validateUsage() hook with the SCANOUT bit
> >> set; for now, it should be enough to just detect that the image is not
> >> scanout-compatible in radeonsi's validateUsage() hook, rejecting the
> >> import which will make Weston fall back to GLES composition.
> >>
> >> That being said, st/dri's dri2_validate_usage() doesn't really fill me
> >> with too much confidence.
> >
> > We don't really validate flags during DMABUF import. The idea is that
> > all clients should know the flags since buffer creation, and have no
> > reason to pass different flags during the import.
> In that case, I guess the only option is to just make Gallium's dri2
> st pass PIPE_USAGE_SCANOUT to every winsys allocation. This pessimises
> allocation and disqualifies tiling/etc modes for buffers which can
> never be scanout, but if there can be no validation (and thus we can't
> reject a compositor which wishes to start using a client buffer for
> scanout), then it's the only other option. Either that or just fail
> every gbm_bo_import for scanout on Gallium.
> Cheers,
> Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171004/5c79720b/attachment.html>

More information about the mesa-dev mailing list