When I update sddm to 0.20.0, the plasma desktop shows no shutdown, reboot or sleep buttons in the app launcher or elsewhere. If I revert sddm to 0.19.0_8, the buttons reappear after a reboot cycle. I didn't investigate yet, DBUS is running and the usual suspects like upower and ConsoleKit2 are installed. May have to look at the configuration files changed in the update. The /var/log/sddm.log shows nothing unusual. Does someone know which power backends are actually used in FreeBSD / X11?
I confirm. After updating I have the same problem.
Created attachment 243573 [details] Screenshot of Application Launcher (In reply to Florian Walpen from comment #0) > … no shutdown, reboot or sleep buttons in the app launcher or elsewhere. … Not reproducible here. I have six options in Application Launcher: Lock Log Out Switch User Sleep Restart Shut Down % pkg iinfo sddm plasma5-sddm-kcm-5.27.6 sddm-0.20.0 sddm-freebsd-black-theme-1.3 % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n264150-c65845d0bb2d-dirty: Fri Jul 14 07:11:27 BST 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400093 1400093 %
Created attachment 243574 [details] screenshot of Restart and Shut Down buttons in the logout greeter /usr/local/lib/libexec/ksmserver-logout-greeter
With this: # pkg iinfo sddm plasma5-sddm-kcm-5.27.6 sddm-0.19.0_8 I have six options in Application Launcher: Lock Log Out Wait Sleep Restart Shut Down With this: # pkg iinfo sddm plasma5-sddm-kcm-5.27.6 sddm-0.20.0 I have only two options in Application Launcher: Lock Log Out FreeBSD 13.2-RELEASE-p1 amd64
Created attachment 243577 [details] Resurrect patch for Xsession script lost in the update to sddm-0.20.0 Resurrect a patch that was removed by the update to sddm-0.20.0 (commit 718687d3ee3e9556cd440c0aa26a36c52937e620). It explicitly starts the session with > exec $STARTUP /usr/bin/dbus-run-session --dbus-daemon=/usr/bin/dbus-daemon -- "$@" This fixes the missing power options for me, sddm-0.20.0 on 13.2-RELEASE-p1. The comment in the patch says: > Fix use of "$@" (see sh(1)). > > There's no systemd on FreeBSD so start the session using $STARTUP which is > defined in 90-consolekit if ConsoleKit2 is installed. By default this allows > local users to shutdown/reboot the machine and access devices like USB keys. > > Also use dbus-run-session so libdbus doesn't have to autolauch the session bus > daemon on first use. Autolaunched dbus daemons tend to linger and may only > exit if the X server exits. Maybe there's something with the autolaunch of the DBUS session not working for Serge and me, but does work for Graham?
Hi Gleb, hope it's ok to CC you here. You did commit 718687d3ee3e9556cd440c0aa26a36c52937e620 and removed the patch for the sddm Xsession script (see above). Could you comment on why the patch was removed?
(In reply to Florian Walpen from comment #5) If you restart the computer and then use SDDM to login: does /var/run/user/ include a directory that corresponds to your UID number?
(In reply to Florian Walpen from comment #5) > dbus-run-session Wouldn't that stop it from working with other programs that use dbus? In my environment, there seems to be some sort of hint in ~/.dbus/session-bus/* to locate autolaunched dbus-daemon. I'm not using KDE, so I'm not sure :) However, qt-related is strange in the way XDG_RUNTIME_DIR is handled.
Missing power options is a known problem. My current theory is that this is caused by buggy interaction between ConsoleKit and SDDM. I'm working in this area right now and will fix this problem as well once I figure it out. Speaking of the patch for $STARTUP, it should be safe to remove: - The system daemon should be started by "dbus_enable=yes" in /etc/rc.conf - The patch uses "/usr/bin/dbus-daemon" path which is wrong for FreeBSD What might explain the differencies you see is the "wheel" group. Check if your user is a member of wheel.
I installed version 0.20.0 and tried to use the file /usr/local/share/sddm/scripts/Xsession from the version 0.19.0_8. And everything worked. So we need a line exec $STARTUP /usr/local/bin/dbus-run-session --dbus-daemon=/usr/local/bin/dbus-daemon -- "$@" in Xsession script.
x11/sddm/files/patch-src_daemon_LogindDBusTypes.cpp seems to have been added for 0.17, does it still make sense for 0.20.0?
(In reply to Tatsuki Makino from comment #11) Yes, ConsoleKit is still not prepared for what SDDM asks it. I have filed a PR upstream: https://github.com/ConsoleKit2/ConsoleKit2/pull/137
(In reply to Graham Perrin ◐ from comment #7) > If you restart the computer and then use SDDM to login: > does /var/run/user/ include a directory that corresponds to your UID number? With the patch above the directory does exist. Without the patch it's missing.
(In reply to Gleb Popov from comment #12) Thank you. I thought there might be a problem in the program, but the XDG_* environment variable might also be a problem. The environment variable for XDG_* may behave strangely if it is not set to either set all or not set all.
Comment on attachment 243577 [details] Resurrect patch for Xsession script lost in the update to sddm-0.20.0 You are right, the patch makes no sense at all. But for a "placebo" it works surprisingly well and consistent :-) Maybe there's timing / retry involved if this line in the script fails? I'll leave the patch here for discussion consistency, but mark it as rejected.
(In reply to Florian Walpen from comment #13) I have the same behavior too.
Another observation, I have an ~/.xinitrc with the following line > exec ck-launch-session startplasma-x11 If I start a "User Session" with this from sddm, the power buttons are also present. Looks like having ck-launch-session run is key to this issue. sddm-0.20.0 unpatched, "Plasma Session (X11)" -> no power buttons: 1938 v0- I 0:00.07 |-- /usr/local/bin/sddm 1958 - S 0:11.38 | |-- /usr/local/libexec/Xorg -nolisten tcp -background none -seat seat0 vt9 -auth / 2000 - I 0:00.03 | `-- /usr/local/libexec/sddm-helper --socket /tmp/sddm-auth-a4daeba8-81ee-4710-89f6 2001 - I 0:00.25 | `-- /usr/local/bin/startplasma-x11 2024 - I 0:00.21 | `-- /usr/local/bin/plasma_session sddm-0.20.0 unpatched, "User Session" with ~/.xinitrc -> power buttons present: 1940 v0- I 0:00.08 |-- /usr/local/bin/sddm 2229 - S 0:02.12 | |-- /usr/local/libexec/Xorg -nolisten tcp -background none -seat seat0 vt9 -auth / 2242 - I 0:00.03 | `-- /usr/local/libexec/sddm-helper --socket /tmp/sddm-auth-972f395d-46c9-4ee6-bada 2243 - I 0:00.02 | `-- ck-launch-session startplasma-x11 2252 - I 0:00.21 | `-- startplasma-x11 2270 - I 0:00.20 | `-- /usr/local/bin/plasma_session sddm-0.20.0 patched, "Plasma Session (X11)" -> power buttons present: 1938 v0- I 0:00.06 |-- /usr/local/bin/sddm 1958 - S 0:01.86 | |-- /usr/local/libexec/Xorg -nolisten tcp -background none -seat seat0 vt9 -auth /v 2000 - I 0:00.03 | `-- /usr/local/libexec/sddm-helper --socket /tmp/sddm-auth-eedacd5c-658e-49a2-9ada- 2001 - I 0:00.02 | `-- /usr/local/bin/ck-launch-session /usr/local/bin/cadence-session-start --syste 2010 - I 0:00.00 | `-- /usr/local/bin/dbus-run-session --dbus-daemon=/usr/local/bin/dbus-daemon -- 2012 - I 0:04.23 | |-- /usr/local/bin/dbus-daemon --nofork --print-address 4 --session 2013 - I 0:00.23 | `-- /usr/local/bin/startplasma-x11 2022 - I 0:00.20 | `-- /usr/local/bin/plasma_session Graham, could you have a look at your session start with "ps dax"? Is ck-launch-session running and how is it started?
Gleb, as to why the patch worked even though the path to dbus-run-session is wrong - this path is replaced with the correct one in post-patch stage, see x11/sddm/Makefile.
FYI, I'm currently testing the following line in /usr/local/share/sddm/scripts/Xsession: > exec $STARTUP "$@" This corresponds to the patch but without the extra dbus-run-session command. Power buttons are present, and DBUS applications like jack_control seem to work. Maybe this is just imagination, but plasma session start and some applications seem more sluggish than before. OTOH, I can now logout and login again with jack_control still working. That wasn't the case before. Please note that there's a similar line in /usr/local/share/sddm/scripts/wayland-session for wayland sessions.
If launching consolekit is a workaround, what was launching consolekit in 0.19.0? Also, there is more dbus code related to consolekit in 0.20.0. It is sddm-0.20.0/src/daemon/DaemonApp.cpp
(In reply to Tatsuki Makino from comment #20) > If launching consolekit is a workaround, what was launching consolekit in 0.19.0? The patch above that was removed in the 0.20.0 update. As the description of the patch explains: > There's no systemd on FreeBSD so start the session using $STARTUP which is > defined in 90-consolekit if ConsoleKit2 is installed. By default this allows > local users to shutdown/reboot the machine and access devices like USB keys. Have a look at the /usr/local/etc/X11/xinit/xinitrc.d directory. The scripts there are injected into my session with $STARTUP. I also see another program inject itself there, the audio/cadence JACK session manager. Thus my proposition to patch in the $STARTUP variable without starting an extra dbus-run-session, which shouldn't be necessary. > Also, there is more dbus code related to consolekit in 0.20.0. > It is sddm-0.20.0/src/daemon/DaemonApp.cpp Correct, I only tested with 0.20.0, not 0.19.0_8. But I don't think it matters, going forward.
Please wait while I'm figuring out ConsoleKit incompatibilities. I'm already at the stage when started session shows power buttons correctly, so we won't need all these startup script hacks.
Ok, plugging dbus-launch into the $STARTUP seems to be a right thing to do. It certainly should be brought back. Now I digged into missing power controls a bit and descended down to polkit. For some reason it always says that I'm not authorized to issue a hibernation command. I actually wonder how did it work before. To test it: # pkcheck -a org.freedesktop.consolekit.system.hibernate -p <PID> where PID corresponds to any program run inside the desktop session (Konsole, for instance) The command says "Not authorized." for me whatever I try. It should say nothing and return 0 code in case of success.
(In reply to Gleb Popov from comment #23) > Now I digged into missing power controls a bit and descended down to polkit. > For some reason it always says that I'm not authorized to issue a hibernation > command. I actually wonder how did it work before. Did I miss something about hibernation being implemented, or do you mean suspend to RAM? The latter does work for me with the change I proposed.
It just about consolekit interface, not the actual support on the kernel side.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=6553c93b0a7ae9491f9af84f63d3115cfa265bc5 commit 6553c93b0a7ae9491f9af84f63d3115cfa265bc5 Author: Gleb Popov <arrowd@FreeBSD.org> AuthorDate: 2023-08-13 13:19:17 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2023-08-13 18:23:35 +0000 x11/sddm: Restore a patch for the Xsession script. Make it start D-Bus and ConsoleKit again. PR: 272637 Sponsored by: Serenity Cybersecurity, LLC x11/sddm/Makefile | 6 ++++-- x11/sddm/files/patch-data_scripts_Xsession (new) | 12 ++++++++++++ 2 files changed, 16 insertions(+), 2 deletions(-)
Should be fixed now.
(In reply to Gleb Popov from comment #27) Works fine now, with the additional dbus-launch even the DBUS lag when using jack_control is gone. Thanks Gleb! Stupid question though - since there's a similar script for wayland: /usr/local/share/sddm/scripts/wayland-session Would that also benefit from an explicit dbus-launch, or does that work in a different way? Never got wayland to run here, so can't test.
(In reply to Florian Walpen from comment #28) > Never got wayland to run here, so can't test. Same here. AFAIK, Plasma doesn't work with Wayland on FreeBSD. Also not sure about SDDM side, maybe its Wayland support is also bugged. We at $WORK are hoping to move to Wayland someday, but that's all blue.
(In reply to Gleb Popov from comment #29) > Same here. AFAIK, Plasma doesn't work with Wayland on FreeBSD. Adriaan de Groot had a blog post about running FreeBSD / wayland / plasma: https://euroquis.nl/kde/2021/04/30/wayland.html That was two years ago, and using a standalone script instead of sddm. Maybe it's time to try again with wayland...