English
Ask Your Question
1

libGL error in SSH session on Fedora 20

asked 2014-06-25 01:32:23 +0000

wheels2050 gravatar image

I'm trying to run some software over an SSH session to another computer on the local network, which is running Fedora 20. However, I'm encountering errors relating to libGL.

Note: The following only applies when I SSH to the computer - if I sit at the computer, I don't receive any errors and the software runs as expected.

If I open a program that should be hardware-accelerated, I encounter the following error messages:

libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965

The program runs extremely slowly (to the point of being basically unusable).

I read elsewhere to try setting LIBGL_DEBUG=verbose, which gives me the following output:

libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
libGL: driver does not expose __driDriverGetExtensions_swrast(): /usr/lib/dri/swrast_dri.so: undefined symbol: __driDriverGetExtensions_swrast
libGL: Can't open configuration file ~/.drirc: No such file or directory.
libGL: Can't open configuration file ~/.drirc: No such file or directory.

so it appears that hardware acceleration is failing due to permissions, and then something is going wrong with software rendering. The graphics chip is an integrated Intel one - here's the relevant line from lspci:

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) If it helps, the output I get from glxinfo is:


name of display: localhost:23.0
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
libGL: driver does not expose __driDriverGetExtensions_swrast(): /usr/lib/dri/swrast_dri.so: undefined symbol: __driDriverGetExtensions_swrast
libGL: Can't open configuration file /remote/adelphi/bwhelan/.drirc: No such file or directory.
libGL: Can't open configuration file /remote/adelphi/bwhelan/.drirc: No such file or directory.
display: localhost:23  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
    GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_fbconfig_packed_float, 
    GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_import_context, 
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, 
    GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)
OpenGL version string: 2.1 Mesa 10.1.5
OpenGL shading language version string: 1.30
OpenGL extensions:
    GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, 
    GL_AMD_seamless_cubemap_per_texture, GL_AMD_shader_trinary_minmax, 
    GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, 
    GL_ARB_ES2_compatibility, GL_ARB_blend_func_extended, 
    GL_ARB_clear_buffer_object, GL_ARB_color_buffer_float, 
    GL_ARB_conservative_depth, GL_ARB_copy_buffer, GL_ARB_debug_output, 
    GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, GL_ARB_depth_texture, 
    GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, 
    GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced, 
    GL_ARB_explicit_attrib_location, GL_ARB_fragment_coord_conventions ...
(more)
edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted
0

answered 2014-06-25 04:40:08 +0000

The way that X servers work is that applications are the client, and the X server provides graphical functions for the client. When you use X forwarding over SSH, the client runs on the remote machine, and requests to the X server are forwarded to your local machine.

What does this mean? Say you ssh into one of your virtual machines and run xcowsay. The virtual machine is running the cow process, and it tells the machine you are connecting from how to draw the cow.

When you run a hardware accelerated application, the software is using the local hardware devices to aid in rendering. If you're on the local machine, that's great; the hardware is right there to use. However, when you are connected via ssh, the application can't talk to the hardware, because the hardware is on a different machine.

So the problem you have, as I see it, is not fixing the libGL error - that is the expected behavior. You need a way for multiple users to access the application. You could give x2go a try, or just create another virtual machine for each user that requres access and have them use the VM client.

edit flag offensive delete link more

Comments

Thanks for the reply. I've done a bit of looking around on the net about running OpenGL programs via ssh, and it seems like something I should be able to get working. Is that the case, or is there something fundamentally preventing me running OpenGL software remotely?

Also, I didn't quite understand the last bit of your last sentence. This isn't software that's running on a virtual machine, it's a 'proper' installation (I'm sshing from one Linux machine to another). Or am I misunderstanding you?

wheels2050 ( 2014-06-25 05:23:22 +0000 )edit

re: something fundamentally preventing you from running openGL apps remotely: that's exactly what I explained in this answer.

On virtual machines, I was making an inference based on this string from your logs: OpenGL vendor string: VMware, Inc. If neither is a VM, perhaps this is a quirk of ssh forwarding?

randomuser ( 2014-06-27 03:02:53 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Use your votes!

  • Use the 30 daily voting points that you get!
  • Up-vote well framed questions that provide enough information to enable people provide answers.
  • Thank your helpers by up-voting their comments and answers. If a question you asked has been answered, accept the best answer by clicking on the checkbox on the left side of the answer.
  • Down-voting might cost you karma, but you should consider doing so for incorrect or clearly detrimental questions and answers.

Stats

Asked: 2014-06-25 01:32:23 +0000

Seen: 4,366 times

Last updated: Jun 25 '14