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

[Daniel Stone]

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.

Cheers,
Daniel