Nicolai Hähnle, on lun. 15 janv. 2018 15:07:03 +0100, wrote:
> On 13.01.2018 12:36, Samuel Thibault wrote:
> > glXGetDriverConfig parameters do not provide a context to dynamically
> > check for the presence of the function, so the dispatcher directly calls
> > glXGetDriverConfig, but in non-dri
On 15.01.2018 15:15, Samuel Thibault wrote:
Nicolai Hähnle, on lun. 15 janv. 2018 15:07:03 +0100, wrote:
On 13.01.2018 12:36, Samuel Thibault wrote:
glXGetDriverConfig parameters do not provide a context to dynamically
check for the presence of the function, so the dispatcher directly calls
On 13.01.2018 12:36, Samuel Thibault wrote:
glXGetDriverConfig parameters do not provide a context to dynamically
check for the presence of the function, so the dispatcher directly calls
glXGetDriverConfig, but in non-dri builds dri_glx.c didn't provide
glXGetDriverConfig.
This change makes it
Dylan Baker, on dim. 14 janv. 2018 09:37:49 -0800, wrote:
> I don't know enough about glx to know if this is correct, but you'll need to
> add the c files to the meson.build as well
Oh, mesa now also uses meson. Ok, now commited that to my tree.
Samuel
I don't know enough about glx to know if this is correct, but you'll need to
add the c files to the meson.build as well
On January 13, 2018 3:36:30 AM PST, Samuel Thibault
wrote:
>glXGetDriverConfig parameters do not provide a context to dynamically
>check for the
glXGetDriverConfig parameters do not provide a context to dynamically
check for the presence of the function, so the dispatcher directly calls
glXGetDriverConfig, but in non-dri builds dri_glx.c didn't provide
glXGetDriverConfig.
This change makes it provide a NULL-returning stub in non-dri