Ubuntu
mesa package

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

Bug #384001 reported by Joakim Plate on 2009-06-05

This bug affects 7 people

Affects		Status	Importance	Assigned to	Milestone
	Mesa	New	Unknown	auto-gitlab.freedesktop.org-mesa-mesa-- #57
	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

See original description

Tags:

Revision history for this message

Joakim Plate (elupus) wrote on 2009-06-05:

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

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 on 2009-06-05:

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 on 2009-06-05:

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) on 2009-07-17

affects:

ubuntu → mesa (Ubuntu)

Revision history for this message

James Willcox (snorp) wrote on 2009-08-03:

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

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-04:

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 on 2009-08-05:

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 on 2009-08-08:

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

Revision history for this message

Bryce Harrington (bryce) wrote on 2009-08-21:

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 on 2009-08-29: 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 on 2009-08-29:

#10

BootDmesg.txt Edit (43.4 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#11

CurrentDmesg.txt Edit (902 bytes, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#12

Lspci.txt Edit (9.9 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#13

Lsusb.txt Edit (1.0 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#14

PciDisplay.txt Edit (1.1 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#15

ProcCpuinfo.txt Edit (1.4 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#16

ProcInterrupts.txt Edit (1.3 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#17

ProcModules.txt Edit (2.8 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#18

UdevDb.txt Edit (103.7 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#19

UdevLog.txt Edit (213.3 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#20

XorgConf.txt Edit (6.8 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#21

XorgLog.txt Edit (23.9 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#22

XorgLogOld.txt Edit (24.5 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#23

Xrandr.txt Edit (493 bytes, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#24

setxkbmap.txt Edit (235 bytes, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#25

xdpyinfo.txt Edit (2.7 KiB, text/plain)

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#26

xkbcomp.txt Edit (47.0 KiB, text/plain)

Changed in mesa (Ubuntu):
status:	Incomplete → New
tags:	added: apport-collected

Revision history for this message

Joakim Plate (elupus) wrote on 2009-08-29:

#27

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 on 2009-08-30:

#28

Thanks

Changed in mesa (Ubuntu):
importance:	Undecided → Low
status:	New → Confirmed

Revision history for this message

Hiroki Nagai (nagai-hiroki) wrote on 2009-08-30:

#29

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 on 2009-09-02:

#30

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) on 2009-09-02

tags:

added: jaunty

Bryce Harrington (bryce) on 2009-09-02

description:

updated

Revision history for this message

In freedesktop.org Bugzilla #24226, Jeremy Sequoia (jeremyhu) wrote on 2009-09-30:

#65

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 freedesktop.org Bugzilla #24226, Olvaffe (olvaffe) wrote on 2009-10-01:

#66

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 freedesktop.org Bugzilla #24226, Jeremy Sequoia (jeremyhu) wrote on 2009-10-01:

#67

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 freedesktop.org Bugzilla #24226, Olvaffe (olvaffe) wrote on 2009-10-02:

#68

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 freedesktop.org Bugzilla #24226, Jeremy Sequoia (jeremyhu) wrote on 2009-10-02:

#69

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 freedesktop.org Bugzilla #24226, Olvaffe (olvaffe) wrote on 2009-10-02:

#70

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 freedesktop.org Bugzilla #24226, Jeremy Sequoia (jeremyhu) wrote on 2009-10-02:

#71

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 freedesktop.org Bugzilla #24226, Olvaffe (olvaffe) wrote on 2009-10-02:

#72

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 freedesktop.org Bugzilla #24226, Olvaffe (olvaffe) wrote on 2009-10-02:

#73

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 freedesktop.org Bugzilla #24226, Jeremy Sequoia (jeremyhu) wrote on 2009-10-02:

#74

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 freedesktop.org Bugzilla #24226, Olvaffe (olvaffe) wrote on 2009-10-08:

#75

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 freedesktop.org Bugzilla #24226, Jon TURNEY (jon-turney) wrote on 2009-10-08:

#76

(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 freedesktop.org Bugzilla #24226, Dbn-lists (dbn-lists) wrote on 2009-10-08:

#77

(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 freedesktop.org Bugzilla #24226, Olvaffe (olvaffe) wrote on 2009-10-09:

#78

(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 freedesktop.org Bugzilla #24226, Olvaffe (olvaffe) wrote on 2009-10-09:

#79

(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 freedesktop.org Bugzilla #24590, Joakim Plate (elupus) wrote on 2009-10-17:

#34

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.

Bug Watch Updater (bug-watch-updater) on 2009-10-17

Changed in xorg-server:
status:	Unknown → Confirmed

Revision history for this message

In freedesktop.org Bugzilla #24590, Joakim Plate (elupus) wrote on 2010-01-15:

#35

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) on 2010-02-01

Changed in mesa (Ubuntu):
status:	Confirmed → Triaged

Revision history for this message

Brendan Grieve (brendan-grieve) wrote on 2010-03-19:

#36

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 on 2010-03-19:

#37

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 on 2010-03-19:

#38

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

Revision history for this message

In freedesktop.org Bugzilla #24226, Gsapountzis (gsapountzis) wrote on 2010-03-27:

#80

(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 on 2010-05-03:

#39

[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 on 2010-05-04:

#40

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 on 2010-05-09: BootDmesg.txt

#41

BootDmesg.txt Edit (41.3 KiB, text/plain)

apport information

description:

updated

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: CurrentDmesg.txt

#42

CurrentDmesg.txt Edit (1.8 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: Lspci.txt

#43

Lspci.txt Edit (9.9 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: Lsusb.txt

#44

Lsusb.txt Edit (677 bytes, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: PciDisplay.txt

#45

PciDisplay.txt Edit (1.1 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: ProcCpuinfo.txt

#46

ProcCpuinfo.txt Edit (1.5 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: ProcInterrupts.txt

#47

ProcInterrupts.txt Edit (1.6 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: ProcModules.txt

#48

ProcModules.txt Edit (2.6 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: RelatedPackageVersions.txt

#49

RelatedPackageVersions.txt Edit (231 bytes, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: UdevDb.txt

#50

UdevDb.txt Edit (98.4 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: UdevLog.txt

#51

UdevLog.txt Edit (215.0 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: XorgConf.txt

#52

XorgConf.txt Edit (6.8 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: XorgLog.txt

#53

XorgLog.txt Edit (23.3 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: XorgLogOld.txt

#54

XorgLogOld.txt Edit (23.9 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: Xrandr.txt

#55

Xrandr.txt Edit (412 bytes, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: setxkbmap.txt

#56

setxkbmap.txt Edit (235 bytes, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: xdpyinfo.txt

#57

xdpyinfo.txt Edit (2.5 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09: xkbcomp.txt

#58

xkbcomp.txt Edit (47.1 KiB, text/plain)

apport information

Revision history for this message

Joakim Plate (elupus) wrote on 2010-05-09:

#59

glxinfo output identical to before..

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

Bryce Harrington (bryce) on 2010-05-14

tags:

added: karmic lucid

Revision history for this message

In freedesktop.org Bugzilla #24226, Michel Dänzer (michel-daenzer) wrote on 2010-06-10:

#81

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

Revision history for this message

Matthew L. Dailey (matthew-l-dailey) wrote on 2010-07-22:

#60

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 on 2010-07-22:

#61

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.

Bug Watch Updater (bug-watch-updater) on 2010-09-14

Changed in xorg-server:
importance:	Unknown → Medium

Revision history for this message

Charlie Kravetz (charlie-tca) wrote on 2010-09-30:

#62

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 freedesktop.org Bugzilla #24226, Jeremy Sequoia (jeremyhu) wrote on 2010-10-14:

#82

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

Revision history for this message

In freedesktop.org Bugzilla #24226, Pathen (pathen) wrote on 2010-10-14:

#83

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.)

Bug Watch Updater (bug-watch-updater) on 2011-01-25

Changed in xorg-server:
importance:	Medium → Unknown

Revision history for this message

sebbu (sebbu) wrote on 2011-02-03:

#63

glxinfo.txt Edit (4.3 KiB, text/plain)

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.

Bug Watch Updater (bug-watch-updater) on 2011-02-03

Changed in xorg-server:
importance:	Unknown → Medium

Revision history for this message

Alasdair Allan (aa-astro) wrote on 2011-02-17:

#64

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 freedesktop.org Bugzilla #24226, Jeremy Sequoia (jeremyhu) wrote on 2011-10-06:

#84

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

Bug Watch Updater (bug-watch-updater) on 2011-10-11

Changed in xorg-server:
status:	Confirmed → Invalid

Bryce Harrington (bryce) on 2011-11-15

Changed in xorg-server:
importance:	Medium → Unknown
status:	Invalid → Unknown

Bug Watch Updater (bug-watch-updater) on 2011-11-24

Changed in xorg-server:
importance:	Unknown → Medium
status:	Unknown → Confirmed

Revision history for this message

Oibaf (oibaf) wrote on 2023-08-21:

#85

Moved upstream report to new location.

Changed in xorg-server:
importance:	Medium → Unknown
status:	Confirmed → Unknown

Bug Watch Updater (bug-watch-updater) on 2023-08-21

Changed in xorg-server:
status:	Unknown → New

Revision history for this message

piersh (piersh) wrote on 2023-09-18:

#86

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) on 2023-09-25

affects:

xorg-server → mesa

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

Add attachment

Remote bug watches

freedesktop-bugs #24226
[NEW] Edit
freedesktop-bugs #24590
[RESOLVED DUPLICATE] Edit
novell-bugs #469280
[RESOLVED FIXED] Edit
auto-gitlab.freedesktop.org-mesa-mesa-- #57
[opened GLX] Edit

Bug watches keep track of this bug in other bug trackers.

Ubuntumesa package

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

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
mesa package