On Wed, Mar 13, 2013 at 11:19 AM, Zack Rusin <za...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
