[PATCH xserver 15/15] dri3: correctly handle failed get_supported_modifiers requests

[Emil Velikov]

On 6 April 2018 at 12:26, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On 6 April 2018 at 12:18, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 4 April 2018 at 19:51, Adam Jackson <ajax at nwnk.net> wrote:
>>> This, combined with 10/15, means you will now throw BadImplementation
>>> when we used to succeed and simply report no modifiers. I can't think
>>> of a good reason to make that an error, it just makes the client's life
>>> harder if it has to distinguish error from reply.
>>
>> I'm a bit split - on one hand any reasonable client should do error checking.
>> At least the Mesa one seems to do so.
>>
>> On the other, the client would handle failed and 0 modifiers identically.
>
> We generally reserve protocol errors for 'client screwed up' (most
> errors), or 'server has tied itself into a knot and does not know how
> to escape' (BadImplementation). The latter is usually accompanied by a
> comment saying '/* XXX: This is really hard so I didn't */'. In both
> cases, there's no way to do what the client wants so we send an error
> down to let it know that its expectations have been broken and it's
> difficult to recover.
>
> On the other hand, zero is a completely valid answer to 'how many
> modifiers do you support?', so that's what we should return. Error
> handling from asynchronous protocols is far more difficult than from
> just making a C function call, hence why we reserve it for cases which
> require active recovery, or are unrecoverable.
>
I see. Thank you very much for the comprehensive answer Dan.

-Emil