It was implemented over two years ago.
It was implemented over two years ago.
Do motherboard/monitor/IC/etc manufactures need to submit their own kernel patches well in advance of product releases, like what AMD and Intel do for their CPUs and GPUs? Are we just waiting for them to give a shit?
Yes. There isn’t really any other good solution.
Why does Nvidia need to support night light?
They don’t, but they needed to support the KMS API for applying lookup tables to the image sent to the screen - desktops relied on that functionality without a fallback, so when it wasn’t available, you just didn’t get the feature.
Can’t someone from Wayland just write a simple shader in any shader language that does colour adjustments and apply it to the desktop?
There’s no such thing as “someone from Wayland”, just the developers of the DEs (well, the project is named after a town, but I’m sure that’s not what you meant).
But, yes, you can use a shader. We implemented that in KWin and we’re using it when the driver or hardware doesn’t support the functionality we need… but that has a noticeable performance impact, so it’s still necessary for the driver to support it natively.
That’s not right. Most monitors use 8 bits per color / 24 bits per pixel, though some are still using 6 bpc / 18bpp.
HDR doesn’t mean or really require more than 8bpc, it’s more complicated than that. To skip all the complicated details, it means more brightness, more contrast and better colors, and it makes a big difference for OLED displays especially.
You could also try using KDE Plasma instead of Gnome, which survives GPU resets.
Okay, then the driver doesn’t allow Plasma to turn it on for some reason. You can report that at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues, maybe someone from Intel can help.
No I can’t move my mouse to the external monitor.
Do you mean that it stays on the internal display, or that it doesn’t show up on the external one?
Or to ask it differently, can you move a window where the monitor should be?
My laptop detects the monitor correctly so it shows up in the KDE plasma display configuration but the monitor is not getting any input.
So the system thinks it’s enabled? Can you move the mouse cursor to it?
It’s an Electron problem, yes. The API is there, just waiting to be used.
Ah, you’re on Xorg. This feature is only available in the Wayland session
Go into system settings > mouse > select your mouse > rebind buttons
Please make a bug report to KWin about that issue then, and attach one of the ICC profiles you tried to the bug report. Maybe something’s wrong in KWin’s profile parsing and it gets silently ignored.
regardless, the whole point of my og comment was color management protocol isn’t only hdr stuff
Yes, nothing wrong with that.
like how color profiles are under ‘color management’ in the system settings you’re telling me to use
No, I’m telling you to use the display settings. The color management page is hidden on Wayland starting with Plasma 6.3, because it’s misleading and confusing.
the wiki says
The wiki is very outdated, it’s about Plasma 5.
It’s in the display settings
If you’re on Plasma, setting the color profile to “built-in” might be all you need to make them reasonably match
No, colord does not handle color profiles on Wayland. You need to set the profile in the display settings.
If you have an ICC profile that doesn’t work, please make a bug report about it for KWin.
This protocol isn’t relevant for your compositor to apply an ICC profile. If you’re using KDE Plasma, you can just select it in the settings. I think Sway allows that now too. If you’re on Gnome, you’ll need to wait.
You don’t need a protocol for profiling, it’s merely a nicer user experience if you have one.
Chromium had it for qhite a while, but it isn’t really relevant… Discord’s implementation of screen sharing was custom on X11, if they had used the one that comes with Electron, this would’ve worked far earlier.
operating systems may not have implemented it umtil more recently
DEs that had a Wayland session (aka Gnome and Plasma) supported it very soon after the portal was made.
The real reason won’t be anything external, but something in the company. Usually it’s just that Linux isn’t a priority for a given company, so even if there’s a motivated engineer that wants to take care of it, it’s hard justifying to their managers why they need to spend a lot of time on it.
This isn’t exclusive to Discord, to use a very similar example, Zoom is kinda worse. In the past, Zoom misused a Gnome screenshot API to do screen casting very badly, and recently they ported to the desktop portal - not because they had a choice, but because Gnome locked down the API they were using. Screen casting still only works on Gnome though, because they still check for the desktop name. If you set it to Gnome, it works perfectly fine everywhere else too!
All it would take to fix that problem is removing an if statement, yet, despite many complaints, it hasn’t happened… because no big customer has complained, so it’s just one of the unimportant Linux bugs.
Umm yes, they did take ages to support it. It took like 7 years…