[PATCH] glx: Duplicate relevant fbconfigs for compositing visuals

Thomas Hellstrom thellstrom at vmware.com
Fri Oct 13 05:43:02 UTC 2017


Hi,

On 10/12/2017 10:32 PM, Adam Jackson wrote:
> On Thu, 2017-10-12 at 15:06 +0200, Thomas Hellstrom wrote:
>> Ping?
> If we're going to do this, and I guess we have to, I'd like to see two
> changes:
>
> 1) Don't duplicate single-buffered fbconfigs

OK. I was trying to figure out what Nvidia was doing here, and they 
appear to expose
both single-buffer and sRGB 32-bit visuals.

> 2) Point all these fbconfigs at the same visual

The problem with doing that is that the glx visual pointed to by the 
fbconfig might have completely
different glx traits compared to the original fbconfig. I'm not sure 
whether that will cause any
problems but I guess it might be confusing. Again, looking at what 
Nvidia does, they expose a
number of 32-bit fbconfigs.

The follow-up RFC patch tries to reduce the number of identical GLX 
visuals, though.

Let me know whether you think we should go the nvidia way or try to 
expose as little as possible.

Another question that has surfaced is the criterion we use to determine 
whether a visual should be compositing or not.
In the patch I've considered 32-bit visuals as compositing. But looking 
at older dri1 client side code, it considers all
visuals with depth != DefaultDepth(dpy, screen) as compositing.

Thanks,
Thomas


>
> - ajax




More information about the xorg-devel mailing list