Black window trying to connecto to GNOME desktop

[friki67]

Hello. Doing

xpra start-desktop :20 --start=gnome-session --resize-display=1440x900 in the server

then

xpra attach ssh://[email protected]/20 --opengl=force in the client

in a brand new installation of Rocky Linux as server gives me a black window.

Clients tried are Archlinux and OpenSuse Tumbleweed.

It is strange because in an Almalinux+GNOME server installation start-desktop was working ok, but "monitor" was giving this black window. Something to do with wayland? What to do?

[totaam]

Have you tried --start=xterm first?
(then run gnome-session from there if it shows up)

[friki67]

Hello.
xterm works ok. I can do start --start=xterm or start-desktop --start=xterm and it works.
Now when I do start-desktop --start=gnome-session, I first receive the "Something went wrong, blablabla close your session and try again" (or alike, Spanish here). If I click "Close session", it goes black (that seems reasonable to me, but... Why is it closing?) What to do?

[totaam]

Why is it closing?

Good question, this is not new:
https://xpra.org/list/2020-April/002557.html
In the past this "oh no, something went wrong" dialog could be dismissed.

The gnome desktop requires OpenGL functions which are not available, so it decides to give up.

You haven't specified which exact version of RockyLinux you are using, or which exact packages...
I would have expected the latest versions to support enough OpenGL functions to run the desktop, but perhaps not.
You could run using a real GPU, perhaps using vglrun.

[friki67]

Last Rocky 9, packages from Xpra stable repository.

Now I'm trying it in a Virtualbox VM. I've tried the Xfce image + Xpra stable and it works ok in Virtualbox. By the other hand, I've been unable to install Rocky KDE image in Virtualbox.

But I got similar behaviour in Almalinux+GNOME, the "Close session" thing, sometimes recovering, sometimes not, and I was unable to use the "monitor" command to use two displays (because it shows always black on both windows, without error).

[friki67]

I've tried unactivating Wayland in /etc/gdm/custom.conf, and now using start-desktop works.

But monitor shows one (or two if --resize-display=1920x1080,1920x1080 is used) black window, no messages at all.

Could it give you a clue?

EDIT: the only differences in the log server between using "monitor" and "start-desktop" are:

1. xpra X11 desktop/monitor version 4.4.6-r29 64-bit
2. monitor gives this message after "Gstreamer vesion 1.18.4"

/usr/lib64/python3.9/site-packager/xpra/x11/desktop/monitor_server.py:180 Warning: g_objet_notify: object class 'xpra+x11+desktop+monitor_model+MonitorDestopModel' has no property named 'title'
model.notify("title")

[totaam]

I've tried unactivating Wayland in /etc/gdm/custom.conf, and now using start-desktop works.

I really don't see how this could make any difference.
Xpra doesn't go anywhere near gdm.

black window, no messages at all

Even with xterm?

monitor gives this message after "Gstreamer vesion 1.18.4"

Odd, desktop uses the same code and should have audio support.
In any case, this is extremely unlikely to be related.

[friki67]

I really don't see how this could make any difference.
Xpra doesn't go anywhere near gdm.

This tells gdm to launch GNOME using Xorg, not Wayland. Just to try.

I've tried to use "monitor" with Xfce in a physical machine, and it works. GNOME made the same thing: monitor gives me always a black window. Ah, xterm works too.

Now I'm trying to setup VirtualGL. Well I set it up, launched "vglrun glxgears" in local and got around 1800 FPS. But when I tried the xpra start --start="vglrun glxgears" in the server and then xpra attach ssh://myuser@myserver/1 I got a really slow turning wheels...
Do you know why? Without the vglrun I'm getting almost same FPS in the xpra log.

And CUDA was working before installing vglrun (I think, I'm installing and deinstalling things) and now says CuInit failed: Invalid argument, but Nvidia driver is installed and working ok.

[totaam]

I got a really slow turning wheels...

It's rendering so fast that it may be syncing to a multiple of your display's vertical refresh rate, giving the impression of being slow.

[friki67]

Its reporting 1 FPS :(

[totaam]

Then something is not setup properly.

[friki67]

Then something is not setup properly.

For sure. First time fighting with Almalinux/Rockylinux or alike and of course, with VirtualGL

EDIT: the strange thing is that same vglrun glxgears in local terminal is giving those 1800FPS

[friki67]

Hello again. I managed to have NVENC and VirtualGL working in my installation (Almalinux 9.2, default kernel, NVIDIA proprietary drivers (installed from rpmFusion repositories). Using Xpra stable version from your repositories.

1. XFCE works in monitor or start-desktop mode, dual or not. Using"vgrun xfce4-session" makes no difference with "xfce4-session".
2. KDE works in monitor or start-desktop mode, dual or not. Using "vglrun startplasma-x11" (that introduces some artifacts) or "startplasma-x11"
3. GNOME refuses to show anything in monitor mode, either using vglrun or not. In start-desktop mode, vglrun introduces too artifacts to use it.

I'm starting xpra using these options for desktop:

xpra start-desktop :20 --start="startplasma-x11" --video-encoders=nvenc --resize-display=1920x1080 in server

xpra attach ssh://[email protected]/20 --opengl=force in client

and for apps

xpra start :23 --start="chromium-browser" --video-encoders=nvenc in server
and same attach in client.

The performance of the seamless app is far better than the desktop option.

Can I do something to get better performance?

EDIT: NVENC an NVFBC patches applied.

[totaam]

--video-encoders=nvenc

Please don't do that. It is counterproductive, as explained many times in this issue tracker.

--opengl=force

This should not be needed.

EDIT: NVENC an NVFBC patches applied.

What are those?
NVFBC is only used by shadow mode.

Can I do something to get better performance?

Use v5 beta and the new stream encoding: #3872

[friki67]

Thank you! I will do it all.

The nvidia-patch. https://github.com/keylase/nvidia-patch. I'm almost sure you suggested it someplace in the docs. For removing the limitations on the number of streams encoded in consumer grade NVIDIA cards.