SSH and OpenGL

D

denverh

Hello,

I recently updated my desktop system from 14.2 to 14.3 and now I'm having trouble running a variety of programs from remote systems, either jails on the desktop system or other hardware. I can run simple X11 programs like xclock or xterm successfully, but not programs that use OpenGL. Running glxinfo on any remote system produces the following results:

Code: 
ssh -X test glxinfo
Error: couldn't find RGB GLX visual or fbconfig
name of display: test:10.0

ssh -Y test glxinfo
(hangs)

glxinfo on the desktop system works, and so do all the OpenGL programs I use: Blender, FreeCAD, OpenSCAD, etc. In all my past experience, if I could run something simple like xclock successfully on a remote system then everything else worked as well.

Graphics hardware (from pciconf):
Code: 
    vgapci0@pci0:0:2:0:    class=0x030000 rev=0x02 hdr=0x00 vendor=0x8086 device=0x3e98 subvendor=0x103c subdevice=0x8597
    vendor     = 'Intel Corporation'
    device     = 'CoffeeLake-S GT2 [UHD Graphics 630]'
    class      = display
    subclass   = VGA

The driver that's installed is
Code: 
drm-61-kmod-6.1.128.1403000_2

I looked through the release notes for 14.3 and didn't see anything that seemed relevant, so I don't know what might have changed. Any ideas? I can supply whatever additional information might be needed.

Regards,

Denver
 
You're right, but it is being loaded.
Code: 
kldstat|grep kms
20    1 0xffffffff83cde000   1df228 i915kms.ko

kldstat|grep drm
21    2 0xffffffff83ebe000    85090 drm.ko

And glxinfo reports everything as it should.
 

Attachments

You did not mention your setting on the X11 Server machine.

/etc/ssh/sshd_config
Code: 
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
These have to be modified.

I also run ssh with -XY.
That said I do not think video acceleration is available over ssh display.
 
Phishfry said:
That said I do not think video acceleration is available over ssh display.
Click to expand...
Indeed. Its not entirely functional. People have been breaking it for years.
VirtualGL is sometimes a solution. Ironically much of my career has been built upon providing fast OpenGL across a wire.

OP: For a nice easy solution / compromise, I recommend LLVMpipe and fast software rendering

try:
remotepc$ LIBGL_ALWAYS_SOFTWARE=1 glxinfo

It should no longer hang. And should report MESA LLVMpipe as the GLX driver.

If this works, then you can set the LIBGL_ALWAYS_SOFTWARE environment variable in i.e ~/.profile
.
 
All the remote system are similar:
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no

In any case, I can run things like xclock on all the remote systems using ssh with no problem. In my experience that has always been an adequate test that everything is set up properly.

I have a headless Linux system connected to a laser engraver that runs LightBurn. I routinely run LightBurn from that system on my desktop using ssh. Since updating my desktop system from 14.2 to 14.3 I can no longer run LightBurn that way. I can run it locally on my desktop, but not from the remote system using ssh. I can run xclock that way using ssh though.

I also have a jail on the desktop system with an older version of deskutils/calibre that I could run using ssh until the update to 14.3. Now it just hangs, regardless of what combination of -X, -Y, or -XY I use. I can run xclock though.
 
kpedersen said:
Indeed. Its not entirely functional. People have been breaking it for years.
VirtualGL is sometimes a solution. Ironically much of my career has been built upon providing fast OpenGL across a wire.

OP: For a nice easy solution / compromise, I recommend LLVMpipe and fast software rendering

try:
remotepc$ LIBGL_ALWAYS_SOFTWARE=1 glxinfo

It should no longer hang. And should report MESA LLVMpipe as the GLX driver.

If this works, then you can set the LIBGL_ALWAYS_SOFTWARE environment variable in i.e ~/.profile
.
Click to expand...
OK, that works, thanks. However, it only works with -X. -Y still seems to hang for some reason, but that's a minor issue as long as something works.

Thanks again,

Denver
 
Some further developments. I set up a second system, from scratch, with 14.3 and the same set of applications as on my desk system. That one has no trouble running remote X applications without using LIBGL_ALWAYS_SOFTWARE=1, and never any hangs with trusted forwarding (-Y). I should mention that the remote applications I'm mostly concerned with aren't graphics intensive, like Blender or FreeCAD. Calibre, for example, is a python script that uses Qt. When I was initially trying to figure out what was wrong, one of the first things I noticed was running glxinfo through ssh failed. That was more of a red herring than an actual problem.

It seemed to me that the two most likely sources of differences would be in /boot/loader.conf and /etc/rc.conf. On my desk system both of those have been carried along for years through any number of hardware and software changes, so I went through both and took out things that were no longer needed. The result is that the remote applications I usually use work now without needing LIBGL_ALWAYS_SOFTWARE. However, although ssh -Y works fine for xclock or xterm, it still causes hangs with other applications. I'm not sure why that is, but I'm not going to worry about that one right now.

Things I took out of /boot/loader.conf:
Code: 
currdrv="nda0p2"
vmm_load="YES"
nmdm_load="YES"
if_bridge_load="YES"
if_tap_load="YES"
hw.vmm.amdvi.enable="1"
uchcom_load="YES"
Most of those were for bhyve VMs and don' need to be specified explicitly anymore, apparently.

And I removed the following from the kld_load line in /etc/rc.conf:
Code: 
linuxkpi
linuxkpi_gplv2
I think those were left over from older hardware.

The linuxkpi modules don't exist on my system anymore, so it's hard to see why trying to load them would cause problems, And it's equally hard to see how the other things would cause any trouble either. So although things are now working about the way they used to, I can't really point to anything that's clearly the culprit.

Thanks,

Denver
 
You must log in or register to reply here.
Back
Top