Forum / NoMachine for Linux / Nxserver -> SDDM -> KDE slow
- This topic has 15 replies, 4 voices, and was last updated 3 years, 5 months ago by Carin.
-
AuthorPosts
-
May 4, 2021 at 17:12 #33227shelterParticipant
If I start nxserver on boot, it detects the running Xorg SDDM instance when I connect to it with the NoMachine client.
Everything is fast in SDDM but as soon as I login to the KDE session everything becomes very slow after 2 seconds (I notice it on the spinning circle) and the desktop is unusable, it updates every 5 seconds or so. If I go physically to that computer running the nxserver, the Xorg screen is black.However, if I instead stop nxserver and restart SDDM then physically login on the machine using the SDDM KDE session and start nxserver from KDE, then go back and connect using the NoMachine client everything is fast.
I’m not sure what happens in the first case scenario? Any ideas? Would be nice to be able to initiate a connection through nxserver and SDDM without physically logging in first.
KDE 5.21.4
NoMachine 7.4.1
Gentoo LinuxMay 5, 2021 at 11:08 #33244graywolfParticipantBlack Xorg screen make me think KDE failed to find connected physical screens. Let me suggest to look at KDE log as first thing (try:
journalctl -b -0 | grep -i -E "kde|plasma"
). Then look at NoMachine logs (specially search for files$HOME/.nx/*/session
).May 5, 2021 at 16:50 #33250shelterParticipantI couldn’t find much in the logs but I checked chrome://gpu when running google chrome and it reports intel as video driver, everything seems normal there.
I also noticed that NX creates a directory under/var/lib/sddm/.nx
that contains logs etc… so I’m a bit confused.It’s a laptop I’m trying to connect to.
I guess I can live with physically logging in first and starting nxserver manually but it would be nice if it worked without doing so.Totally different issue but I can’t for the life of me get pulseaudio forwarding to work. I don’t have any NX audio sliders under the volume control. (I had it working once, but then after a reboot, they went missing for good):(
NX is configured for pulseaudio…May 6, 2021 at 08:07 #33260shelterParticipantI think I figured the slowness/black screen issue out, it happens if the laptop lid is closed when connecting to the running xorg/sddm instance. If the lid is open and the screen is active, it works as intended.
Is there any fix/workaround for this other than having the lid open at startup/reboot?Now I only need sound working…
May 6, 2021 at 12:55 #33275shelterParticipantIf I connect headless without sddm running, NX audio forwarding works.
But if I connect through a running Xorg/sddm instance I get no forwarding.
Only error I see is:
pulseaudio[6058]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
May 7, 2021 at 14:23 #33295shelterParticipant“Solution” to the audio problem (I’m running OpenRC, so no systemd:
1. Set “autospawn = no” in /etc/pulse/client.conf.
2. Manually starting pulseaudio with “pulseaudo –start” in the NX Xorg session (because it doesn’t autostart for me with the above setting).
3. Restart the nxserver instance through the NX service GUI.The keyword was to set autospawn to no but still a very dirty workaround.
I spent hours to find these workarounds. 🙁 But hope it helps someone in the future.But the biggest question is still, Is there any fix/workaround for the black screen/slowness other than having the laptop lid open at startup/reboot?
May 7, 2021 at 16:05 #33310graywolfParticipantI don’t know if it is possible to setup Xorg to be fully functional with lid closed. Let me suggest to compare the Xorg log in the two cases: started with lid closed and with lid open.
May 7, 2021 at 17:27 #33316BritgirlKeymasterRegarding the audio problem. We don’t officially support Gentoo, but since we try and test with as many flavours as possible, we also tested with Gentoo. We happen to have a Gentoo server with SDDM-KDE configured and NoMachine installs and works out of the box. Additionally, audio works without extra manual configuration.
May 10, 2021 at 10:48 #33321shelterParticipant@graywolf Yeah, I’ll try and have a look.
@Britgirl Could be an OpenRC/elogind/dbus issue I don’t know, I have Arch Linux too that runs systemd and there everything works fine. I did have problems with “Monitor cannot be started for session type loginwindow” but that went away, don’t know if it was because I switched to EGL in the nxserver config because at first it didn’t help.
Do you run systemd in Gentoo?Thanks for a good product nonetheless, I was using NoMachine some years ago and despite my issues now I feel that it evolved very much.
May 10, 2021 at 10:50 #33325shelterParticipantRegarding the audio issue I figured out a much better solution.
1. Set “autospawn = no” in /etc/pulse/client.conf.
2. Put /usr/bin/pulseaudio in KDE’s autostart.This is because Gentoo doesn’t start PulseAudio at all if autospawn is set to no (at least not for me).
Now I have the NX audio controls under the volume control.The video issue still puzzles me tho’.
May 20, 2021 at 09:20 #33540BritgirlKeymasterDo you run systemd in Gentoo?
The tests we did on the fly were done without systemd in this particular case.
Now I have the NX audio controls under the volume control.
Thanks for letting us know.
June 1, 2021 at 13:56 #33820shelterParticipant@britgirl Any idea what this command does with the display manager script? Because I get an error:
# /etc/NX/nxserver --egl-capture yes NX> 900 EnableEGLCapture key set to: 1. NX> 900 Cannot find any display manager script.
June 1, 2021 at 14:09 #33822shelterParticipantBtw, I also figured out a workaround for KDE and the slowness that occurs.
If you have the lid closed on the laptop, then it fails to find any screens which makes the session very slow and the laptop screen is black even if you open the lid.
To fix it, make a script containing this and put it in KDE Autostart as a login script:
#!/bin/sh
(sleep 5s && xrandr –output eDP1 –auto) &The above script activates the display after 5 seconds and the problem is solved!
PS.
If you need to find out your display (in this case it’s, eDP1), just run xrandr in an X console.June 1, 2021 at 17:03 #33828CarinParticipantHi -shelter,
Any idea what this command does with the display manager script?
KDE session scripts are likely in an unusual location. Can you tell us if in Gentoo these files are in place?
/usr/bin/startplasmacompositor /usr/bin/kwin_wayland
I also figured out a workaround for KDE and the slowness that occurs.
Thank you for sharing the workaround that you’ve found. 🙂
June 1, 2021 at 18:34 #33830shelterParticipantI don’t think Gentoo uses /usr/bin/startplasmacompositor – there’s no such file anywhere.
-
AuthorPosts
This topic was marked as solved, you can't post.