https://bugs.kde.org/show_bug.cgi?id=429079
wolthera <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #17 from wolthera <[email protected]> --- (In reply to Haelwenn (lanodan) Monnier from comment #16) > Also tablet support works, I don't know where the code for it is but it > hooks up properly to the tablet protocol of wayland (as seen with > WAYLAND_DEBUG=1), tested with a "Wacom Co., Ltd CTL-470". > Positioning, Pen, Pressure, … are working. > > Not sure how to test for color management but maybe this is more something > that Krita's rendering has to manage rather than the wayland compositor No, as far as we understand the Wayland philosophy, the last part of the color management has to be handled by the compositor. There's a protocol being worked on here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/swick/wayland-protocols/-/blob/color/unstable/color-management/color.rst The textbook problem comes with multiple monitors which each have their own colorspace characteristics. For example, a fancy wide gamut monitor and a simple srgb monitor. Krita then needs to know whether the canvas is on screen 1 or 2 to be able to convert the image colors to the display colors. Wayland's big deal with monitor information is that it doesn't think programs should know where on the monitor they are. So then, the final conversion from image to display color needs to be done by Wayland if such multi monitor setups are to work correctly. I hope this makes sense. As for the tablet stuff, I got the impression we were using libinput via Qt, and libinput has wayland support, but I am hardly an expert on wayland. -- You are receiving this mail because: You are watching all bug changes.
