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)
- 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 (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
