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

Rob Clark robdclark at gmail.com
Tue Mar 12 17:16:47 PDT 2013

On Tue, Mar 12, 2013 at 8:09 PM, Zack Rusin <zackr at 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.


> z

More information about the mesa-dev mailing list