Small in-window dialogs in QtQuick-based software have gotten a visual overhaul to remove everything not visually necessary, which gives the text and buttons more focus (Carl Schwan, Frameworks 6.3. Link 1 and link 2)
And the regression from last patch with drag and drop freezing Dolphin entirely seems unfixed. Honestly I think it’s the first time in 7 years I’m affected by an annoying KDE bug, but it still stings regressions are not first priority :(
On Wayland, KWin can now be configured to pull color profile information from the monitor’s EDID metadata where present. Note that color profile information in EDID metadata is often wrong, so use this setting with caution.
Can anyone speak towards why the EDID metadata is often wrong?
I don’t know about color profile data, but I can vouch for the EDID potentially being totally wrong sometimes on even basic data like physical size or even logical size (number of pixels).
As for the why, I don’t know, but following Occam’s razor I would guess that it’s cheaper when you just don’t care and leave it as somebody else’s problem.
Most displays provide settings to modify the colors of your screen; mine has like 10 different “picture modes” that strongly modify gamma curves, colors and the whitepoint. The EDID only describes colors of one of them, so if you change display settings, the data no longer applies.
More generally, the information isn’t used by Windows or other popular video sources by default, so manufacturers don’t have much of an incentive to put correct information in there. If it doesn’t make a difference for the user, why would they care? Some displays even go so far as to intentionally report wrong physical size information, to make Windows select the default scale the manufacturer wants to have on that display (or at least that’s what I think is the case with my cheap AliExpress portable monitor)…
That’s not to say that the information is actually often completely wrong or unusable, but if one in tenthousand displays gets really messed up colors because we toggle this setting on by default, it’s not worth it. We might add some heuristics for detecting at least usable color information and change this decision at some point though
Any conversion (including internally at the display) can result in colorspace mismatches.
If the sink has an unsupported mode, the source will send a default - which is usually a mismatch.
I wouldn’t call it often wrong, personally. I’d say some devices are really bad with EDIDs, and are consistently problematic. It’s more like -recent hardware is generally pretty good, but relying entirely on EDID won’t always work, so use with care.
Some great examples of problematic devices/situations (in general):
Apple. Pretty much anything they make.
DP to HDMI - while DP supports HDMI natively, that can be one of the situations where EDID issues crop up. But much less often than…
DVI to HDMI or vice versa - this is probably the most problematic of general use. Happens somewhat often where a different or default colorspace gets used.
If you’ve got a single PC going to a display (or several), just set it once manually and you’re good to go. If you’re plugging and unplugging often with multiple devices (like with a dock), an EDID minder can be handy, but come with a price that generally makes setting it manually preferred anyway.
Add comment