This is a strawman. There's a reason I mentioned color management in particular. Most people who aren't aware (even software developers) tend to make two assumptions:
- that color management is needed for a tiny subset of users (those weird guys with printers and calibrators...).
- that it can be delegated to 3rd parties or implemented later when the time comes.
Neither of that is true. Color management is just another word for correct rendering of everything that comes through your stuff. Every pixel must have a well defined path from the physical input to the application to the physical output, you can't just implement a part of it and move everything else out of scope. To display anything in HDR, you have to build your entire pipeline around color management from the ground up.
The reason you are ignoring it is that you're using an sRGB display, in any other case it would be immediately apparent to you. sRGB also needs color management but everything assumes sRGB so you're able to mostly get away with it. This no longer holds in the modern hardware. You need a properly managed pipeline for gaming, movies, web, YouTube, GUI, smartphone family photos, and basically everything else.
Wayland developers actually found it the hard way, and are trying to implement it for, what, 3 years? That this wasn't a feature of a display server protocol from the start is a massive design flaw.
Same with the input methods handling being forced to be lumped up together in the downstream software, without at least specifying how it should be done. They took a well understood problem, and moved it out of scope; it might not have been an issue, but the lack of a spec will lead to fragmentation and less options. This affects most of the userbase, not "weirdos with remote desktops".
The vast majority of linux desktop computer users are likely using sRGB displays to look at things in the sRGB colourspace.
Should colour management be in Wayland? Sure. Could it have been designed better to cater for it? Absolutely. Wayland's got its warts, sure. But for most people it's good enough, and that's what matters in software. It'll get fixed, and the more people who care about it actually contribute, the faster it'll get fixed. Open source is amazing!
- that color management is needed for a tiny subset of users (those weird guys with printers and calibrators...).
- that it can be delegated to 3rd parties or implemented later when the time comes.
Neither of that is true. Color management is just another word for correct rendering of everything that comes through your stuff. Every pixel must have a well defined path from the physical input to the application to the physical output, you can't just implement a part of it and move everything else out of scope. To display anything in HDR, you have to build your entire pipeline around color management from the ground up.
The reason you are ignoring it is that you're using an sRGB display, in any other case it would be immediately apparent to you. sRGB also needs color management but everything assumes sRGB so you're able to mostly get away with it. This no longer holds in the modern hardware. You need a properly managed pipeline for gaming, movies, web, YouTube, GUI, smartphone family photos, and basically everything else.
Wayland developers actually found it the hard way, and are trying to implement it for, what, 3 years? That this wasn't a feature of a display server protocol from the start is a massive design flaw.
Same with the input methods handling being forced to be lumped up together in the downstream software, without at least specifying how it should be done. They took a well understood problem, and moved it out of scope; it might not have been an issue, but the lack of a spec will lead to fragmentation and less options. This affects most of the userbase, not "weirdos with remote desktops".