shelter

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • shelter
    Participant

    I did manage to get the virtual desktop working but I felt the performance wasn’t the same as using the Xorg server session, so I went ahead trying to fix that session instead.

    Regarding the missing KDE taskbar in the session, specifically the Xorg session, the command plasmashell --replace fixes it.
    The xrandr --output eDP-1 --auto command in the script fixes the slowness if the lid is closed on the laptop.
    The xrandr modelines adds a custom 1080p resolution, my laptop screen supports 1080p but the mode isn’t detected automatically, so those lines doesn’t apply for everyone.

    shelter
    Participant

    I can’t edit the above post but I finetuned the scripting a bit, and adding plasmashell –replace at the end solves all problems.

    !/bin/sh
    (sleep 5s && xrandr --newmode "1920x1080_60.00" \
    173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync && xrandr
    --addmode eDP-1 "1920x1080_60.00" \
    && xrandr --output eDP-1 --auto && plasmashell --replace) &
    shelter
    Participant

    There are some tricks to get it working even if the lid is closed. You can also add a custom resolution if you’re limited by the laptop screen resolution.

    I’m now logged in to the X server session when the lid was closed, running in 1080p (the laptop screen supported only 720p), KDE taskbar works and there’s no slowness/lag.

    To get the display running when the lid is closed you need to do the following:
    1. First find your display id (in this case it’s, eDP-1), just run xrandr in an X terminal window.

    2. Make a script containing the following and put it in KDE Autostart as a login script, make sure the script is executable (chmod a+x <script>):

    #!/bin/sh
    (sleep 5s && xrandr –output eDP-1 –auto) &

    3. Add custom 1080p resolution to the session, run this in an X terminal window:

    xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
    xrandr --addmode eDP-1 "1920x1080_60.00"

    4. Change to the 1080p resolution in gnome/kde/xfce or whatever DE you’re running.

    No dummy display dongle neeeded!

    shelter
    Participant

    Yea, adding a dummy display made things work, no black screen… I’ll play around some more later, I need to tweak the configs a bit.

    in reply to: Connecting Arch desktop to Arch laptop got 
Error 104 #39941
    shelter
    Participant

    A bit laggy or very laggy?

    Perhaps it can’t find your screen. Is the lid closed on the laptop? Try connecting to the laptop with the screen active.

    shelter
    Participant

    No, that just gave me a black desktop. I think the issue I was facing was due to that it tried to connect to a running Xorg server and it couldn’t find the display/screen which’s a somewhat known problem on laptops if the lid is closed.

    However I also would like to have to be able to chose between a virtual desktop or running Xorg server. If I have Xorg running it connects me straight to that “session/server”. I can’t figure out what configuration I need to change for that.

    in reply to: Connecting Arch desktop to Arch laptop got 
Error 104 #39909
    shelter
    Participant

    Silly question maybe but is the NoMachine service started?

    in reply to: Nxserver -> SDDM -> KDE slow #33830
    shelter
    Participant

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

    in reply to: Nxserver -> SDDM -> KDE slow #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.

     

    in reply to: Nxserver -> SDDM -> KDE slow #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.

     

    in reply to: Nxserver -> SDDM -> KDE slow #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’.

    in reply to: Nxserver -> SDDM -> KDE slow #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.

    in reply to: Nxserver -> SDDM -> KDE slow #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?

    in reply to: Very slow with Xubuntu 20.04 #33279
    shelter
    Participant

    The missing libs are because NoMachine runs in it own “chroot” or something. Nothing to worry about.

    The libs are under /usr/NX/lib/

    in reply to: Nxserver -> SDDM -> KDE slow #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

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