Forum Replies Created
-
AuthorPosts
-
CRCinAUParticipant
Sorry – got a bit of head fog with the flu at the moment – but are you saying that this should work with Wayland now?
For the record, my setup consists of doing:
# systemctl set-default multi-user.target
Then in server.cfg I change:
DisablePersistentSession “all”
EnableNetworkBroadcast 0
CreateDisplay 1
DisplayOwner “myusername”In node.cfg I change:
#DefaultDesktopCommand “dbus-launch –exit-with-session /usr/bin/startplasma-wayland”
DefaultDesktopCommand “dbus-launch –exit-with-session /usr/bin/startplasma-x11”
AvailableSessionTypes unix-remote,unix-console,unix-default,unix-application,physical-desktop,shadow,unix-xsession-default,unix-xdm,unix-kde
AudioInterface pipewire
CommandStartPipeWire “/usr/bin/pipewire -c”For X11 or Wayland – last testing, Wayland worked, but didn’t allow me to change resolution dynamically.
I don’t think I do anything else to make things work.
CRCinAUParticipantThanks for this info.
I do note though that the session does seem to go between X11 and Wayland depending on the launcher. See the attached screenshots.
The only thing that doesn’t seem to work properly is sizing the desktop in Wayland.
Attachments:
CRCinAUParticipantSent logs + Screenshots.
CRCinAUParticipantAh – sorry – I’ll compress it to a JPG so that it attaches ok….
Attachments:
CRCinAUParticipantThanks – updated to 8.12.12 – and same thing…
Attached screenshots of the difference between using x11 and wayland.
It seems the x11 version uses
nxoutput0
as the display, wayland seems to showX11-0
as the display.Attachments:
CRCinAUParticipantI did just try calling
startplasma-wayland
– and it seems that everything works ok – except for changing the remote screen resolution to match the NoMachine client session.It seems to be locked to 1024 x 768 – and I can’t use the client settings to change the remote display resolution.
Swapping back to using
startplasma-x11
, and this resolution thing works fine.CRCinAUParticipantThanks Britgirl.
It doesn’t look like the KDE Spin of Fedora has a
startkde
script.I want to tinker around with the wayland side of things again – as Fedora 41 will not install X11 by default – so trying to update my workflows accordingly.
I might as well do this when the new update comes out as well.
CRCinAUParticipantFor the benefit of the forum, this is my current status:
1) Install fresh Fedora 40 VM
2) Install nomachine
3) systemctl set-default multi-user.target
4) Add ‘selinux=0 audit=0’ to grub kernel cmd line
5) RebootThe logs attached are at this point in time.
I note that DefaultDesktopCommand was not set for the KDE desktop.
As such, I then changed the DefaultDesktopCommand in node.cfg to:
DefaultDesktopCommand "dbus-launch --exit-with-session /usr/bin/startplasma-wayland"
Then restarted NXServer via:
root@remote-apps:/usr/NX/etc# ../bin/nxserver --restart
NX> 162 Disabled service: nxd.
NX> 162 Disabled service: nxserver.
NX> 162 Service: nxnode already disabled.
NX> 111 New connections to NoMachine server are enabled.
NX> 161 Enabled service: nxserver.
NX> 162 WARNING: Cannot find X servers running on this machine.
NX> 162 WARNING: A new virtual display will be created on demand.
NX> 161 Enabled service: nxd.I noticed that the following was set in /usr/NX/etc/node.cfg:
DefaultDesktopCommand "/etc/X11/xinit/Xsession default"
Likely, this wasn’t going to work, so I edited it to:
DefaultDesktopCommand "dbus-launch --exit-with-session /usr/bin/startplasma-wayland"
This kind-of-worked – but things were VERY slow. I then installed the plasma-session-x11 package, and changed the line to:
DefaultDesktopCommand "dbus-launch --exit-with-session /usr/bin/startplasma-x11"
After a reboot, I was able to log in – and this seems to work – which is rather strange, as I couldn’t get this working at all last time – even though I did the above steps as well.
I’m pretty sure that wayland has worked before for KDE – but I’ll keep tinkering to see if / what I can break 🙂
CRCinAUParticipantHi Britgirl – good to see you’re still active 🙂
I’m not 100% sure that’s the only case. To keep the details in the same place, I did install nomachine on Fedora 39 – which worked perfectly. After installing all the latest updates to Fedora 39, this also broke and seemed to fail in the same way. Fedora 39 is still on KDE Plasma 5.
I will however do a fresh install of Fedora 40 – with no messing around attempting to make it work – and post the logs as requested.
CRCinAUParticipantWas there ever any kind of followup for this? In my current testing with the KDE Spin of Fedora, I’ve found the following:
1) F39 clean install from the Live ISO -> NoMachine works fine
2) After running updates on F39, NoMachine no longer works with a similar error
3) F40 doesn’t work from a fresh install, or after updates have been installed.
CRCinAUParticipantI came back to this after finding out that pipewire is not supported for Virtual Desktops….
As such, I reverted to pulseaudio. The
nxnode --audiosetup
didn’t work as there was no /etc/pulse/client.conf.I copied that in from somewhere in /usr, and ran
nxnode --audiosetup
again, and after that point, all works.CRCinAUParticipantI did some further digging…. It looks like maybe the module didn’t build with the new version update.
After rebuilding the kernel module on my server system, I can now share USB correctly.
It also seems like it works ok with Linux -> Linux, it just sometimes takes 10+ seconds to enumerate the USB devices connected – which may be something new.
February 10, 2021 at 08:50 in reply to: How to get correct resolution when running NoMachine in a VM #31870CRCinAUParticipantThanks!
I edited the included dkms.conf to make it happy with newer dkms versions:
PACKAGE_VERSION=”1.0.0″
PACKAGE_NAME=”nxusb”
DEST_MODULE_LOCATION[0]=”/kernel/drivers/usb/misc/”
AUTOINSTALL=”yes”
BUILT_MODULE_NAME=”nxusb”I haven’t had a chance to test this properly yet, but I also had to symlink /usr/NX/share/src/uxusb -> /usr/src/nxusb-1.0.0
Then run: dkms install nxusb/1.0.0
In theory, this should work – but I’ll need to run it through a few more kernel updates to make sure…
February 2, 2021 at 17:15 in reply to: How to get correct resolution when running NoMachine in a VM #31669CRCinAUParticipantThanks for the reply – I did manage to figure this out by doing:
# systemctl set-target multi-user.target
# rebootWhen nxserver starts and a new connection begins, this does create a new virtual desktop and the sizing issues are resolved, yay!
The only part I struggle with now is keeping the nxusb module loaded and active between kernel updates. I’ve played with trying to get the dkms part configured, but I’m not sure how well that works as yet – as I’m still testing a number of things.
Is there any best practice documentation on this topic?
-
AuthorPosts