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

Zack Rusin zackr at vmware.com
Wed Mar 13 08:19:35 PDT 2013


> 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.

> 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. 

> 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.

z


More information about the mesa-dev mailing list