Bug 241231 - security/plasma5-kscreenlocker: "Start New Session" does not work
Summary: security/plasma5-kscreenlocker: "Start New Session" does not work
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Gleb Popov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-13 18:57 UTC by Raphael Kubo da Costa
Modified: 2024-03-16 20:26 UTC (History)
6 users (show)

See Also:
arrowd: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raphael Kubo da Costa freebsd_committer freebsd_triage 2019-10-13 18:57:24 UTC
avg@ reports to the mailing list (https://mail.kde.org/pipermail/kde-freebsd/2019-July/031951.html):

> Does user switching work for anybody?
> Is there any additional configuration needed to get it working?
>
> It does not work for me at all.  When I click "Start New Session" I am taken
back to the unlock screen for a current user.
> This is with the latest plasma 5.16.2.

I haven't tested this with 5.16.5, but I guess it's still broken.
Comment 1 Mikael Urankar freebsd_committer freebsd_triage 2019-10-14 08:26:06 UTC
Yes it's still broken.
Comment 2 Andriy Gapon freebsd_committer freebsd_triage 2019-10-16 13:15:57 UTC
I should clarify that the original report was for sddm.

Later, I tried lightdm and with it "Start New Session" does indeed start a new X/lightdm session.
Comment 3 Gleb Popov freebsd_committer freebsd_triage 2021-09-29 10:49:19 UTC
Works for me with current SDDM and Plasma. Andriy, can you check it out again?
Comment 4 Dwayne MacKinnon 2021-09-29 13:07:09 UTC
I can switch users under SDDM. My issue is switching back to the first one. When I do that (by logging out the second user) the first user can't open up any new windows; the XAuth permissions are all messed up.
Comment 5 Gleb Popov freebsd_committer freebsd_triage 2021-09-29 13:08:22 UTC
(In reply to Dwayne MacKinnon from comment #4)
Can you provide exact steps to reproduce the problem?
Comment 6 Dwayne MacKinnon 2021-09-29 13:12:08 UTC
(In reply to Gleb Popov from comment #5)

1) Lock the screen (either timeout or manual lock is fine.)
2) Use Start New Session to log in as a second user.
3) Log out of the second session. 
4) Unlock the screen for the first session.
5) Try to open any new window (firefox, konsole, kmail, anything.)
Comment 7 Gleb Popov freebsd_committer freebsd_triage 2021-09-30 06:37:55 UTC
Indeed, I managed to reproduce this!

After following outlined steps it is impossible to run any X application. Running "kwrite" yields:

qt.qpa.xcb: could not connect to display :0

I believe, this is an upstream SDDM problem.
Comment 8 Gleb Popov freebsd_committer freebsd_triage 2021-09-30 06:46:40 UTC
Another interesting thing is that after switching back to the first user, it somehow gains an ability to shutdown/reboot the machine even if it hasn't before.
Comment 9 Gleb Popov freebsd_committer freebsd_triage 2021-10-11 11:41:10 UTC
I tried pulling in this patch: https://github.com/sddm/sddm/pull/1230 however it didn't help with this issue.

I have some other PRs to sddm in flight, so I'll get back to this issue after these land.

Meanwhile, any info on how that XAUTHORITY thing works would be really appreciated.
Comment 10 Gleb Popov freebsd_committer freebsd_triage 2024-02-20 18:55:26 UTC
I implemented fix for that, but it depends on many changes, so this is blocked by upstream for now. I'm waiting for a new ConsoleKit release.