Summary: | X11R6.8.1 Xprt server generates lots of 'No matching visual for __GLcontextMode with visual class = 5 (32771), nplanes = 8' warnings | ||
---|---|---|---|
Product: | xprint | Reporter: | David Schweiger <dvschweiger> |
Component: | Server: Extensions: Other | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | major | ||
Priority: | high | CC: | johan.walles, MostAwesomedude, roland.mainz |
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
David Schweiger
2004-12-28 09:15:50 UTC
see programs/Xserver/GL/mesa/X/xf86glx.c:init_screen_visuals(), around line 568. pScreen->visuals for the driver needs to contain a set of visuals that match what the GLX engine says are available. the visuals in Initialize{Ps,Pcl,...}Driver() need to be extended to match the ones listed by glxinfo at each depth. see mga_dri.c:MGAInitVisualConfigs() for an example; note especially the call to GlxSetVisualConfigs at the end, which tells the GLX core to use the driver-supplied visuals rather than the default fallback set. I have quiet the same problem with Xorg 6.8.2, but it's written on tty1 at the login prompt. Does anyone have any patch for this problem? It's a bit depressing to see this message every day. I have the same problem, but my radeon now does not accelerate with depth = 16 bits. Before this messages appeared I could did that, and glxinfo says this: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 16 tc 0 16 0 r . . 6 5 0 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r . . 6 5 0 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r . . 6 5 0 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r . . 6 5 0 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 tc 0 16 0 r y . 6 5 0 0 0 16 0 0 0 0 0 0 0 None 0x28 16 tc 0 16 0 r y . 6 5 0 0 0 16 8 0 0 0 0 0 0 Slow 0x29 16 tc 0 16 0 r y . 6 5 0 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 tc 0 16 0 r y . 6 5 0 0 0 16 8 16 16 16 0 0 0 Slow 0x2b 16 dc 0 16 0 r . . 6 5 0 0 0 16 0 0 0 0 0 0 0 None 0x2c 16 dc 0 16 0 r . . 6 5 0 0 0 16 8 0 0 0 0 0 0 Slow 0x2d 16 dc 0 16 0 r . . 6 5 0 0 0 16 0 16 16 16 0 0 0 Slow 0x2e 16 dc 0 16 0 r . . 6 5 0 0 0 16 8 16 16 16 0 0 0 Slow 0x2f 16 dc 0 16 0 r y . 6 5 0 0 0 16 0 0 0 0 0 0 0 None 0x30 16 dc 0 16 0 r y . 6 5 0 0 0 16 8 0 0 0 0 0 0 Slow 0x31 16 dc 0 16 0 r y . 6 5 0 0 0 16 0 16 16 16 0 0 0 Slow 0x32 16 dc 0 16 0 r y . 6 5 0 0 0 16 8 16 16 16 0 0 0 Slow 0x4b 32 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None My Xorg is now 24 bits (last output was with depth = 16) and as you can see r g and b values seems to be moved left (correct may be r:5 g:6 b:5, but now r=6, g=5 and b=0. My system accelerates well quake3 (32 bit emulation), enemy territory (32 bit emulation), glxgears (native 64 bit), but not quake4, for example. I have been looking for the solution of the problem, but I am not familiarized with Xorg internals, and I haven't find the origin of the problem. I would agree if anyone would find a sollution. I use gentoo, and tested all possible combinations of Mesa 6.4.1, xorg-server 0.99.4, 1.0.0 and 1.0.1, DRM from CVS and DRM from gentoo (20050807 and 20051028), and libdrm 2.0 and from cvs too. I haven't been able to reach the situation before the update (I had same drm and Mesa then, and 0.98 Xorg, I think). Xorg's output says it too: No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 16 (16 times). In 16 bit depth i get "Error: couldn't get an RGB, Double-buffered visual" from glxgears. Xprt only "displays" on printers, so if you're using an X server with a radeon card, it's not Xprt, and probably not the same as this bug. Closing WONTFIX because nobody cares about Xprint. Reopen if you plan to address this bug. |
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.