[Mesa-dev] [PATCH 2/3] st/dri2: Return invalid modifier when no driver support

[Emil Velikov]

On 24 July 2017 at 12:44, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On 24 July 2017 at 12:30, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 22 July 2017 at 09:00, Daniel Stone <daniel at 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.
>
Agreed - there is no interface atm. The quick "if still INVALID,
return false" sounds like a reasonable solution for now.

>> 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.
>
I was under the impression that cannot happen. Perhaps it can ...
silly me, making assumptions.

Thanks
Emil