Bug 2868 - Mesa seems to be unable to handle 30bit TrueColor visuals
Summary: Mesa seems to be unable to handle 30bit TrueColor visuals
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: high enhancement
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-31 05:15 UTC by Roland Mainz
Modified: 2019-09-18 20:16 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Debug patch to make "XMesaCreateWindowBuffer: depth mismatch between visual and window!" more verbose (1.99 KB, patch)
2005-03-31 05:17 UTC, Roland Mainz
Details | Splinter Review

Description Roland Mainz 2005-03-31 05:15:20 UTC
An attempt to run "glxgears" on a Xserver which has a 30bit TrueColor visual
results in the following error (note that the Xserver also supports 24bit and
16bit TrueColor visuals):
-- snip --
% glxgears
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  144 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  39
  Current serial number in output stream:  39
-- snip --

A quick check added in glxgears shows that the requested visual depth and the
window depth are the same (30bit) so I assume this isn't the part which causes
problems.
On the Xserver side the following waring is printed:
-- snip --
Mesa warning: XMesaCreateWindowBuffer: depth mismatch between visual and window!
-- snip --

I've added the following debug code to the Mesa engine...
-- snip --
Index: xc/extras/Mesa/src/mesa/drivers/x11/xm_api.c
===================================================================
RCS file: /cvs/xorg/xc/extras/Mesa/src/mesa/drivers/x11/xm_api.c,v
retrieving revision 1.1.1.1
diff -u -2 -0 -r1.1.1.1 xm_api.c
--- xc/extras/Mesa/src/mesa/drivers/x11/xm_api.c        16 Jun 2004 09:19:01
-0000      1.1.1.1
+++ xc/extras/Mesa/src/mesa/drivers/x11/xm_api.c        31 Mar 2005 13:08:09
-0000
@@ -1734,48 +1734,53 @@
 #ifdef FX
    char *fxEnvVar;
 #endif
    int client = 0;
 
    XMesaBuffer b = alloc_xmesa_buffer();
    if (!b) {
       return NULL;
    }
 
    (void) c;
 
 #ifdef XFree86Server
    client = CLIENT_ID(((XMesaDrawable)w)->id);
 #endif
 
    assert(v);
 
 #ifdef XFree86Server
    if (GET_VISUAL_DEPTH(v) != ((XMesaDrawable)w)->depth) {
+      _mesa_warning(NULL, "XMesaCreateWindowBuffer: depth mismatch between
visual (%d) and window (%d)!\n",
+                    (int)GET_VISUAL_DEPTH(v), (int)((XMesaDrawable)w)->depth);
+      return NULL;
+   }
 #else
    XGetWindowAttributes( v->display, w, &attr );
 
    if (GET_VISUAL_DEPTH(v) != attr.depth) {
-#endif
-      _mesa_warning(NULL, "XMesaCreateWindowBuffer: depth mismatch between
visual and window!\n");
+      _mesa_warning(NULL, "XMesaCreateWindowBuffer: depth mismatch between
visual (%d) and window (%d)!\n",
+                    (int)GET_VISUAL_DEPTH(v), (int)attr.depth);
       return NULL;
    }
+#endif
-- snip --
... and then I get:
-- snip --
Mesa warning: XMesaCreateWindowBuffer: depth mismatch between visual (24) and
window (30)!
-- snip --

Any ideas what may be going wrong here ?
Comment 1 Roland Mainz 2005-03-31 05:17:49 UTC
Created attachment 2269 [details] [review]
Debug patch to make "XMesaCreateWindowBuffer: depth mismatch between visual and window!" more verbose

(BTW: It may be a nice idea to apply this to Xorg trunk, X11R6.8.2 stable
branch and Mesa trunk to make the error message a little bit more usefull).
Comment 2 Brian Paul 2005-04-04 09:08:22 UTC
I've updated the warning strings in Mesa CVS to basically match your patch.

I don't recall ever testing 30-bit truecolor visuals (and I have no means to do
so here) and I wouldn't expect them to work without writing some new code.

We should probably add a check for > 8-bit channels and gracefully reject/ignore
such visuals.  Can you write a patch for that?
Comment 3 Roland Mainz 2005-04-04 13:26:38 UTC
Brian Paul wrote:
> I've updated the warning strings in Mesa CVS to basically match your patch.

Thanks! :)
Could you please attach the patch here that I can commit it to the Xorg trunk,
too ?

> I don't recall ever testing 30-bit truecolor visuals (and I have no means to 
> do so here) and I wouldn't expect them to work without writing some new code.

What exactly needs to be done for Mesa to support such visuals ?

> We should probably add a check for > 8-bit channels and gracefully 
> reject/ignore such visuals.  Can you write a patch for that?

I tried to hack such a patch but failed to get it working - glxgears still
picked-up the 30bit Truecolor visuals (and failed) or the initvisuals code in
the Xserver shot itself into it's feet (likely I am too dumb to get this
working... ;-/).
Comment 4 chemtech 2013-03-15 13:40:13 UTC
Roland Mainz,
Do you still experience this issue with newer drivers ?
Please check the status of your issue.
Comment 5 GitLab Migration User 2019-09-18 20:16:25 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/892.


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.