Nxserver -> SDDM -> KDE slow

Forums / NoMachine for Linux / Nxserver -> SDDM -> KDE slow

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #33227
    -shelter
    Participant

    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 Linux

    #33244
    graywolf
    Moderator

    Black 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).

    #33250
    -shelter
    Participant

    I 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, NX seems to create logs all over the place.

    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)
    There are no NX sinks to be found. I even made pulseaudio system-wide but it didn’t change anything. 🙁
    NX is configured for pulseaudio…

    #33260
    -shelter
    Participant

    I 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…

    #33275
    -shelter
    Participant

    If 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

    #33295
    -shelter
    Participant

    “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?

    #33310
    graywolf
    Moderator

    I 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.

    #33316
    Britgirl
    Keymaster

    Regarding 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.

    #33321
    -shelter
    Participant

    @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.

    #33325
    -shelter
    Participant

    Regarding 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’.

    #33540
    Britgirl
    Keymaster

    Do 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.

     

    #33820
    -shelter
    Participant

    @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.

     

    #33822
    -shelter
    Participant

    Btw, 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.

     

    #33828
    Carin
    Participant

    Hi -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. 🙂

    #33830
    -shelter
    Participant

    I don’t think Gentoo uses /usr/bin/startplasmacompositor – there’s no such file anywhere.

Viewing 15 posts - 1 through 15 (of 16 total)

This topic was marked as solved, you can't post.