Re: [RFC wayland-protocols v2 1/1] unstable: add color management protocol
Hi,
Simon Ser writes:
> Hi,
>
> Here are a few comments, from a protocol design perspective.
>
> On Wednesday, March 6, 2019 6:09 PM, Sebastian Wick
> wrote:
>> This protocol allows clients to attach a color space and rendering
>> intent to a wl_surface. It further allows the client to be informed
>> which color spaces a wl_surface was converted to on the last presented.
>>
>> Signed-off-by: Sebastian Wick
>> ---
>> Makefile.am | 1 +
>> unstable/color-management/README | 4 +
>> .../color-management-unstable-v1.xml | 189 ++
>> 3 files changed, 194 insertions(+)
>> create mode 100644 unstable/color-management/README
>> create mode 100644
>> unstable/color-management/color-management-unstable-v1.xml
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 345ae6a..80abc1d 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -23,6 +23,7 @@ unstable_protocols =
>> \
>> unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \
>>
>> unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
>> \
>> unstable/primary-selection/primary-selection-unstable-v1.xml
>> \
>> +unstable/color-management/color-management-unstable-v1.xml
>> \
>> $(NULL)
>>
>> stable_protocols =
>> \
>> diff --git a/unstable/color-management/README
>> b/unstable/color-management/README
>> new file mode 100644
>> index 000..140f1e9
>> --- /dev/null
>> +++ b/unstable/color-management/README
>> @@ -0,0 +1,4 @@
>> +Color management protocol
>> +
>> +Maintainers:
>> +Sebastian Wick
>> diff --git a/unstable/color-management/color-management-unstable-v1.xml
>> b/unstable/color-management/color-management-unstable-v1.xml
>> new file mode 100644
>> index 000..47dd453
>> --- /dev/null
>> +++ b/unstable/color-management/color-management-unstable-v1.xml
>> @@ -0,0 +1,189 @@
>> +
>> +
>> +
>> +
>> +Copyright © 2019 Sebastian Wick
>> +Copyright © 2019 Erwin Burema
>> +
>> +Permission is hereby granted, free of charge, to any person obtaining a
>> +copy of this software and associated documentation files (the
>> "Software"),
>> +to deal in the Software without restriction, including without
>> limitation
>> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> +and/or sell copies of the Software, and to permit persons to whom the
>> +Software is furnished to do so, subject to the following conditions:
>> +
>> +The above copyright notice and this permission notice (including the
>> next
>> +paragraph) shall be included in all copies or substantial portions of
>> the
>> +Software.
>> +
>> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
>> OR
>> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> OTHER
>> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> +DEALINGS IN THE SOFTWARE.
>> +
>> +
>> +
>> +This protocol provides the ability to specify the color space
>> +of a wl_surface. If further enumerates the color spaces currently
>
> Typo: "It"
>
>> +in the system and allows to query feedback about which color spaces
>> +a wl_surface was converted to on the last present.
>> +The idea behind the feedback system is to allow the client to do color
>> +conversion to a color space which will likely be used to show the
>> surface
>> +which allows the compositor to skip the color conversion step.
>
> Wording: the "which" repetition could be avoided by splitting this into two
> sentences ("This would allow the compositor…").
>
>> +
>> +
>> +
>> +
>> + The color manager is a singleton global object that provides access
>> + to outputs' color spaces, let's you create new color spaces and attach
>
> Typo: "lets"
>
>> + a color space to surfaces.
>> +
>> +
>> +
>> +
>> +render intents
>
> This could probably be expanded to at least be a sentence.
>
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +Well-known color spaces
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +These fatal protocol errors may be emitted in response to
>> +illegal color management requests.
>> +
>> +
>> +
>> +
>> +
>> +
>> +Set the color space of a surface. The color space is double
>> buffered,
>> +and will
Re: wayland-protocols scope and governance
On 2019-03-08 11:28 AM, Daniel Stone wrote: > > If we're establishing a table, it may make sense to give wlroots as a > > whole a seat at that table. wlroots is where the implementation lives, > > after all, for all of the compositors who use it. We already kind of do > > this with wlr-protocols. > > If they're happy for you (or wlroots as a project) to speak for them > all, then I have no problem with it. I spoke with everyone and we're in agreement on this point. We can always split into more entities later. However, based on this we ought to be careful with anything like voting where a majority or percentage of members is required. We wouldn't appreciate exchanging voting power for convenience. > J> I think formalizing a set of categories, including wp_ and xdg_ and at > J> least a third one is a good idea. I think that with a "free for all" > J> method suggested by Pekka, where we put all the responsibility on > J> everyone else to figure out what protocol fits under what category > J> (because there will still, in practice, be categories, we just avoid > J> spelling them out), we loose too much in terms of discoverability and > J> perceived scope. It'll be harder to know what to expect. > J> > J> What I mean here is that it should be clear what protocols are > J> "plumbing" (e.g. wp_viewporter), what protocols are for window > J> management related tasks where the application aim to be portable in a > J> sense that they will work on both fully integrated and non-integrated > J> compositors (e.g. xdg-shell and xdg-decoration), as well what protocols > J> are for applications that want to be a building block of a > J> non-integrated compositor (e.g. the layer shell protocol). I don't think > J> it's possible to avoid politics completely here, no matter how > J> "annoying" it is, because protocol development is partly about that. > J> There are most likely good reasons Khronos have chosen to work like > J> this as well. > J> > J> A protocol support matrix will still be very useful here either way, and > J> I expect all categories will include protocols with varying support, as > J> so is the situation already, but it wouldn't be the only source of > J> clarity of scope and potential adoption. > J> > J> We could also keep the door open for other groups of protocols, such as > J> IVI and maybe even those for fully coupled systems like the content > J> protection protocols that has been floating around, assuming those who > J> write protocols agree to act as maintainers and use our versioning > J> system. > > Under what he's describing, xdg_shell isn't miscategorised, because it > _is_ the thing that everyone agrees on and uses. If we reserve xdg_* > for uncontroversial/unvetoed things, then xdg_shell would presumably > be a part of that. I think xdg_shell's primary focus is definitely the > desktop, and it's pretty unapologetic about that, but there is enough > wiggle room that it's usable way beyond the desktop. Same thing with > the XDG specs, where the ICCCM is useful for kiosks, .desktop files > are useful for phones, xdg-basedir is useful for display walls, etc. I still maintain that xdg-shell is somewhat shoehorned in for cases which are not the desktop. But that's kind of what I'm getting at: > I think xdg_shell's primary focus is definitely the desktop and > [xdg-shell] is the thing that everyone agrees on and uses. If we > reserve xdg_* for uncontroversial/unvetoed things These are in conflict. There are protocols which are unsuitable to the desktop, like IVI shell, which may nevertheless have unanimous support among the compositors which use it. I could see more shells being made in the future, particularly for mobile, as I don't think xdg-shell is designed with mobile well enough in mind. In other words: xdg cannot at once be the unanimous view of all of Wayland and a desktop-centric namespace. > > > XDG is already overloaded enough that I'd like not to add 'stuff some > > > people use but others feel very strongly about not using' to it. Some > > > people also interpret XDG to mean 'freedesktop.org Certified Seal of > > > Approval™', which is ... sort of the opposite of that. > > > > The frustrating problem is that xdg-shell exists and is stable and is > > called xdg-shell. We should probably rename xdg-output, by the way, > > before it becomes stable. > > Mm, but then shell is agreed on by everyone? Even IVI moved over to > xdg_shell for clients. Who do you have in mind who feels very strongly > about not using it? Me :) I were to make a mobile compositor (and I very well might) and I was willing to patch clients with support for a new protocol (doubtful), I think I would do that before I'd use xdg-shell. The main issues that come to mind are: - Interactive move/resize probably doesn't make sense on mobile. xdg-shell was influenced by parties who are strongly in favor of client autonomy, but on mobile there's really no reason for me to let you move or resize yourself on a t
Re: [PATCH wayland 2/2] connection: fix demarshal of invalid header
Hi, On Wednesday, March 6, 2019 12:58 PM, Pekka Paalanen wrote: > From: Pekka Paalanen pekka.paala...@collabora.com > > The size argument to wl_connection_demarshal() is taken from the message by > the > caller wl_client_connection_data(), therefore 'size' is untrusted data > controllable by a Wayland client. The size should always be at least the > header > size, otherwise the header is invalid. > > If the size is smaller than header size, it leads to reading past the end of > allocated memory. Furthermore if size is zero, wl_closure_init() changes > behaviour and leaves num_arrays uninitialized, leading to access of arbitrary > memory. > > Check that 'size' fits at least the header. The space for arguments is already > properly checked. > > This makes the request_bogus_size test free of errors under Valgrind. > > Fixes: https://gitlab.freedesktop.org/wayland/wayland/issues/52 > > Signed-off-by: Pekka Paalanen pekka.paala...@collabora.com Both patches look good to me. I've also tested them with -fsanitize=address. Take this with a grain of salt since I'm not very familiar with libwayland's demarshalling code, but this is: Reviewed-by: Simon Ser ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols v2 1/1] unstable: add color management protocol
Hi,
Here are a few comments, from a protocol design perspective.
On Wednesday, March 6, 2019 6:09 PM, Sebastian Wick
wrote:
> This protocol allows clients to attach a color space and rendering
> intent to a wl_surface. It further allows the client to be informed
> which color spaces a wl_surface was converted to on the last presented.
>
> Signed-off-by: Sebastian Wick
> ---
> Makefile.am | 1 +
> unstable/color-management/README | 4 +
> .../color-management-unstable-v1.xml | 189 ++
> 3 files changed, 194 insertions(+)
> create mode 100644 unstable/color-management/README
> create mode 100644 unstable/color-management/color-management-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 345ae6a..80abc1d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -23,6 +23,7 @@ unstable_protocols =
> \
> unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \
>
> unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
> \
> unstable/primary-selection/primary-selection-unstable-v1.xml
> \
> + unstable/color-management/color-management-unstable-v1.xml
> \
> $(NULL)
>
> stable_protocols =
> \
> diff --git a/unstable/color-management/README
> b/unstable/color-management/README
> new file mode 100644
> index 000..140f1e9
> --- /dev/null
> +++ b/unstable/color-management/README
> @@ -0,0 +1,4 @@
> +Color management protocol
> +
> +Maintainers:
> +Sebastian Wick
> diff --git a/unstable/color-management/color-management-unstable-v1.xml
> b/unstable/color-management/color-management-unstable-v1.xml
> new file mode 100644
> index 000..47dd453
> --- /dev/null
> +++ b/unstable/color-management/color-management-unstable-v1.xml
> @@ -0,0 +1,189 @@
> +
> +
> +
> +
> +Copyright © 2019 Sebastian Wick
> +Copyright © 2019 Erwin Burema
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +
> +
> +
> +This protocol provides the ability to specify the color space
> +of a wl_surface. If further enumerates the color spaces currently
Typo: "It"
> +in the system and allows to query feedback about which color spaces
> +a wl_surface was converted to on the last present.
> +The idea behind the feedback system is to allow the client to do color
> +conversion to a color space which will likely be used to show the surface
> +which allows the compositor to skip the color conversion step.
Wording: the "which" repetition could be avoided by splitting this into two
sentences ("This would allow the compositor…").
> +
> +
> +
> +
> + The color manager is a singleton global object that provides access
> + to outputs' color spaces, let's you create new color spaces and attach
Typo: "lets"
> + a color space to surfaces.
> +
> +
> +
> +
> +render intents
This could probably be expanded to at least be a sentence.
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +Well-known color spaces
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +These fatal protocol errors may be emitted in response to
> +illegal color management requests.
> +
> +
> +
> +
> +
> +
> +Set the color space of a surface. The color space is double buffered,
> +and will be applied at the time wl_surface.commit of the
> corresponding
> +wl_surface is called.
Wording: "and will be applied on the next wl_surface.commit"
> +The render intent gives the comp
Re: [RFC wayland-protocols v2 0/1] Color Management Protocol
Hi, Comments inline On Tue, 12 Mar 2019 at 14:01, Pekka Paalanen wrote: > > On Thu, 7 Mar 2019 12:37:52 +0100 > Erwin Burema wrote: > > > Wed Mar 6 17:09:27 UTC 2019 Sebastian Wick : > > >... > > > > > 2. The whole pipeline should look something like > > > > > > [surface cs] -cs conversion-> [output cs] -tone mapping-> [output cs] > > >-degamma-> [output linear cs] -blending-> [output linear cs] -gamma-> > > >[output cs]. > > > > > >Where some parts can be skipped if e.g. surface cs == output cs or > > >surface and output are SDR. > > > > For expert/pro applications this is probably indeed the pipline > > needed, the only thing that troubles me here is, is that there no > > guarente that an output color space is well behaved so might still > > contain some non-linearities or other issues after the degamma > > process[1], so for non-expert/non-pro stuff that still cares to some > > extent for color a better pipeline might be > > [surface cs] -cs conversion-> [blending scene referred cs] -blending-> > > [blending scene referred cs] -tone mapping-> [blending output referred > > cs] -cs conversion-> [output cs] > > Of course since this requires two cs conversion steps this is not > > ideal for anything pro but the only blending operation that is > > guaranteed to be artifact free in output cs is bit blitting which is > > not something we want to limit compositors to. > > Hi Erwin, > > did you consider that the blending we talk about here is only alpha > blending with alpha in [0, 1] and 1-alpha coefficients and nothing > else? I forget who recently noted that alpha blending shouldn't cause > any problems since mathematically the result cannot exceed the source > space. > > Could you elaborate on the potential problems with the proposed > pipeline more? > Yes alpha blending can't exceed color space but can lead to color artifacts (if you ever edited/created a picture in sRGB and saw some dark/black borders that is one possible effect) Some of the problems of blending colors in non-linear spaces are described here: https://ninedegreesbelow.com/photography/linear-gamma-blur-normal-blend.html (not my site, has lots of pictures which hopefully makes the explanation a bit better) Theoretically this should be solved by degamma but there is no guarantee that after that operation a profile is well behaved (see https://ninedegreesbelow.com/photography/well-behaved-profile.html), it might be neither withe balanced nor normalized, in which case you will get similar artifacts as if working in a non-linear space. > Do you mean that the degamma mapping computed from the output color > profile might be so far off, that alpha blending would produce a > visibly wrong color on the monitor? > Yes, see above, also not sure if a degamma is always possible (especially with LUT based profiles) Graeme Gill can probably give a more complete answer here. Although this will be a bigger issue on cheap consumer monitors then expensive pro-ones. > I would lean on taking that risk though, to have support for "pro > applications". People would definitely be upset if "pro apps" were not > properly supported, while alpha blending is usually just for visual > special effects like rounded corners or fade-in/out animations and > other less important window system gimmicks. I also do not see the > latter important enough to warrant implementing both ways in a > compositor. > If you can be sure alpha blending is only used for effects and nothing else this is an acceptable trade off but blending HDR and non-HDR content should probably be done in a scene referred color space which the output one isn't (even if it is degammaed) which means that in some cases you might need/want the second way anyway, that said pro-applications that deal with both HDR and non-HDR content should probably take care of the critical parts of the blending itself and output in HDR (so only the user interface would then be non-HDR) > > > > > ... > > > > > 3. Do the standard color spaces actually improve anything? When the > > > compositor doesn't have to make them available to clients and they > > > can't rely on them being available, what's the point? Especially when > > > displays don't really support standard color spaces most of the time > > > (according to the EDID). > > > > The point (to me at least) is that if a program uses one of the > > default/standard color space we can mostly assume that they are not > > extremely color critical and can use an intermediate blending space, > > anything that renders directly to an output they are displayed on > > should be considered color critical, in which case a compositor should > > follow your proposed pipeline (maybe without degamma/gamma since we > > should be bit blitting by then anyway). Now an alternative to this > > might be to let programs set ICC profiles (RGB ones only of course) in > > which case so long as it is not an output profile it should be fine to > > use a blending space.
Re: [RFC wayland-protocols v2 0/1] Color Management Protocol
On Wed, 6 Mar 2019 18:09:27 +0100 Sebastian Wick wrote: > Sending in v2 with small fixes only. I'm using this in the hope to focus > the previous discussion in the direction of the actual protocol and > implementation. > > It looks like we have come to at least some consensus on a few points. > If anyone disagrees here that would be great to know. > > 1. The color management protocol should contain support for HDR. I've >previously argued against it but everyone else seems to agree and I >don't have a strong opinion. > > 2. The whole pipeline should look something like > >[surface cs] -cs conversion-> [output cs] -tone mapping-> [output cs] >-degamma-> [output linear cs] -blending-> [output linear cs] -gamma-> >[output cs]. > >Where some parts can be skipped if e.g. surface cs == output cs or >surface and output are SDR. > > 3. A CMS (like lcms2) can create a 3d lut which the pipeline can use to >do the color space conversion from two 3 channel ICC profiles and a >rendering intent. > > 4. A CMS can also create a 1d lut from the same data to linearize a >surface from the output color space (degamma, gamma). > > 5. Device link profiles don't offer enough information to correctly do >blending and convert to a random output color space. > > 6. The client should know which color spaces the surface is likely going >to be converted to. > > 7. The CRTC gamma lut belongs to the compositor and no client should be >able to directly change it. Hi Sebastian, all the above sounds good to me. > Which brings me to open issues: > > 2. How exactly should the client be informed of the "prefered" color >spaces? >IMO there are a few requirements: >* the client should know when the prefered color space changes >* the client should know when multiple color spaces are involved >* the priority of those color spaces >The single "prefered" color space that can be requested doesn't meet >those requirements, neither does the wl_output.enter/leave (missing >priority) nor does my protocol (moving the surface to another output >will not trigger any new events). >Another point here is that wl_output actually doesn't map to a single >but multiple color spaces (e.g. cloned display). >Better ideas are very welcome! Actually, a single wl_output should correspond to a single monitor... if you are to believe my clone mode implementation in Weston. I think that is still not fully decided on how cloned monitors should be exposed. My rationale is based on wl_output exposing the monitor make and model. If you take color spaces instead of wl_outputs, then that issue disappears. Let's say you find a way to expose a priority list of color spaces that the compositor would prefer. It will not exempt the compositor from having to support arbitrary color spaces from custom ICC profiles with three channels. How would a client choose what color profile to use? I'm thinking this: - If the client cannot do color transformations efficiently itself or doesn't care, it picks whatever color space its content already has. The compositor can probably do it much more efficiently. - If the client can do color transformation efficiently or even produce the content in any given color space, it would want to pick the color space that saves the compositor's work the most. What kind of use case am I missing where it would be beneficial for the client to have a priority list to choose from? Thanks, pq pgpclvgcAWE7C.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols v2 1/1] unstable: add color management protocol
On Wed, 6 Mar 2019 18:09:28 +0100 Sebastian Wick wrote: > This protocol allows clients to attach a color space and rendering > intent to a wl_surface. It further allows the client to be informed > which color spaces a wl_surface was converted to on the last presented. > > Signed-off-by: Sebastian Wick > --- > Makefile.am | 1 + > unstable/color-management/README | 4 + > .../color-management-unstable-v1.xml | 189 ++ > 3 files changed, 194 insertions(+) > create mode 100644 unstable/color-management/README > create mode 100644 unstable/color-management/color-management-unstable-v1.xml > + > + > + The color manager is a singleton global object that provides access > + to outputs' color spaces, let's you create new color spaces and attach > + a color space to surfaces. > + Hi, this interface is missing the destructor. Thanks, pq pgpISaF1aw3Ow.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols v2 0/1] Color Management Protocol
On Thu, 7 Mar 2019 12:37:52 +0100 Erwin Burema wrote: > Wed Mar 6 17:09:27 UTC 2019 Sebastian Wick : > >... > > > 2. The whole pipeline should look something like > > > > [surface cs] -cs conversion-> [output cs] -tone mapping-> [output cs] > >-degamma-> [output linear cs] -blending-> [output linear cs] -gamma-> > >[output cs]. > > > >Where some parts can be skipped if e.g. surface cs == output cs or > >surface and output are SDR. > > For expert/pro applications this is probably indeed the pipline > needed, the only thing that troubles me here is, is that there no > guarente that an output color space is well behaved so might still > contain some non-linearities or other issues after the degamma > process[1], so for non-expert/non-pro stuff that still cares to some > extent for color a better pipeline might be > [surface cs] -cs conversion-> [blending scene referred cs] -blending-> > [blending scene referred cs] -tone mapping-> [blending output referred > cs] -cs conversion-> [output cs] > Of course since this requires two cs conversion steps this is not > ideal for anything pro but the only blending operation that is > guaranteed to be artifact free in output cs is bit blitting which is > not something we want to limit compositors to. Hi Erwin, did you consider that the blending we talk about here is only alpha blending with alpha in [0, 1] and 1-alpha coefficients and nothing else? I forget who recently noted that alpha blending shouldn't cause any problems since mathematically the result cannot exceed the source space. Could you elaborate on the potential problems with the proposed pipeline more? Do you mean that the degamma mapping computed from the output color profile might be so far off, that alpha blending would produce a visibly wrong color on the monitor? I would lean on taking that risk though, to have support for "pro applications". People would definitely be upset if "pro apps" were not properly supported, while alpha blending is usually just for visual special effects like rounded corners or fade-in/out animations and other less important window system gimmicks. I also do not see the latter important enough to warrant implementing both ways in a compositor. > > > ... > > > 3. Do the standard color spaces actually improve anything? When the > > compositor doesn't have to make them available to clients and they > > can't rely on them being available, what's the point? Especially when > > displays don't really support standard color spaces most of the time > > (according to the EDID). > > The point (to me at least) is that if a program uses one of the > default/standard color space we can mostly assume that they are not > extremely color critical and can use an intermediate blending space, > anything that renders directly to an output they are displayed on > should be considered color critical, in which case a compositor should > follow your proposed pipeline (maybe without degamma/gamma since we > should be bit blitting by then anyway). Now an alternative to this > might be to let programs set ICC profiles (RGB ones only of course) in > which case so long as it is not an output profile it should be fine to > use a blending space. I do not think building in such assumptions, that a client that uses a predefined color space would be somehow less color-critical, is a good idea. If there must be a notion of less and more color-critical, they would need to be exactly defined and explicitly communicated in the protocol. I suspect defining and implementing such things would be quite difficult. Thanks, pq > --- > [1] If that is even possible, although if we run into that case we are > probably dealing with a cheap consumer monitor that someone has > calibrated/profiled to get the best out of it > > Kind Regards, > > Erwin Burema pgplKzHe9nYEW.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
Michel Dänzer wrote: > It was never reliable for that. Other clients using any of those > mechanisms could always interfere, at least for the RandR compatibility > output. I disagree. It was reliable in the sense that running the profile loader set it to a known state, irrespective of whatever other applications may have done via other API's. With the behavior changed to combine all the API settings, there is no simple way to set it to a known state. > To make all these mechanisms work reliably and consistently at all times. Except it has the opposite effect in a color management sense ! > If you have specific suggestions, please post them to the xorg-devel > mailing lists or create a merge request at > https://gitlab.freedesktop.org/xorg/xserver/merge_requests . Fair enough. Cheers, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: 2019 X.Org Foundation Election Candidates
On Tue, Mar 12, 2019 at 12:24:00AM +, Wentland, Harry wrote: > To all X.Org Foundation Members: > > The election for the X.Org Foundation Board of Directors will begin on > 14 March 2019. We have 6 candidates who are running for 4 seats. They > are (in alphabetical order): > Attached below are the Personal Statements each candidate submitted > for your consideration along with their Statements of Contribution > that they submitted with the membership application. Please review > each of the candidates' statements to help you decide whom to vote for > during the upcoming election. > > If you have questions of the candidates, you should feel free to ask them > here on the mailing list. > > The election committee will provide detailed instructions on how the voting > system will work when the voting period begins. > > Harry, on behalf of the X.Org elections committee Are these candidates the only thing we will be voting on? Luc Verhaegen. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Mon, 11 Mar 2019 21:12:14 +0100 Victor Berger wrote: > All this to say: I'd really appreciate if the discussions regarding > wayland-protocols specifically could be done in a medium to which it > would be possible to subscribe independently from weston/libwayland. Be > it a gitlab repo or a dedicated mailing-list, I don't really care as > long as I can filter them automatically into different folders of my > mail client. Hi Victor, now that we have turned merge requests on for libwayland, I think we have pretty much reached the state you wish for. When wayland-protocols gets its gitlab.fd.o repository, I expect most of protocol development to happen there, leaving the wayland-devel@ mailing list essentially for announcements and questions. Would that be good for you? You probably need to set up your filters to look at some additional headers. Oh, and libinput. I guess libinput has moved to Gitlab merge requests too, at least they have it enabled. Libinput might still use wayland-devel@ for annoucements and questions. > > Now, I fully understand that Smithay is still a pretty small project > with little to no influence, and my lack of participation in any recent > discussions on this mailing does no help with that, so I guess I'm not > legitimate at making any requests of this kind. Please just take this as > an attempt at constructive feedback. :) > > I'll see to take some time to carefully read the rest of this thread and > make any relevant contribution I can. One has to start somewhere, you are welcome. :-) Thanks, pq pgpusaFue3iAO.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
