Bug 2875

Summary:	Incorrect set of GLX extensions reported for remote display
Product:	Mesa	Reporter:	Ian Romanick <idr>
Component:	GLX	Assignee:	Ian Romanick <idr>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	high
Version:	git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	1690
Attachments:	Example of incorrect glxinfo output.

Description Ian Romanick 2005-03-31 13:06:06 UTC

Running glxinfo on system A with DISPLAY set to system B, which is DRI capable,
results in the correct "server GLX extension", the correct "client GLX
extensions", but INCORRECT "GLX extensions".

I dug a bit into the code and it appears that libGL is acting as though direct
rendering is enabled, even though the display is remote (and direct rendering is
impossible).  Since the non-existant DRI driver didn't enable any GLX extensions
in its __driCreateNewScreen function, the extensions aren't enabled.

So, it looks like the test to determine whether or not direct rendering is
possible in glXQueryExtensionsString is wrong.

Comment 1 Ian Romanick 2005-03-31 13:07:10 UTC

Created attachment 2278 [details]
Example of incorrect glxinfo output.

Comment 2 Ian Romanick 2005-07-01 10:12:31 UTC

Assigning bug to myself.  I should have a patch by July 7th or so.

Comment 3 Ian Romanick 2005-08-06 05:15:01 UTC

Fixed by looking at driScreen.private instead of driDisplay.private.

In order to create the set of available extensions, we have to know if
direct-rendering is possible on a given screen.  It is not possible to determine
this by just looking at driDisplay.private in the display structure.  However,
it is possible to determine this by looking at driScreen.private in the screen
structure.  This field is only non-NULL if a DRI driver has been successfully
loaded and bootstrapped.  Once we get to that point, we know that
direct-rendering is at least theoretically possible.

Comment 4 Adam Jackson 2009-08-24 12:23:07 UTC

Mass version move, cvs -> git

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.