Evgeny Pokhilko's Weblog

Programmer's den

OpenGL hardware acceleration through remote X11 SSH connection


This article is about running an OpenGL application on a remote server and using the local graphics card for rendering. It can help you in different rare scenarios: 1. You have a server in your network and it has some software with graphical output. You want to use that software remotely on many computers in the network without installing it on each machine individually. 2. Your application needs specific hardware configuration or resources that are only available on the server. 3. You experiment with remote OpenGL rendering for some reason.

For demonstration we are going to play chromium-bsu running on a remote server using the local graphics card.


You should be aware of the security risk of opening X server for hardware rendering. The ssh server gets more control of the client with inderict rendering enabled.

My environment

I have a server with OpenSUSE Tumbleweed 13.2. It runs in headless mode. I also have a laptop with Lubuntu 15.10 wily that connects to the server through SSH. I will call these machines OpenSUSE and Lubuntu.


You need to be familiar with general X11 client / server and SSH concepts. Counter intuitively, in my environment the laptop acts as X server and OpenSUSE Tumbleweed as X client. At the same time, Lubuntu is ssh client and OpenSUSE is ssh server.

Direct rendering – the OpenGL application sends instructions directly to the local hardware bypassing the target X server. This is only possible with single machine. We cannot use it in our scenario.

Software rendering – software rendering engine is used without leveraging the graphics card. It can be slow.

Indirect rendering – The remote application sends instructions to the X server which transfers them to the graphics card. This is what we are going to demonstrate in this article.

Before we start

This article will not explain known topics. We assume that SSH is already configured and all packages and drivers are installed. You have a private key for ssh to connect to the server and the server authorized_keys contains the corresponding public key.

Configure OpenSUSE

We need to enable X11 forwarding in the sshd configuration file:

  1. Open /etc/ssh/sshd_config in your favorite text editor.
  2. Add or uncomment X11Forwarding yes
  3. Restart your sshd daemon

    service sshd restart

  4. Install the game

    zypper install chromium-bsu

Nothing else needs to be done on OpenSUSE.

Configure Lubuntu

  1. Enable trusted forwarding. Open or create ~/.ssh/config

    Host ForwardX11Trusted yes

Trusted forwarding is needed to enable 3D hardware rendering.

  1. Enable indirect redering. Open /etc/lightdm/lightdm.conf

Add or uncomment:

xserver-command=X +iglx

The command enables iglx, which I believe is indirect glx.

  1. Restart lightdm or reboot the X server

    systemctl restart lightdm.service

Run Chromium B.S.U

  1. Connect to the SSH server.
  2. Run chromium-bsu with the environment variables below:

    LIBGL_ALWAYS_INDIRECT=1 chromium-bsu

You can also enable debug output for LIBGL with LIBGL_DEBUG=verbose chromium-bsu

The game is already playable. I get 30 FPS.

Make it even faster

To improve the performance further we need to enable direct TCP connection to the X server rather than going through SSH. Please note that this represents a security vulnerability and disabled by default. You can only use in a trusted local network.

  1. Open /etc/lightdm/lightdm.conf

Add or uncomment:

xserver-command=X -listen tcp +iglx
  1. Open /etc/xinit/xserverrc

Commend out -nolisten tcp and another line as follows:

# exec /usr/bin/X -nolisten tcp "$@"
exec /usr/bin/X "$@"
  1. Enable X11 connection to all clients (very unsafe!):

    xhost +

Run Chromium B.S.U. with direct TCP connection

LIBGL_ALWAYS_INDIRECT=1 DISPLAY=<client-tcp>:0 chromium-bsu

This mode gave me the best possible performance. I could not distinguish between the game running locally and remotely from the server.

Troubleshooting and diagnostics

Use LIBGL_DEBUG=verbose environment variable to see warning messages. I get the following messages when the application falls back to the software rendering:

libGL error: failed to authenticate magic 1
libGL error: failed to load driver: r600
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so

You can also see the following message when X server does not allow iglx (+iglx option):

AIGLX: Screen 0 is not DRI capable

March 4, 2017 Posted by | Linux, Networking, SUSE | Leave a comment

Run a bash script with sudo, nohup and in the background

This command will run script.sh under super user and you can disconnect and come back later:

sudo nohup bash script.sh &

It’s useful if you don’t have Screen or you want the process to close when it finishes without a screen session hanging around.

By default, the output will go to nohup.out. You can change it by redirecting it to a file:

sudo nohup bash script.sh > script.out &

nohup runs a command immune to hangups. It redirects input and output of the process. If you want to connect to the server again and see the output, use tail, as below:

tail -f script.out

The command will  be printing output as your command produces it as if it runs in your terminal session. Ctrl-C will terminate tail but not the nohup command.

If you need to kill the command before it finishes, find the process id first with:

sudo ps -Af | grep “bash script.sh”
sudo kill <process id>

I hope it helps.

February 20, 2012 Posted by | Linux, Networking | | 3 Comments

Suse 11 workstation as a router

My task was to connect to my office through VPN from a SUSE workstation and allow another Windows machine to use office network resources. In this scenario SUSE acts as a router forwarding ip packets from the Windows machine to the office network.

I am using NetworkManager for VPN on my SUSE machine. In one of the previous articles I wrote about establishing VPN connection to a windows server from SUSE.

IP forwarding is disabled by default. You can check it with the following command:

cat /proc/sys/net/ipv4/ip_forward

It returns either 1 or 0. 1 means IP forwarding is enabled. I suppose you will see 0. Otherwise you wouldn’t read this article. But use this command later to verify that ip forwarding is enabled.

In my configuration I need to change settings of the SUSE firewall to allow IP forwarding. The settings you see in YAST are not comprehensive and they are not enough for the task.

Instead open /etc/sysconfig/SuSEfirewall2 in gedit. Add your VPN network interface name (run/sbin/ifconfig after connecting to VPN to get all active interfaces) to FW_DEV_EXT. It will make your office network external for the SUSE router. Add your internal network (where the packets will be coming from) to FW_DEV_INT. As a result SUSE knows that your internal network is your home network and your office network is external.

Change FW_ROUTE to yes. This will allow IP forwarding. I also changed FW_MASQUERADE to yes. Not sure it was necessary for my task. By the way masquerading can be configured in YAST GUI tool unlike IP forwarding.

Now if you invoke cat /proc/sys/net/ipv4/ip_forward, you should see 1 returned.

Forwarding will be performed according to your routing table. To see the routing table invoke

/sbin/route -n

Now go to your Windows machine. Say your office network is 111.222.333.0 ( and the SUSE machine IP address is 193.333.222.1.

route add mask

This will send packets going to your office network to the SUSE router.

February 24, 2010 Posted by | Networking, SUSE | , | Leave a comment

Remote desktop via VPN from SUSE 11.1

I needed to work at weekends and connected to my machine at work. VPN + Remote Desktop

I used this guide to install VPN:


“sudo apt-get install network-manager-pptp” didn’t work in suse. I had to find the rpm packages. There were two I had to install:



I installed them running one command:

rpm -ivh <package1> <package2>

Then I installed rdesktop. I connect from command prompt:

rdesktop <full DNS address> -f

-f switch is full screen

There is another switch for setting the resolution:

-g 1024×768

May 30, 2009 Posted by | Networking, SUSE | , | Leave a comment