So today I clicked ‘enable HDR’ on one of my monitors and something broke. The whole system froze up and the HDR monitor went black. If I reboot it freezes right after I login.

If I unplug that monitor or start in X11 instead of Wayland then everything is fine. Plugging the HDR monitor in while I’m logged into a Wayland session also freezes everything.

How can I disable the HDR setting? The monitor doesn’t show in System Settings whilst its unplugged so I’m hoping theirs some way to fix it on the CLI. The only place I’ve found HDR referenced is .config/kwinoutputconfig.json. I set HDR to false but after reboot it’s set to true again. I also tried deleting .config/kwinrc and .local/share/kscreen but no luck.

I’m fine with just resetting all Display settings if that’s required.

----- UPDATE ------

Bug report filed here: https://bugs.kde.org/show_bug.cgi?id=485403

Fixed by

  • Ctrl + Alt + F3 to go into terminal
  • Set HighDynamicRange and WideColorGamut to false in ~/.config/kwinoutputconfig.json
  • Execute plasmashell --replace
  • Reboot, Login, Reattach HDR Monitor

Thank you everyone for your help 🎉

      • Dudewitbow@lemmy.zip
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        HDR for the most part, is a two way feature. must be enabled by driver/de as well as enabled on the monitor for it to in work, because its not always ideal to have local dimming enabled on monitor (one of the key components required for HDR)

      • SpacetimeMachine@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        My monitor AW2432DWF does allow you to turn off HDR, although it is a relatively recent monitor and my first HDR one, so I don’t know how common that is.

      • Zamundaaa@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

        Many monitors allow you to turn off HDR, they just claim they don’t support it to the computer when you do that

  • UnfortunateShort@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    8 months ago

    Not an answer, but maybe the KDE folks should add “and may seriously break things” to the “is experimental” warning next to HDR :D

    • setVeryLoud(true);@lemmy.ca
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      This is why GNOME hasn’t implemented it yet, they want to wait until it’s perfect and not experimental before adding the feature.

    • Zamundaaa@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 months ago

      Almost every output setting “may seriously break things” in my experience. Display drivers are sadly quite fragile

    • Russ@bitforged.space
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 months ago

      Since Plasma 6. Not sure about HDR wallpapers (never even heard of an “HDR Wallpaper”, so I’ve not looked into support for it), it should work with fullscreen videos though, and Steam games work if you run it through a nested gamescope session with a special HDR Vulkan layer installed.

      • Possibly linux@lemmy.zip
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

        I assume it will work for a live system? When Fedora 40 eventually comes out I’ll give it a try. I can’t stand to daily drive plasma unfortunately. (Gnome works better for me)

        Maybe if it works well I’ll run plasma on a media machine.

  • Rustmilian@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    8 months ago

    kscreen-doctor -o
    Then adjust the below command accordingly :
    kscreen-doctor output.1.hdr.disable

    Make sure you go open a bug report.

    • ByteBovine@lemmy.mlOP
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      The monitor does not display with kscreen-doctor -o as it’s disconnected.

      I will create a bug report.

      • Rustmilian@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        8 months ago

        I see you got it fixed.
        When you run hw-prope make sure your offending monitor is connected. hw-prope will help identify the monitor by hardware ID which is used in various areas like kernel space and will help with identifying the exact model of the problem monitor hopefully allowing for devs to reproduce the bug in a lab environment.

          • Rustmilian@lemmy.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            8 months ago

            Looking through the probe logs, and seeing that your monitor is using EISA bus and works fine without HDR, there doesn’t appear to be any issues on the Linux side of things. My guess is that they didn’t implement HDR on the monitors side exactly to spec and that’s where the problem resides. So, in this sense some monitor specific quirk fixup code is needed on the Linux side of things to get it working properly. If the devs ask any additional steps from you, be sure to do it and provide feedback.

  • Zamundaaa@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 months ago

    Changing the output config file should work, as long as KWin isn’t running while you make the change (in which case the change will just be overridden)