-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
issues with display profile installation on Wayland #129
Comments
well even if the script places the display file in the right location, there is an issue on wayland how to assign the colour profile to the screen. now that the colour management protocol is finalised (is it?) all we have to do is wait for glfw and all compositors in the world to implement support. note to self, in category super dirty hacks: the way to support per-monitor colour management on wayland today is to conspire with hyprland, which will give us the required information no problem (monitor id of the window, name of the monitor etc, even window position). i could then do the same as on x11, determine overlap with monitor and apply profile in shader. relevant data acquisition paths:
|
I am not following vkdt development very closely at the moment. Afaik hyprland does not do system wide wayland color management yet, there is a long dicussion thread about hyprland color management on the github page of hyprland, a lot of users want the feature apparently. But sway has implemented the wayland color management protocol a few months ago, although when I tested it for the last time right after the feature was merged, it didn't work well. Just to clarify: could vkdt show colors outside srgb if the wayland compositor can do color management? Because afiak there is no image viewer or graphics software yet that can communicate with the wayland color management. |
yes i've seen the thread (and your comments there). vkdt will happily serve numbers way outside sRGB. the internal working space is rec2020 but since it's mostly floating point i don't usually clip at 0 or 1. so if the compositor simply passes the pixel values to the display, vkdt's colour management will work for a single monitor (by applying the profile in a full-window fragment shader, same as the compositor would do it anyways but in an additional pass). for more than one monitor, wayland doesn't usually tell you which monitor your window is on, but with the abovequoted commands you can find out on hyprland. i'm calling this a hack because obviously it will never work with any other compositor and also it depends on the current state that there is no additional colour management in the compositor. |
The display profile installation script is currently set to name the profile after the connection/port name. However, the Wayland native appimage of vkdt does not recognize the the connection name but the actual name of the display model:
It's possible to get this name with the tool wlr-randr, but that does not work on KDE Plasma 6.
Should this be fixed in the script or in vkdt?
Edit: apparently it is possible to show the screen name with hwinfo --monitor. So this can definitely be fixed in the script. So first the script should check whether vkdt runs on Wayland or X11, and then if Wayland then use hwinfo. I think I can fix this, but maybe there is a better solution?
The text was updated successfully, but these errors were encountered: