[Mesa-dev] [PATCH] DRI2: don't advertise GLX_INTEL_swap_event if it can't

[Rob Clark]

On Wed, Mar 13, 2013 at 11:19 AM, Zack Rusin <zackr at vmware.com> wrote:
>> well, I'm more familiar w/ EGL where we don't have the xserver
>> advertising anything, and it is all on the client side.. but when it
>> is an inexpensive check, it seems reasonable to want mesa to do the
>> right thing where possible.
>
> It's simply silly. In the same sense that adding yet another if (ptr) to "if (ptr) if (ptr) FREE(ptr);" while not technically wrong is simply silly. Like I said we already check whether those extensions are advertised by the server and don't advertise the ones that aren't.
>

well, if the other component that provided FREE() had a bug that it
didn't check for null, it wouldn't be completely silly.  But still a
hack/workaround..

>> Probably there are other cases where we
>> should do the same thing.  I can update my patch to also exclude other
>> extensions
>
> No, the point it that we don't want to do that. It's fundamentally broken and you know that it's broken because you'll notice that this extension is still advertised by the server (for our sake that's all required to fix Clutter, but it's still broken). It's a weird thing for an extension which is implemented by the server to be advertised by the server and yet having a client which is essentially not involved at all, not be advertising it. The only reason we have to worry about this is that the server is broken. So while we might want to make things easier on us by not forcing users to keep repatching the Xserver we shouldn't have any illusions about what this is: it's a nasty hack required by a bug in the Xserver. As such that code has only two requirements:
> 1) That all drivers requiring that hack go through the same codepath and that it's as minimal as possible so it's trivial to remove it once a fixed Xserver gets into most distros.
> 2) That it's clearly documented as hack thanks to which anyone reading this code will immediately understand what's the purpose of the weird code and what are the prerequisites for removing it.
> Everything else is of no consequence in this case. So whether you'll decide to use names or some any number of other extensions that came after dri2inforec version 4 to check for makes no difference as long as it fulfills the two above goals.
>

I'm ok with documenting it as a hack, and removing it once updated
xserver is in most distro's.  But it does seem useful to have at least
in the short term.

>> true, it is not shipping in any distro yet, so anyone who wants to try
>> it gets to try git master of mesa, which runs into problems because of
>> advertising the INTEL_swap extension.  Asking everyone to rebuild
>> xserver with some extra patch which is not merged yet is a big pita.
>
> Sure, but at the same time adding hacks to shared mesa code to make it easier to try a dev driver doesn't make terribly convincing argument. In the end though, at least in this case, the bug is severe enough that a hack in mesa makes sense and we've spent too much time discussing a very simple issue, so whatever you do just please make sure to fulfill the two requirements above and everything will be ok.
>

true, I suppose.. although there are currently enough challenges
getting proper linux running on some of these devices, I don't really
like to make it harder than it already is.

I'll re-submit the patch making it more clear that it is a hack.  I
think point #1 is already met, it is a pretty localized hack and
should be easy to remove later.

BR,
-R

> z