Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol

On Wed, Mar 6, 2019 at 9:53 PM Graeme Gill wrote: > > Right, but I don't think that's relevant to alpha blending in a per channel > linearized device space. I totally missed that this is only alpha blending. I was thinking general purpose for arbitrary blending, e.g. the now ISO defined (via

Re: HDR support in Wayland/Weston

On Wed, Mar 6, 2019 at 10:02 PM Graeme Gill wrote: > > Chris Murphy wrote: > > > Hmmm. For a while now we've had display calibration+profiling > > applications compel full screen mode so they're not really usable > > alongside anything else. They are in effect taking over. So if it's > > possible

Re: HDR support in Wayland/Weston

Chris Murphy wrote: > Hmmm. For a while now we've had display calibration+profiling > applications compel full screen mode so they're not really usable > alongside anything else. They are in effect taking over. So if it's > possible for the calibration app to set aside the Wayland session, use >

Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol

Chris Murphy wrote: Hi Chris, > Real displays often are not gray balanced. Calibration should achieve > this, often it can't. What if the display is characterized and not > calibrated to force R=G=B to be a neutral. And also what is neutral? > Usually the black point xy (chromaticity, CIE xyY

Re: HDR support in Wayland/Weston

Michel Dänzer wrote: > As of xserver 1.19, if the Xorg driver calls xf86HandleColormaps(), all > relevant mappings (colormap, global gamma, xf86VidMode per-X-screen > ramp, RandR per-CRTC ramp) are composed, and the result is applied to > the hardware LUT for all CRTCs. Hmm. Yuk from a color

Re: HDR support in Wayland/Weston

Adam Jackson wrote: > Sure, but one would not expect to control the display's global > calibration state from an X client in this model, for broadly the same > reasons that RANDR under Xwayland is read-only. The wayland server owns > that state, the Xwayland server is simply a very demanding

Re: HDR support in Wayland/Weston

On Wed, Mar 6, 2019 at 7:12 PM Graeme Gill wrote: > > Carsten Haitzler wrote: > > for the purposes of calibration, imho a calibration tool should just use > > drm/kms directly and run in a console outside of wayland. > > Sorry, but that's a total non-starter. Calibration & profiling > tools are

Re: HDR support in Wayland/Weston

Carsten Haitzler wrote: > On Wed, 6 Mar 2019 16:37:55 +1100 Graeme Gill said: > it involves a screen or set of screens "flashing" between different > colorspaces. it's much the same kind of effect of ye olde colormap installs. > not as extreme, but still the entire screen content changing

Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol

Niels Ole Salscheider wrote: Hi, > We added the device link profiles for "professional" applications that want > to > have full control. Right, but with the availability of wl_surface.enter/leave events, the client can keep track of which displays the surface is mapped to, and do its own

Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol

Kai-Uwe wrote: Hi Kai-Uwe, > See above. Without offloading the conversion to the compositor, that > will be typical slower. Maybe I am wrong? But I do not see too many > applications doing GPU color management by their own. For certain they > do not share the color transforms in memory. but the

[PATCH] wayland-util.h: add forward declaration for wl_object

The definition of wl_argument in wayland-util.h references wl_object, so wl_object ought to be defined in wayland-util.h. This resolves gitlab issue #78. --- src/wayland-util.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/wayland-util.h b/src/wayland-util.h index

Re: HDR support in Wayland/Weston

On Wed, Mar 6, 2019 at 3:15 AM Carsten Haitzler wrote: > > for the purposes of calibration, imho a calibration tool should just use > drm/kms directly and run in a console outside of wayland. it then owns the > display. it's not like it's a commonly used tool (likely once on purchase of a > gpu

Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol

On Wed, Mar 6, 2019 at 5:28 AM Pekka Paalanen wrote: > > On Wed, 6 Mar 2019 13:44:39 +1100 > Graeme Gill wrote: > > > Blending could convert from the device space back > > to XYZ, blend, and then convert back to device space. > > It would use whatever intent is appropriate for blending > >

[RFC wayland-protocols v2 1/1] unstable: add color management protocol

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 +

[RFC wayland-protocols v2 0/1] Color Management Protocol

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

Re: HDR support in Wayland/Weston

On 2019-03-06 5:00 p.m., Adam Jackson wrote: > On Wed, 2019-03-06 at 15:52 +1100, Graeme Gill wrote: >> Adam Jackson wrote: >> >>> The second, which games typically use, is setting per-channel gamma >>> (implicitly for the whole screen) as single floating-point values with >>> the xf86vidmode

Re: HDR support in Wayland/Weston

On Wed, 2019-03-06 at 15:52 +1100, Graeme Gill wrote: > Adam Jackson wrote: > > > X kinda has three mechanisms for this. The first one, that nobody > > really uses, is setting the colormap for a DirectColor visual. > > Actually this is something I check and set to linear before > calibration &

RE: [RFC wayland-protocols v2 1/1] Add the color-management protocol

Regards Shashank > -Original Message- > From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On > Behalf Of Pekka Paalanen > Sent: Wednesday, March 6, 2019 7:10 PM > To: Graeme Gill ; Niels Ole Salscheider > ; Sebastian Wick > ; > Nautiyal, Ankit K > Cc: Kai-Uwe ;

Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol

On Wed, 6 Mar 2019 21:26:56 +1100 Graeme Gill wrote: > I'm maintaining a summary of my current thinking here: > for anyone interested. Hi Graeme, so very good you made a write-up! The email threads are growing unwieldy to search for a specific topic

Re: EXT: Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow

On Wed, 6 Mar 2019 at 04:49, Ray, Ian (GE Healthcare) wrote: > > > > > On 6 Mar 2019, at 11.28, Pekka Paalanen wrote: > > > > Going once, going twice... > > > > Any objections? More acks? Acked-by: Derek Foreman Personally, I really see no harm in pushing this during code freeze, since it's

Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol

On Wed, 6 Mar 2019 13:44:39 +1100 Graeme Gill wrote: > Pekka Paalanen wrote: > > Sebastian's protocol proposal includes render intent from applications. > > Conversion of client content to the blending space should ideally be > > lossless, so the render intent in that step should be irrelevant

[PATCH wayland 1/2] tests: add request_bogus_size

From: Pekka Paalanen This attempts to reproduce the error conditions from https://gitlab.freedesktop.org/wayland/wayland/issues/52 and make it crash. While the crash was repeatable in my tests, it depends on garbage on stack leading to access of invalid memory, which is not guaranteed. This is

[PATCH wayland 2/2] connection: fix demarshal of invalid header

From: Pekka Paalanen 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

Re: EXT: Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow

> On 6 Mar 2019, at 11.28, Pekka Paalanen wrote: > > Going once, going twice... > > Any objections? More acks? > > Let's say I'll push this and enable MRs on Friday if there are no > further comments. More acks and I might do it sooner. :-) > > LGTM Acked-by: Ian Ray > Thanks, > pq >

Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol

Pekka Paalanen wrote: Hi, > I'm still wondering, if an application uses an ICC profile for the > content it provides and defines an intent with it, should a compositor > apply that intent when converting from application color space to the > blending color space in the compositor? yes it

Re: HDR support in Wayland/Weston

On Wed, 6 Mar 2019 16:37:55 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > apps should not have exclusive access. we're re-doing the whole horrid > > "install colormap" thing from the x days of 256 color (or > > paletted/colormapped displays). > > It's not quite the same

Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow

On 27/02/19 11:35 pm, Pekka Paalanen wrote: From: Pekka Paalanen The experience from Weston shows that the Gitlab merge request based workflow works really well. Recently there have also been issues with the mailing list that have made the email based workflow more painful than it used to be.

Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow

Going once, going twice... Any objections? More acks? Let's say I'll push this and enable MRs on Friday if there are no further comments. More acks and I might do it sooner. :-) Thanks, pq On Wed, 27 Feb 2019 12:35:09 +0200 Pekka Paalanen wrote: > From: Pekka Paalanen > > The experience

Re: [PATCH v8 1/6] tests: use /dev/fd to count open fds

On Mon, 4 Mar 2019 13:53:56 +0200 Pekka Paalanen wrote: > On Wed, 27 Feb 2019 21:13:08 +0200 > Leonid Bobrov wrote: > > > *BSD don't have /proc/self/fd, they use /dev/fd instead. > > At Linux /dev/fd is a symlink to /proc/self/fd > > > > Signed-off-by: Leonid Bobrov > > --- > >