Setting flags +wayland -x11

Does this happen still or on a fresh user?

(In reply to Bharadwaj Raju from comment #2)
> Does this happen still or on a fresh user?

Yes to both.

That's with git-master frameworks/plasma updated a couple hours ago.  (I didn't answer immediately as I'm working on a project and hadn't updated in ~10 days or so, but I'm updated now.)

While retesting the likely reason occurred to me:

Unlike X's wide-open security model which lets any X app know about the windows of other X apps, wayland-native apps normally only get to know about their own windows.  The wayland compositor itself (kwin_wayland in plasma's case) is the only normal exception, tho it can obviously arrange to share its knowledge with specific apps via private protocol (assuming there's no wayland-shell-specific protocol already standardized that I simply haven't seen anything on yet).

My guess is that either kwin doesn't have such a private sharing arrangement for that setup with plasmashell yet, or if it does and it's working for some, for whatever reason (missing dependency?) it's not working here.

By contrast, kwin's window switchers and effects such as the grid just work as they're direct kwin plugins and operate with direct compositor privileges.

So plasmashell on wayland literally doesn't have and cannot get the information about other windows that it uses on X to populate the taskmanager, icons-only-taskmanager, and desktop-window-list option (configurable as a desktop mouse option).

Tho one would /think/ kwin_wayland would have developed such a private protocol to share with its plasmashell desktop shell, but the evidence suggests either it hasn't yet, or I'm missing a critical dependency it normally uses for that.

Thanks for confirming.

It's working for me. And as far as I know KWin *does* have a private protocol with Plasmashell exactly for things like these. Unfortunately I don't know for sure what dependency you're missing. There's a package "plasma-wayland-protocols" which sounds like the closest match.

You might also want to try a Plasma Wayland session which comes pre-installed and configured, like Fedora 34 KDE.

>My guess is that either kwin doesn't have such a private sharing arrangement for that setup with plasmashell yet, or if it does and it's working for some, for whatever reason (missing dependency?) it's not working here.

It's a likely guess. Debug of plasmashell should tell you.
Our sharing arrangement is done by keys in the .desktop file and matching paths. Please confirm if everything is installed to /usr and without any other quirks.

(In reply to David Edmundson from comment #6)
> 
> It's a likely guess. Debug of plasmashell should tell you.

"Debug of plasmashell" means?

I did try restarting plasmashell from the terminal to get its output, both with and without a taskmanager plasmoid.  Lots of noise from other stuff (comic plasmoid seems to be the worst, well, that and complaints about missing udisks2, see below) that appeared in both.  But diffing the output I /did/ see one different message that /might/ be relevant:

org.kde.kf5.kwindowsystem.kwayland: This compositor does not support the Plasma Window Management interface

Or did you mean turning on kdebug in kdebugdialog5 or kdebugsettings?  If so which one and which settings, and then do I get the debug info from terminal output or the journal/syslog or a log file somewhere in /home/?

Or did you mean rebuilding with debug enabled (just plasma-workspace?) and running gdb?

Or...?

> Our sharing arrangement is done by keys in the .desktop file and matching
> paths. Please confirm if everything is installed to /usr and without any
> other quirks.

It's "installed" to /usr, but there are indeed a few quirks, two of which I could imagine having some effect here.

The first (since you mentioned /usr) is that I have a "reverse-usr-merge", that being a /usr -> . symlink so the canonical path for everything normally found in /usr is / instead (but still findable in /usr via the symlink).  But with the symlink that normally causes no problems and I doubt it is here either.

(I also have $XDG_CONFIG_HOME and $XDG_DATA_HOME set, and $HOME itself is a non-standard location, but not only are the envvars set but I have symlinks from the standard locations as well, so that shouldn't be a problem either.)

What I'm more thinking, however, starts with the fact that I have a pretty "lite" plasma install here, no baloo or semantic-desktop, no polkit, no udisks2, etc.

In the past I've found that kwalletmanager5 will show me the kwallet settings but not allow me to edit them in the GUI, presumably because it thinks it needs polkit, despite the fact that the kwalletrc file it presumably writes to is perfectly read-writable and thus text-editable by my same user!  So I had to first find that file (luckily not hard as I'm reasonably familiar with kde's config layout), then ddg/google the settings I wanted to change so as to be sure I got the format correct when textediting it.

So now that I know plasmashell apparently has access to the window list for other wayland users, despite that information not normally being available to wayland apps other than the compositor, I'm wondering if the reason I'm not seeing it here is a similar polkit-moderated permissions issue for stuff I really should have access to as my normal user anyway, just as seems to be the case with kwalletmanager5.  But polkit is a rather expensive dep to pull in just to test a dependency theory, 8 new packages plus rebuilding systemd with polkit support, including spidermonkey, which IIRC from when I last had it merged, isn't a trivial build.

i also dont have any application/window icons in the task manager widget in my panel. if i add a new icons only task manager widget to the panel i get the default pinned and unpinned icons(open application/windows) showing up like normal. i will report back but ive done this before and after a reboot they are gone again.

just noticed that when i go in and enable "from current screen", the unpinned window icons go away. they come back if i set to false again.

I have the same problem. As far as I know I haven't done anything special (like installing plasma to a different folder or anything). Using arch linux. Are there any solutions or ideas how to debug this? Running plasmashell in the terminal does not yield anything useful as far as I can tell.

(In reply to agzgtrtvquysegfqtl from comment #10)
> I have the same problem. As far as I know I haven't done anything special
> (like installing plasma to a different folder or anything). Using arch
> linux. Are there any solutions or ideas how to debug this? Running
> plasmashell in the terminal does not yield anything useful as far as I can
> tell.

The solitary but big clue so far is that  one message:

org.kde.kf5.kwindowsystem.kwayland: This compositor does not support the Plasma Window Management interface

You might grep the output (with one of the taskmanager plasmoids setup to run on the desktop or a panel, of course) and see if something similar shows up.  Tho it has been awhile since I tried that so the message might have changed.  I'll have to try again to verify it's still there (just updated and haven't restarted yet so can't ATM).

Also, please confirm that you have polkit/policykit installed, as that's my theory on what's missing here (with the problem low-priority enough for me not to bother installing it and its heavy deps just to test the theory), but I'd guess arch has it at least by default (it's a recommended default-on option for a gentoo/kde installation, but off here) so you /should/ have it installed, in which case you're either missing something else or my theory is wrong.

Fortunately for me (unfortunately for debugging) I ran without a taskmanager plasmoid for quite some time and had just been experimenting with one when I switched to wayland, so it hasn't been a high priority for me here as I just deleted the non-functional plasmoid and went back to my old method of depending on kwin-centric methods of window-switching (alt-tab, desktop-grid, etc).  But having the /option/ would be nice, and I'd probably have a taskmanager plasmoid (probably icons-only) running if I could actually make it work.  *Having* to depend on the hotkey-kwin methods because the pointy-clicky plasmashell methods are broken is a drag.

I indeed have polkit installed. If I just restart plasmashell I do not get any useful errors, but if I remove taskmanager and readd it to the panel I get the same message as you (together with some semi related things next to it):

file:///usr/lib/qt/qml/org/kde/plasma/extras/PlasmoidHeading.qml:75: TypeError: Value is undefined and could not be converted to an object
org.kde.kf5.kwindowsystem.kwayland: This compositor does not support the Plasma Window Management interface
This plugin does not support setting window opacity
Arrived mimeData () ("text/x-plasmoidservicename") at 12 ,  811
adding "org.kde.plasma.taskmanager"
This plugin does not support setting window opacity

So at least I think it's not polkit.

(In reply to agzgtrtvquysegfqtl from comment #12)
> So at least I think it's not polkit.

Interesting.  Thinking it was polkit had de-prioritized it further for me.  So (for me personally) that has both good and bad implications; good, in that there's a chance it could work here (without polkit which isn't a cost I considered worth it); bad, in that now I can't just excuse not looking into it further with that. =:^\

Meanwhile, if you're still seeing the same message, that means it hasn't changed... tho it's worth keeping in mind that tho it's  the best/only real lead so far we don't /know/ it's related to the bug -- it could just be typical non-fatal noise that always occur with the plasmoid, whether it works or not, due to changes to the underlying system that the plasmoid hasn't kept up with.  Unfortunately the devs seem to be much better about adding deprecation warnings and the like than they are about following up on them, and the output of kde apps is *notoriously* *noisy* in this regard as a result, making troubleshooting harder instead of easier.  =:^(

*** Bug 444226 has been marked as a duplicate of this bug. ***

*** Bug 438729 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #14)
> *** Bug 444226 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #15)
> *** Bug 438729 has been marked as a duplicate of this bug. ***

In my case (original reporter, this bug), I don't (didn't, probably time to try it again, maybe it's semi-fixed?) see *any* running-app icons, X11 or wayland-native, *ever*.  The *only* icons I see are the pinned-app-launchers.

In the two just-duped bugs it seems hit-or-miss whether a running app, apparently especially X11 apps (wayland-native app icons either always or most of the time show up, if I'm reading the bugs correctly).

That doesn't make it different bugs (which they might or might not be); it makes me the unfortunate 100% reproducer. =:^\

Meanwhile, one of them, bug #444226 comment 2 mentions that the taskmanager code can be found at https://invent.kde.org/plasma/plasma-desktop/-/tree/master/applets/taskmanager .  (Mostly as a note to myself to take a look; no dev claims but sometimes I can hack-patch or perhaps shell-script up a work-around, if I'm pointed at it say by a git bisect or commit log touching something related, and/or stare at it hard enough for long enough.)

i dont have this issue anymore on:

Operating System: KDE neon 5.23
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.89.0
Qt Version: 5.15.3
Kernel Version: 5.11.0-46-generic (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i7-5600U CPU @ 2.60GHz
Memory: 11.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 5500

(In reply to Duncan from comment #16)
> In my case (original reporter, this bug), I don't (didn't, probably time to
> try it again, maybe it's semi-fixed?) see *any* running-app icons, X11 or
> wayland-native, *ever*.  The *only* icons I see are the pinned-app-launchers.

Just tested again (on live-git-master frameworks/plasma updated a couple days ago) and still seeing the bug here.

Additionally, testing an idea I found elsewhere, I tried export=QT_QPA_PLATFORM=xcb plasmashell --replace (which when run in a wayland session tells the replacement to run as an X app on top of xwayland instead of as a native wayland app), and... then I get the taskmanager showing X apps, but still not showing wayland-native apps.  AFAIK that's the expected result there -- it shows X apps because it's running in X mode, but doesn't then know anything about wayland-native apps.  So /that/ seems to be working.

It's only native-wayland (QT_QPA_PLATFORM=wayland or wayland-egl) that can't see any windows at all, X or native-wayland.

(In reply to kinghat from comment #17)
> i dont have this issue anymore on:
> Operating System: KDE neon 5.23
> KDE Plasma Version: 5.23.5
> KDE Frameworks Version: 5.89.0
> Qt Version: 5.15.3
> Graphics Platform: Wayland

Wish I knew what the difference in config was between your working system and my bugged system.  I'm running live-git plasma/frameworks of course, but the bug has been open long enough to cover the minimal version differences.

> org.kde.kf5.kwindowsystem.kwayland: This compositor does not support the Plasma Window Management interface

I wonder if there's something Gentoo skips building by default which makes this happen? Like plasma-wayland-protocols or something related? Because a properly-built KWin definitely supports Plasma Window Management interfaces.

(In reply to Bharadwaj Raju from comment #19)
> I wonder if there's something Gentoo skips building by default which makes
> this happen? Like plasma-wayland-protocols or something related? Because a
> properly-built KWin definitely supports Plasma Window Management interfaces.

Definitely not a missing plasma-wayland-protocols.  That's installed and (on live-git) I see it updated routinely.

I was able to reproduce this when trying to start plasmashell (kdesrc-build environment) from the command line. I tried both of these:

killall plasmashell; kstart5 plasmashell

plasmashell --replace

There is no problem when I try to do it with the release version of plasma (5.23.4)

This could possibly be related to kwin not finding plasmashell's desktop file.

If you're hitting this issue, can you please provide kwin logs and check if you have something like:
"Interface org_kde_plasma_window_management not in X-KDE-Wayland-Interfaces of /usr/bin/plasmashell"

(In reply to Aleix Pol from comment #22)
> This could possibly be related to kwin not finding plasmashell's desktop
> file.
> 
> If you're hitting this issue, can you please provide kwin logs and check if
> you have something like:
> "Interface org_kde_plasma_window_management not in X-KDE-Wayland-Interfaces
> of /usr/bin/plasmashell"

How do I get kwin logs on wayland?

(In reply to Noah Davis from comment #23)
> How do I get kwin logs on wayland?

(See also comment #6 and my reply in comment #7, basically same question but s/kwin/plasmashell/, without direct answer ...)

There *is* a rather too obscure and poorly documented kde app/package, kdebugsettings, to set the debug/logging level of the various components.

Ideally there'd be a nice kdebugsettings tutorial and such mentions of logging or debugging could specify the desired component and link the tutorial.  Unfortunately without that, I installed and turned off everything to stop the torrent of noise I was seeing in syslog/journal, and have hesitated to mess with it since lest I restart the uncontrolled torrent.  Maybe it's time I revisit that...

Meanwhile, the more traditional output redirection method would be...

!! Be ready as this will restart your plasma session, the reason I've not tried it myself just yet !!

kwin_wayland --replace &> /path/to/dumpfile

Tho I remain unsure that will produce the logging he had in mind...

(In reply to Duncan from comment #24)
> !! Be ready as this will restart your plasma session, the reason I've not
> tried it myself just yet !!
> 
> kwin_wayland --replace &> /path/to/dumpfile

Tried it.  Just got an empty logfile (and a messed up session I had to manually un-mess). =:^(

(In reply to Duncan from comment #24)
> Ideally there'd be a nice kdebugsettings tutorial and such mentions of
> logging or debugging could specify the desired component and link the
> tutorial.  Unfortunately without that, I installed and turned off everything
> to stop the torrent of noise I was seeing in syslog/journal, and have
> hesitated to mess with it since lest I restart the uncontrolled torrent. 
> Maybe it's time I revisit that...

And so I am.  Just guessing on what to turn on feels like shooting in the dark hoping to hit something, but it's what I can do ATM.  With everything else turned all the way off, I turned the following to full debug:

KWindowSystem (kf.windowsystem)
wayland integration (windowsystem) (org.kde.kf5.kwindowsystem.kwayland)
KWin Core (kwin_core)
KWayland Server Library (kf.wayland.server)

I also tried KWayland Client Library (kf.wayland.client) but it was far too noisy, lots of output for each app.

A full logout/login cycle didn't seem to log anything of interest (to syslog/journal) and not much at all, beyond losing the connection at logout, etc.

Doing a plasmashell --replace, however, with output to konsole and with the window list and task manager plasmoids setup on one of my desktops, spit this out (among other output) to konsole (IOW not to syslog/journal, to the konsole I ran it from, FWIW these messages generally appeared twice each, maybe once per activity/screen since I have two?):

org.kde.kf5.kwindowsystem.kwayland: This plugin does not support changing KeepBelow window state
org.kde.kf5.kwindowsystem.kwayland: This plugin does not support changing SkipPager window state
org.kde.kf5.kwindowsystem.kwayland: This plugin does not support setting window on all desktops
org.kde.kf5.kwindowsystem.kwayland: This plugin does not support getting windows

That's generally the expected complaints when an app tries to set window properties on wayland that it can only set on X (they're the domain of the compositor on wayland), and most of them appear elsewhere in the output as well, but that last one, does not support getting windows, looks like it /might/ be relevant, did *not* appear elsewhere in the output tho it was appeared twice in a row right there, and was followed by:

qml: PlasmaExtras.ScrollArea is deprecated. Use PlasmaComponents3.ScrollView instead.
file:///share/plasma/plasmoids/org.kde.plasma.windowlist/contents/ui/main.qml:118:13: Unable to assign [undefined] to QString

Again, line 118 seems to be trying to set desktop which I don't believe it can do on wayland so it would be expected, but the point here is that the doesn't support getting windows line above is close enough to guess it /might/ be from the windowlist plasmoid, possibly indicating something about why it can't get and show the window list.

But as I said I'm just shooting in the dark and it could well be as irrelevant as the other lines.

And I did *not* see anything like the "Interface org_kde_plasma_window_management not in X-KDE-Wayland-Interfaces
of /usr/bin/plasmashell" asked about in comment #22.  But for all I know I don't have the right logging enabled or am looking at the wrong logs. <shrug>

(In reply to kinghat from comment #17)
> i dont have this issue anymore on:
> 
> Operating System: KDE neon 5.23
> KDE Plasma Version: 5.23.5
> KDE Frameworks Version: 5.89.0
> Qt Version: 5.15.3
> Kernel Version: 5.11.0-46-generic (64-bit)
> Graphics Platform: Wayland
> Processors: 4 × Intel® Core™ i7-5600U CPU @ 2.60GHz
> Memory: 11.6 GiB of RAM
> Graphics Processor: Mesa Intel® HD Graphics 5500

i have actually ran into this again. actually im not sure if its the same thing anymore because all the items in the panel seem to freeze, like the time stops incrementing for example. ill keep an eye out.

(In reply to kinghat from comment #27)
> (In reply to kinghat from comment #17)
> > i dont have this issue anymore on:
> > 
> > Operating System: KDE neon 5.23
> > KDE Plasma Version: 5.23.5
> > KDE Frameworks Version: 5.89.0
> > Qt Version: 5.15.3
> > Kernel Version: 5.11.0-46-generic (64-bit)
> > Graphics Platform: Wayland
> > Processors: 4 × Intel® Core™ i7-5600U CPU @ 2.60GHz
> > Memory: 11.6 GiB of RAM
> > Graphics Processor: Mesa Intel® HD Graphics 5500
> 
> i have actually ran into this again. actually im not sure if its the same
> thing anymore because all the items in the panel seem to freeze, like the
> time stops incrementing for example. ill keep an eye out.

That's a known but separate bug

*** Bug 449200 has been marked as a duplicate of this bug. ***

*** Bug 442321 has been marked as a duplicate of this bug. ***

OK, playing with kdebugsettings a bit more, again with everything else (including the kwin and wayland settings I tried on debug above) off, I tried setting Plasma Core lib and Plasma Quick lib (kf.plasma.core and kf.plasma.quick) to full debug.

With a plasmashell replace I got this taskmanager-related error several times in the same second (otherwise nothing else of interest, tho lots of irrelevant binding-loop complaint noise, etc):

file:///share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/ContextMenu.qml:321: TypeError: Cannot call method 'indexOf' of undefined

Context lines (with line numbers) from that file:

...
019 PlasmaComponents.ContextMenu {
020     id: menu
...
283     PlasmaComponents.MenuItem {
284         id: virtualDesktopsMenuItem
...
304         PlasmaComponents.ContextMenu {
305             id: virtualDesktopsMenu
...
309             function refresh() {
310                 clearMenuItems();
311
312                 if (virtualDesktopInfo.numberOfDesktops <= 1) {
313                     return;
314                 }
315
316                 var menuItem = menu.newMenuItem(virtualDesktopsMenu);
317                 menuItem.text = i18n("Move &To Current Desktop");
318                 menuItem.enabled = Qt.binding(function() {
319                     return menu.visualParent && menu.get(atm.VirtualDesktops).indexOf(virtualDesktopInfo.currentDesktop) === -1;
320                 });
321                 menuItem.clicked.connect(function() {
322                     tasksModel.requestVirtualDesktops(menu.modelIndex, [virtualDesktopInfo.currentDesktop]);
323                 });
324
325                 menuItem = menu.newMenuItem(virtualDesktopsMenu);
326                 menuItem.text = i18n("&All Desktops");


Possible clue?

Note that I have three virtual desktops setup (running on dual monitors if it matters, with two activities).  Maybe the bug is number-of-desktops sensitive and in some cases on wayland the number of desktops is >1 to get past the return on 312/313, but virtualDesktopInfo.currentDesktop is junk (plasma not getting that info on wayland?)?  Thus the type-error.

If that type-error then aborts the entire tasklist gathering (instead of ignoring it and continuing with what it can) it would explain why I'm not getting any tasks shown.

So the next test is whether reducing the number of virtual desktops to one gets me anywhere, as I think it should then just return on lines 312/313, which should then simply skip the virtual-desktops functionality in the menu, thus skipping the buggy code.

(In reply to Duncan from comment #31)
> So the next test is whether reducing the number of virtual desktops to one
> gets me anywhere, as I think it should then just return on lines 312/313,
> which should then simply skip the virtual-desktops functionality in the
> menu, thus skipping the buggy code.

No luck. =:^(  A single virtual desktip did eliminate the type-error, but it didn't give me a working taskmanager, and nothing else of interest seemed to log, either.

(In reply to David Edmundson from comment #6)
> >My guess is that [kwin's] private sharing arrangement [for] plasmashell[, while] working for some, for whatever reason (missing dependency?) [isn't] working here.
> 
> It's a likely guess. Debug of plasmashell should tell you.
> Our sharing arrangement is done by keys in the .desktop file and matching
> paths.

Following this hint, after a bit of looking I found the X-KDE-Wayland_Interfaces= setting in a number of *.desktop files:

In /share (and also in /usr via /usr -> . symlink):

/share/kglobalaccel/
org.kde.krunner.desktop

/share/kservicetypes5
application.desktop

/share/applications
org.kde.plasma.browser_integration.host.desktop
org.kde.plasmawindowed.desktop
org.kde.plasmashell.desktop

In /etc:

/etc/xdg/autostart/
org.kde.plasmashell.desktop  (identical to the one in /share/applications)

Comparing the plasmashell *.desktop against those for krunner and browser_integration, they all three have in their X-KDE-Wayland-Interfaces= line:

org_kde_plasma_window_management

And for the latter two it seems to work, as krunner can see and activate windows based on their titles (presumably the krunner file) and can see and switch tabs in firefox (presumably the browser_integration file).

But it doesn't seem to work for plasmashell...

Could it be that plasmashell is started by path instead of via the *.desktop file, or otherwise doesn't match it, so doesn't get the benefit of its X_KDE_Wayland_Interfaces= line?


Note that I do not run a *DM here, instead starting plasma from the CLI using a script that simply does:

dbus-run-session startplasma-wayland

Maybe when started by that method, plasmashell is launched via shell path instead of the *.desktop file, despite the /etc/xdg/autostart/ *.desktop file?

With today's updates (previous update was a week ago) I suddenly had running windows showing up! =:^)

Without actual bisecting I believe the problem was resolved by: 
kwin commit 9c65d61b9
utils/serviceutils: compare executablePath against canonical path of exec fields in .desktops

Quoting its comment:

|     /proc/%/exec always points to the canonical/real path of a binary,
|     the exec field of a .desktop might contain a symlink and therefore
|     differ from canonical path.
|     Explicitely canonicalizing the path in exec prevents this mismatch.

As I noted in an earlier comment, I have a "reverse usr-merge" with my /usr being a symlink /usr -> .   so all of /usr ends up actually directly under /, but still accessible under /usr via the symlink.  The (gentoo/kde overlay live-git) installation, however, is still to /usr, so that's what the paths in the *.desktop files presumably use.  This commit adjusts to use the canonical path, so the paths started matching and the X_KDE_Wayland_Interfaces= line in the *.desktop file actually took effect!

Regardless of whether that's the fix or not, the bug as I filed it appears to be fixed.  However, there's a bunch of others duped to this bug now that were more intermittent and thus may well be different bugs that aren't fixed yet.  So pending other reports that those are fixed too I'll leave the bug open for now...

That makes perfect sense. I'll mark this as resolved and go through the duplicates. Super cool.

Bug 444226 is also from a Gentoo person so that's probably the same issue.

Bug 449200 and Bug 442321 are from Arch users and Bug 438729 is from a Fedora user. I'll ask them if it's fixed in Plasma 5.24.1 for them.

It is not fixed for me, but I will add that context in the other bug report then.

Thanks folks.

Hello! Many apologies for bumping this but I believe I'm still affected by this bug. That being said I'm also not entirely sure if the cause of the problem is the same or they just manifest in a similar fashion in which case I can open a new bug if requested. At some point between 5.27.7 and 5.27.8 taskbar stops tracking new windows and only pinned applications show up exactly as described in the original bug report. I browsed the git commits of plasma-workspace between 5.27.7 and 5.27.8 and there were a few commits that *look* like they might be associated with this, for instance this [0] or this [1] but unfortunately I am not qualified enough to say. I also get the same error as reported here when starting plasmashell from a terminal ("org.kde.kf5.kwindowsystem.kwayland: This compositor does not support the Plasma Window Management interface"). 

I'm on Arch Linux with Plasma 5.27.8 and an NVIDIA graphics card. I don't encounter this issue if I revert plasma-workspace (which includes plasmashell) back to 5.27.7.

[0] https://invent.kde.org/plasma/plasma-workspace/-/commit/b235a5900107ef1cec7d6ac30f5569ee5e3357c1
[1] https://invent.kde.org/plasma/plasma-workspace/-/commit/cb7dfe90f2a91f20c40a7e4744112602534aee38

Yes, please submit a new bug report for that issue. If reverting to Plasma 5.27.7 fixes it for you, then it's caused by a code change that went into 5.27.8, which would be quite recent.

Opened Bug 475896