[Mesa-dev] Why are we using server-side GLX fbconfigs?

[Kristian Høgsberg]

On Thu, Jun 29, 2017 at 7:36 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> Hi!
>
> I was spending some time going through the GLX code to try to fix up the
> GLX_OML_swap_method extension implementation.
>
> I then stumbled across the fact that when we, for direct rendering
> connections, construct the list of fbconfigs, we start out with the server
> provided fbconfigs from the AIGLX driver and then try to match each fbconfig
> with a corresponding client driver driconfig. Effectively making us use the
> intersection of the server AIGLX capabilities and the client Direct
> rendering capabilities.
>
> Wouldn't it be more correct, or at least "better" if we, for direct
> rendering, took a list of client driver driconfigs, matched each with a
> server provided visual and if we have a match, built an fbconfig from that
> driconfig? That would make us essentialy exposing all client driver
> capabilities regardless of what the server is using, as long as we have a
> matching visual?
>
> Any insights into this would be greatly appreciated.

I'm largely to blame for that. Historically it was part me trying to
keep things working they did before as well as having to pay more
attention to server side configs as DRI2 tried to share aux buffers
(not just color) between clients. I think mesa today only shares color
buffers with DRI2 and DRI3 is obviously fine, so what you're proposing
sounds like a nice simplification of the code as well as something
that might expose more configs to the client.

Kristian

> Thanks,
>
> Thomas
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev