As already reported upstream x11-misc/sddm from 0.20.0 onward has broken mutli-seat support. As of 0.21 it is not fixed yet. See https://github.com/sddm/sddm/issues/1791 https://github.com/sddm/sddm/issues/1939 Workaround: mask versions >=0.20. So at least until a fixed upstream version is available 0.18 should be kept in tree. Maybe the affected versions should be masked globally or set to testing but as it probably affects only a few knowledgeable people it may be OK to leave it for them to handle it. This bug could be a kept open as a reference if someone stumbles upon it and is searching for hints.
No, we can't seriously mask >=0.20 globally for that, and 0.18.1-r8 has its own fair share of issues.
If you say sddm develop branch fixes this for you, then 0.21.0_p20240302 should work as well.
I haven't tried 0.21.0_p20240302 (March 2nd?) yet as the working version was from May 25th but if interested I could check and post here.
https://github.com/sddm/sddm/issues/1762#issuecomment-1966632467 is from end of feb
(In reply to Konstantin Münning from comment #3) > I haven't tried 0.21.0_p20240302 (March 2nd?) yet as the working version was > from May 25th but if interested I could check and post here. There haven't been any commits to the branch since then.
(In reply to Konstantin Münning from comment #3) > I haven't tried 0.21.0_p20240302 (March 2nd?) yet as the working version was > from May 25th but if interested I could check and post here. ?
(In reply to Andreas Sturmlechner from comment #6) > (In reply to Konstantin Münning from comment #3) > > I haven't tried 0.21.0_p20240302 (March 2nd?) yet as the working version was > > from May 25th but if interested I could check and post here. > ? I am sorry for the delay but trying 0.21.0_p20240302 involves upgrading qt and kde among others (I didn't want to run in trouble by using --nodeps) and it's still working on its 1000 or so ebuilds. I should have the results next week.
Finally I could try 0.21.0_p20240302 and it seems to fix the multi-seat regression of 0.20 for X11. At least all I could test worked as good as with 0.18. (seat0+seat1) Wayland multi-seat is still broken but this didn't work earlier either. When using sddm with DisplayServer=x11 (default) seats are initialized as expected but starting Plasma (Wayland) just gets back to the login screen. As Plasma (Wayland) is the default session and I found no way to change the ordering in sddm my workaround is to delete /usr/share/wayland-sessions/plasma.desktop on a multi-seat system so users don't get confused or stuck. With sddm set to use DisplayServer=wayland (noted as experimental) the greeters for both seats were placed on top of each other on the second monitor and the first stayed black, although in graphics mode. That corresponds to some reports of "freezing" computers as no reaction to keyboard/mouse could be seen on the first screen and on the second it was below the second greeter. Anyway, login is possible and with CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1 the sessions started as expected on the correct screens (default weston didn't work that well). So when upstream fixes Wayland seat assignment it could work as well.
(In reply to Konstantin Münning from comment #7) > (In reply to Andreas Sturmlechner from comment #6) > > (In reply to Konstantin Münning from comment #3) > > > I haven't tried 0.21.0_p20240302 (March 2nd?) yet as the working version was > > > from May 25th but if interested I could check and post here. > > ? > > I am sorry for the delay but trying 0.21.0_p20240302 involves upgrading qt > and kde among others Thanks for testing and sorry I didn't realise this would be that involved in case you were a stable user.
