Hi, On 24 July 2017 at 12:30, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 22 July 2017 at 09:00, Daniel Stone <dan...@fooishbar.org> wrote: >> We can address that as well, but not instead. Drivers which aren't >> aware of modifiers will return success (as they know how to export >> KMS-type handles), but not initialise the modifier field (because they >> aren't aware of it). So we can check for failure, but the case I was >> seeing here is that resource_get_handle() was succeeding - else we >> wouldn't have had a buffer to query modifiers on in the first place - >> but failing to either give the correct modifier or INVALID. >> > You're right - my suggestion seems orthogonal to the issue at hand. > > At the same time if the driver does not support modifiers, we should > return false for the query, shouldn't we?
Indeed, it should. Unfortunately, there's no explicit query for modifier: we just expect the driver to set whandle.modifier when we do a KMS handle query. Or, in this case, not set it. I didn't easily see a query interface we could use to support this. > The egl/wayland will need an update code to correctly handle the > queryImage failure (sorry for missing that earlier), falling back to > wl_drm. > GBM already has similar checks/fallback paths. I can do that. > AFAICT that will make the check in 1/3 unreachable, yet still nice to have. I don't really see how? 1/3 is for when we have zwp_linux_dmabuf_v1 support in the Wayland compositor, but it fails to advertise any modifiers for the formats we're interested in. Cheers, Daniel _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
