search

eoyilmaz / displaycal-py3

DisplayCAL Modernization Project
https://eoyilmaz.github.io/displaycal-py3/
GNU General Public License v3.0
782 stars 56 forks source link

wayland no access to video card gamma table #133

Open 24fpsDaVinci opened 2 years ago

24fpsDaVinci commented 2 years ago

fedora 42.2 wayland mutter 42.2

running the pip displaycal package, theres no access to gamma table. the entire Tools>Video Card Gamma Table is greyed out. the same issue also happens with in the old displaycal flatpak

eoyilmaz commented 2 years ago

Yeah as far as I know the Video Card gamma table can not be changed under Wayland. There are all sorts of other limitations with Wayland too.

24fpsDaVinci commented 2 years ago

i think wayland does allow basic gamma correction through colord, the icc/icm profiles made under windows or xorg can be applied.

this series of MRs maybe of interest to you https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141

eoyilmaz commented 2 years ago

Thanks for the link.

I might overlooked to your problem, but I answered in this way because of this line in the code:

https://github.com/eoyilmaz/displaycal-py3/blob/f32a60b747bacf1d5abf97a7053c841393a62ffa/DisplayCAL/worker.py#L15300

This is Florian's note.

But, let me check what Tools -> Video Card Gamma Table does and return back with a proper answer.

kepstin commented 1 year ago

GNOME does have a desktop-specific interface for retrieving and setting the video LUT (gamma ramps) - it's done via dbus on the org.gnome.Mutter.DisplayConfig interface: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/data/dbus-interfaces/org.gnome.Mutter.DisplayConfig.xml#L219-253

The argyllcms tools don't support accessing this interface, tho. I'm not sure if this is something that DisplayCAL would be able to do for them, or if there's things that the argyllcms tools do which require that they're able to set and/or fetch the video LUT themselves.

eoyilmaz commented 1 year ago

@kepstin this is exactly where we are getting the EDID from:

https://github.com/eoyilmaz/displaycal-py3/blob/main/DisplayCAL/RealDisplaySizeMM.py#L151

sans-c commented 1 year ago

Let me hijack this to ask a more basic question. I've read lots of conflicting information recently. Does displaycal work as intended under wayland (as in profile creation, verification and installation works) or does it not?

I recently created a profile in a wayland session with gnome and I can install it via the gnome-UI. Everything seems to work. And still I read a lot about limitations and displaycal/color calibration supposedly not working under wayland. Can someone elaborate and maybe incorporate the info into a wiki or readme? This is really confusing.

kepstin commented 1 year ago

Some things work, some things are iffy.

This issue about is access to the video card LUT. The tools in the DisplayCAL gui are fixable by having them access the LUT via the DBus interface provided by Mutter (GNOME Shell). That said, those tools aren't required for the basic profile creation functionality.

The underlying argyllcms tools used for calibration also have this problem. The main issue this causes is that if you currently have a profile loaded, that profile won't be cleared while calibration/profiling is running - so the newly generated profile will be garbage. It's possible that DisplayCAL could work around this by clearing the LUT before running the argyllcms tools. Note that the argyllcms tools still think they can access the LUT when running in XWayland, so they will put the calibration data into the profile.

You might also have issues with the position and/or scaling of the colour swatches, especially if you have multiple monitors and/or have display scaling set to a value other than 100%.

The installation in GNOME might be ok? The install needs to happen by the profile being added to colord (and possibly selected in the GNOME Settings Color panel), and then GNOME Shell itself handles loading the video card lut from the profile. (DisplayCAL's own loader is unneeded and doesn't work.) If all else fails, you can install the profile into colord manually.

sans-c commented 1 year ago

Thank you for your reply! That was helpful. I am not entirely clear on one point though.

Note that the argyllcms tools still think they can access the LUT when running in XWayland, so they will put the calibration data into the profile.

What does this imply exactly? Is that supposed to mean the resulting profile isn't correct (given that I made sure that no profile is assigned/loaded prior to calibration)?

You might also have issues with the position and/or scaling of the colour swatches, especially if you have multiple monitors and/or have display scaling set to a value other than 100%.

I think I noticed some different behaviour compared to a Windows setup but once the size/position of the calibration window was adjusted properly, things seemed to work.

On a side note and slightly off topic, can you perhabs speak to wether xwayland-windows honor color profiles set up in a gnome wayland session? Some graphics software, specifically darktable do not support wayland for lack of "proper" color managment yet and there seems to be confusion about what works and what does not.

kepstin commented 1 year ago

Note that the argyllcms tools still think they can access the LUT when running in XWayland, so they will put the calibration data into the profile.

What does this imply exactly? Is that supposed to mean the resulting profile isn't correct (given that I made sure that no profile is assigned/loaded prior to calibration)?

If argyllcms detects that that it's unable to read or set the video card LUT, then it will not perform the calibration step. But since it still thinks it can read/write the LUT when running under Xwayland (even tho it can't), then it does perform the calibration step and saves the result to the generated ICC profile. If you've ensured that you have a "linear" mapping loaded into the video card LUT while running calibration/profiling, then the calibration and profile will be correct.

Note that I've found it to be unreliable to use GNOME Settings to unload a profile. Disabling colour management on a display usually leaves the calibration data from the last used profile loaded, and switching profiles doesn't always apply the calibration data from the new profile. Fortunately, in my case the display looks visibly different between my profile with calibration data and a profile with a linear mapping or no calibration data, so I can try toggling back and forth until i see it actually change :/

On a side note and slightly off topic, can you perhabs speak to wether xwayland-windows honor color profiles set up in a gnome wayland session? Some graphics software, specifically darktable do not support wayland for lack of "proper" color managment yet and there seems to be confusion about what works and what does not.

Full screen correction based on the calibration data loaded into the video card LUT applies to all apps, including xwayland apps.

There is no native wayland protocol to get the profile assigned to a monitor for apps that want that information. They have to ask colord for it (over dbus) based on information retrieved from the Wayland wl_output.

… but they should be asking colord for the profiles anyways, using information from Xrandr on X11. This is because the legacy method for ICC profiles on X11 only allows you to have a single profile per X11 "display", but when you span a desktop over multiple monitors, you get multiple monitors sharing the single X11 "display".