Bug 488941

I should have added, I have no issue login in into a Plasma X11 session.

After deleting ~/.config/kwinoutputconfig.json, I could login. I did some tests and the issue happens when HDR is enabled. In the config file that put "highDynamicRange" and "wideColorGamut" to "true". Just changing "highDynamicRange" to "false" doesn't work, but if I put both to "false", I can login again.

So if you enable HDR while in the session, that works, and only if you log in with HDR already enabled, it fails?

I am having the same issue. I enable HDR and try to reboot I get the No Signal screen when login into a Wayland session. Also unable to switch TTYs.
Changing "highDynamicRange" and "wideColorGamut" to "false" in the kwinoutputconfig.json and making the file immutable allowed me to log back into the Wayland session.

(In reply to Zamundaaa from comment #3)
> So if you enable HDR while in the session, that works, and only if you log
> in with HDR already enabled, it fails?

Yes. I can enable HDR once I login without issue and the screen does switch to HDR mode. But if I let it enabled and I reboot, I get "No Signal".

I also starting having this on Arch/Nvidia 550 when KDE updated to 6.1 in the `extra` repo.

Relevant `journalctl` output:

Repeated:

>Jun 20 17:03:07 gogeta kwin_wayland[2604]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
>Jun 20 17:03:07 gogeta kwin_wayland[2604]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"

Followed by single:

> Jun 20 17:03:07 gogeta kwin_wayland[2604]: kwin_wayland_drm: Checking test buffer failed!
> Jun 20 17:03:07 gogeta kwin_wayland[2604]: kwin_core: Applying output config failed!

Issue exists under every permutation of [NVIDIA DRM](https://wiki.archlinux.org/title/NVIDIA#DRM_kernel_mode_setting).

>    OS: Arch Linux x86_64
>    Host: X570S I AORUS PRO AX (-CF)
>    Kernel: Linux 6.9.6-arch1-1
>    Uptime: 15 hours, 28 mins
>    Packages: 970 (pacman)
>    Shell: bash 5.2.26
>    Display (AW3225QF): 3840x2160 @ 120Hz (HDMI 2.1)
>    DE: KDE Plasma 6.1.0
>    WM: KWin (X11)
>    WM Theme: Breeze
>    Theme: Breeze (Dark) [QT], Breeze-Dark [GTK2], Breeze [GTK3/4]
>    Icons: breeze-dark [QT], breeze-dark [GTK2/3/4]
>    Font: Noto Sans (10pt) [QT], Noto Sans (10pt) [GTK2/3/4]
>    Cursor: breeze (24px)
>    Terminal: yakuake 24.05.1
>    CPU: AMD Ryzen 5 5600 (12) @ 3.50 GHz
>    GPU: NVIDIA GeForce RTX 4070 SUPER [Discrete]

Have just been leaving HDR off until it's resolved, and X11 for gaming until official NVIDIA driver update for explicit sync.

Also, same behavior as submitter:

1. Backup .config/kwinoutputconfig.json
2. Enable HDR in Wayland session (nothing else) everything works fine during that session.  
3. Reboot or re-log and I get:

w/o nvidia  in initramfs & nvidia_drm.modeset=1 and nvidia_drm.fbdev=1 
> Black screen w/white cursor

w/nvidia  in initramfs & nvidia_drm.modeset=1 and nvidia_drm.fbdev=1
> No signal to display

4. Login to X11 session and restore .config/kwinoutputconfig.json
5. Reboot/re-log into Wayland session; everything fine again (HDR off)

I am also experiencing the exact same problem and have found the same temporary solution to work.

Same problem here, though I had to make kwinoutputconfig.json read only for Plasma to start in Wayland

Same issue with nvidia 555.58 driver and the following:

Operating System: Arch Linux 
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 32 × 13th Gen Intel® Core™ i9-13900KS
Memory: 62.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3090 Ti/PCIe/SSE2

Deleting '~/.config/kwinoutputconfig.json' temporarily fixes the issue.

I haven't been able to reproduce this issue with driver 555.58 with a laptop rtx 3060 myself. Is it 100% reproducible for you, or does it only happen sometimes?

(In reply to Zamundaaa from comment #11)
> I haven't been able to reproduce this issue with driver 555.58 with a laptop
> rtx 3060 myself. Is it 100% reproducible for you, or does it only happen
> sometimes?

Nvidia 555 hit the `extra` repo (Arch) a couple days ago and the Issue is not happening for me on this driver (555.58).  It was happening 100% of the time on 550.90.

I can confirm, upgrading to Nvidia 555.58 and a reboot fixed the bug for me. I can start KDE / Plasma with HDR enabled and everything starts correctly without needing to hack a conf file.

Great! Probably just a weird driver bug then

Hi,

I can still reproduce this after just having upgraded the nvidia drivers from 555.58 to 555.58.02. I have `nvidia-drm.modeset=1` and `nvidia-drm.fbdev=1`. When I start into the Wayland session from SDDM with HDR enabled, I loose all display output and switching to a different tty no longer works. I can boot up to SDDM, switch to a different tty, disable HDR in `~/.config/kwinoutputconfig.json` and then just start the Wayland session no problem. Also enabling HDR when already in the session works.

Operating System: EndeavourOS 
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-9700K CPU @ 3.60GHz
Memory: 31.2 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2080/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: Z390 AORUS MASTER

(In reply to Kai from comment #15)
> Hi,
> 
> I can still reproduce this after just having upgraded the nvidia drivers
> from 555.58 to 555.58.02. I have `nvidia-drm.modeset=1` and
> `nvidia-drm.fbdev=1`. When I start into the Wayland session from SDDM with
> HDR enabled, I loose all display output and switching to a different tty no
> longer works. I can boot up to SDDM, switch to a different tty, disable HDR
> in `~/.config/kwinoutputconfig.json` and then just start the Wayland session
> no problem. Also enabling HDR when already in the session works.
> 
> Operating System: EndeavourOS 
> KDE Plasma Version: 6.1.1
> KDE Frameworks Version: 6.3.0
> Qt Version: 6.7.2
> Kernel Version: 6.9.7-arch1-1 (64-bit)
> Graphics Platform: Wayland
> Processors: 8 × Intel® Core™ i7-9700K CPU @ 3.60GHz
> Memory: 31.2 GiB of RAM
> Graphics Processor: NVIDIA GeForce RTX 2080/PCIe/SSE2
> Manufacturer: Gigabyte Technology Co., Ltd.
> Product Name: Z390 AORUS MASTER

I just verified that I have the same Nvidia kernel flags enabled as you, Pacman says 555.58-2 installed. Nvidia tools ( nvidia-smi, nvidia-settings ) both say 555.58 ( no .2 on the end ), so I'm not sure which to tell you exactly. I am also running EndeavourOS. I am also using the same kernel as you. The only difference I could possibly think is that I had the LTS kernel installed from reading a different solution and removed it right before the system upgrade. Other than that, I have been having perfect results, surviving a reboot, and now it is also surviving turning off my hdmi tv for lengths of time and coming back without a session restart. I'm using an RTX 3060, I'm a Ryzen 5, I am on the same version of Plasma, Frameworks, and QT as you as well. Have you tried to create a new user, separate from you main, to isolate that it isn't something else in your confs that might also be triggering this?

This is also happening to me on any 555.58.x driver, although my primary display is black on Wayland or X11 not just on Wayland. If I back down to 550.90.07, it's fine under X11. Wayland is iffy on that version for me.

Operating System: EndeavourOS 
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 16 × 11th Gen Intel® Core™ i9-11900K @ 3.50GHz
Memory: 62.6 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3070 Ti/PCIe/SSE2
Manufacturer: ASUS

I can still reproduce the issue after upgrading the Nvidia driver to 555.58.02 (and fully up to date ArchLinux). I get the same behavior and the exact same kind of error messages: 

juil. 04 05:13:16 galeanthrope-mini kwin_wayland[1404]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
juil. 04 05:13:16 galeanthrope-mini kwin_wayland[1404]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"

For me the issue can be reproduced 100% of the time. If I have the wrong configuration (HDR enabled), I get "No Signal" every time. When I want to go back to a good configuration, I do like Kay and switch to a TTY while I'm still at the SDDM screen.

Can confirm with the lastest nvidia drivers (nvidia 555.58.02-1) in arch this problem still exists. If HDR is enabled on boot the GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT errors still occur under wayland session.

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

Can confirm that the bug is still there. 
I have the Nvidia driver 555.58.02
KDE Plasma 6.1.2
OS is up to date.

After login to KDE 6.1.2 + Wayland both monitors go into standby when HDR is activated. After deleting the file "~/.config/kwinoutputconfig.json" the login is possible. HDR is then deactivated.

This only started happening to me on the Nvidia driver 555.58.02 upgrade. Using Fedora/KDE 40 (KDE is at 6.1.1) and did the driver upgrade last night (from stable).

Changing the "highDynamicRange" and "wideColorGamut" to "false" in ~/.config/kwinoutputconfig.json did the fix for me. If I set the HDR back on again and restart, it gives me a black screen again, so it seems I would have to be disabling HDR before logout/restart every time.

I managed to trigger this issue by making atomic commits fail in a development build; in that case at least the OpenGL errors were just a consequence of the problem, but not the cause or even related to it.

Could someone affected please follow https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues to get a drm debug log of KWin failing to enable the screen? If the issue is similar, it should reveal the source of the problem.

Created attachment 171517 [details]
drm-debug.log

I'm able to reproduce this easily and it's been happening to me since I setup Fedora 40 recently. 
KDE 6.0-6.1.1, Nvidia stable 550 - beta 555.58.02

My main screen is HDR and my secondary is SDR. When enabling HDR my main screen stops getting input and my secondary freezes completely, unable to access the terminal. So a hard reset is required.

Zamundaaa, I got a DRM log of the issue. It's huge, but hopefully it's of some use.

Also, first time contributing to a bug report here, so hopefully I'm attaching this correctly.

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

Thanks, sadly it just says
> [   74.508990] nvidia 0000:01:00.0: [drm:drm_atomic_check_only] atomic driver check for 0000000025e12e2d failed: -22
with all the logs about the checks being successful.

I looked a bit through the open NVidia driver and couldn't find anything that would be responsible. As it looks like KWin's doing everything right, I'll hand this problem over to NVidia now.

Pretty sure this is a driver issue, it happens when switching refresh rate as well. 
i've got 4x4k@144hz, kwin runs fine on 60hz with hdr disabled but as soon as i switch one of the screens to 144hz, screens freeze and log is full of   

kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"

i have to reset ~/.config/kwinoutputconfig.json and kill sddm to get back to normal

Finally found this issue... Struggling with this for quite some time after I tried the 555 beta driver to finally be able to get to Wayland , fixed the explicit sync issue and can use HDR... But sadly it's still broken... I did reinstalled fedora 40 spin because I didn't looked carefully before and found the hints that led me to this thread... 🤦🏻‍♂️

I can only confirm right now after enabling HDR and ah restart it's only black screen and after ah few seconds the system looks like to freeze for me... I can't change tty and I can only hard reset the system...

I did managed to even break SDDM when applying the plasma settings to SDDM... Then youve to clean out the kwinoutputconfig.json from the sddm .config folder... 

Changing my refresh rate didn't break it.. at least I use gysync and have 120Hz default and it's serving the reboot with this setting!

looks like 120Hz seem to work on my system! 144Hz still doesn't.

fwiw i'm on latest plasma, nvidia-dkms 555.58.02-1 (tried nvidia-beta-dkms too but they are probably the same version atm)

nvidia_drm.modeset=1 nvidia_drm.fbdev=1 nvidia.NVreg_EnableGpuFirmware=0 nvidia.NVreg_PreserveVideoMemoryAllocations=1
( don't think the kernel args matter tbh)

2 thoughts again from my side....

it does work when changing the setting manually and applying the configuration... the screen changes the input... mine also displays as small info box where i can see it switches to HDR output (this does never happen after ah reboot)

but basically why is it even working when done manually? is it because before it was disabled? because event then it just don't line up.. when you didn't apply the settings to sddm, sddm itself is coming up fine without HDR, and after login it would/should switch to HDR Output almost the same as when you enable it manually?? whats the difference there?

and is there ah possible workaround? is there any command available to enable/disable HDR so we might can add this so session logon/logoff (through SDDM?), so on logoff HDR gets disabled by ah command, and after logon it gets enabled again?

(In reply to Stephan from comment #32)
> 2 thoughts again from my side....
> 
> it does work when changing the setting manually and applying the
> configuration... the screen changes the input... mine also displays as small
> info box where i can see it switches to HDR output (this does never happen
> after ah reboot)
> 
> but basically why is it even working when done manually? is it because
> before it was disabled? because event then it just don't line up.. when you
> didn't apply the settings to sddm, sddm itself is coming up fine without
> HDR, and after login it would/should switch to HDR Output almost the same as
> when you enable it manually?? whats the difference there?
> 
> and is there ah possible workaround? is there any command available to
> enable/disable HDR so we might can add this so session logon/logoff (through
> SDDM?), so on logoff HDR gets disabled by ah command, and after logon it
> gets enabled again?

Try this (you'll need to install yq):
```
fix-kwin.sh:

#!/bin/sh
~/bin/yq -iP '.[0].data[0].highDynamicRange = false | .[0].data[0].wideColorGamut = false'  ~/.config/kwinoutputconfig.json
```

issue goes back to september and has an internal tracking number so they probably are aware of it https://forums.developer.nvidia.com/t/external-monitor-freezes-when-using-dedicated-gpu/265406/21

Could someone here record a drm debug log of enabling HDR while in the session? Maybe there's some difference vs. when logging in

My log was taken with HDR enabled in the OS and HDR disabled on my monitor initially. I logged in normally, then enabled HDR on my monitor to trigger the freeze.

If I start with it disabled in the OS, then enable it, it doesn't freeze but the colors are all washed out. I suspect it's not putting the monitor in the correct mode, so I restart my monitor and it freezes.

It looks like editing kwinoutputconfig.json while the system is running doesn't work, so I need to boot another OS to disable HDR in the config. Do you want me to get another log with HDR disabled initially?

You can edit the grub bootline... Just add ah 3 behind and you'll boot without GUI (to run level 3 only) and you can edit the file and then boot normally or just enter "init 5" to load the GUI :)

Please don't change the bug status.

(In reply to noahblaker333 from comment #36)
> If I start with it disabled in the OS, then enable it, it doesn't freeze but
> the colors are all washed out. I suspect it's not putting the monitor in the
> correct mode, so I restart my monitor and it freezes.
The colors being wrong is a different NVidia driver bug (see bug 482780).

> It looks like editing kwinoutputconfig.json while the system is running
> doesn't work, so I need to boot another OS to disable HDR in the config.
You can edit/delete/rename the file from the tty to disable it.

> Do you want me to get another log with HDR disabled initially?
Yes, I want the debug logging for what the driver does when you enable HDR while you're already logged in. Evidently that does *something* different from when you log in with HDR already enabled, otherwise it would also hang.

Created attachment 171748 [details]
DRM debug log

Here's a fresh log. It's ~8MB which is over the upload limit here so it's compressed.
- Started with HDR disabled in OS, Enabled on monitor
- Logged in and enabled HDR in OS
- Colors are incorrect, turned off monitor and turned back on
- System freezes after monitor turns on

This still occurs on the latest beta 560 driver.

Interestingly another user on the nvidia forum found if you enable HDR via kscreen-doctor, it works fine. I tried this myself and it seems to be stable.

https://forums.developer.nvidia.com/t/560-release-feedback-discussion/300830/156

(In reply to noahblaker333 from comment #40)
> This still occurs on the latest beta 560 driver.
> 
> Interestingly another user on the nvidia forum found if you enable HDR via
> kscreen-doctor, it works fine. I tried this myself and it seems to be stable.
> 
> https://forums.developer.nvidia.com/t/560-release-feedback-discussion/300830/
> 156

thx for the information, interesting finding.. 
btw. i would also reccoment to enable the "wide color gamut mode" -> kscreen-doctor output.xxxx.wcg.enable

this changes the colors also somewhat, i would say not that much washed out then without it... but i would have to compare to windows with the same test pictures/video to check really what the difference in color grading/shading/warmth

nope... still the same issue for me.. after rebooting only black display! 
strangely in the nvidia forum the talked about HDR is disabled in plasma settings after the kscreen-doctor command.. not for me.. its enabled there then.. 

haaaaa... i just double checked whats happening while i was writing this post... and apparently, setting the wide color gamut mode to enable with kscreen-doctor, it also gets enabled in plasma settings! without this, just the HDR enable command/parameter doesnt't enable it in the UI settings...

so the black screen hast to be related to the wcg setting!

I'm seeing the same issue on openSUSE Tumbleweed with latest Nvidia drivers, even with HDR and wide color gamut disabled and refresh rate set to 60Hz. GPU is a mobile 4080.

(In reply to Stephan from comment #42)
> nope... still the same issue for me.. after rebooting only black display! 
> strangely in the nvidia forum the talked about HDR is disabled in plasma
> settings after the kscreen-doctor command.. not for me.. its enabled there
> then.. 
> 
> haaaaa... i just double checked whats happening while i was writing this
> post... and apparently, setting the wide color gamut mode to enable with
> kscreen-doctor, it also gets enabled in plasma settings! without this, just
> the HDR enable command/parameter doesnt't enable it in the UI settings...
> 
> so the black screen hast to be related to the wcg setting!

Can confrim for me it's stable with HDR enabled, but unstable with WCG enabled.

I can confirm this behavior with separate HDR/WCG settings.
- both disabled: Plasma starts
- HDR enabled and WCG disabled: Plasma starts
- HDR disabled and WCG enabled: no output to screen
- both enabled: no output to screen

Same problem across multiple distros running KDE6.  Once I turn on HDR, I am no longer able to return to Wayland until I disable it after boot but before login.

Encountering this same issue. Cannot enable HDR without Wayland completely dying on reboot. Without HDR everything works fine.

Latest drivers, using 144hz display.

Has there been any development on this? I'm still unsure if this is a KDE issue or an Nvidia issue, and I haven't seen any acknowledgement from Nvidia on this.

Can we rule out GPU vendors either? I have a ASUS TUF 4080 super. Hoping we can build some kind of correlation because it seems like HDR works fine for some people.

Sorry for reviving this thread without any new information, but I'm hoping to make some discussion to keep this issue alive.

The NVidia driver rejects the atomic commit without any debug output, so I can only assume it's a driver bug.

(In reply to noahblaker333 from comment #48)
> Can we rule out GPU vendors either? I have a ASUS TUF 4080 super. Hoping we
> can build some kind of correlation because it seems like HDR works fine for
> some people.
If you mean the board partners, that's not relevant. Driver and firmware versions could make a difference, the hardware generation could as well.

I am having the same issue. Nvidia 3080 Ti - driver version 560.35.03 and an Alienware AW3423DWF for my monitor. Tried the potential fixes in this post to no avail. 

With HDR mode on in my monitor, when I boot my monitor gets no signal. I have to reboot the machine and turn HDR off for it to display an image. I don't know if its just me, but when I do get in and turn on HDR the colors look a bit odd? I dual-boot Windows and HDR looks very very different there. Probably not related to this bug, but...

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6483

Please do not change the status of this bug. This is a driver problem, and except for disabling the functionality entirely in KWin (which the linked MR does), there is nothing we can do.

(In reply to Ralphie from comment #50)
> when I do get in and turn on HDR the colors
> look a bit odd? I dual-boot Windows and HDR looks very very different there.
> Probably not related to this bug, but...
That is a known problem, and also a driver bug :/

Can confim this bug is still present, the status shouldn't have been changed to resolve yet in my opinion

"Resolved" doesn't mean it's fixed, it means there's nothing to do for us here.

Git commit 67d9529951147d2ca9aeaf483b3e6ba2714ae2c5 by Xaver Hugl.
Committed on 25/09/2024 at 12:56.
Pushed by zamundaaa into branch 'master'.

backends/drm: block the colorspace capability by default on NVidia

There have been many reports that enabling HDR on NVidia can lead to KWin's atomic commits
being rejected on login, which means KWin can't display anything. To prevent users from
falling into that trap, this commit disables the colorspace capability unless the
KWIN_DRM_ALLOW_NVIDIA_COLORSPACE=1 environment variable is set.
This commit should be reverted once the driver problem causing the issue has been fixed.

M  +8    -1    src/backends/drm/drm_output.cpp

https://invent.kde.org/plasma/kwin/-/commit/67d9529951147d2ca9aeaf483b3e6ba2714ae2c5

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6497

Git commit a20669a56e3e0998fe226882593608fa83fa8d26 by Xaver Hugl.
Committed on 25/09/2024 at 14:15.
Pushed by zamundaaa into branch 'Plasma/6.2'.

backends/drm: block the colorspace capability by default on NVidia

There have been many reports that enabling HDR on NVidia can lead to KWin's atomic commits
being rejected on login, which means KWin can't display anything. To prevent users from
falling into that trap, this commit disables the colorspace capability unless the
KWIN_DRM_ALLOW_NVIDIA_COLORSPACE=1 environment variable is set.
This commit should be reverted once the driver problem causing the issue has been fixed.


(cherry picked from commit 67d9529951147d2ca9aeaf483b3e6ba2714ae2c5)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +8    -1    src/backends/drm/drm_output.cpp

https://invent.kde.org/plasma/kwin/-/commit/a20669a56e3e0998fe226882593608fa83fa8d26

Am i reading the commit request correctly and that the HDR option will be disabled for now until the driver bug is fixed unless an env var is set? Just want to confirm steps i need to do to enable hdr. Currently im just disabling on shutdown and re enabling when logging in.

(In reply to kde.vintage958 from comment #58)
> Am i reading the commit request correctly and that the HDR option will be
> disabled for now until the driver bug is fixed unless an env var is set?
> Just want to confirm steps i need to do to enable hdr. Currently im just
> disabling on shutdown and re enabling when logging in.

I was thinking about doing similar, it works without issues?
Can you throw your script up on a gist?

Ive personally tried enabling a script but kde seems to have no cli method of enabling and disabling the use of hdr annoyingly. So its just a simple change to my change of process in remembering to do it each time
Obviously if its that flag that needs enabling to enable hdr then just add that to a bash profile hopefully will work, or just add to a script for startup

(In reply to kde.vintage958 from comment #60)
> Ive personally tried enabling a script but kde seems to have no cli method
> of enabling and disabling the use of hdr annoyingly. So its just a simple
> change to my change of process in remembering to do it each time
> Obviously if its that flag that needs enabling to enable hdr then just add
> that to a bash profile hopefully will work, or just add to a script for
> startup

I thought about creating a script that disables HDR on boot, and enables it on Login.  But not sure if it would work out.

(In reply to kde.vintage958 from comment #58)
> Am i reading the commit request correctly and that the HDR option will be
> disabled for now until the driver bug is fixed unless an env var is set?
> Just want to confirm steps i need to do to enable hdr. Currently im just
> disabling on shutdown and re enabling when logging in.
Yes. You just need to set the env var for KWin, then the HDR option will appear again.

(In reply to Zamundaaa from comment #62)
> (In reply to kde.vintage958 from comment #58)
> > Am i reading the commit request correctly and that the HDR option will be
> > disabled for now until the driver bug is fixed unless an env var is set?
> > Just want to confirm steps i need to do to enable hdr. Currently im just
> > disabling on shutdown and re enabling when logging in.
> Yes. You just need to set the env var for KWin, then the HDR option will
> appear again.

Okay perfect thanks for clarifying, will add that env var when its needed

(In reply to Zamundaaa from comment #62)
> (In reply to kde.vintage958 from comment #58)
> > Am i reading the commit request correctly and that the HDR option will be
> > disabled for now until the driver bug is fixed unless an env var is set?
> > Just want to confirm steps i need to do to enable hdr. Currently im just
> > disabling on shutdown and re enabling when logging in.
> Yes. You just need to set the env var for KWin, then the HDR option will
> appear again.

Would you set this in your profile, and it would effectively be disabled until login?
Can this be used to use HDR but have it disabled until after you login to Wayland?
My gut is telling me it's going to be ages if ever that nvidia fixes it upstream.

(In reply to Zack from comment #64)
> (In reply to Zamundaaa from comment #62)
> > (In reply to kde.vintage958 from comment #58)
> > > Am i reading the commit request correctly and that the HDR option will be
> > > disabled for now until the driver bug is fixed unless an env var is set?
> > > Just want to confirm steps i need to do to enable hdr. Currently im just
> > > disabling on shutdown and re enabling when logging in.
> > Yes. You just need to set the env var for KWin, then the HDR option will
> > appear again.
> 
> Would you set this in your profile, and it would effectively be disabled
> until login?
> Can this be used to use HDR but have it disabled until after you login to
> Wayland?
> My gut is telling me it's going to be ages if ever that nvidia fixes it
> upstream.

Potentially could be a way around yes, on login youd still need to tick the box but maybe by having the option not enabled as an env var until after login, the hdr option is off. Itd require some testing to see if that theory works.
Annoyingly theres no way to interact with that setting other then gui

(In reply to kde.vintage958 from comment #65)
> (In reply to Zack from comment #64)
> > (In reply to Zamundaaa from comment #62)
> > > (In reply to kde.vintage958 from comment #58)
> > > > Am i reading the commit request correctly and that the HDR option will be
> > > > disabled for now until the driver bug is fixed unless an env var is set?
> > > > Just want to confirm steps i need to do to enable hdr. Currently im just
> > > > disabling on shutdown and re enabling when logging in.
> > > Yes. You just need to set the env var for KWin, then the HDR option will
> > > appear again.
> > 
> > Would you set this in your profile, and it would effectively be disabled
> > until login?
> > Can this be used to use HDR but have it disabled until after you login to
> > Wayland?
> > My gut is telling me it's going to be ages if ever that nvidia fixes it
> > upstream.
> 
> Potentially could be a way around yes, on login youd still need to tick the
> box but maybe by having the option not enabled as an env var until after
> login, the hdr option is off. Itd require some testing to see if that theory
> works.
> Annoyingly theres no way to interact with that setting other then gui

You can modify it via ~/.config/kwinoutputconfig.json, this is how I went about fixing it so I can login again.  I was thinking I would set it to disable HDR on boot, then once login, have it change it, but I don't know what I'd need to do to get it to re-read the config on change though, but both highDynamicRange & wideColorGamut has to be false to be able to log into Wayland.

(In reply to Zack from comment #64)
> Would you set this in your profile, and it would effectively be disabled
> until login?
> Can this be used to use HDR but have it disabled until after you login to
> Wayland?
> My gut is telling me it's going to be ages if ever that nvidia fixes it
> upstream.

No, it can't be changed at runtime. If you want to make some script to disable it before logout, and enable it again after login, you can do that, but we won't include such workarounds in KWin. The risk of causing session  breaking issues is too high.

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

This looks to be resolved by Nvidia's beta 565.57.01 driver. I was able to enable HDR and log in/reboot freely. The image is also no longer washed out.

I only tested it briefly because the image is very unstable on my machine, the driver still needs some work. It could also be because I installed with the .run file, as it looks like it's not packaged for fedora 40 yet.

(In reply to noahblaker333 from comment #69)
> This looks to be resolved by Nvidia's beta 565.57.01 driver. I was able to
> enable HDR and log in/reboot freely. The image is also no longer washed out.
> 
> I only tested it briefly because the image is very unstable on my machine,
> the driver still needs some work. It could also be because I installed with
> the .run file, as it looks like it's not packaged for fedora 40 yet.

I noticed this as well, I am looking forward to it coming to arch.  I thought this was going to be ages to have a resolution.

With fedora 41 recently shipping 565.57.01 by default , I also tested this. I can confirm this isn't happening to me, but I didn't test if I had the issue in the first place.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6778

Git commit cb9d538948302134d760bfdc632930179f5133b7 by Xaver Hugl.
Committed on 15/11/2024 at 14:08.
Pushed by zamundaaa into branch 'master'.

backends/drm: re-allow HDR on NVidia with driver version 565.57.01+

The bug that made me disable it by default was fixed in that version

M  +16   -5    src/backends/drm/drm_gpu.cpp
M  +3    -0    src/backends/drm/drm_gpu.h
M  +1    -1    src/backends/drm/drm_output.cpp

https://invent.kde.org/plasma/kwin/-/commit/cb9d538948302134d760bfdc632930179f5133b7

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6782

Git commit c37a17f0bc2d544c151875071058e6f1fcdfb6ef by Xaver Hugl.
Committed on 15/11/2024 at 14:27.
Pushed by zamundaaa into branch 'Plasma/6.2'.

backends/drm: re-allow HDR on NVidia with driver version 565.57.01+

The bug that made me disable it by default was fixed in that version


(cherry picked from commit cb9d538948302134d760bfdc632930179f5133b7)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +16   -5    src/backends/drm/drm_gpu.cpp
M  +3    -0    src/backends/drm/drm_gpu.h
M  +1    -1    src/backends/drm/drm_output.cpp

https://invent.kde.org/plasma/kwin/-/commit/c37a17f0bc2d544c151875071058e6f1fcdfb6ef