On Tue, Mar 12, 2013 at 8:38 PM, Zack Rusin <za...@vmware.com> wrote: >> hmm, well, I think my fix is not incorrect.. we can tell from dri2 >> proto version that the xserver does not support ScheduleSwap. Maybe >> there should be other conditions where we also don't advertise this >> extension, but this patch still improves things. If we absolutely >> know from the dri2 proto version that ScheduleSwap is not supported, >> then we should not advertise this extension. > > And GLX_MESA_swap_control and GLX_SGI_make_current_read and the same for > every extension which should be checked and advertised correctly by the > Xserver. The issue is that you shouldn't worry about those because Xserver > should check and advertise correctly what it supports. The issue with using > swap_control symbols with checking for swap_event is that it creates > arbitrary distinction between those two extensions on the client side only > because Xserver does the correct thing for one of them and not the other. >
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. Probably there are other cases where we should do the same thing. I can update my patch to also exclude other extensions (although a list of extensions that depend on ScheduleSwap would be helpful, since I'm less familiar with the GLX extensions. >> Without this, gnome-shell (and mutter/clutter) on freedreno is broken. >> I'd rather not filter out based on the driver name, because when I >> eventually have a display driver where I can support swap, and bump >> the dri2 version #, I'd like this extension to be advertised. > > TBH, I don't think you need this check at all, you just need a fixed xserver > which doesn't advertise intel_swap_event if it doesn't support it. Until > freedreno is shipped you don't have to worry about Xserver breaking the > extension strings because you control the environment. > And just to be clear, I'm not nacking this patch, I just think it's silly to > keep fixing Xserver bugs in mesa, but if you really hate the check for names, > then please remove the strcpy vmwgfx and fix the comment above the check so > that we have one master hack for this extension instead of accumulating a > number of them. > 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. BR, -R > z _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev