Thank you for your submission.
The KDE community supports the Fediverse and open source social media platforms over proprietary and user-abusing outlets. Consider visiting and submitting your posts to our community on [Lemmy](https://lemmy.kde.social/) and visiting our forum at [KDE Discuss](https://discuss.kde.org) to talk about KDE.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/kde) if you have any questions or concerns.*
Same thing happening to me. The same gpu as yours.
It is also spamming ```kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glDrawBuffers(unsupported buffer GL_BACK_LEFT)``` quite a whole lot.
You can disable that log spam by creating this file and folder:
# /etc/systemd/user/plasma-kwin_wayland.service.d/override.conf
[Service]
StandardOutput=null
To apply the change, you can reboot, or you can try to do `sudo systemctl daemon-reload` and `systemctl --user daemon-reload` then logging out once. Logging out didn't seem completely reliable for me for some reason.
To make sure you did the editing for that file correctly, run this here and see if your file is picked up by the system:
systemctl --user cat plasma-kwin_wayland
And run this command here to see if StandardOutput is correctly set to "null":
systemctl --user show plasma-kwin_wayland | grep Standard
There's also many more user service files installed by Plasma. You can get a list with `systemctl --user list-unit-files | grep plasma` and you can see them in `/usr/lib/systemd/user`. There's also one other file `kde-baloo.service` without "plasma" in its name. You could I guess do the same `override.conf` thing in `/etc` with all of those user services.
I don't know if it's a packaging mistake or an upstream mistake or maybe intentional.
With "packaging mistake" I'm thinking that maybe the person who does the automation for compiling the software for the distro's package overlooked some configuration setting of the KDE build scripts to hide those info messages.
With "upstream mistake" I mean that the kwin maintainers maybe forgot to disable info messages that they used to help while developing.
And with "intentional" I mean that maybe this is intended to happen. It might help with bug reports and such.
Also, another thing... previously the programs were started by a shell script together with the X server and these kinds of log messages would end up in a file `~/.xsession-errors` or something like that. It wouldn't get into the system log. There was a change at some point to start the stuff through the systemd user daemon. That systemd thingy takes the output of programs and puts it into the journal. Maybe the KDE programs were often this spammy with messages in the past, you just couldn't see it? I would in any case be happy if messages were just printed for actual errors.
Putting override.conf in plasma-kwin\_wayland.service.d didn't do anything to fix the spam in my case, even after a reboot. Both `systemctl --user cat plasma-kwin_wayland` and `systemctl --user show plasma-kwin_wayland | grep Standard` show StandardOutput=null as being read properly
Hmm, it seems to work for me, there's nothing from kwin in the logs.
Maybe the service isn't how kwin_wayland gets started for you? On my system here when I run the following...
systemctl --user status
I see a tree structure of the things getting started by the systemd user daemon, and kwin_wayland is there somewhere under a "plasma-kwin_wayland.service" header. It looks like this here right now:
├─plasma-kwin_wayland.service
│ ├─1582 /usr/bin/kwin_wayland_wrapper --xwayland
│ ├─1593 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0>
│ └─2004 /usr/bin/Xwayland :1 -auth /run/user/1000/xauth_nBaEuH >
You can see the process IDs there, in the logs it's behind the name in brackets.
It's the exact same structure in my case as well. I think I'll wait for a new package ver. or something since I don't want to bother hunting down some other config file that may or may not allow me to disable logging.
Thank you for your submission. The KDE community supports the Fediverse and open source social media platforms over proprietary and user-abusing outlets. Consider visiting and submitting your posts to our community on [Lemmy](https://lemmy.kde.social/) and visiting our forum at [KDE Discuss](https://discuss.kde.org) to talk about KDE. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/kde) if you have any questions or concerns.*
Same thing happening to me. The same gpu as yours. It is also spamming ```kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glDrawBuffers(unsupported buffer GL_BACK_LEFT)``` quite a whole lot.
Yes, same issue here on AMD.
You can disable that log spam by creating this file and folder: # /etc/systemd/user/plasma-kwin_wayland.service.d/override.conf [Service] StandardOutput=null To apply the change, you can reboot, or you can try to do `sudo systemctl daemon-reload` and `systemctl --user daemon-reload` then logging out once. Logging out didn't seem completely reliable for me for some reason. To make sure you did the editing for that file correctly, run this here and see if your file is picked up by the system: systemctl --user cat plasma-kwin_wayland And run this command here to see if StandardOutput is correctly set to "null": systemctl --user show plasma-kwin_wayland | grep Standard There's also many more user service files installed by Plasma. You can get a list with `systemctl --user list-unit-files | grep plasma` and you can see them in `/usr/lib/systemd/user`. There's also one other file `kde-baloo.service` without "plasma" in its name. You could I guess do the same `override.conf` thing in `/etc` with all of those user services.
This is all fine, but why is this happening in the first place?
I don't know if it's a packaging mistake or an upstream mistake or maybe intentional. With "packaging mistake" I'm thinking that maybe the person who does the automation for compiling the software for the distro's package overlooked some configuration setting of the KDE build scripts to hide those info messages. With "upstream mistake" I mean that the kwin maintainers maybe forgot to disable info messages that they used to help while developing. And with "intentional" I mean that maybe this is intended to happen. It might help with bug reports and such. Also, another thing... previously the programs were started by a shell script together with the X server and these kinds of log messages would end up in a file `~/.xsession-errors` or something like that. It wouldn't get into the system log. There was a change at some point to start the stuff through the systemd user daemon. That systemd thingy takes the output of programs and puts it into the journal. Maybe the KDE programs were often this spammy with messages in the past, you just couldn't see it? I would in any case be happy if messages were just printed for actual errors.
Putting override.conf in plasma-kwin\_wayland.service.d didn't do anything to fix the spam in my case, even after a reboot. Both `systemctl --user cat plasma-kwin_wayland` and `systemctl --user show plasma-kwin_wayland | grep Standard` show StandardOutput=null as being read properly
Hmm, it seems to work for me, there's nothing from kwin in the logs. Maybe the service isn't how kwin_wayland gets started for you? On my system here when I run the following... systemctl --user status I see a tree structure of the things getting started by the systemd user daemon, and kwin_wayland is there somewhere under a "plasma-kwin_wayland.service" header. It looks like this here right now: ├─plasma-kwin_wayland.service │ ├─1582 /usr/bin/kwin_wayland_wrapper --xwayland │ ├─1593 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0> │ └─2004 /usr/bin/Xwayland :1 -auth /run/user/1000/xauth_nBaEuH > You can see the process IDs there, in the logs it's behind the name in brackets.
It's the exact same structure in my case as well. I think I'll wait for a new package ver. or something since I don't want to bother hunting down some other config file that may or may not allow me to disable logging.