Announcement

Collapse
No announcement yet.

GNOME's Mutter Lands Experimental Code For HDR Modes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GNOME's Mutter Lands Experimental Code For HDR Modes

    Phoronix: GNOME's Mutter Lands Experimental Code For HDR Modes

    Yesterday saw GNOME Shell and Mutter drop the last of their GTK3 dependence while today there is another interesting change to mention on the Mutter compositor side... An experimental option for enabling some HDR modes with supported high dynamic range displays...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I am very much looking forward to gnome 44...
    I may as well buy myself upgrade myself from 5700xt and get a new monitor that is not damaged...

    Comment


    • #3
      Too bad the monitor market is a shitshow. You want a 16:10 4K screen? Haha. Okay what about 16:10 with 120hz? Pfff.
      Everything 16:9, and the options are depressing.

      Comment


      • #4
        Originally posted by Alexmitter View Post
        Too bad the monitor market is a shitshow. You want a 16:10 4K screen? Haha. Okay what about 16:10 with 120hz? Pfff.
        Everything 16:9, and the options are depressing.
        I want an 30''+ 16:10 with 2k, good HDR and 120Hz as well.
        But there is no good option, apart form the very very expensive gaming monitors which are 800€+

        Comment


        • #5
          Why did they release this now and not wait for the hackfest, that is just one month away, where everyone discusses and agrees on something common?
          I find it strange to implement HDR before and then at the hackfest to use that as an excuse to have it your way saying that you already implemented it.
          I hope that this is just experimental and not a thing to push your way harder than others.

          Comment


          • #6
            Originally posted by Danny3 View Post
            Why did they release this now and not wait for the hackfest, that is just one month away, where everyone discusses and agrees on something common?
            I find it strange to implement HDR before and then at the hackfest to use that as an excuse to have it your way saying that you already implemented it.
            I hope that this is just experimental and not a thing to push your way harder than others.
            I think Sebastian Wick is quite competent in developing this, he does HDR / Colormanagement work in wayland as well since years.
            The aim of the color management extension is to allow clients to know the color properties of outputs, and to tell the compositor about the color properties of...


            i think they already have a good widely discussed protocol for wayland to do HDR and Colormanagement. So most of the design in mutter is already governt by the wayland protocol, which is a good thing IMHO as it avoid having 5000 implementation of color management done by the individual applications themself.

            Comment


            • #7
              being able to trigger HDR isn't really something promising, what we need from the protocol are for apps to be able to tell the compositor, what colorspace and gamma they are, their peak (dynamic HDR is going to be just phenomenal for compositors to handle). and then from there we need compositors to be able to do normalization and balancing as well as tonemapping.

              technically speaking, you could always probably just use whatever metadata the foreground app is doing or the brightest I guess, but that would be a terrible experience. normalization is also critically important. I highly recommend anyone who is interested in the topic watch the HDR colorgrading talk by Steve Robertson from last Demuxed. while it is primarily designed for content creators, he brings up issues that are very relevant to HDR compositor support.

              Comment


              • #8
                Originally posted by Danny3 View Post
                Why did they release this now and not wait for the hackfest, that is just one month away, where everyone discusses and agrees on something common?
                I find it strange to implement HDR before and then at the hackfest to use that as an excuse to have it your way saying that you already implemented it.
                I hope that this is just experimental and not a thing to push your way harder than others.
                I'm amazed by the ability some people have to turn good stuff into something negative.

                Comment


                • #9
                  Originally posted by Danny3 View Post
                  Why did they release this now and not wait for the hackfest, that is just one month away, where everyone discusses and agrees on something common?
                  I find it strange to implement HDR before and then at the hackfest to use that as an excuse to have it your way saying that you already implemented it.
                  I hope that this is just experimental and not a thing to push your way harder than others.
                  Looking at this positively instead, it could be a good Proof of Concept to kick-start discussions, it's clearly labeled experimental after all.
                  Same with how mutter implemented fractional scaling experimentally behind config switches and never exposed it to users, meanwhile they're now working on the new implementation using Wayland protocol.

                  Comment


                  • #10
                    Spacefish Alexmitter You can run a TV (or a big monitor) with centered timings for 16:10.

                    Comment

                    Working...
                    X