[RFC wayland-protocols] Color management protocol
Pekka Paalanen
ppaalanen at gmail.com
Fri Jan 13 12:34:13 UTC 2017
On Thu, 5 Jan 2017 12:51:58 +1100
Graeme Gill <graeme2 at argyllcms.com> wrote:
> Pekka Paalanen wrote:
>
> > 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, screen saving will not activate,
> > etc. anything that might hamper calibration will not happen.
>
> That's all good - but aren't these the sorts of controls
> that other applications need too ?
Maybe, but not that way. Wayland is intended to have a semantic desktop
shell protocol where clients communicate exact intents, while X11 was a
purely mechanical protocol with no intents at all.
For instance, to fullscreen a window, in X11 you "set position, set
size, stack on top" (wait, what position? what size is appropriate?)
and the WM has to guess what you wanted. In Wayland, you "make me
fullscreen", and the WM will know exactly what you want and it will do
exactly what you need and it can even tell you what the appropriate
size is, so no-one has to guess anything.
Yes, X11 actually has the NET_WM fullscreening protocol added later by
EWMH IIRC. It communicates intent.
> Slide show or Video player apps need to prevent screensaving,
> modal dialogs need to be able to pop to the top of
> the window stack etc.
Preventing screensaving is a lot more complicated that you might first
think when integrated properly.
No application will be able to unconditionally steal your whole desktop
like traditional modal dialogs can, so there will not be such a
request, or it will be limited to the windows of the single client, or
a client-provided sub-set of windows. It would not help at all with a
calibration app. Similarly there is no "stack on top" unconditional
request, but there will likely be a "wants attention" request which
under the compositors policy may cause the window to be stacked on top.
And then the "etc.". Compositors may gain new features you have not
anticipated, that will interfere with calibration. How would you know
to write support for them all in your calibration app to disable them
one by one?
Would it not be simpler to just say "I'm doing calibration now, make
sure nothing interferes"?
Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170113/311b7196/attachment.sig>
More information about the wayland-devel
mailing list