Missing something auth-related in my Plasma 6 setup, what is it?

I’ve been doing Plasma 6 development for about half a year. Was hoping that at some point, the situation resolves itself through clean builds, a random bugfix, or such. But it’s not happening, so I’d like to ask if you have an idea what’s going wrong for me that I haven’t heard anyone else complain about.

My Plasma 6 setup works in general, and importantly allows using apps and switching windows. But fails in different ways, some more annoying than others:

  • In SDDM, the names shown for my Plasma 6 sessions are “” and " (Wayland)" which is clearly missing a part of the name for both X11 and Wayland sessions.
    • The files appear to be installed correctly, and obviously execute the right binaries when logging in. No clue how SDDM loses just a part of their name.
    • The regular 5.27 distro package shows its own session names just fine.
    • This turned out to be an issue with SDDM’s .desktop file parser not reading text with commas correctly up to version 0.20.0.
  • Spectacle doesn’t work. As per console output:
    • Screenshot request failed: “The process is not authorized to take a screenshot”
    • IIRC, this used to work at least on X11 initially but has been failing there as well for a while, same error message.
  • Power management KCMs in System Settings won’t show fields for screen dimming and charge limits.
    • Screen brightness controls are also missing from the Brightness applet.
    • This turned out to be an issue with KAuth, which I was able to fix after Duha (below) pointed to the correct probable cause.
  • The panel’s task manager apparently doesn’t know about open windows (in Wayland only, X11 works for this).
    • This manifests in ways such as not showing indicators for running apps, or starting a new instance of an already running app when clicking the app icon.
    • A few months back, I tried to figure out where exactly this is going wrong and ended up in code that requires privileged access to a Wayland extension.
  • As of today’s rebuild of all workspace repositories, the task manager now crashes because it can’t initialize the screencasting Wayland protocol.
  • When pressing Alt in QML pages (e.g. via kcmshell6), letters don’t get underscored according to their mnemonics shortcuts.
    • No indicator that this is auth-related, but who knows if it is, right?

For long enough, I’ve been adding a disclaimer to my merge requests in the vein of, “I think this should work, but my setup is broken so I’m not sure and could you please please do some extra testing”. Now I filed a crash bug that may not exist for other people, although I can’t fully know for sure. This sucks for everyone.

So, please help? Where could my installation go so wrong? It really seems that something at the very core of the session (e.g. startkde-plasma) isn’t getting those permissions that all other software needs. But if there any docs about how to get them set up properly, I haven’t found those.

If you’ve got any ideas, I’d be forever thankful and perhaps end up more productive in improving Plasma & Co. for everyone. Thanks in advance for your help!


Appendix: Boring but necessary details about my build

I use standard kdesrc-build as per Get Involved development wiki page. I run Plasma 6 under a different user than the standard 5.27 packages that Arch Linux provides. I’m not using any “trusted” permission systems such as SELinux or App Armor. Qt packages come from Arch directly, KDE software (and selected standard repos such as wayland or appstream) are built from scratch as per default contributor docs.

For a full build of Plasma 6, I’ve used commands such as these:

kdesrc-build workspace print-manager kdeconnect-kde spectacle dolphin --include-dependencies
rm -rf ~/build/kde6/prefix
~/build/kde6/plasma/plasma-workspace/login-sessions/install-sessions.sh

Relevant portion of my kdesrc-buildrc config file:

global
    branch-group kf6-qt6
    include-dependencies False

    # Where to download source code. By default the build directory and
    # logs will be kept under this directory as well.
    source-dir ~/src/kde # Make this ~/kde/src if you want to use same repos as KF6

    directory-layout invent

    # Where to perform the build of source code before installation.
    build-dir ~/build/kde6

    kdedir ~/build/kde6/prefix
    prefix ~/build/kde6/prefix # probably redundant, should use kdedir as default
    cmake-options -DCMAKE_BUILD_TYPE=Debug -DQT_MAJOR_VERSION=6 -DBUILD_WITH_QT6=ON -DBUILD_KCM_MOUSE_X11=ON -DBUILD_KCM_TOUCHPAD_X11=OFF

    # This can be set to a specific value if auto-detection fails.
    # Set to 'auto' to use (the number of detected cores) - 1
    num-cores 20

    # This is the same as above but used for heavyweight modules like
    # qtwebengine, though you can use it for modules yourself. A conservative
    # thumbrule is one core for every 2 GiB of total memory.
    num-cores-low-mem 2

    # For CMake modules this configures CMake to use Ninja as the build
    # controller and generate metadata to make editing with Kate easier.
    cmake-generator Kate - Ninja

    # This defines a new "repository" entry for module-sets for Qt6, see
    # custom-qt6-libs-build-include
    # Not version-prefixed on KDE Invent, but Qt5 is version prefixed instead.
    git-repository-base qt6-copy https://invent.kde.org/qt/qt/
end global

Error message for accessing charge thresholds (via KAuth helper) in the Advanced Power Settings KCM:

org.kde.powerdevil.chargethresholdhelper.getthreshold failed: "DBus Backend error: could not contact the helper. Connection error: Rejected send message, 1 matched rules; type=\"method_call\", sender=\":1.2268\" (uid=2001 pid=204756 comm=\"systemsettings kcm_powerdevilprofilesconfig\") interface=\"org.kde.kf6auth\" member=\"performAction\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.kde.powerdevil.chargethresholdhelper\" (uid=0 pid=204810 comm=\"/usr/lib/kauth/chargethresholdhelper\").

This is because Spectacle switched to using the same KWin protocol to grab content from the screen on X11 as it does on Wayland. To explain why it now fails the same way :slight_smile: Use KWin ScreenShot2 DBus API whenever available (!255) · Merge requests · Graphics / Spectacle · GitLab

1 Like

Same for me. And atleast one other person who posted in the forums a few weeks/months ago. So probably not a issue with your setup.

Works for me on Wayland. Do you only have problems on X11 or also on Wayland?

Fails on both X11 and Wayland, for the reason that @redstrate mentioned above.

Thanks. If your session names are also missing but Spectacle is working, this indicates that at least the former might be unrelated to the various auth errors that I’m getting after logging in.

@jpetso from Plasma/Plasma 6 - KDE Community Wiki

In a built-from-source dev session on top of a distro-provided Plasma 5 session, all actions using KAuth are not working at the moment. Examples of such actions include changing the screen brightness and saving root-owned files in Kate and KWrite. See Co-installability fixes (!45) · Merge requests · Frameworks / KAuth · GitLab.

Does that explain your Auth issues?

1 Like

To clarify a bit: I am also running Arch with a compiled plasma 6 session (wayland only). So what works for me should also work for you.

  1. For the SDDM name display I have the same issue as you.
  2. Spectacle on wayland should work for you. (Does for me). I think the issue is the same as your crash issue. If not have a look at this: 446628 – Spectacle : Screenshot request failed: "The process is not authorized to take a screenshot"
  3. Power management I am not sure, since I am on a Desktop PC and not on a Laptop. Possibly a auth issue? Not sure.
  4. Not sure If I understand correctly but if I do I cannot reproduce.
  5. Did also rebuild today, didn’t notice any crashes.
  6. mnemonics shortcuts: There was a bug report a few days ago, but I cannot find it anymore :frowning:. If you tell me exactly where you have this issue I can try to reproduce, if you want (or try harder to find the bug report)
1 Like

I’m not sure what “a built-from-source dev session on top of a distro-provided Plasma 5 session” means exactly. I’m running my dev session next to a distro-provided Plasma 5 session. Logging in from SDDM directly, as opposed to running in some kind of child process. So theoretically it shouldn’t need anything from my Plasma 5 session.

But I guess all of the globally installed .desktop files from /usr/* can still be found by my built-from-source Plasma 6 session, and I can indeed see duplicated list entries in the Desktop Effects KCM as described in one of the listed known issues. So you may be on the right track here.

I need to read and understand the linked co-installability patch to see how this affects me and what could be done to perhaps only look at the ones in my built-from-source prefix. Perhaps I’ll try to revert it and see if anything starts working again.

Thanks for the pointers!

It explains all of my KAuth issues, which as it turns out is still only part of the listed problems. Thanks to your hint, I had a concrete lead to look into and got dev session KAuth helpers working again. Roughly, at least, with potential for fixing other people’s setups as well.

Having a fix for KAuth also shows that Spectacle and missing Plasma/KWin running task associations are unrelated to this, they’re still suffering from the originally mentioned points. I believe both stem from the same issue, an inability to call certain Wayland extensions for some reason. Why? Who knows!

The issue with this is that the name is to long for SDDM to display.
The issue is the ,. Removing , shows the name correctly

For example the name in:
/usr/share/wayland-sessions/plasmawayland-dev6.desktop
for me is
Name=Plasma (Development, Wayland /home/duha/kde/usr/bin)
Which seems to be to long. If I rename that to something shorter without , (like Dev Wayland) it works.

It looks like the file is generated here: login-sessions/plasmawayland-dev.desktop.cmake · master · Plasma / Plasma Workspace · GitLab

I haven’t found a bug report for this so far and I am unsure if this should be fixed in Plasma Workspace or SDDM.

Screenshot_20231230_140247

1 Like

Do you have a git version of SDDM to test? It would be nice to try fixing that upstream first, and implementing a workaround in Plasma as a last resort :slight_smile:

I had this on Arch one or two months ago.

Ha! Excellent find. This means it’s trying to interpret the comma as delimiter between two strings in an array. I just tried adding quotes around Plasma (Development, Wayland /home/kpetso/build/kde6/prefix/bin) and that makes it show up correctly.

Going to submit a merge request for plasma-workspace. Thanks @Duha!

Predictably, fixing the display name still doesn’t solve the main issue of several Wayland protocols being inaccessible once logged in. I still love seeing it come together piece by piece.

1 Like

Oh, I see the problem. SDDM’s last release is 0.20.0 from June 23. However, a few days later a fix got merged that replaces the .desktop file parser with a new one that conforms to the Desktop Entry Specification. The actual .desktop file is valid, but the last released version parses it incorrectly and a new release including the fix has not yet been released.

Looks like we’ll just need to wait until that happens, no further action or MR necessary.

Edit: I added a bullet point to the Plasma 6 known issues list. Hopefully people are okay with that, it’s quite a bit less severe than other bugs listed there, but also is immediately visible and prevents people like me from getting confused/concerned about it.

1 Like

Okay, so this took me a while, but I made some progress today. Using some recently acquired systemd skills, I made KWin print more logging messages. When executing spectacle, kwin_wayland reports:

KWIN_UTILS: Could not find the desktop file for "/home/kpetso/build/prefix/bin/spectacle"

That, in turn, prevents KWin from getting the necessary information to allow access to the privileged D-Bus and Wayland interfaces that Spectacle needs. The same issue also explains why my plasmashell doesn’t know what programs are running and their screen casts to put into the taskbar hover pop-up.

I added some extra logs to see what kind of commands get considered by KApplicationTrader::query() when called from KWin. Needless to say, my local ~/build/prefix/share/applications/org.kde.spectacle.desktop file with Exec=/home/kpetso/build/prefix/bin/spectacle is not among them. Somehow a few selenium-webdriver-* binaries from my prefix’s bin/ directory made it into the list, but the rest is all missing.

Running kbuildsycoca6 --noincremental didn’t do anything either. But at least now we know where the culprit is. Next steps may include checking whether regular programs after loading the session get the same queried service list as KWin, and if so, figuring out why a whole bunch of correctly located service files are not being discovered.

There is a way forward. I’ll get my screenshots and open tasks in the panel working eventually.

1 Like

The simplest way to fix this is to install Arch kdr-unstable plasma-desktop and other packages, too. kwin requires spectable desktop file to be under /usr to use privileged protocols. And other similar issues where the dev srssion doesn’t quite work.

Installing unstable distro Plasma feels like the wrong solution to me.

On one hand because I’d be executing different code than the one I’m developing on, which reduces the scope of changes I can make to my system. On the other hand because the actual bug (KApplicationTrader::query() not considering all the installed .desktop files, at least in this context) would remain unresolved and might continue to surface in different areas. Also I’d rather avoid messing with my stable fallback session too much.

If it’s true that KWin won’t accept privileged interface access from .desktop files in /home, then this should be listed explicitly in the relevant wiki page together with a workaround that links or installs some targeted files from my build prefix into /usr/local. No such explanation is listed there right now, and neither does the relevant Get Involved page mention any such limitations. ~/kde/build/plasma-workspace/login-sessions/install-sessions.sh is the recommended script, which I’ve been using and it does not prevent these issues.

If you have a pointer to another spot where a better explanation/suggestion is given to make self-built executables work correctly, maybe we can merge that info where a new developer might expect to find it.

That’s a small security feature, in Wayland for a program to be allowed to take screenshots it must have a special key in its .desktop file (which spectacle does) and the executable used must be owned by the root user.
So you local dev env might be concerned, but when installed from packages it should work fine.
That’s a “feature” I added a while back but we might want to undo it.
X11 isn’t concerned at all (in X11 any app can listen any keystroke and make recording of the video output, i.e no security at all).
Still Wayland by default has a better security story and we want to uphold it.
But this solution is not very practical, we’d need a dedicated authorization framework sort of what browsers do for webcam access.

1 Like

I wonder why manual intervention is required for @jpetso but not for me?

I also run Arch stable with wayland. I have a basic kdersc install and I didn’t add any desktop file manually.
Spectacle works for me and seems to be on Master:

Spectacle
Version 24.04.70
1 Like

Again, according to my log output, KApplicationTrader::query() doesn’t even consider my built-from-source spectacle. It’s not that KWin/Wayland rejects it due to its location. It’s not even showing up in the original listing.

So after a fresh install and kdesrc-build on a new PC I cannot launch via shortcut or from Application launcher: “the name is not activatable”.

Still works form the terminal.
@jpetso can you still not launch from terminal with a somewhat recent build?