Created attachment 150375 [details] native resolution SUMMARY When using a screen with an arguably _non-standard_ (or should I say _not-so-common_) resolution, screen sharing is pretty much broken on Chromium-based browsers. The "recording stream" looks glitchy and borked, for some reason. This didn't happen in Plasma 5.24.x, though. Please see pictures attached. Strangely enough, things work great on Firefox and OBS, but this wasn't broken in Plasma 5.24. Things also work if I scale back to a rather more common resolution, i.e. 2560x1080, 1920x1080, etc. In fact, I'm only able to reproduce the bug using my monitor's native resolution (3440x1440). STEPS TO REPRODUCE 1. Use any website that allows you to record your screen (zoom, jitsi, screenapp.io, etc). OBSERVED RESULT The captured stream looks glitchy, with lots of artifacts. Almost as if the computer were having GPU issues. EXPECTED RESULT No glitches or screen artifacts in the recorded stream. SOFTWARE/OS VERSIONS Linux Version: 5.15.2 Note: This doesn't seem to be a kernel issue, since I am able to reproduce the same behavior in kernel versions 5.15.x - 5.18.x. --- KDE Plasma Version: 5.25.2-1 --- KDE Frameworks Version: 5.95.0-2 --- Qt Version: 5.15.5+kde+r166-1 ADDITIONAL INFORMATION - I'm using my laptop's integrated graphics (Intel 8th gen U-series CPU). It has no issue driving the 2k screen - I'm pretty sure this is not a driver/mesa issue since I was unable to reproduce the same issue on GNOME 42 + same chromium release - I tried using older chromium releases (pre 103.x) to no avail - I did enable pipewire support in chrome://flags - I'm able to reproduce the same behavior using Flathub's Chromium, Brave, Arch's Chromium and ungoogled-chromium as well - I tried forcing Chromium's VAAPI support to see if it was a hardware-accel related issue, but that doesn't seem to be the case. - It looks like Chromium fails to call GetVSyncParametersIfAvailable() but ONLY when I use my display's native resolution. No such thing happens when I use smaller display resolutions. Maybe kwin is failing to provide some necessary info?
Created attachment 150376 [details] native resolution, no VAAPI/hw accel hacks
Created attachment 150377 [details] smaller resolution, everything works just fine
A couple of things worth noting: 1. None of what I mentioned above of below happens on Xorg (lol) 2. Firefox does seem to be broken as well, but not as badly as Chromium. This might deserve a bug report on its own, but here's a TL;DR of what happens when I try to test screen sharing using https://mozilla.github.io/webrtc-landing/gum_test.html : - The portal dialog shows up as usual asking me to pick a screen - I can see my screen in the miniature preview, but the preview remains frozen shortly after clicking the OK button in the portal dialog - Clicking the Pause/Play button will unfreeze the preview and things will work as expected - CPU usage goes brrrrr, with Firefox using about 60% of a CPU core and kwin_wayland using an entire CPU core. This doesn't happen with Chromium - My display's refresh rate drops to ~24 FPS with Firefox (it's a 75Hz display). I tried lowering the resolution but I still see a massive FPS drop on Wayland. This doesn't happen on Chromium, though - None of this happens on Xorg as well. CPU usage remains consistently low (no more than 20% core usage on both Chromium and FF), and no FPS drops either. 3. This also happens when using either DP or HDMI. Please let me know which logs you need, and/or the instructions to get you all the info needed to sort this out. :)
Seems to be a bug in webrtc that recently , which is shared by both firefox and chromium: https://webrtc-review.googlesource.com/c/src/+/265384 Can you test if you also have this problem with OBS?
Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1333304 It is fixed in Chrome/Chromium 105.
(In reply to Aleix Pol from comment #4) > Seems to be a bug in webrtc that recently , which is shared by both firefox > and chromium: https://webrtc-review.googlesource.com/c/src/+/265384 > > Can you test if you also have this problem with OBS? (In reply to Aleix Pol from comment #4) > Seems to be a bug in webrtc that recently , which is shared by both firefox > and chromium: https://webrtc-review.googlesource.com/c/src/+/265384 > > Can you test if you also have this problem with OBS? I just tested with OBS and everything works just fine (yay!). However, this bug is kinda weird because I was unable to replicate the same issue on GNOME (with all the latest updates as of yesterday). All these bug reports seem to indicate this issue only happens on KDE, though there's one comment about someone using NixOS + GNOME having the same issue.