[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