Error couldn t open display null glxgears

Код: Выделить всё

xxxxxxxxxr@tolga-laptop:~> glxgears
Xlib:  extension "GLX" missing on display ":0.0".
glxgears: Error: couldn't get an RGB, Double-buffered visual.
Ошибка сегментирования

asked Mar 24, 2014 at 9:17

Errors like this mean that you are running a program that needs a graphical display and it can’t find one. GUI programs connect to the display defined by the $DISPLAY environmental variable. The general format of the error is

Could not open display $DISPLAY

Since, in your case, the error says (null), this means that $DISPLAY is not set. You therefore need to:

1. If you are logging in to a remote machine using something like ssh, you will need to export the $DISPLAY of your local machine and tell the remote computer to display GUI programs there. This can be done with the -X or -Y options of ssh:

   ssh -Y root@10.251.56.90
   

   As explained in man ssh:

    -Y  Enables trusted X11 forwarding.  Trusted X11 forwardings are not
        subjected to the X11 SECURITY extension controls.
    -X  Enables X11 forwarding.  This can also be specified on a per-host
        basis in a configuration file.
   

2. If this is your local machine, you need to install a graphical environment. If one is already installed, assuming a default Ubuntu setup, you can start it with this command:

   sudo service lightdm start
   

3. If you have a graphical environment running but for whatever reason, $DISPLAY is set to null, you can redefine it. The details will depend on your actual situation but in most cases, what you will need (assuming, again, you are on your local machine) is

   export DISPLAY=:0.0
   

   You can then run your GUI program normally.

4. If you do have an X server running but have switched to a tty (for example by pressing Ctrl+Alt+F1), you might simply need to return to your graphical environment. This depends on which virtual console your GUI is running but in most cases on Ubuntu that will be 7, so you can get back to it using Alt+F7.

   If that does not bring you back to your desktop, just cycle through all ttys Alt+Left Arrow or Alt+Right Arrow until you find the right one.

5. Another common problem is that you have started an X session as your normal user and are now trying to connect to it as root or another user. To enable this, you need to specify that this user has the right to access your graphical desktop. For example:

   xhost +si:localuser:terdon
   

   That will allow the local user terdon to connect to the running X server. The command needs to be run by the owner of the X session. Alternatively, to allow anyone to connect:

   xhost +
   

   And to revoke permissions:

   xhost -
   

answered Mar 24, 2014 at 22:48

Several things:

1. You are able to run GLXgears directly because TurboVNC has a built-in software-only OpenGL implementation, but if you run an OpenGL application in TurboVNC without VirtualGL, that application will not use the GPU.

2. Please use GLXspheres instead of GLXgears. It is a much more meaningful benchmark, and it also displays the OpenGL renderer string, which allows you to verify whether the GPU is being used.

3. The vglserver_config script only supports specific Linux distributions, so I need to know which Linux distribution you are using in order to diagnose the problem.

4. I can’t imagine any scenario in which the sanity checks mentioned at https://cdn.rawgit.com/VirtualGL/virtualgl/2.6.2/doc/index.html#hd006002001 work but VirtualGL still fails to access the 3D X server. The first line of the sanity check is xauth merge /etc/opt/VirtualGL/vgl_xauth_key, which would fail if /etc/opt/VirtualGL/vgl_xauth_key does not exist. I strongly suspect that you are mis-reporting something.

Thank you for your answer!

2./opt/VirtualGL/bin/glxspheres64
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
GLX FB config ID of window: 0xa1 (8/8/8/0)
Visual ID of window: 0x1ea
Context is Indirect
OpenGL Renderer: Gallium 0.4 on llvmpipe (LLVM 3.9, 256 bits)
14.920510 frames/sec — 15.467197 Mpixels/sec
13.778510 frames/sec — 14.283355 Mpixels/sec
12.883871 frames/sec — 13.355936 Mpixels/sec
13.051807 frames/sec — 13.530025 Mpixels/sec
13.273729 frames/sec — 13.760078 Mpixels/sec
11.918804 frames/sec — 12.355509 Mpixels/sec
11.793930 frames/sec — 12.226060 Mpixels/sec
5.661016 frames/sec — 5.868435 Mpixels/sec
9.466578 frames/sec — 9.813433 Mpixels/sec
6.741568 frames/sec — 6.988579 Mpixels/sec
8.812639 frames/sec — 9.135534 Mpixels/sec
9.581499 frames/sec — 9.932565 Mpixels/sec
8.593932 frames/sec — 8.908814 Mpixels/sec
3.955810 frames/sec — 4.100751 Mpixels/sec
8.705185 frames/sec — 9.024143 Mpixels/sec
5.800145 frames/sec — 6.012662 Mpixels/sec
10.387560 frames/sec — 10.768160 Mpixels/sec
8.666726 frames/sec — 8.984275 Mpixels/sec
11.716695 frames/sec — 12.145994 Mpixels/sec
3.986369 frames/sec — 4.132429 Mpixels/sec
6.317764 frames/sec — 6.549247 Mpixels/sec
6.490367 frames/sec — 6.728174 Mpixels/sec
6.139027 frames/sec — 6.363961 Mpixels/sec
6.854301 frames/sec — 7.105443 Mpixels/sec
6.908684 frames/sec — 7.161818 Mpixels/sec
6.352117 frames/sec — 6.584858 Mpixels/sec
6.713118 frames/sec — 6.959087 Mpixels/sec
6.492184 frames/sec — 6.730058 Mpixels/sec
5.253095 frames/sec — 5.445568 Mpixels/sec
6.832524 frames/sec — 7.082868 Mpixels/sec
5.815673 frames/sec — 6.028759 Mpixels/sec
5.950129 frames/sec — 6.168141 Mpixels/sec
6.613416 frames/sec — 6.855732 Mpixels/sec
6.754384 frames/sec — 7.001864 Mpixels/sec
6.214130 frames/sec — 6.441815 Mpixels/sec

1. I am using a google cloud instance, output of uname -a .
   Linux sbsy-vm 4.9.0-9-amd64 Migrate documentation to AsciiDoc #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 GNU/Linux

2. You are correct, xauth merge /etc/opt/VirtualGL/vgl_xauth_key fails because the file does not exists. The other sanity checks run without outputing error messages.

P.S My task is based on . I need to build it and it requires:
OpenGL (Desktop / ES / ES2)
-(lin) sudo apt install libgl1-mesa-dev
Glew
-(win) built automatically (assuming git is on your path)
-(deb) sudo apt install libglew-dev
-(mac) sudo port install glew
I have not yet install mesa-dev, because I am not sure whether it will cause more problems.

You appear to be running Debian 9 («Stretch»), which should work with VirtualGL. (Debian 10 «Buster» has not been tested, to my knowledge. Refer to https://virtualgl.org/Documentation/OSSupport.) However, Google Cloud instances require additional configuration in order to make them work with VirtualGL. I provide that configuration assistance only as a paid service, but I can tell you that the major differences between a GCP VirtualGL configuration and an ordinary VirtualGL configuration are:

1. The need to use a specific Google-supplied build of the nVidia drivers (https://cloud.google.com/compute/docs/gpus/add-gpus#installing_grid_drivers_for_virtual_workstations)
2. The need to configure the X server as headless (https://virtualgl.org/Documentation/HeadlessNV)
3. The need to install and enable a display manager (GDM, LightDM, etc.)

If the advice above is insufficient to make VirtualGL work with your GCP instance, then you will need to pay me to produce a configuration procedure for that specific instance. I do that work for a flat fee. Contact me through e-mail if you are interested in pursuing that: https://virtualgl.org/About/Contact.

Thanks, sudo nvidia-xconfig -a --allow-empty-initial-configuration --use-display-device=None --virtual=1920x1200 --busid {busid} and re-run vgl configure script did the work for me.

asked Dec 1, 2019 at 21:17

answered Dec 6, 2019 at 5:29