[kwin] [Bug 467574] kwin_screencast: Dropping a screencast frame because the compositor is slow
https://bugs.kde.org/show_bug.cgi?id=467574 Paulo Marcos changed: What|Removed |Added Status|REPORTED|CONFIRMED Version|5.27.3 |5.27.5 Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 467574] kwin_screencast: Dropping a screencast frame because the compositor is slow
https://bugs.kde.org/show_bug.cgi?id=467574 --- Comment #13 from Paulo Marcos --- (In reply to Prajna Sariputra from comment #12) > Just patching out the QCWarning line does not resolve the problem of KWin > using 100% of a single core in my case, I have to either revert KWin to > 5.27.4.1 or revert commit 226d8c0a3b464f8870c45bfe5079f042a3cd5d67 > (screencast: Ensure we respect the negotiated framerate) on top of KWin > 5.27.5 to get that issue to go away. I reverted kwin to 5.27.4.1 on my system and confirmed: this fixes the 100% usage of a single core. While this problem is not fixed yet, i'm about to create a pull request to remove the kwin_wayland flood on 5.27 (doing the same way it's already fixed on master for plasma 6) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 467574] kwin_screencast: Dropping a screencast frame because the compositor is slow
https://bugs.kde.org/show_bug.cgi?id=467574 --- Comment #11 from Paulo Marcos --- (In reply to Paulo Marcos from comment #10) > and keeps flooding for more than ~200 messages PER SECOND, by just launching Also this makes me wonder about the "if (m_pendingBuffer)": Is this statement checking "m_pendingBuffer" as fast as the CPU can handle? If there's no sleep() or even something similar to prevent this, every dropped frame (m_pendingBuffer == true) will send a lot of "kwin_wayland[1197]: kwin_screencast: Dropping a screencast frame because the compositor is slow" to the journalctl and use 100% of a CPU core. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 467574] kwin_screencast: Dropping a screencast frame because the compositor is slow
https://bugs.kde.org/show_bug.cgi?id=467574 Paulo Marcos changed: What|Removed |Added CC||contato-myghi63@protonmail. ||com --- Comment #10 from Paulo Marcos --- THE PROBLEM: Recording the screen via OBS + Vaapi is pretty smooth even at 144fps here, but the main problem (flood from kwin_screencast) is even worse, because if I use my monitor at 144hz, kwin_wayland starts using 100% of a single core and keeps flooding for more than ~200 messages PER SECOND, by just launching OBS or sharing screen on any app. I also tried increasing rtkit priority of pipewire proccess on it's settings (pipewire.conf), but the problem still happens. POSSIBLE ROOT OF THE ISSUE: So I noticed a possible cause of this problem by looking at a patch from PortageStuff (URL at the bottom of this comment). First of all, m_pendingBuffer is being set to true very frequently for some reason (pipewire fault?), so for every single dropped frame, the if statement is executing the qCWarning comamnd, which can both stress a CPU core and cause all the flooding. SUGGESTED WORKAROUND/FIX: If possible, for every second doing the screencast, track how much frames has been dropped and compare it to the target FPS. If more than 60% of the frames are being dropped, then finally send the kwin_screencast warning, because in this specific case the screencast performance is significantly worse than it should! SOFTWARE/OS VERSIONS AND HARDWARE: Operating System: Arch Linux (Updated at 8 June, 2023) KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.3.6-zen1-1-zen (64-bit) Graphics Platform: Wayland Pipewire: 1:0.3.71-2 Wireplumber: 0.4.14-1 Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 31,3 GiB de RAM Graphics Processor: AMD Radeon RX 5500 XT PortageStuff's patch: https://github.com/FireBurn/PortageStuff/blob/53f540ce02d32c1e8e9f13f23e0fcd3b9205e96b/patches/kde-plasma/kwin/spam.patch#L9 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 433969] Unable to add ufw firewall rules with port ranges
https://bugs.kde.org/show_bug.cgi?id=433969 Paulo Marcos changed: What|Removed |Added CC||contato-myghi63@protonmail. ||com --- Comment #4 from Paulo Marcos --- I'm also having the same limitation with plasma-firewall 5.27.0-1 (Arch Linux) It's the same problem on both firewalld and ufw. I wanted to open 1714:1764 ports through plasma-firewall, but ended up doing that via CLI. -- You are receiving this mail because: You are watching all bug changes.
