Re: [RFC wayland-protocols] Color management protocol
On Sat, 14 Jan 2017 11:52:25 +0100 Kai-Uwe said: > Am 14.01.2017 um 03:24 schrieb Carsten Haitzler (The Rasterman): > > On Fri, 13 Jan 2017 18:08:51 +0200 Pekka Paalanen > > said: > >> Oh, ok, that's why. We could as easily have the compositor show the > >> color swatch only on a part of the output and leave the rest of the > >> area for normal use. > >> > >> However, if that is done with a special protocol so that the compositor > >> actually knows this is the profiling color swatch, it can make sure > >> other windows cannot interfere. It could be like the color swatch was > >> on an always-on-top overlay. You cannot do that any other way from a > >> Wayland client. > >> > >> And if unform color for the swatch is all you need, the protocol could > >> simply take 3 numbers for the color instead of an image buffer. Then > >> people would not get the urge to abuse this interface for e.g. > >> application splash screens. > > > > i kind of like the idea of a special protocol with 32bit ints per rgb etc. > > to say "display this exact uncalibrated color as-is without luts or > > anything else in the way"... but apply it to a separate toplevel > > window/surface (and put your guided ui controls in another window) or... > > use a subsurface. > > +1 for subsurface. The compositor can even take over responsibility to > move the belonging window to the desired output, for the case the > underlying application can not manage or handle that itself (e.g. for > mirrored outputs). indeed as it knows the parent surface etc. and thus can "do the right thing" without the calibration app needing to know or care at all. in the end a calibrator really just needs to present some data (unmolested by gamma luts/color correction/blending etc.) onto a display so some colorimiter device dangling on the screen can read it and feed back what it sees. using this dat produce a set of calibration data a compositor (or an app) canuse later that would be applicable to that monitor. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Color management protocol
On Sat, 14 Jan 2017 10:32:43 +0100 Benoit Gschwind said: > Hello Pekka, > > Your idea is mostly correct, but I have few comment. Some element of > context: on my side I do not do photo editing at all but I calibrate and > profile my monitor often to get a similar visual experience from a > computer to another. > > On 13/01/2017 17:03, Pekka Paalanen wrote: > > On Fri, 13 Jan 2017 15:56:50 +0100 > > Florian Höch wrote: > > > >> [ Bunch of replies to different posts crammed into one, apologies in > >> advance. ] > >> > >> Pekka Paalanen wrote: > >>> Would it not be simpler to just say "I'm doing calibration now, make > >>> sure nothing interferes"? > >> > >> Sure, I just hope that "I'm doing calibration now, make sure nothing > >> interferes" still allows conventional application UI (e.g. using UI > >> frameworks like Gtk3, Qt etc) to be visible, because otherwise it would > >> effectively block users from interacting with said UI (going by your > >> comment "I also forgot to mention that surfaces with the > >> cms_calibration_surface role, when actually presented, would also > >> guarantee that nothing else will be shown on that specific output" > >> somehow sounds like it would not, but maybe I'm misunderstanding what > >> you mean by "output". I would certainly not be enthused if I had to > >> low-level re-implement parts of the UI I currently have - in fact I can > >> tell you right now that it would never, ever happen if it's not as > >> simple as writing for any of the common UI frameworks). > > > > Hi, > > > > my idea for a user story would be something like this: > > > > - user starts a calibration app and clicks "profile output HDMI 2" > > > > - optional: the compositor shows a dialog: "Application Foo wants to > > profile output HDMI 2. Allow / Deny ? You can press Esc to abort > > profiling after it starts." > > optional but recommended, this avoid the abuse of the protocol for > splash screen. This dialog should also grant the access to change to the > hardware settings (VideoLUT and other things) not sure the app should directly change the lut ... but should provide the calibration data it gathered and let the compositor figure out how to program the lut to do the correcting. compositor could now store that data in any wayit likes for future re-use (next time it starts auto apply this correction as long as that monitor is attached to that output etc.) > > > > - The output HDMI 2 gets filled with the profiling pattern according > > the application requests, and literally nothing else will show up on > > that output. > > > > As explained in another e-mail[1] the user may want to use unused space > to do something else, I do it often because: (1) calibrating take quite > a long time, (2) my requirement are not very high in term of accuracy > and (3) the software that perform the calibration may want to show some > calibration/profiling progress and/or feedback or (4) the software that > perform the calibration may want show GUI button to pause/resume the > calibration. > > Another random remark is that, as far as I understand, the calibration > process may affect all monitors, depending on hardware because they may > expose only one VideoLUT shared for all outputs. this is why i think the video lut should be hidden from client view entirely as above. :) > > - If the user wants to abort the profiling run before it completes, he > > presses Esc, which the compositor grabs and restores HDMI 2 to normal. > > > > - If the profiling finishes by itself, HDMI 2 is restored to normal > > automatically. > > > > - The profiling application will know what happened in all cases. > > > > How's that sound? I'm running blind here, because I've never used a > > profiling app. > > > > You are mostly correct in the approach, imo. > > > Would you really need the user to interact with the UI while the > > profiling pattern is shown? > > > > If you show any UI bits on the profiled output, how do you avoid the UI > > affecting the profiling results? Keep in mind the window positioning > > limitations in Wayland desktop. > > > > Other outputs should remain normal during profiling, but of course > > there might be only one output connected. > > > >> Put bluntly, but I agree as well. A "calibration/profiling/measurement" > >> application is not more of a "special-purpose client" than, say, a CAD > >> application, a code editor, or an application that lets you create 3D > >> scenes of rotating bunnies wrapped around bunnies (scnr), ... etc. > > > > Graeme just managed to explain to me why the profiling app needs access > > to the VideoLUT (see [1]) which is a global resource. That makes the > > profiling app a very special case on Wayland, because on Wayland we > > very very carefully avoid unconditional access to such global > > resources, so that apps cannot take the user or the desktop hostage or > > mess it up even if they tried to(*). Changing the VideoLUT will mess up > > all othe
Re: [RFC wayland-protocols] Color management protocol
Am 14.01.2017 um 03:24 schrieb Carsten Haitzler (The Rasterman): > On Fri, 13 Jan 2017 18:08:51 +0200 Pekka Paalanen said: >> Oh, ok, that's why. We could as easily have the compositor show the >> color swatch only on a part of the output and leave the rest of the >> area for normal use. >> >> However, if that is done with a special protocol so that the compositor >> actually knows this is the profiling color swatch, it can make sure >> other windows cannot interfere. It could be like the color swatch was >> on an always-on-top overlay. You cannot do that any other way from a >> Wayland client. >> >> And if unform color for the swatch is all you need, the protocol could >> simply take 3 numbers for the color instead of an image buffer. Then >> people would not get the urge to abuse this interface for e.g. >> application splash screens. > > i kind of like the idea of a special protocol with 32bit ints per rgb etc. to > say "display this exact uncalibrated color as-is without luts or anything else > in the way"... but apply it to a separate toplevel window/surface (and put > your > guided ui controls in another window) or... use a subsurface. +1 for subsurface. The compositor can even take over responsibility to move the belonging window to the desired output, for the case the underlying application can not manage or handle that itself (e.g. for mirrored outputs). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Color management protocol
Hello Pekka, Your idea is mostly correct, but I have few comment. Some element of context: on my side I do not do photo editing at all but I calibrate and profile my monitor often to get a similar visual experience from a computer to another. On 13/01/2017 17:03, Pekka Paalanen wrote: On Fri, 13 Jan 2017 15:56:50 +0100 Florian Höch wrote: [ Bunch of replies to different posts crammed into one, apologies in advance. ] Pekka Paalanen wrote: Would it not be simpler to just say "I'm doing calibration now, make sure nothing interferes"? Sure, I just hope that "I'm doing calibration now, make sure nothing interferes" still allows conventional application UI (e.g. using UI frameworks like Gtk3, Qt etc) to be visible, because otherwise it would effectively block users from interacting with said UI (going by your comment "I also forgot to mention that surfaces with the cms_calibration_surface role, when actually presented, would also guarantee that nothing else will be shown on that specific output" somehow sounds like it would not, but maybe I'm misunderstanding what you mean by "output". I would certainly not be enthused if I had to low-level re-implement parts of the UI I currently have - in fact I can tell you right now that it would never, ever happen if it's not as simple as writing for any of the common UI frameworks). Hi, my idea for a user story would be something like this: - user starts a calibration app and clicks "profile output HDMI 2" - optional: the compositor shows a dialog: "Application Foo wants to profile output HDMI 2. Allow / Deny ? You can press Esc to abort profiling after it starts." optional but recommended, this avoid the abuse of the protocol for splash screen. This dialog should also grant the access to change to the hardware settings (VideoLUT and other things) - The output HDMI 2 gets filled with the profiling pattern according the application requests, and literally nothing else will show up on that output. As explained in another e-mail[1] the user may want to use unused space to do something else, I do it often because: (1) calibrating take quite a long time, (2) my requirement are not very high in term of accuracy and (3) the software that perform the calibration may want to show some calibration/profiling progress and/or feedback or (4) the software that perform the calibration may want show GUI button to pause/resume the calibration. Another random remark is that, as far as I understand, the calibration process may affect all monitors, depending on hardware because they may expose only one VideoLUT shared for all outputs. - If the user wants to abort the profiling run before it completes, he presses Esc, which the compositor grabs and restores HDMI 2 to normal. - If the profiling finishes by itself, HDMI 2 is restored to normal automatically. - The profiling application will know what happened in all cases. How's that sound? I'm running blind here, because I've never used a profiling app. You are mostly correct in the approach, imo. Would you really need the user to interact with the UI while the profiling pattern is shown? If you show any UI bits on the profiled output, how do you avoid the UI affecting the profiling results? Keep in mind the window positioning limitations in Wayland desktop. Other outputs should remain normal during profiling, but of course there might be only one output connected. Put bluntly, but I agree as well. A "calibration/profiling/measurement" application is not more of a "special-purpose client" than, say, a CAD application, a code editor, or an application that lets you create 3D scenes of rotating bunnies wrapped around bunnies (scnr), ... etc. Graeme just managed to explain to me why the profiling app needs access to the VideoLUT (see [1]) which is a global resource. That makes the profiling app a very special case on Wayland, because on Wayland we very very carefully avoid unconditional access to such global resources, so that apps cannot take the user or the desktop hostage or mess it up even if they tried to(*). Changing the VideoLUT will mess up all other windows on that output, and the profiling app will not even tolerate any other windows on that output at the same time. Any application you listed does not require similar access to a global resource. A profiling app OTOH cannot use the normal content delivery paths because as Graeme explained they often do not reach the full precision without changing the VideoLUT. Another example of where Wayland denies access to global resources is that an application cannot make an input grab at will. Input grabs are always conditional, and breakable. We should have similar behaviour also with "screen grabs" like these. [1] https://lists.freedesktop.org/archives/wayland-devel/2017-January/032616.html (*) The classic example of messing up the user's desktop is games changing the X server video mode, and for one reason or another (do