https://bugs.kde.org/show_bug.cgi?id=520483
Dustin <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|REPORTED |CONFIRMED CC| |[email protected] --- Comment #1 from Dustin <[email protected]> --- I reproduced this on my own two-seat machine (NVIDIA on seat0, AMD iGPU on seat1, second keyboard attached to seat1) and found the cause. Plasma Login Manager only ever starts ONE login screen, no matter how many seats you have. The daemon correctly prepares a separate greeter for every seat, but the login screen itself runs as systemd user services in the single "plasmalogin" account (plasma-login-kwin_wayland.service and plasma-login.service), and those can only run once per user. So two seats still produce one login screen. Which seat it's wired to is a race between the two greeter launchers - and the screen can even end up displayed on one seat's monitor while being wired to the other seat. The losing seat shows nothing, and logging in on the screen you CAN see creates your session on whichever seat won the race, not the seat you're sitting at. That explains every symptom in your report: seat1 stays black, the login comes out "for VT 2" (that's just a normal seat0 login — seat0's greeter holds VT 1, so the session gets VT 2), and the exit 255 is normal post-login cleanup, not an error. On my machine the race went the other way: I typed at the seat0 screen and my session came up on seat1, with my seat0 monitors dropping to a text console. You can confirm it in your own log: "Message received from greeter: Connect" appears only once, even though two greeters started. One connection = one login screen. The fix is to start one login screen per seat (templating the systemd units). I'm working on a patch and will link it here. -- You are receiving this mail because: You are watching all bug changes.
