Remote X glx problems [not solved]

[jesnow]

Edited for clarity.

I am using remote X with ssh -Y:

Many applications work that do not start OpenGL, like xosview and pcmanfm-qt.
BUT when I go to start dolphin I get:

[szatox]

Geez, man, that chaos.....
Right now I have an impression that you can run KDE apps over SSH, but you can't run them locally on the server after you physically walk up to that machine, which makes it effectively your workstation and there is no point in even mentioning that SSH, because you're not using it when the problem occurs.

What are you trying to do on which machine and it doesn't work?
And which machine do those bits of code come from?
_________________
Make Computing Fun Again

[jesnow]

Unhelpful "insult then ignore".

[jesnow]

So now I understand the *category* of problem I seem to be having. This is very old, very arcane stuff. Mostly only people trying to run 3D X apps on supercomputers that don't have graphics cards have this problem.

https://mail.ncmir.ucsd.edu/pipermail/3dem/2019-February/006512.html

KDE plasma requires GLX hardware acceleration. This doesn't work in a remote X window, obviously. It's a known issue obviously for decades. So GLX rendering is forced to use the software rendering. Which it will do if allowed.

The problem is apparently that Xorg disabled indirect GLX rendering by default many years ago, so it is necessary to edit xorg.conf, or rather one of the many files in /usr/share/X11/xorg.conf.d/ so I added a file /usr/share/X11/xorg.conf.d/99-allow-indirect-glx.conf

containing:

[szatox]

[jesnow]

Thanks for your help!

I have been using X for a while, and have been in this particular pitfall before and gotten out of it. When you do things that were once common (eg Remote X) people often decide for you that another way is better ("just use rdp!") you then sometimes find that your way has been quietly deprecated and isn't possible any more. I really use remote X every day, where an application is runinng on some remote machine but showing its face to the world on the X server on my desk. Basic x apps like xeyes and xosview and pcmanfm-qt still run just fine. Remote X is 100% healthy, except for GLX.

Systems: Headless server Merckx. Hasn't has a screen attached to it in years. It *should* be able to start X, but I have no idea.
Client (but of course where the X server lives) Bartali.

The code is all from merckx. In a terminal running on bartali. Emerge --info also merckx, as that's what I understood should be doing the software rendering.

I enabled indirect glx on Bartali. Since merckx is never running an x server it would be pointless. And it didn't change anything.

glxgears runs just great on bartali. If I use __GL_SYNC_TO_VBLANK=0 I get 29Kfps. glxinfo on bartali shows many attributes like GL_AMD_multidraw_indirect, so I'm guessing that it would accept indirect GLX instructions if merckx were sending them.

There seem to be a few *possible* solutions:
- Don't use kde apps (this will work: pcmanfm-qt works but is not as functional as dolphin)
- Remove or turn off GLX from KDE and its dependencies (this is probably very difficult)
- Have KDE/QT fall back to software rendering seamlessly (wasn't this the default behavior before?)
- *Force* KDE/QT to do its GLX rendering in software (should be possible but I don't know how)
- Get KDE/QT to do its GLX rendering indirectly on bartali's GPU (I tried this, but nothing changed, I'm probably not doing it right)

I'm not trying to run games, so I don't care at all about performance. It just needs to work. It *has* worked in the past. I was able to connect this way from japan with a massive ping aand low bandwidth and still get done what I needed done. I had *chromium* running in a remote X window from Japan at one point (long story why), it was just last year.

I suspect kde of simply deciding that kde-plasma 6 depends on hardware acceleration because of course everybody has that now.

Any of the above you can help with would be greatly appreciated.

Cheers,
Jon.

[Ralphred]

[szatox]