ssh forwarded glx returns "Error: couldn't find RGB GLX visual or fbconfig" against older servers

Bug #384001 reported by Joakim Plate
48
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Mesa
New
Unknown
mesa (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

After upgrading to Jaunty 9.04 from Hardy remote glx rendering (over ssh or just network) against older servers is not working anymore.

Currently i've only tested against two X servers:
X-Win32
Mac OSX Leopard X11 Server

Both of which works fine on the same machine when rebooted into Hardy (still available on another partition)

glxinfo outputs:
> name of display: localhost:10.0
> Xlib: extension "Generic Event Extension" missing on display "localhost:10.0".
> Error: couldn't find RGB GLX visual or fbconfig

xdpyinfo outputs that i have SGI-GLX and GLX extension, will attach the full output later.

I suspect that newer glx client side libs must be needing something not provided by the older servers.

Let me know what other types of logs that are of interest

[lspci]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03)
     Subsystem: AOPEN Inc. Device [a0a0:062d]

---
Architecture: i386
DistroRelease: Ubuntu 10.04
DkmsStatus: Error: [Errno 2] No such file or directory
MachineType: AOpen i965GMx-IF
Package: mesa (not installed)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-22-generic root=UUID=0f9b4a48-eec1-46c2-a350-078a0eed0034 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Tags: lucid lucid
Uname: Linux 2.6.32-22-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare video
dmi.bios.date: 12/11/2007
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 6.00 PG
dmi.board.name: i965GMx-IF
dmi.board.vendor: AOpen
dmi.board.version: 558EX10I690
dmi.chassis.type: 3
dmi.chassis.vendor: AOpen
dmi.chassis.version: i965GMx-IF
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd12/11/2007:svnAOpen:pni965GMx-IF:pvrAO00001JW:rvnAOpen:rni965GMx-IF:rvr558EX10I690:cvnAOpen:ct3:cvri965GMx-IF:
dmi.product.name: i965GMx-IF
dmi.product.version: AO00001JW
dmi.sys.vendor: AOpen
glxinfo:
 Error: couldn't find RGB GLX visual or fbconfig
 name of display: localhost:10.0
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-22-generic

Revision history for this message
Joakim Plate (elupus) wrote :

This is the glxinfo from an intrepid system (which happens to have NVIDIA drivers installed)

display: localhost:10 screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbo se)
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
    GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info,
    GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync,
    GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGI_swap_control, GLX_ARB_create_context, GLX_NV_float_buffer,
    GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float,
    GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB,
    GLX_NV_present_video, GLX_NV_multisample_coverage
GLX version: 1.2
GLX extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_ARB_get_proc_address
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 1.2 (2.0.6471 Release)
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_multitexture, GL_ARB_point_parameters,
    GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map,
    GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
    GL_ARB_window_pos, GL_EXT_bgra, GL_EXT_blend_color,
    GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
    GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
    GL_EXT_packed_pixels, GL_EXT_rescale_normal, GL_EXT_secondary_color,
    GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap,
    GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
    GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array,
    GL_NV_blend_square, GL_NV_texgen_reflection, GL_SGIS_generate_mipmap,
    GL_SGIS_texture_lod

4 GLX Visuals
   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 24 tc 0 32 0 r . . 8 8 8 8 2 32 8 16 16 16 16 2004364842 97656505 1 None
0x24 24 tc 0 32 0 r y . 8 8 8 8 2 32 8 16 16 16 16 909327152 809329520 None
0x25 8 pc 0 0 0 c . . 0 0 0 0 2 32 8 16 16 16 16 0 0 None
0x26 8 pc 0 0 0 c y . 0 0 0 0 2 32 8 16 16 16 16 0 0 None

Revision history for this message
Joakim Plate (elupus) wrote :

Was abit unclear.. The above data is from Intrepid System with an X-Win32 Server

Here follows a glxinfo from the broken jaunty system with it's own local X Server (i skipped the OpenGL extensions as i'm very sure this is a GLX problem)

name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group

Revision history for this message
Joakim Plate (elupus) wrote :

Actually looking at this i think I know the problem.. The older server doesn't support GLX_SGIX_fbconfig..

Could the fallback to older methods in jaunty be broken?

Joakim Plate (elupus)
affects: ubuntu → mesa (Ubuntu)
Revision history for this message
James Willcox (snorp) wrote :

I can confirm the same behavior with Leopard 10.5.7. Very annoying :/

Revision history for this message
Joakim Plate (elupus) wrote :

Nice to know i'm not alone. I wonder if this is a Ubuntu specific problem. Perhaps it should be reported upstream?

Revision history for this message
Bryce Harrington (bryce) wrote :

Can you reproduce it on Karmic? If so, we may be able to send it upstream.

Changed in mesa (Ubuntu):
status: New → Incomplete
Revision history for this message
Joakim Plate (elupus) wrote :

I've reproduced same thing on Karmic. Identical issue.

Revision history for this message
Bryce Harrington (bryce) wrote :

Thank you for verifying it still occurs on Karmic. Please execute the following command in a terminal after reproducing the issue, and it it will automatically gather debugging information needed for forwarding this bug upstream:

  apport-collect 384001

(You may need to install the python-launchpadlib package from the universe repository. Additionally, when prompted to give apport-collect permissions for Launchpad you will need to give it at least the ability to "Change Non-Private" data as it will be adding information to your bug report.)

Changed in mesa (Ubuntu):
status: Incomplete → New
status: New → Incomplete
Revision history for this message
Joakim Plate (elupus) wrote : apport-collect data

Architecture: i386
DistroRelease: Ubuntu 9.10
MachineType: AOpen i965GMx-IF
Package: mesa (not installed)
PccardctlIdent:

PccardctlStatus:

ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-8-generic root=UUID=0f9b4a48-eec1-46c2-a350-078a0eed0034 ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-8.28-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.6.0~git20090829.00413d87-0ubuntu0tormod2
 libdrm2 2.4.12+git20090825.ce6c68dc-0ubuntu0tormod3
 xserver-xorg-video-intel 2:2.8.1+git20090829.7c48c21b-0ubuntu0tormod
 xserver-xorg-video-ati 1:6.12.99+git20090829.39dfac41-0ubuntu0tormod
Uname: Linux 2.6.31-8-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 12/11/2007
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 6.00 PG
dmi.board.name: i965GMx-IF
dmi.board.vendor: AOpen
dmi.board.version: 558EX10I690
dmi.chassis.type: 3
dmi.chassis.vendor: AOpen
dmi.chassis.version: i965GMx-IF
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd12/11/2007:svnAOpen:pni965GMx-IF:pvrAO00001JW:rvnAOpen:rni965GMx-IF:rvr558EX10I690:cvnAOpen:ct3:cvri965GMx-IF:
dmi.product.name: i965GMx-IF
dmi.product.version: AO00001JW
dmi.sys.vendor: AOpen
fglrx: Not loaded
glxinfo:
 Xlib: extension "Generic Event Extension" missing on display "localhost:10.0".
 Error: couldn't find RGB GLX visual or fbconfig
 name of display: localhost:10.0
system:
 distro: Ubuntu
 architecture: i686kernel: 2.6.31-8-generic

Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Revision history for this message
Joakim Plate (elupus) wrote :
Changed in mesa (Ubuntu):
status: Incomplete → New
tags: added: apport-collected
Revision history for this message
Joakim Plate (elupus) wrote :

I ran that command from a ssh terminal that exhibited the problem, assume that is what you wanted?

Revision history for this message
Bryce Harrington (bryce) wrote :

Thanks

Changed in mesa (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Hiroki Nagai (nagai-hiroki) wrote :

I think I bumped into the same bug when conncecting freenx server on Jaunty from nx client elsewhere.

$ glxinfo -display :1001
name of display: :1001.0
Xlib: extension "Generic Event Extension" missing on display ":1001.0".
Error: couldn't find RGB GLX visual or fbconfig

$ xdpyinfo -display :1001 | grep GLX
    GLX
    SGI-GLX

Revision history for this message
Trey Stout (treystout+launchpad) wrote :

Architecture: i386
DistroRelease: Ubuntu 9.04
Package: mesa
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_US.UTF-8
ProcVersion: Linux version 2.6.28-15-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009
Uname: Linux 2.6.28-15-generic i686
UserGroups:

XorgConf:

glxinfo:
 name of display: localhost:10.0
xkbcomp:

Bryce Harrington (bryce)
tags: added: jaunty
Bryce Harrington (bryce)
description: updated
Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

If I ssh to a remote box, and I try to run 'glxinfo' on the remote system, it fails unless I explicitly force indirect mode via LIBGL_ALWAYS_INDIRECT.

The problem is that without LIBGL_ALWAYS_INDIRECT set, glx_direct gets set to true in glxext.c:

---
glx_direct = (getenv("LIBGL_ALWAYS_INDIRECT") == NULL);
glx_accel = (getenv("LIBGL_ALWAYS_SOFTWARE") == NULL);

   /*
    ** Initialize the direct rendering per display data and functions.
    ** Note: This _must_ be done before calling any other DRI routines
    ** (e.g., those called in AllocAndFetchScreenConfigs).
    */
   if (glx_direct && glx_accel) {
      dpyPriv->dri2Display = dri2CreateDisplay(dpy);
      dpyPriv->driDisplay = driCreateDisplay(dpy);
   }
   if (glx_direct)
      dpyPriv->driswDisplay = driswCreateDisplay(dpy);
---

Then in AllocAndFetchScreenConfigs(), we get our visuals and fbconfigs via:
      getVisualConfigs(dpy, priv, i);
      getFBConfigs(dpy, priv, i);

but then they get thrashed by:
      if (psc->driScreen == NULL && priv->driswDisplay)
         psc->driScreen = (*priv->driswDisplay->createScreen) (psc, i, priv);

which is driCreateScreen in drisw_glx.c and ends up doing:
   psc->configs = driConvertConfigs(psc->core, psc->configs, driver_configs);

which results in psc->configs being set to NULL which is causing GetGLXPrivScreenConfig to return GLX_BAD_VISUAL and thus causing glxinfo to bail.

Revision history for this message
In , Olvaffe (olvaffe) wrote :

glxinfo creates a context that allows direct rendering, and libGL is capable of doing direct rendering (through drisw). I think it is a reasonable behavior. To get indirect rendering, you can specify -i when executing glxinfo.

As for driConvertConfigs, it should not return NULL normally. It returns NULL when the original psc->configs and driver_configs have no config in common. Can you check what's in the original psc->configs?

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

You miss the point. This isn't about glxinfo, this is about *ALL* glx applications. glxinfo is just an example.

You said, "glxinfo creates a context that allows direct rendering" ... but direct rendering is not available because the client is remote from the server. In older versions of mesa (6.5 for sure, not sure through when), it would detect when remote and use indirect. This behavior seems to have reverted.

Now, when remote, it tries to use drisw, but it results in an empty set of visuals and fbconfigs as described by the codepath in my initial report.

Revision history for this message
In , Olvaffe (olvaffe) wrote :

I see your point. I guess the old behavior is simply because there was no swrast_dri.

As for swrast_dri, it has _direct_ access to the (pure software) OpenGL pipelines, and is thus chosen for direct rendering. The fact that xserver is remote is not taken into consideration. I am not sure which behavior is desired/correct though. Other people should have better answer than me.

The empty visual/fbconfig list you saw might be some other bug. That's why I would like to know the original value of psc->configs. I can run glxgears from a remote machine under "ssh -X" just fine, and it uses swrast_dri. My remote machine runs mesa 7.5.1.

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

Created attachment 29991
glxinfo.txt

Here's glxinfo's output when run as a local client.

numvisuals was 800 before calling into drisw to prune them, and it looks the same as the output from the remote host when forcing INDIRECT.

Revision history for this message
In , Olvaffe (olvaffe) wrote :

Created attachment 29992
no empy configs

Do you have a nvidia card on your local machine?

driConvertConfigs filters out any visual/fbconfig that has no matching DRI configs. It could be that nvidia report visuals/fbconfigs that none of them matches DRI configs (the matching rule is strict).

The patch (against git master) makes the conversion fail in such case and skips the failing DRI screen. It should hopefully skip swrast_dri in your case.

Can you help verify it? I don't have any machine with nvidia cards.

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

Yes, I have an nVidia card on this machine, but it also happens when I have an ATI card on the server machine. The vendor card information is abstracted away and we just query information straight from our OpenGL.framework, so the drivers are not directly involved.

Even if you had an nVidia card, that wouldn't help unless you were running OSX as well.

Can you tell me or point me to a spec that details the matching rule? We just generate a series of configurations based on the reported details from OpenGL.framework, but it's possible that we are missing a few or can add a few others for compatability with drisw

http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/GL/visualConfigs.c

I'll test the patch and let you know.

Revision history for this message
In , Olvaffe (olvaffe) wrote :

There is no spec on the rules. The visuals/fbconfigs reported by the server are converted to __GLcontextModes in mesa. You can have a look at driConfigEqual in src/glx/x11/dri_common.c.

Revision history for this message
In , Olvaffe (olvaffe) wrote :

I had a quick look at the link you gave. It might be maxPbufferWidth/maxPbufferHeight that fails the matching test. But there is no point to adjust the two fileds (maybe some others) only to pass the test.

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

Excellent. With that patch in place, we end up with AIGLX rather than erroring out. Looks good to me.

Revision history for this message
In , Olvaffe (olvaffe) wrote :

Any comment on the patch? IMO, the issue is a general one that can be seen on XQuartz and other non-DRI based X servers.

Revision history for this message
In , Jon TURNEY (jon-turney) wrote :

(In reply to comment #10)
> Any comment on the patch? IMO, the issue is a general one that can be seen on
> XQuartz and other non-DRI based X servers.

From my experience working on a similar problem with the Cygwin/X DDX, I think the real problem is that the config matching code expects to exactly match bindToTexture and maxPbuffer with a value of -1 (don't care), hence if these are actually set to report our capabilities, no configs remain after the attempt find the common configs.

Your patch to fall back to indirect if we can't find any common configs makes sense, but I don't actually think that should be happening.

(In reply to the bug title)

It's currently a policy in libGL to use swrast in preference to indirect, unless forced, and swrast is direct (Comment #3)

It would be nice if for Xservers which can only do indirect acceleration, there was a way to cause local clients to automatically use the indirect path, but I'm not sure how that could be done cleanly.

Revision history for this message
In , Dbn-lists (dbn-lists) wrote :

(In reply to comment #11)
>
> It would be nice if for Xservers which can only do indirect acceleration, there
> was a way to cause local clients to automatically use the indirect path, but
> I'm not sure how that could be done cleanly.

I might not be understanding the issue correctly, but you can build GLX to only support indirect rendering. Basically, the code needs to build without -DGLX_DIRECT_RENDERING. With configure, this is --disable-driglx-direct.

Revision history for this message
In , Olvaffe (olvaffe) wrote :

(In reply to comment #11)
> From my experience working on a similar problem with the Cygwin/X DDX, I think
> the real problem is that the config matching code expects to exactly match
> bindToTexture and maxPbuffer with a value of -1 (don't care), hence if these
> are actually set to report our capabilities, no configs remain after the
> attempt find the common configs.
> Your patch to fall back to indirect if we can't find any common configs makes
> sense, but I don't actually think that should be happening.
IMO, driConfigEqual is doing great. It should look for exact match. I think GLX_DONT_CARE is only assigned to those attributes that are not common to visual and fbconfig. It is so that driConfigEqual can work without caring a __GLcontextModes is from a visual or a fbconfig.

In the patch, driConvertConfigs fails only when _none_ of the configs reported by the server has a matching dri config. It should be quite safe. But I am also starting thinking that it should fail if _any_ of the configs reported by the server has no matching dri config...

> (In reply to the bug title)
> It's currently a policy in libGL to use swrast in preference to indirect,
> unless forced, and swrast is direct (Comment #3)
But only in some sense. It is hard to say which interpretation is desirable.

> It would be nice if for Xservers which can only do indirect acceleration, there
> was a way to cause local clients to automatically use the indirect path, but
> I'm not sure how that could be done cleanly.
A config runs with reduced performance when GLX_CONFIG_CAVEAT reports GLX_SLOW_CONFIG. It is not about direct or indirect though.

Revision history for this message
In , Olvaffe (olvaffe) wrote :

(In reply to comment #12)
> I might not be understanding the issue correctly, but you can build GLX to only
> support indirect rendering. Basically, the code needs to build without
> -DGLX_DIRECT_RENDERING. With configure, this is --disable-driglx-direct.
The question is, when libGL.so is compiled with direct rendering support, how to decide if direct rendering is viable at runtime? The connection to xserver may be remote or local. The configs from xserver and dri driver may or may not match. How do they affect the decision?

Revision history for this message
In , Joakim Plate (elupus) wrote :

After upgrading to Ubuntu Jaunty 9.04 from Hardy remote glx rendering (over ssh or just network) against older servers is not working anymore. This is still a problem in current git (or atleast in current xorg-edgers repo)

I've tested against two X servers, verified from other sources:
X-Win32
Exceed (third party that I can't be 100% on it's validity)
Mac OSX Leopard X11 Server

All of which works fine on the same machine when rebooted into Hardy using older xorg stack

glxinfo outputs:
> name of display: localhost:10.0
> Xlib: extension "Generic Event Extension" missing on display "localhost:10.0".
> Error: couldn't find RGB GLX visual or fbconfig

xdpyinfo outputs that i have SGI-GLX and GLX extension.

I suspect that newer glx client side libs must be needing something not provided by the older servers.

I've reported this bug on launchpad "https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/384001" where also logs are available about the issue.

Though I'd take it upstream since that bug report seems to be stalled.

Changed in xorg-server:
status: Unknown → Confirmed
Revision history for this message
In , Joakim Plate (elupus) wrote :

Thought i'd just mention that same bug occurs with nvidia binary drivers as x server, and jaunty/karmic as client.

I've mentioned it to nvidia, but since the bug is in the client, i suspect the best they can do is work around it for their own server.

Omer Akram (om26er)
Changed in mesa (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Brendan Grieve (brendan-grieve) wrote :

I too had this same error, but I found a workaround. Set the environment variable 'LIBGL_ALWAYS_INDIRECT=yes' and then try running the program.

Example: -
  administrator@artemis:~$ glxinfo
  name of display: localhost:11.0
  Error: couldn't find RGB GLX visual or fbconfig

  administrator@artemis:~$ LIBGL_ALWAYS_INDIRECT=yes glxinfo
  name of display: localhost:11.0
  display: localhost:11 screen: 0
  direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
  server glx vendor string: NVIDIA Corporation
  server glx version string: 1.4
  server glx extensions:
      GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,
  ...
  ...
  ...

Works both through NX and SSH tunnelling.

Revision history for this message
Joakim Plate (elupus) wrote :

doesn't work here on jaunty. could your nvidia drivers i suppose. will test lucid when i get the time.

Revision history for this message
Joakim Plate (elupus) wrote :

tested on lucid, not working there either. X-Win32 server with lucid as the client over ssh.

Revision history for this message
In , Gsapountzis (gsapountzis) wrote :

(In reply to comment #14)
> The question is, when libGL.so is compiled with direct rendering support, how
> to decide if direct rendering is viable at runtime? The connection to xserver
> may be remote or local. The configs from xserver and dri driver may or may not
> match. How do they affect the decision?
>

I don't think there is a simple way to decide. One way to answer this is to change glxext.c from:

   if (glx_direct)
      dpyPriv->driswDisplay = driswCreateDisplay(dpy);

to:

   if (glx_direct && !glx_accel)
      dpyPriv->driswDisplay = driswCreateDisplay(dpy);

and see if people complain :-(

It will mainly affect developers who usually explicitly set LIBGL_ALWAYS_SOFTWARE. Also wiki's won't have to be updated because they usually instruct people to set the envvar.

Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automatic notification.]

Hi elupus,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 384001

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 384001 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/384001

Changed in mesa (Ubuntu):
status: Triaged → Incomplete
tags: added: needs-retested-on-lucid-by-june
Revision history for this message
Joakim Plate (elupus) wrote :

Sure will do, tested it a while back on lucid beta 1 i think and was still and issue. Maybe all the backporting/reverting of xorg might have fixed it.

Revision history for this message
Joakim Plate (elupus) wrote : BootDmesg.txt

apport information

description: updated
Revision history for this message
Joakim Plate (elupus) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : Lspci.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : Lsusb.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : PciDisplay.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : ProcModules.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : RelatedPackageVersions.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : UdevDb.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : UdevLog.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : XorgConf.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : XorgLog.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : XorgLogOld.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : Xrandr.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : setxkbmap.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : xdpyinfo.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote : xkbcomp.txt

apport information

Revision history for this message
Joakim Plate (elupus) wrote :

glxinfo output identical to before..

name of display: localhost:10.0
Error: couldn't find RGB GLX visual or fbconfig

Bryce Harrington (bryce)
tags: added: karmic lucid
Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

*** Bug 28415 has been marked as a duplicate of this bug. ***

Revision history for this message
Matthew L. Dailey (matthew-l-dailey) wrote :

Just wanted to add a note to confirm that this still exists under lucid.

Setting the LIBGL_ALWAYS_INDIRECT variable does work around this, both through remote X and neatx.

Another workaround I have found is to either remove or chmod 000 /usr/lib/dri/swrast_dri.so and /usr/lib32/dri/swrast_dri.so - it looks like neither of these existed on hardy. With these files inaccessible, glx apps work properly via remote X and neatx.

I hope this helps to narrow this one down...

Revision history for this message
Joakim Plate (elupus) wrote :

The LIBGL_ALWAYS_INDIRECT change does not work on jaunty atleast. But it didn't work on my previous test on lucid either. I still think that is only applicable for people that have nvidia binary drivers installed.

Changed in xorg-server:
importance: Unknown → Medium
Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

Thank you for the supporting documents. Thanks also for confirming this issue in Ubuntu 10.04. There should be enough information for the developers to begin work to resolve this issue.

Changed in mesa (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

More users are complaining about this... ping...

Revision history for this message
In , Pathen (pathen) wrote :

1) To further document "lots of people affected by this" (and I'm well aware I haven't gotten off my posterior to fix this either):

SuSE brought this up last year[1] and ended up shipping with this patch[2] (a band-aid):

- if (glx_direct)
- dpyPriv->driswDisplay = driswCreateDisplay(dpy);
+// if (glx_direct)
+// dpyPriv->driswDisplay = driswCreateDisplay(dpy);

[1] http://<email address hidden>/msg06684.html
[2] https://bugzilla.novell.com/show_bug.cgi?id=469280

2) Bear in mind that making the visuals match exactly merely allows the software renderer to be used, it doesn't allow indirect GLX (check your GLX server strings carefully).

LIBGL_ALWAYS_INDIRECT is quite a pain, (more so for XDMCP sessions). In my experience client-side rendering is what most people want if the display is remote. If the network load is too heavy for client-side the render load will very likely be too heavy for the software rasterizer. (And apps can use display lists to alleviate the network load.)

Changed in xorg-server:
importance: Medium → Unknown
Revision history for this message
sebbu (sebbu) wrote :

The workaround (LIBGL_ALWAYS_INDIRECT=yes) works on ubuntu 10.04 (lucid) for my windows vista sp2 X server (XMing), as the log shows.

System is a fresh OVH installation, with xorg & glxgears just installed after apt-get update.

Changed in xorg-server:
importance: Unknown → Medium
Revision history for this message
Alasdair Allan (aa-astro) wrote :

Confirmed that this still affects Ubuntu 10.04 Server, forwarding onto a Mac OS X 10.6 system. However the

% setenv LIBGL_ALWAYS_INDIRECT yes

work around before running the affected application seems to resolve the problem.

Whereas direct rendering means that application can access the GPU hardware directly without communication with the X server first via Mesa, indirect rendering means that the GLX protocol will be used to transmit OpenGL commands and the X server will do the real drawing. Direct rendering is faster as it does not require change of context into X process of course, although in both cases rendering is done on the GPU if acceleration is present.

Revision history for this message
In , Jeremy Sequoia (jeremyhu) wrote :

*** Bug 24590 has been marked as a duplicate of this bug. ***

Changed in xorg-server:
status: Confirmed → Invalid
Bryce Harrington (bryce)
Changed in xorg-server:
importance: Medium → Unknown
status: Invalid → Unknown
Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Oibaf (oibaf) wrote :

Moved upstream report to new location.

Changed in xorg-server:
importance: Medium → Unknown
status: Confirmed → Unknown
Changed in xorg-server:
status: Unknown → New
Revision history for this message
piersh (piersh) wrote :

I'm seeing this bug with a fresh install of 22.04 server:

```
$ DISPLAY=172.17.0.1:0 glxinfo -i
name of display: 172.17.0.1:0
Error: couldn't find RGB GLX visual or fbconfig
```

This is a Ubuntu-only issue. I am able to successfully run glxinfo over the network from fully-updated Centos7, Rocky9 & Fedora34 machines.

Oibaf (oibaf)
affects: xorg-server → mesa
To post a comment you must log in.