On Sat, 14 Jan 2017 10:32:43 +0100 Benoit Gschwind <gschw...@gnu-log.net> 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 <lists+wayland-de...@hoech.org> 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 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 (don't > > care, bug, broken, crashed) never restores it to original, or even if > > it does restore, all your icons on the desktop get squashed in the > > top-left corner. That is one reason why Wayland does not have a RandR > > interface. > > > > > >> Graeme Gill wrote: > >>> I'm also thinking it would really help a lot if you and > >>> others contributing to this thread were able > >>> to procure something like a X-Rite i1 display Pro, > >>> run up the manufacturer provided software on > >>> MSWindows or OS X to get a feel for what it does, > >>> then fire up DisplayCAL+ArgyllCMS on Linux/X11 > >>> and take it for a spin. > >>> (Another path would be to obtain one of Richard's > >>> ColorHug's, but I think seeing how the commercial > >>> software operates as well, would add a broader perspective.) > >> > >> Even watching some videos of a typical calibration/profiling workflow on > >> YouTube may already help. > > > > That's an excellent idea! Could you recommend some, so I don't pick a > > random "oh, but they're doing it wrong" video? > > > > > > Thanks, > > pq > > > > > > > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > Best regards > > [1] > https://lists.freedesktop.org/archives/wayland-devel/2017-January/032619.html > > -- > Benoit (blocage) Gschwind > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- ------------- 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
