Bro, that is literally the first comment on the post! None of the solutions were posted when it was made.

They’re wrong, but you are just being a dick.

The irony is insane. “Act authoritative” even tho I literally didn’t claim to know anything for certain (I do not -think-, perhaps, I believe). Also as other gentleman pointed out, no other comment was there when I tried to help. I asked about vnc -after- I made my initial comment, because a few minutes after other people started pitching in with more accurate and relevant information. I feared the post would go on to have no responses so I tried to pitch in; you don’t have to know everything about everything in order to try and help someone out, all I did was provide my take on the matter, which is better than ignoring the question, regardless of how fruitful or fruitless what I had to say was. People like you are why noobs are afraid if dipping their toes in more technical areas such as linux, and get scared off by smartass supremacists that like to spoil things for no good reason. Sincere, seek help. 🤦🏻‍♂️

Virtual Network Computing. It’s basically an alternative to remote desktop.

running a “second seat” on a different F key like in the link might be a good way to do that.

back in the day i would just log out and log in. there’s so much going on with desktop environments i kinda had to spend some time in one doing my daily to figure out if it was what i wanted.

You can also bookmark comments on Lemmy, and copy the comment URL and store that in (synced) browser bookmarks!

Oh, copy the comment text and save it in a text- or markdown-file on your devices, in case it gets taken down! You can even for the text in case you forgot where you kept it!

Screenshot of said mess? Purley for entertainment 😄

Make sure to use machinectl and not sudo or anything else. That’s about the symptoms I’d expect from an incomplete session setup. The use of machinectl there was very deliberate, as it goes through all the PAM, logind, systemd and D-Bus stuff as any normal login. It gets you a clean and properly registered session, and also gets rid of anything tied to your regular user:

max-p@desktop ~> loginctl list-sessions
SESSION  UID USER  SEAT  LEADER CLASS   TTY   IDLE SINCE
      2 1000 max-p seat0 3088   user    tty2  no   -    
      3 1000 max-p -     3112   manager -     no   -    
      8 1001 tv    -     589069 user    pts/4 no   -    
      9 1001 tv    -     589073 manager -     no   -    

It basically gets you to a state of having properly logged into the system, as if you logged in from SDDM or in a virtual console. From there, if you actually had just logged in a tty as that user, you could run startplasma-wayland and end up in just as if you had logged in with SDDM, that’s what SDDM eventually launches after logging you in, as per the session file:

max-p@desktop ~> cat /usr/share/wayland-sessions/plasma.desktop 
[Desktop Entry]
Exec=/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland
TryExec=/usr/bin/startplasma-wayland
DesktopNames=KDE
Name=Plasma (Wayland)
# ... and translations in every languages

From there we need one last trick, it’s to get KWin to start nested. That’s what the additional WAYLAND_DISPLAY=/run/user/1000/wayland-0 before is supposed to do. Make sure that this one is ran within the machinectl shell, as that shell and only that shell is the session leader.

The possible gotcha I see with this, is if startplasma-wayland doesn’t replace that WAYLAND_DISPLAY environment variable with KWin’s, so all the applications from that session ends up using the main user. You can confirm this particular edge case by logging in with the secondary user on a tty, and running the same command including the WAYLAND_DISPLAY part of it. If it starts and all the windows pop up on your primary user’s session, that’s the problem. If it doesn’t, then you have incorrect session setup and stuff from your primary user bled in.

Like, that part is really important, by using machinectl the process tree for the secondary user starts from PID 1:

max-p@desktop ~> pstree
systemd─┬─auditd───{auditd}
        ├─bash─┬─(sd-pam)                 # <--- This is the process machinectl spawned
        │      └─fish───zsh───fish───zsh  # <-- Here I launched a bunch of shells to verify it's my machinectl shell
        ├─systemd─┬─(sd-pam) # <-- And that's my regular user
        │         ├─Discord─┬─Discord───Discord───46*[{Discord}]
        │         ├─DiscoverNotifie───9*[{DiscoverNotifie}]
        │         ├─cool-retro-term─┬─fish───btop───{btop}
        │         ├─dbus-broker-lau───dbus-broker
        │         ├─dconf-service───3*[{dconf-service}]
        │         ├─easyeffects───11*[{easyeffects}]
        │         ├─firefox─┬─3*[Isolated Web Co───30*[{Isolated Web Co}]]

Super weird stuff happens otherwise that I can’t explain other than some systemd PAM voodoo happens. There’s a lot of things that happens when you log in, for example giving your user access to keyboard, mouse and GPU, and the type of session depends on the point of entry. Obviously if you log in over SSH you don’t get the keyboard assigned to you. When you switch TTY, systemd-logind also moves access to peripherals such that user A can’t keylog user B while A’s session is in the background. Make sure the machinectl session is also the only session opened fo