Skip to content
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

Open
blitzgneisserin opened this issue Jun 15, 2024 · 3 comments
Open

issues with display profile installation on Wayland #129

blitzgneisserin opened this issue Jun 15, 2024 · 3 comments

Comments

@blitzgneisserin
Copy link
Contributor

blitzgneisserin commented Jun 15, 2024

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:

[anna@archlinux Downloads]$ ./vkdt-rawler-wayland-0.8.99-35-gb7ce8d37-x86_64.AppImage
[gui] glfwGetVersionString() : 3.3.6 Wayland EGL OSMesa clock_gettime evdev shared
[gui] monitor [0] BNQ BenQ SW240 at 0 0
[gui] vk extension required by GLFW:
[gui]   VK_KHR_surface
[gui]   VK_KHR_wayland_surface
[gui] no joysticks found
[gui] no display profile file display.BNQ BenQ SW240, using sRGB!

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?

@hanatos
Copy link
Owner

hanatos commented Dec 3, 2024

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:

hyprctl activewindow -j
hyprctl monitors -j

@blitzgneisserin
Copy link
Contributor Author

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.

@hanatos
Copy link
Owner

hanatos commented Dec 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants