HDR Streaming Very Dark After Plasma 6.2 Update #3298
Comments
|
I have the same experience, but I my first guess would be that it's something on KWin side. Maybe issues such as these are related https://bugs.kde.org/show_bug.cgi?id=494502 In my case, host looks OK (but M28U is not the best display) but guest is just wrong (tested Moonlight on Android TV and Steam Deck). |
I figured it was a change on KWin, but maybe not a bug, but "max nits 100000" seems like a bug lol. I will try setting a max nits with kscreen and see if that at least works around it, otherwise, yeah, this def looks like a KWin bug that KDE needs to fix. |
|
I experienced this and thought it was me. As a workaround turning off HDR on moonlight returns things to normal it seems, but I'd really like to have it on! |
|
I played around with brightness ranges for kscreen-doctor a bit but that didn't do anything useful to the streamed image. I took a debug log which appears to simply pull the provided HDR gamut info from kwin and start, as it did before. I'm gonna sit on the log for the night (cause I don't feel like making a new account at 11:10 PM lol) and add probably add to that KDE bug report that @slagiewka linked in the morning. Can't hurt for them to have more information on the issue. |
|
I've checked back on that KDE bug report and it looks to me that its less a KDE bug than a normal change that reveals a bug in applications communicating metadata to Kwin. Plasma 6.1 ignored HDR metadata whereas Plasma 6.2 does not and their findings appear to show that applications were passing way out of whack HDR metadata to Kwin (10 million peak brightness, for example) causing the resulting image to come out exceptionally dark. The KDE devs have added a check for "obviously wrong HDR metadata" that should fix the issue in 6.2.1, so I'm hopeful that HDR streaming on Linux will be back to normal once that commit hits Fedora 40. Given that information, is it possible that Sunshine is doing the same thing when it runs the screen capture with KMS? KDE seems to have a fix of sorts going in, but it does seem that the true root cause of the issue is that applications are communicating extremely wrong metadata to Kwin. |
That didn't make the cut for 6.2.1. It should be in 6.2.2. It will be released on October 22nd. |
|
Closing this as there it seems there is nothing do on Sunshine side of things. If 6.2.2 doesn't resolve it, please let me know and I will re-open this. |
|
It seems 6.2.2 didn't fix the issue, I still get a very dark and saturated image on latest kwin when streaming to my Steam Deck or Tablet with HDR, downgraded to kwin 6.1.5 as a workaround. 6.1.99 has the same issue as 6.2.2 |
What OS are you running where you have 6.2.2 already? I'm on Fedora 41 (now) and I'm still on 6.2.1 and don't expect to see 6.2.2 until at least Sunday. |
Running Arch, plasma was updated today to 6.2.2 https://archlinux.org/packages/extra/x86_64/kwin/ |
|
KDE will not fix it: Question: is there any report yet? |
|
I've re-opened this, and opened a dedicated issue about migrating the capture protocol. #3327 |
|
I unfortunately have no coding skills, but I am a veteran sysadmin with a penchant for tinkering and testing so feel 100% free to tag me in any testing efforts required for the new capture protocol in either issue. |
Oh, I suppose coding is not a really hard skill. Commanding machines to work for you is really fun! Just take a little time to try it! |
|
I have the same issue in my software, gpu screen recorder. I didn't find a proper solution for it yet, but applying gamma correction (1.8) seems to fix it. Need a proper fix though. |
If the application you're using is also using kmsgrab (as Sunshine is) then the solution is going to have to be to switch to an interface that Wayland/KDE will support going forward. I believe the two main candidates are the pipewire portal (which I believe doesn't support HDR capture in Kwin yet) or the new Wayland screencopy portal (though I think merging of this feature is limited to wlroots for the moment). |
|
Hello do we still need to stay on KDE <= 6.2 for HDR streaming to work? |
and others
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
HDR streaming to HDR clients now produces an extremely dark image on the client that is not really usable after the recent Plasma 6.2 update that has come to Fedora over the past few days.
Expected Behavior
A normal HDR picture without black crush present.
Additional Context
I'm able to at least work around the issue by not streaming in HDR, so it's not showstopping. I have tested this on a Sep 30th build and the most recent lizardbyte/beta copr build that doesn't segfault (the version listed below).
Host Operating System
Linux
Operating System Version
Fedora Linux 40 (KDE Plasma)
Architecture
amd64/x86_64
Sunshine commit or version
2024.1006.230920-1
Package
Linux - Fedora Copr
GPU Type
AMD
GPU Model
AMD Radeon RX 7900 XTX
GPU Driver/Mesa Version
Mesa 24.1.7
Capture Method
KMX (Linux)
Config
wan_encryption_mode = 2 lan_encryption_mode = 2 key_rightalt_to_key_win = enabled origin_pin_allowed = lan resolutions = [ 1280x720, 1920x1080, 2560x1440 ] fps = [30,60,90,120,240] sunshine_name = EmpokNor channels = 2 #audio_sink = alsa_output.usb-M-Audio_AIR_192_4-00.analog-stereo #output_name = 2Apps
No response
Relevant log output
The text was updated successfully, but these errors were encountered: