Re: [RFC wayland-protocols] Color management protocol

On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone wrote: > Hi Graeme, > > On 17 December 2016 at 10:16, Graeme Gill wrote: >>> then no need for any extension. :) compositor HAs to be involved to at >>> least >>> tell you the colorspace of the monitor...

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

Hello Daniel, Am 20.12.2016 um 17:44 schrieb Daniel Stone: > On 20 December 2016 at 14:46, Kai-Uwe wrote: >> Am 20.12.2016 um 15:25 schrieb Daniel Stone: >>> On 19 November 2016 at 16:29, Niels Ole Salscheider + + +This request returns a

Re: [RFC wayland-protocols] Color management protocol

Hi Chris, On 20 December 2016 at 18:11, Chris Murphy wrote: > On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone wrote: >> On 17 December 2016 at 10:16, Graeme Gill wrote: >>> As I've explained a few times, and extension is

Re: [RFC wayland-protocols] Color management protocol

Hi, I'm going to be very blunt here, because the attitude, arrogance, lack of respect and civility, and general unwillingness to see a point demonstrated by multiple people in this thread is perhaps the worst I've ever seen on this list. I recommend you re-read Pekka's emails a couple of times

Re: [RFC wayland-protocols] Color management protocol

On Tue, Dec 20, 2016 at 11:33 AM, Daniel Stone wrote: > Hi Chris, > > On 20 December 2016 at 18:11, Chris Murphy wrote: >> On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone wrote: >>> On 17 December 2016 at 10:16, Graeme Gill

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

Carsten Haitzler (The Rasterman) wrote: > it's a different mapping of byte1, byte2, byte3 within a pixel to different > r,g > and b points in the visible spectrum. :) It's not though - it's colorimetry, so there is no control over the visible spectrum - the spectral characteristic is determined

Re: [PATCH] gestures: if fingers don't move, force a gesture by finger position

On Tue, Dec 20, 2016 at 12:20:38PM +0100, Hans de Goede wrote: > Hi, > > On 20-12-16 04:57, Peter Hutterer wrote: > > If the fingers rest on the touchpad without moving for a timeout, switch to > > pinch or swipe based on the finger position. We already did so for > > two-fingers > > switching

Re: [RFC wayland-protocols] Color management protocol

Pekka Paalanen wrote: > On Tue, 20 Dec 2016 15:17:31 +1100 > Graeme Gill wrote: > When I was talking about configuration, your reply talks about content > delivery. We are continuously talking past each other. I talk about one > thing, you deliberately interpret me talking

Re: [RFC wayland-protocols] Color management protocol

On Tue, Dec 20, 2016 at 3:54 PM, Graeme Gill wrote: > But from the the calibration application writers point of view, > to write such an application it's very highly desirable > (i.e. may make the difference between such an application > existing or not) that there be a

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

Kai-Uwe wrote: > PDF, SVG2 require handling of different blending color spaces. So the > interface appears to be useful. Yes, but would the compositor really be used to implement this ? My assumption is that blending is a facility to allow the window manager to create various visual effects,

Re: [RFC wayland-protocols] Color management protocol

Pekka Paalanen wrote: > When one integrates a CMS in a compositor, you no longer need to > expose configuration (hardware configuration, like CLUT programming) > via any protocol. The compositor talks directly with the CMS and if the > compositor can set e.g. CLUTs, CMS can tell it what to set.

Re: [RFC wayland-protocols] Color management protocol

Daniel Stone wrote: Hi Daniel, > That's one way of looking at it, yes. But no, the exact thing you're > describing will never occur for any reason. If you'd like to take a > step back and explain your reasoning, as well as the alternate > solutions you've discarded, then that's fine, but

Re: [RFC wayland-protocols] Color management protocol

On Tuesday, 20 December 2016, 13:38:55 CET, Graeme Gill wrote: > Niels Ole Salscheider wrote: > > Yes, exactly. But these are things that do not use the "normal" wayland > > protocols but are initiated by the compositor. > > I'm not sure what you mean by that. Why should the compositor launch >

Re: [RFC wayland-protocols] Color management protocol

Richard Hughes wrote: > On 20 December 2016 at 07:22, Graeme Gill wrote: >> Or be prepared to re-visit Wayland's fundamental design decisions >> if they turn out to be based on a false premise. > > I don't think that's fair. I think Wayland is the opportunity to upset >

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

Daniel Stone wrote: Hi, > If there was a per-output blending colourspace (as well as final > display colourspace), that would make a great deal more sense to me. Agreed. It depends on what is demanded of this blending colorspace - if the demands are not highly critical, then either blending in

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

Daniel Stone wrote: Hi, > it. Some KMS devices can perform per-plane colour management > (typically a variable-depth degamma LUT, 3x3 CTS matrix and re-gamma > LUT), such that a non-fullscreen client can have correct colour > conversion, independent of any compositor rendering. there's

Re: [RFC wayland-protocols] Color management protocol

Hi Chris, > So the traditional way of making absolutely certain no program can > hose the workflow is this crude lever in the video card. If you can > come up with an equivalently sure fire reliable s that doesn't demand > that the user draw up a list of "don't ever run these programs" while >

Re: [RFC wayland-protocols] Color management protocol

Kai-Uwe wrote: > Maybe the device link is kind of a extension for later implementation. I'm not enthused by that - I'd rather have it there right from the start if no other practical means of an application doing the color conversion itself. To do otherwise means that it will never be uniformly

[PATCH v2 libinput] gestures: if fingers don't move, force a gesture by finger position

If the fingers rest on the touchpad without moving for a timeout, switch to pinch or swipe based on the finger position. We already switched to two-finger scrolling based on the timeout, now we also do so for 3 and 4 finger gestures. This gives us better reaction to small movements. This also

[PATCH libinput] test: add test for the vertical position-dependent pinch

Signed-off-by: Peter Hutterer --- test/gestures.c | 55 +++ test/litest.c | 6 ++ test/litest.h | 3 +++ 3 files changed, 64 insertions(+) diff --git a/test/gestures.c b/test/gestures.c index

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

On Tue, 20 Dec 2016 16:46:07 + Daniel Stone said: > Hi, > > On 19 December 2016 at 02:08, Carsten Haitzler wrote: > > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider > > said: > >> + > >> + > >> +

Re: [RFC wayland-protocols] Color management protocol

Daniel Stone wrote: Hi, > I'm going to be very blunt here, because the attitude, arrogance, lack > of respect and civility, and general unwillingness to see a point > demonstrated by multiple people in this thread is perhaps the worst > I've ever seen on this list. I'll agree with that. It's

Re: [RFC wayland-protocols] Color management protocol

Niels Ole Salscheider wrote: Hi, >> Why is that so, given that compositor at the end of the Wayland >> protocol has the job of managing graphics hardware ? > > Because wayland does not have protocols for configuration as others have > pointed out. There isn't even a protocol to change the

Re: [RFC wayland-protocols] Color management protocol

On Tue, 20 Dec 2016 15:17:31 +1100 Graeme Gill wrote: > Pekka Paalanen wrote: > >> Since Wayland doesn't currently implement any color management support, > >> I'm not following how it can be a step backwards. > > > > It is step towards "clients are in control and the

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

On Tue, 20 Dec 2016 18:25:40 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > > what if the display can do different color profiles for different regions? > > my example is yuv colorspace. 601 vs 709 etc. actually can be assigned per > > hw plane...

Re: [PATCH libinput 1/4] test: don't set LITEST_VERBOSE during make check

Hi, On 20-12-16 03:51, Peter Hutterer wrote: I've never had the log output help me identify a bug during a test run. Now that we run all tests in the same binary the verbosity just leads to a massive file that makes it hard to find the actual failure. Turn off LITEST_VERBOSE by default but

Re: Remote display with 3D acceleration using Wayland/Weston

On Mon, 19 Dec 2016 13:23:26 -0600 DRC wrote: > On 12/19/16 2:48 AM, Pekka Paalanen wrote: > > Hmm, indeed, maybe it would be possible if you are imposing your own > > EGL middle-man library between the application and the real EGL library. > > > > That's

Re: [PATCH 00/13] Revamp touchpad acceleration code

Hi, On 19-12-16 06:20, Peter Hutterer wrote: This patchset is a cleanup and revamp of the touchpad acceleration code. It doesn't give us perfect acceleration, but it goes from the current rather abysimal state to one that should at least be good enough most of the time. More tweaking will come,

Re: [PATCH] gestures: if fingers don't move, force a gesture by finger position

Hi, On 20-12-16 04:57, Peter Hutterer wrote: If the fingers rest on the touchpad without moving for a timeout, switch to pinch or swipe based on the finger position. We already did so for two-fingers switching to scrolling, now we also do so for 3 and 4 finger gestures. This gives us better

Re: [RFC wayland-protocols] Color management protocol

On Mon, 19 Dec 2016 08:04:48 -0700 James Feeney wrote: > On 12/19/2016 03:04 AM, Pekka Paalanen wrote: > > We very deliberately avoid defining any "standard" Wayland interfaces > > for configuring a compositor, because every compositor is different. > > With X11, you had the

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

Hi Niels, Just nitpicking at the protocol side of things a little bit; please excuse what I'm sure is a horrific abuse of the terminology, contained in what I'm sure is a series of stupid questions. On 19 November 2016 at 16:29, Niels Ole Salscheider wrote: > +

Re: [RFC wayland-protocols] Color management protocol

Am 20.12.2016 um 14:08 schrieb Pekka Paalanen: > On Tue, 20 Dec 2016 13:05:10 +0100 > Kai-Uwe wrote: > Oh nice. So indeed, CMS belongs in the compositor too (not only > clients), because it is the window manager in the Wayland architecture. The compositor has at least access to

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

Am 20.12.2016 um 15:25 schrieb Daniel Stone: > On 19 November 2016 at 16:29, Niels Ole Salscheider > wrote: >> + >> + >> +This request allows to create a zwp_colorspace_v1 object from an ICC >> +profile. The fd argument is the file

Re: [RFC wayland-protocols] Color management protocol

On Tue, 20 Dec 2016 13:05:10 +0100 Kai-Uwe wrote: > Am 20.12.2016 um 10:08 schrieb Pekka Paalanen: > > Niels had an extremely good point that compositors *can* do all the > > hard stuff too, by using the libraries the CMS experts have written. > > This is not the X11 where you

Re: [RFC wayland-protocols] Color management protocol

Am 20.12.2016 um 03:38 schrieb Graeme Gill: > Niels Ole Salscheider wrote: >> What MIGHT be possible is that an application provides the complete surface >> in >> all color spaces of all outputs so that the compositor can use the parts it >> needs. > > Yes, that's an interesting thought. It

Re: [RFC wayland-protocols] Color management protocol

Am 20.12.2016 um 10:08 schrieb Pekka Paalanen: > Niels had an extremely good point that compositors *can* do all the > hard stuff too, by using the libraries the CMS experts have written. > This is not the X11 where you cannot add these features and > dependencies to the X server. That's not

Re: [RFC wayland-protocols] Color management protocol

On 20 December 2016 at 07:22, Graeme Gill wrote: > Or be prepared to re-visit Wayland's fundamental design decisions > if they turn out to be based on a false premise. I don't think that's fair. I think Wayland is the opportunity to upset the status quo with color

[PATCH] wayland-server: Destroy Clients upon wl_display_destroy()

From: "Vivek.A" Without this, client socket file descriptors are being kept open until the process hosting the compositor gets terminated / exit. This causes compositor termination goes undetected through its fd. This could be reproduced by having

Re: [RFC wayland-protocols] Color management protocol

Hi Graeme, On 17 December 2016 at 10:16, Graeme Gill wrote: >> then no need for any extension. :) compositor HAs to be involved to at >> least >> tell you the colorspace of the monitor... as the screen is its resource. > > As I've explained a few times, and extension is

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

Hi Kai-Uwe, On 20 December 2016 at 14:46, Kai-Uwe wrote: > Am 20.12.2016 um 15:25 schrieb Daniel Stone: >> On 19 November 2016 at 16:29, Niels Ole Salscheider >>> + >>> + >>> +This request returns a zwp_colorspace_v1 object for the blending >>> color >>> +

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

Hi, On 19 December 2016 at 02:08, Carsten Haitzler wrote: > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider > said: >> + >> + >> + This interface represents a color space that can be attached to >> surfaces. >> + It