Bug 1929643 - logout after switch returns the user to console instead of sddm
Summary: logout after switch returns the user to console instead of sddm
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sddm
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Bříza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F34FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2021-02-17 11:16 UTC by Kamil Páral
Modified: 2021-10-14 00:36 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-04-22 20:22:40 UTC
Type: Bug


Attachments (Terms of Use)
Scenario 1 video (2.92 MB, video/webm)
2021-02-17 11:18 UTC, Kamil Páral
no flags Details
Scenario 1 journal (312.92 KB, text/plain)
2021-02-17 11:19 UTC, Kamil Páral
no flags Details
Scenario 1 journal - priority notice and higher (53.91 KB, text/plain)
2021-02-17 11:23 UTC, Kamil Páral
no flags Details
Scenario 2 video (4.66 MB, video/webm)
2021-02-17 11:24 UTC, Kamil Páral
no flags Details
Scenario 2 journal (376.34 KB, text/plain)
2021-02-17 11:25 UTC, Kamil Páral
no flags Details
Scenario 2 journal - priority notice and higher (87.39 KB, text/plain)
2021-02-17 11:25 UTC, Kamil Páral
no flags Details
Scenario 3 video (4.60 MB, video/webm)
2021-02-17 11:26 UTC, Kamil Páral
no flags Details
Scenario 3 journal (406.27 KB, text/plain)
2021-02-17 11:26 UTC, Kamil Páral
no flags Details
Scenario 3 journal - priority notice and higher (100.39 KB, text/plain)
2021-02-17 11:27 UTC, Kamil Páral
no flags Details
rpm -qa (58.66 KB, text/plain)
2021-02-17 11:28 UTC, Kamil Páral
no flags Details
rpm -qa from today (74.33 KB, text/plain)
2021-03-29 18:33 UTC, Geraldo Simião
no flags Details
coredumpctl from plasma wayland attempt (2.00 KB, text/plain)
2021-03-29 19:29 UTC, Geraldo Simião
no flags Details
drkonki kcrash report (1.40 KB, text/plain)
2021-03-29 19:33 UTC, Geraldo Simião
no flags Details
Scenario 1 journal (sddm-0.19.0-10.fc34) (308.42 KB, text/plain)
2021-04-14 10:51 UTC, Kamil Páral
no flags Details
Scenario 1 journal - priority notice and higher (sddm-0.19.0-10.fc34) (43.67 KB, text/plain)
2021-04-14 10:51 UTC, Kamil Páral
no flags Details
Crash coredump when doing Scenario 1 (sddm-0.19.0-11.fc34) (1.42 MB, application/octet-stream)
2021-04-17 02:02 UTC, Neal Gompa
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github sddm sddm issues 1281 0 None open ReuseSession=true is broken for multiple sessions 2021-04-17 02:24:23 UTC
KDE Software Compilation 435389 0 NOR UNCONFIRMED switch user fails 2021-04-05 17:28:09 UTC

Description Kamil Páral 2021-02-17 11:16:53 UTC
Description of problem:
On F34 KDE, I found a problem with logging out, after the "user switch" option has been used (even when no user has been actually switched). The outcome is that the user is switched to console - either to tty2 with a working text login prompt, or to tty1 where only a blinking cursor appears (no login prompt). In all cases, if the user is no power user, they'll have no idea what to do or how to even reboot the system safely.

I found several different scenarios how to cause the problem, but I decided to report all of them into this single bug, because I believe the root cause is probably the same for all of them, it's just triggered differently.

The first scenario can easily occur when you misclick a button (choose Switch User instead of Log Out). The second and third scenario can easily occur when user1 lets user2 to use the computer for a short while (like checking her email).

Please see below the attached videos, reproduction steps, and logs.

In all those scenarios, I see a suspicious error in the journal:

> sddm[858]: Failed to read display number from pipe
> sddm[858]: Could not start Display server on vt 2


Version-Release number of selected component (if applicable):
Fedora-KDE-Live-x86_64-34-20210215.n.0.iso
sddm-0.19.0-7.fc34.x86_64
plasma-workspace-5.21.0-1.fc34.x86_64
kf5-plasma-5.79.0-2.fc34.x86_64
dbus-1.12.20-3.fc34.x86_64
dbus-broker-26-2.fc34.x86_64
systemd-247.3-1.fc34.x86_64
kernel-5.11.0-0.rc7.149.fc34.x86_64

How reproducible:
always

Steps to Reproduce:
will be provided for each use case individually, see comments below

Comment 1 Kamil Páral 2021-02-17 11:18:48 UTC
Created attachment 1757527 [details]
Scenario 1 video

Scenario 1) A single user switch and logout

1. Log in using user1
2. KDE menu -> Leave -> Switch User
3. Log in back to the user1 session (don't switch the user)
4. KDE menu -> Leave -> Log Out -> OK
5. You'll end up on tty2 with a text login prompt. On tty3-tty6 there are also text login prompts. On tty1 there is only a blinking cursor. Sddm is nowhere to be found.

See the attached video in this comment, and logs below.

Comment 2 Kamil Páral 2021-02-17 11:19:39 UTC
Created attachment 1757528 [details]
Scenario 1 journal

Comment 3 Kamil Páral 2021-02-17 11:23:28 UTC
Created attachment 1757529 [details]
Scenario 1 journal - priority notice and higher

Comment 4 Kamil Páral 2021-02-17 11:24:19 UTC
Created attachment 1757530 [details]
Scenario 2 video

Scenario 2) Two users switch, the first logout fails

1. Log in using user1
2. KDE menu -> Leave -> Switch User
3. Switch User
4. Log in using user2
5. KDE menu -> Leave -> Log Out -> OK
# there seems to be a race which will determine whether Scenario 2) or 3) will happen
6. You'll end up on some tty (perhaps tty4) with just a text blinking cursor. If you're a power user and know how to use Ctrl+Alt+Fn, you might be able to find a running sddm on a different tty. 

See the attached video in this comment, and logs below.

Comment 5 Kamil Páral 2021-02-17 11:25:17 UTC
Created attachment 1757531 [details]
Scenario 2 journal

Comment 6 Kamil Páral 2021-02-17 11:25:36 UTC
Created attachment 1757532 [details]
Scenario 2 journal - priority notice and higher

Comment 7 Kamil Páral 2021-02-17 11:26:24 UTC
Created attachment 1757533 [details]
Scenario 3 video

Scenario 3) Two users switch, the second logout fails

1. Log in using user1
2. KDE menu -> Leave -> Switch User
3. Switch User
4. Log in using user2
5. KDE menu -> Leave -> Log Out -> OK
# there seems to be a race which will determine whether Scenario 2) or 3) will happen
6. Return into the existing session of user1
7. KDE menu -> Leave -> Log Out -> OK
8. You'll end up on tty2 with a text login prompt. On tty3-tty6 there are also text login prompts. On tty1 there is only a blinking cursor. Sddm is nowhere to be found. (Alternatively, I've also seen ending up on just a black screen, with no login prompt, and VT switching not working).

See the attached video in this comment, and logs below.

Comment 8 Kamil Páral 2021-02-17 11:26:52 UTC
Created attachment 1757534 [details]
Scenario 3 journal

Comment 9 Kamil Páral 2021-02-17 11:27:13 UTC
Created attachment 1757535 [details]
Scenario 3 journal - priority notice and higher

Comment 10 Kamil Páral 2021-02-17 11:28:16 UTC
Created attachment 1757536 [details]
rpm -qa

Comment 11 Kamil Páral 2021-02-19 14:57:52 UTC
I nominate this to be a F34 Final blocker. It is somewhere in between these two criteria:
"Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. "
https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria#Shutdown.2C_reboot.2C_login.2C_logout
"User switching must work using the mechanisms offered (if any) by all release-blocking desktops in their default configuration. "
https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#User_switching

Login/logout works, as long as you don't attempt to switch. Switching works, as long as you don't attempt to log out... :-)

Comment 12 Geoffrey Marr 2021-02-22 20:16:48 UTC
Discussed during the 2021-02-22 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criteria:

"Shutting down, rebooting, logging in and logging out must work..." and "User switching must work using the mechanisms offered...". It seems reasonable to expect both to work together.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-02-22/f34-blocker-review.2021-02-22-17.07.txt

Comment 13 Adam Williamson 2021-03-27 00:59:58 UTC
Martin, Rex - where are we with this? This is an accepted F34 Final blocker, and Final freeze is coming up April 6. I'd like us to be out in front of accepted blockers at this point. Thanks!

Comment 14 Geraldo Simião 2021-03-29 18:29:01 UTC
I just tried to reproduce this bug here on my F34kde and it all worked fine, no bug. Will attach my output of rpm -qa to this ticket. Tried only in X11 sessions so far, will test on wayland later.

Tested the scenarios with two users, firts is mine default user (adm) and second I created as regular user.

Fedora 34 (KDE Plasma Prerelease) x86_64 / Kernel: 5.11.10-300.fc34.x86_64 / Plasma 5.21.3 / Qt: 5.15.2 / Frameworks: 5.80.0

sddm-0.19.0-8.fc34.x86_64 / sddm-breeze-5.21.3-1.fc34.noarch / sddm-kcm-5.21.3-1.fc34.x86_64

I'm ready to send more info if needed.

:)

Comment 15 Geraldo Simião 2021-03-29 18:33:02 UTC
Created attachment 1767441 [details]
rpm -qa from today

Comment 16 Geraldo Simião 2021-03-29 19:24:49 UTC
Tried on plasma wayland sessions... first and second time I log in and log out worked fine, but when I tried to switch users it didn't. SDDM freezed so badly that my only way out was a restart.
then I tried several more times (6 to be honest) and it worked on 4 and had problems on 2 of them, but without the terrible freeze I experienced before.
So, it apears this bug show itself when we use plasma wayland sessions.

Comment 17 Geraldo Simião 2021-03-29 19:29:46 UTC
Created attachment 1767460 [details]
coredumpctl from plasma wayland attempt

Comment 18 Geraldo Simião 2021-03-29 19:33:12 UTC
Created attachment 1767462 [details]
drkonki kcrash report

Comment 19 Geraldo Simião 2021-03-29 19:46:37 UTC
Forgot to say: I tested with two monitors (laptop and second monitor)

Comment 20 Rex Dieter 2021-04-05 17:28:12 UTC
bug filed upstream,
https://bugs.kde.org/show_bug.cgi?id=435389

Comment 21 Rex Dieter 2021-04-08 14:57:40 UTC
Plasma upstream confirmed issue.

The switch to systemd user sessions (and wayland) improvied some things (lingering processes on logout in particular), but seems we still have some steps to go.

As upstream has documented this now as a known unresolved issue,
https://community.kde.org/Plasma/Wayland_Showstoppers#Session_management
I think there's not much we can do but live with it for now.

Comment 22 Ben Cotton 2021-04-09 18:05:00 UTC
In chat, Nate Graham said they hope to have a fix by early next week. As a backup plan, we could consider disabling user switching in our sddm package until this is fixed.

Comment 23 Adam Williamson 2021-04-13 17:19:22 UTC
https://koji.fedoraproject.org/koji/taskinfo?taskID=65861107 is a scratch build with the commit mentioned by Nate backported. If folks could please test that and see if it helps, that would be great. I'll try to follow kparal's reproducer steps myself today if I get a minute.

Comment 24 Ben Cotton 2021-04-13 18:07:18 UTC
With scenario 1 and Adam's scratch build, I don't get the bad behavior in step 5. However logging back into the same user's session (step 3) gives me a black screen indefinitely. Once I switch to a different virtual terminal and back, I get a normal login session.

With scenario 2/3 and Adam's scratch build, I can reliably switch between the two accounts. However, when logging out of one of those sessions, I get a black screen until I switch to tty-not1 and back to tty1.

I'd say this patch improves things, but doesn't fully fix it. Scenario 1 seems less likely to be encountered in the wild than scenario 2/3 (though it's certainly something a general user might do). For the purposes of release blocking, I'd be willing to accept the scratch build as a sufficient fix for blocker status and commonbugs the remaining issues, with the hopes that we can fix it relatively soon after release.

Comment 25 Geraldo Simião 2021-04-13 18:19:28 UTC
Agree with Ben's remarks. Tested Adam's scratch build here too.
Worked fine at X11, no errors.
At wayland it worked changing users for 5 times, then when I logged out second user and tried to go to first user it gave me black screen, but with ctrl+alt+F1 the screen appeared again and worked fine.
Scenario 2/3 returned just like Ben described.

Comment 26 Fedora Update System 2021-04-14 00:02:51 UTC
FEDORA-2021-87d6b51834 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-87d6b51834

Comment 27 Adam Williamson 2021-04-14 00:03:43 UTC
Thanks for the feedback, Ben and Geraldo. If it's not too much trouble it'd be great if you could re-test with the final update, as it's a bit different to the scratch build. It adds one more commit that we hope may improve things more (but it'd be good to know it at least doesn't make anything worse!) Thanks!

Comment 28 Kamil Páral 2021-04-14 08:43:25 UTC
I tested with packages only from stable repos (updates-testing not used), and sddm updated to sddm-0.19.0-10.fc34.

Scenario 1 from comment 1 is broken, but different. After step 3 I see only a black screen with a cursor. It seems 100% repeatable. I can use Ctrl+Alt+F1 to switch to the actual session.

Scenario 2 from comment 4 is broken, basically unchanged. The only difference is that in step 6 I sometimes see a blinking cursor and sometimes just a black screen. It seems 100% repeatable. Ctrl+Alt+F1 can be used to switch to the first session.

Scenario 3 from comment 7 I couldn't replicate (every time I tried, I got Scenario 2 instead).

I also tested the scratch build from comment 23 and my results are exactly the same as above.

So I'm not sure why it works better for other people, but there's little change (or even a regression) for me.

Comment 29 Kamil Páral 2021-04-14 10:51:12 UTC
Created attachment 1771857 [details]
Scenario 1 journal (sddm-0.19.0-10.fc34)

I tested with a clean KDE VM installed from netinst with only stable repos enabled (and then sddm updated), still the same issue as in my comment above. Journal attached.

Comment 30 Kamil Páral 2021-04-14 10:51:44 UTC
Created attachment 1771858 [details]
Scenario 1 journal - priority notice and higher (sddm-0.19.0-10.fc34)

Comment 31 Ben Cotton 2021-04-14 12:36:41 UTC
With sddm-0.19.0-10.fc34 (on Wayland), I get the same behavior as the scratch build. Improvement, but not a full fix. Like Kamil, it's always scenario 2 in the 2/3 test.

Comment 32 Fedora Update System 2021-04-14 17:14:12 UTC
FEDORA-2021-87d6b51834 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-87d6b51834`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-87d6b51834

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 33 Geraldo Simião 2021-04-14 17:49:31 UTC
Tested now with the new update (sddm-0.19.0-10.fc34). X11 sessions always works fine. Wayland sessions don't. Between scenarios 2/3 always gave me scenario 2. It doesn't goes to blank screen, but a freezed login screen, where I cannot click on nothing, but using ctrl+alt+F1 or F4 returns to the graphical session alright.
So, I confirm here what Kamil and Ben found on their tests too.

Comment 34 Neal Gompa 2021-04-17 01:00:25 UTC
I've made a scratch build[1] that adds one small extra commit[2] that may have an impact on this. Could folks test this and see if it helps any?

[1]: https://koji.fedoraproject.org/koji/taskinfo?taskID=66095690
[2]: https://github.com/sddm/sddm/commit/8b371572ab6cf5f4652b7f95c700b13a89c9f109

Comment 35 Ben Cotton 2021-04-17 01:39:08 UTC
With Wayland...

The extra commit seems to make it slightly differently broken. Scenario 1 is unchanged. Scenario 2/3 results in:

* if I log out user2, user1 gets the same "blank screen until I go back to tty1" behavior
* if I log out user1, user2 gets an "x"-shaped cursor on a black screen and has to try Ctrl+Alt+F<N> until they find the correct tty

I will note that switching between users (without logging out) seems to work fine.


With X11...

Scenario 1 works, except I have to enter the password twice. Scenario 2/3 results in what appears to be all ttys being blank, with the exception of a static cursor. But that may just be the system going catatonic, as it does not reply to ctrl+alt+del or libvirt's reboot and power off buttons. I have to force it off to recover. After downgrading to sddm-0.19.0.10 (FEDORA-2021-87d6b51834) I get the same behavior. (I had not previously tested X11)

Comment 36 Neal Gompa 2021-04-17 01:45:25 UTC
I have the same results as Ben in my test environments with -10 and -11 on both X11 and Wayland. I had hoped that -11 would improve things, but nope. :(

Comment 37 Neal Gompa 2021-04-17 02:02:50 UTC
Created attachment 1772703 [details]
Crash coredump when doing Scenario 1 (sddm-0.19.0-11.fc34)

At some point while having gdb attached to sddm while executing Scenario 1, I captured this coredump. It may or may not be useful, but might as well upload for posterity.

Comment 38 Neal Gompa 2021-04-17 02:24:27 UTC
I also found a related issue from SDDM upstream on this that seems to describe some aspects of what we're seeing here: https://github.com/sddm/sddm/issues/1281

Comment 39 Rex Dieter 2021-04-20 12:40:24 UTC
I looked into the possibility of disabling user switching, but I'm guessing this solution may not be agreeable either.

Following 
https://develop.kde.org/deploy/kiosk/introduction/

I tested disabling combinations of
action/switch_user
action/start_new_session

The result was that the menu options to do these were still present, clicking them effectively does nothing.  If that's really the way we want to go, I can implement that to satisfy this blocker.

Comment 40 Ben Cotton 2021-04-20 12:54:32 UTC
I think I'd prefer a button that does nothing to a button that drops people to a blank screen. I suspect a lot of more casual users would not know how to ctrl+alt+Fn their way back to a working session. We can commonbugs the Button That Does Nothing[tm] (and maybe put it in the release notes. I'd have to think about how to phrase that in the least "sorry we broke this for you, but it's better than the breakage you'd have otherwise" way).

It doesn't seem like we're close to a real fix, so at this point I'd say nothing is better than something. I'm open to other arguments.

Comment 41 Neal Gompa 2021-04-20 13:05:25 UTC
Given that we as a SIG haven't *actually* explicitly worked to support this functionality and my own failure to integrate upstream changes that *might* help here, I think we should go with the "buttons do nothing, CommonBugs to say why" approach. We can always go back and fix this with an update along with Plasma 5.22 in the summer.

Comment 42 Neal Gompa 2021-04-20 13:07:26 UTC
To be clear, my recommendation is to modify https://bodhi.fedoraproject.org/updates/FEDORA-2021-87d6b51834 to *also* include the disabler as described in comment 39.

Comment 43 Neal Gompa 2021-04-20 13:08:58 UTC
And once this is fixed upstream and pulled into an update, we should probably modify our OpenQA tests to add fast-user-switching cases so it doesn't break again in the future.

Comment 44 Adam Williamson 2021-04-20 15:01:48 UTC
I think I would say that a button which does nothing would still be a blocker, as you'd be offering it and it clearly wouldn't work. *But*, we could reasonably waive it on the grounds that we can't say we have an opportunity to fix it properly in any kind of reasonable timeframe right now.

Comment 45 Adam Williamson 2021-04-20 15:02:18 UTC
Is it really complicated to just patch out a menu button, though?

Comment 46 Adam Williamson 2021-04-20 15:17:01 UTC
user switching is intentionally disabled for KDE in the openQA tests right now because it was known unreliable when we wrote them, btw:
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/master/f/tests/desktop_login.pm#_274

Comment 47 Neal Gompa 2021-04-20 15:17:55 UTC
(In reply to Adam Williamson from comment #45)
> Is it really complicated to just patch out a menu button, though?

I'd defer to Rex on this, but we'd need to patch out both kscreenlocker and sddm to get rid of the buttons. The UIs are duplicated in both programs.

Comment 48 Adam Williamson 2021-04-20 17:03:01 UTC
I've been looking at it all morning. KDE appears to be locked in a heated battle with DNF for the title of Most Confusing Heap Of Abstraction Layers, but I'm trying a few ways to attack it.

Comment 49 Adam Williamson 2021-04-20 17:09:20 UTC
Rex, are you sure you tested right? For me, with this in /etc/xdg/system.kdeglobals:

[KDE Action Restrictions]
action/switch_user=false
action/start_new_session=false

the entries disappear entirely from both the "Leave..." submenu and the lock screen, and that's what I *think* I'd expect from the code too.

Comment 50 Rex Dieter 2021-04-20 18:35:27 UTC
Adam, I'll test again... possible I didn't restart my session after adjusting kdeglobals.  You may be right, if so, we have a winner.

Comment 51 Fedora Update System 2021-04-20 19:11:54 UTC
FEDORA-2021-a526beb5e7 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a526beb5e7

Comment 52 Ben Cotton 2021-04-20 19:34:53 UTC
Confirmed FEDORA-2021-a526beb5e7 removes the switch user button from the Leave menu and the lock screen.

Comment 53 Kamil Páral 2021-04-22 08:00:09 UTC
Also can confirm the button is gone

Comment 54 Sampson Fung 2021-04-22 13:00:41 UTC
Tested with Fedora 34 RC1.

Confirmed the switch user button is gone.

Comment 55 Geraldo Simião 2021-04-22 13:32:09 UTC
Confirmed here too, with Fedora-KDE-Live-x86_64-34-1.1.iso no more user switching

Comment 56 Fedora Update System 2021-04-22 14:53:52 UTC
FEDORA-2021-a526beb5e7 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 57 John C. Beima 2021-05-14 00:34:48 UTC
When is this being fixed? Taking user switching away from KDE desktop installs of Fedora 34 is not a solution, it is hiding a problem that has existed for more than a year. This challenge has been around since Fedora 32.

You can't simply take user switching away from desktop machines, you are making KDE simply an unusable desktop.

Comment 58 Kamil Páral 2021-05-14 10:38:18 UTC
Hi John, hopefully in F35, but it's really an upstream KDE issue, you need to ask there. User switching wasn't present in F33 either, btw. We have certain quality standards which must be met, which includes highly visible system actions to be working. If you want to experiment or you don't mind your sessions breaking, you can edit the file from comment 49 and change "false" to "true", which should make the Switch button visible again.

Comment 59 Neal Gompa 2021-05-15 09:03:21 UTC
(In reply to John C. Beima from comment #57)
> When is this being fixed? Taking user switching away from KDE desktop
> installs of Fedora 34 is not a solution, it is hiding a problem that has
> existed for more than a year. This challenge has been around since Fedora 32.
> 
> You can't simply take user switching away from desktop machines, you are
> making KDE simply an unusable desktop.

The fact that this functionality has been increasingly breaking for two years, and got so broken that we don't even auto test for it anymore since Fedora 32 should tell you how little the functionality is actually used in practice. Nobody was working with upstream KDE to ensure this functionality worked for *years*.

I would like to say we can restore it in Fedora Linux 35, but I honestly don't know if that will be the case. SDDM is going through a huge rework right now, and that may improve things on this front, or make it worse. I'm optimistic, but I can't reasonably say it'll happen for sure.

Comment 60 Sudhir Khanger 2021-10-13 10:19:17 UTC
Is this still an issue? I see that KDE upstream bug mentioned has been marked as resolved. SDDM issue hadn't seen any comments.

If it has been resolved is there a plan to enable this or how can I safely enable it now?

Comment 61 Adam Williamson 2021-10-13 15:04:01 UTC
Hmm, I don't think we re-tested it this time around, really. Kamil, do you want to re-enable user switching and try it out a bit? I can do the same. Assuming we slip this week, we probably have time to turn it back on if it's working.

Neal, Rex, any thoughts from KDE sig perspective?

Comment 62 Adam Williamson 2021-10-13 22:05:58 UTC
well, I just re-enabled user switching and tried Kamil's scenario 2 - log in as user A, switch user, log in as user B, log out - and the system got stuck at a blank screen. So I'd say it doesn't look like things are hunky dory here yet...

Comment 63 Rex Dieter 2021-10-13 23:11:50 UTC
Issue remains indeed, won't have a chance to test this until we can rebase to a newer sddm.

And can't do that until xauth support is ported

Comment 64 Neal Gompa 2021-10-14 00:36:22 UTC
(In reply to Rex Dieter from comment #63)
> Issue remains indeed, won't have a chance to test this until we can rebase
> to a newer sddm.
> 
> And can't do that until xauth support is ported

... or we get to a point where SDDM can run in all scenarios in pure Wayland, which is dependent on bug 1986222.


Note You need to log in before you can comment on or make changes to this bug.