7

Setting up GPU accelerated remote desktop with sound on headless Linux using NoM...

 3 years ago
source link: https://mightynotes.wordpress.com/2021/02/27/setting-up-gpu-accelerated-remote-desktop-with-sound-on-headless-linux-using-nomachine/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

I have always wanted to setup a remote desktop on my NAS. It feels really cool to have the exact same desktop anywhere. In lab, out side at a caffe, in lecture. But I’ve never got GPU acceleration working properly. While I can’t rely on the puny Cortex-A72 cores to draw the entire desktop (it works, but low FPS). Took me a year of on-and-off trial and error to get it right.

GPU acceleration on a headless server

Having an accelerated desktop running headlessly is a lot harder than I though. Various conditions have to be met:

  1. Using the “real” X.org server
  2. GPU is connected to a monitor
  3. DBus is properly launched
  4. Desktop runs as you, not root

This is easy when working locally with a physical monitor. Not quite when headless. First of all, GPU acceleration only work with the real X.org server while the GPU is connected to a monitor. But most remote solutions package themselves with a (most likely some fork of Xvfb) standalone X. And you don’t have a screen in a headless setup. The most common solution is to get a dummy display plug:

A dummy HDMI plug

It tricks the GPU into thinking that there’s actually a display connected to it. So framebuffer allocation and etc works. If you’re using an AMD GPU with AMDGPU driver, consider yourself lucky. AMDGPU supports virtual display out of the box. Edit /etc/modprobe.d/amdgpu.conf and add the line options amdgpu virtual_display=xxxx:xx:xx.x,y to it. Where xxxx:xx:xx.x is the PCIe device ID (the thing you get from lspci) and y is the screen ID (starting from 1) attached to the card. For me adding a single display to my card on 0001:01:00.0:

options amdgpu virtual_display=0001:01:00.0,1

(Note: virtual display disables physical output)

Now install your favorite display manager, DE/WM. And reboot if AMDGPU config is changed. A display manager is required to launch DBus and switch user for us. Manually doing it quite hard.

NoMachine

My solution was to use x11vnc and attach it to a working X server. It does get GPU working. But it is quite laggy and audio passthrough have to be done separately. As much as I want to use an open source server, NoMachine is a far superior solution. It’s faster, easier to use and passthrough the audio automatically for you. The steps to NoMachine depends on the distribution. Arch Linux users could simply use the nomachine AUR package. After installing, start both display manager and NoMachine. NoMachine could be launched with sudo /usr/NX/bin/nxserver --start nxd if systemd didn’t start it.

With both NoMachine and the DM launched. Simply to the server using their client. Login. Then you should see the desktop running. OpenGL and audop should also be working too.

My remote KDE desktop

Ctrl + Alt + F will expend the window into fullscreen. And Ctrl - Alt - K enables key garbing. Which make keys that normally goes to the local window manager instead go into the remote session. So keys like F12 to fullscreen, Ctrl - Alt + Up to switch virtual desktop would work. And Ctrl - Alt - 0 brings up a menu for changing audio quality, resolution, etc…

Well, it isn’t perfect. I think it’s a AMDGPU/Mesa bug. But Gtk3 windows got really heavy artifacts on them. Just stick to Qt or Gtk4 apps.

That’s it. Feel free to leave a comment.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK