On Tue, Mar 12, 2013 at 8:09 PM, Zack Rusin <za...@vmware.com> wrote: > > well, from what I can tell, if you advertise this extension >> applications will expect a swap event. Which will never come if >> dri/glx on client side remaps scheduleswap to copyregion. >> >> So maybe there are other conditions where we should not advertise this >> extension. But if we know we will never get events, we should not >> advertise this extension. > > The issue isn't on this side, it's on the Xserver side. We don't advertise > extensions that aren't advertised by the server, unfortunately Xserver > unconditionally enables this extension. I've sent a patch to xorg-devel at > least limiting exposure ( > http://lists.x.org/archives/xorg-devel/2013-February/035449.html ) but it > hasn't been applied. The only reason for the vmwgfx hack is that we have a > shipping driver that badly broke with the new Xserver so instead of leaving > our users with broken systems we disable the extension on the client side. > That isn't the correct approach though, in fact it's wrong, but it keeps > those systems working until fixed xserver is out. I'd prefer to keep more > hacks to fix this situation out of mesa. >
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. 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. BR, -R > z _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
