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

On Wed, Dec 21, 2016 at 5:49 PM, Carsten Haitzler wrote: > On Wed, 21 Dec 2016 12:24:33 -0700 Chris Murphy > said: > >> So... >> >> Do applications (wayland clients) choose what compositor to use? Each >> application could be using a different

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

On Wed, 21 Dec 2016 12:24:33 -0700 Chris Murphy said: > So... > > Do applications (wayland clients) choose what compositor to use? Each > application could be using a different compositor? > > Does it make any sense that there'd be three different classes of >

Re: A solution for gamma-adjustment support in Wayland

On Wed, Dec 21, 2016 at 4:57 AM, Daniel Stone wrote: > I also cannot disagree more with your assertion that 'it's bad enough > that colour management is done by the compositor'. The compositor is > the very thing between clients producing pixels, and the final output. > If

Re: [RFC wayland-protocols] Color management protocol

Hello Pekka, Am 21.12.2016 um 11:59 schrieb Pekka Paalanen: > On Wed, 21 Dec 2016 10:30:50 + > Richard Hughes wrote: > >> On 21 December 2016 at 09:14, Pekka Paalanen wrote: >> I think that's basically correct, argyllcms doesn't have any header >>

Re: A solution for gamma-adjustment support in Wayland

On Wed, 21 Dec 2016 21:05:13 +0100 Kai-Uwe wrote: > Hello Mattias, > > Am 21.12.2016 um 12:31 schrieb Mattias Andrée: > > If there is no API for these thinks, functionality > > such as inverting the colours, lowering the temperature, > > and (requires matrices) simulating

Re: [RFC wayland-protocols] Color management protocol

Hello Richard, Am 21.12.2016 um 11:30 schrieb Richard Hughes: > On 21 December 2016 at 09:14, Pekka Paalanen wrote: >> I suggest that compositors use the CMS you have spent so much time and >> effort perfecting, and you start with the assumption that they will not >> or

Re: A solution for gamma-adjustment support in Wayland

Hello Mattias, Am 21.12.2016 um 12:31 schrieb Mattias Andrée: > If there is no API for these thinks, functionality > such as inverting the colours, lowering the temperature, > and (requires matrices) simulating defective colour > vision must be done in the compositor. This is not > a sustainable

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

So... Do applications (wayland clients) choose what compositor to use? Each application could be using a different compositor? Does it make any sense that there'd be three different classes of compositor: no-color management, assume sRGB color management, and full color management (all objects

Re: [RFC wayland-protocols] Color management protocol

On Wed, Dec 21, 2016 at 5:05 AM, Daniel Stone wrote: >I'd like to attack and bottom out the > non-calibration usecase without muddying those waters, though ... What about games? I'm not aware of any color managed games. As far as I know they all assume deviceRGB and are

Re: [PATCH weston v2 04/24] xwayland: detect initially positioned X11 windows

On Wed, 21 Dec 2016 14:56:11 + Daniel Stone wrote: > Hi Pekka, > > On 21 December 2016 at 14:40, Pekka Paalanen wrote: > > @@ -2500,6 +2510,17 @@ legacy_fullscreen(struct weston_wm *wm, > > } > > > > static bool > >

Re: [PATCH weston v2 04/24] xwayland: detect initially positioned X11 windows

Hi Pekka, On 21 December 2016 at 14:40, Pekka Paalanen wrote: > @@ -2500,6 +2510,17 @@ legacy_fullscreen(struct weston_wm *wm, > } > > static bool > +weston_wm_window_is_positioned(struct weston_wm_window *window) > +{ > + if (window->map_request_x == INT_MIN || > +

[PATCH weston v2 23/24] xwm: do not draw decor twice on map

From: Pekka Paalanen Normal windows enter the MapRequest handler, which schedules drawing the decorations. Then Xwayland realizes the window, which ends with a call to xserver_map_shell_surface(). The decorations are already drawn, no need to draw them a second

[PATCH weston v2 08/24] libweston-desktop/xwayland: debug commits

From: Pekka Paalanen Helps tracking what happens with XWM. Use the same debugging guard as XWM. Signed-off-by: Pekka Paalanen --- libweston-desktop/xwayland.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH weston v2 21/24] xwm: debug when weston_surface gets created

From: Pekka Paalanen This comes via Wayland, WL_SURFACE_ID comes via X11. They race. Nice to get both printed. Signed-off-by: Pekka Paalanen --- xwayland/window-manager.c | 6 -- 1 file changed, 4 insertions(+), 2

[PATCH weston v2 18/24] xwm: move fini near init in set_pending_state

From: Pekka Paalanen Move the region fini just above the region init. They are a pair and belong togeether. Split a long line. Reads better this way. No functional changes. Signed-off-by: Pekka Paalanen ---

[PATCH weston v2 09/24] xwm: detect legacy fullscreen on MapRequest

From: Pekka Paalanen The legacy fullscreen state needs to be detected at MapRequest time, because that is when the X11 client has alredy set up the initial window state. Doing it at xserver_map_shell_surface() meant that it would be done as a response to Xwayland

[PATCH weston v2 11/24] xwm: move frame_set_title() into draw_decoration()

From: Pekka Paalanen The only thing using the frame title is frame_repaint(). Move the call to frame_set_title() from weston_wm_window_read_properties() into weston_wm_window_draw_decoration() where the only call to frame_repaint() is. Do not check for

[PATCH weston v2 19/24] xwm: split out weston_wm_window_set_pending_state_OR()

From: Pekka Paalanen Having it in a separate function makes it more clear what it is, and allows it to be called from elsewhere. This really is the set_pending_state() alternative for override-redirect windows, because OR windows do not get a frame window

[PATCH weston v2 17/24] xwm: split weston_wm_window_draw_decoration()

From: Pekka Paalanen Split the function into two: - weston_wm_window_draw_decoration() that only draws the decorations with Cairo, and - weston_wm_window_set_pending_state() which sets up the surface state to be latches into use on the next commit from Xwayland.

[PATCH weston v2 16/24] xwm: delete dead flags from weston_wm_window_draw_decorations()

From: Pekka Paalanen Obviously unused. Looks like weston_wm_window_activate() is doing that job. Signed-off-by: Pekka Paalanen --- xwayland/window-manager.c | 4 1 file changed, 4 deletions(-) diff --git

[PATCH weston v2 10/24] xwm: clarify props[] in weston_wm_window_read_properties()

From: Pekka Paalanen The props array contained offsets to struct members. It is convenient for writing static const arrays as you only store a constant offset and compute the pointer later. However, the array was not static to begin with, the atoms are not build

[PATCH weston v2 12/24] xwm: move set_title and set_pid

From: Pekka Paalanen Move the calls to set_title() and set_pid() out of weston_wm_window_read_properties() and into the three callers, each slightly different. xserver_map_shell_surface(): already calls these functions after creating the shell surface, so need to

[PATCH weston v2 22/24] xwm: explain the read_properties() in xserver_map_shell_surface()

From: Pekka Paalanen To me it was not obvious that this call is necessary, so provide some rationale. Signed-off-by: Pekka Paalanen --- xwayland/window-manager.c | 9 + 1 file changed, 9 insertions(+) diff --git

[PATCH weston v2 05/24] shell: implement set_xwayland_position

From: Pekka Paalanen Store the initial xwayland position explicitly in struct shell_surface. New variables are needed, because e.g. saved_x, saved_y are the view position, and to compute that we need the window geometry, which is not available before the first

[PATCH weston v2 24/24] xwm: use _XWAYLAND_ALLOW_COMMITS

From: Pekka Paalanen No more jumping windows on map. This patch uses the new feature proposed for Xwayland in the patch series https://patchwork.freedesktop.org/series/16610/ . When the frame window is created, immediately forbid Xwayland commits on it. This

[PATCH weston v2 20/24] xwm: schedule repaint from MapRequest

From: Pekka Paalanen When we as the WM tell the X server to map a window, it gets mapped. We can start drawing into it immediately. There is no reason to wait for any other events before drawing the decorations. Signed-off-by: Pekka Paalanen

[PATCH weston v2 15/24] xwm: postpone geometry dirtying from pending.opaque

From: Pekka Paalanen Changing the opaque region has no immediate effect, therefore there is no need to mark the view geometry dirty. The view geometry will be invalidated automatically by the next commit from Xwayland, in weston_surface_commit_state(). The

[PATCH weston v2 06/24] libweston-desktop/xwayland: react to geometry changes

From: Pekka Paalanen It so happens that Xwayland commits the first frame before XWM can set the geometry info, making initial window position act as if there were no decorations - the window position is off by the width of the decorations. Fix up the window

[PATCH weston v2 04/24] xwayland: detect initially positioned X11 windows

From: Pekka Paalanen X11 applications expect -geometry command line option to work for setting the initial window position, but currently this does not work. During map, detect X11 windows that set an explicit position. This works by heuristics: if window

[PATCH weston v2 13/24] xwm: debug changes to override-redirect flag

From: Pekka Paalanen For every event we handle and that delivers the override-redirect flag, print it to debug log. Add a comment to one code path explaining when it gets hit, because it is unobvious. It also serves as a reminder that we do not handle changes to

[PATCH weston v2 07/24] desktop-shell: debug set_position_from_xwayland

From: Pekka Paalanen Helps tracking what happens with XWM. Use the same debugging guard as XWM. Signed-off-by: Pekka Paalanen --- desktop-shell/shell.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH weston v2 01/24] xwayland: WM debug prints

From: Pekka Paalanen Add WM debug prints on map, decoration drawing and geometry setting. These help see the sequence and timing of operations, when debugging Xwayland window management glitches. Signed-off-by: Pekka Paalanen ---

[PATCH weston v2 03/24] libweston-desktop: add set_xwayland_position API

From: Pekka Paalanen X11 applications expect -geometry command line option to work for setting the initial window position, but currently this does not work. Add provision to relay the initial position through libweston-desktop: - weston_desktop_api gains a new

[PATCH weston v2 02/24] xwayland: add set_toplevel_with_position to internal API

From: Pekka Paalanen Add a new entry to the internal interface between the xwayland plugin and libweston-desktop (or any other desktop protocol implementation). The new entry is identical to set_toplevel except it carries an absolute position for the toplevel

[PATCH weston v2 00/24] Initial Xwayland window positioning, with XWM reordering

From: Pekka Paalanen Hi all, for the history and motivation of this series, please refer to: https://phabricator.freedesktop.org/T7622 Most importantly, you can see the introduction and motivation here:

[no subject]

ㅣ ⁣--- What You Think Is What You Get. Software will make your dream come true. Welcome, http://nicesj.com --- ​___

Re: [RFC wayland-protocols] Color management protocol

Hi Niels, On 21 December 2016 at 13:24, Niels Ole Salscheider wrote: > On Wednesday, 21 December 2016, 12:05:12 CET, Daniel Stone wrote: >> On 20 December 2016 at 20:49, Chris Murphy wrote: >> > For example a still very common form of

Re: [RFC wayland-protocols] Color management protocol

Hi Graeme, On 21 December 2016 at 02:57, Graeme Gill wrote: > Daniel Stone wrote: >> I recommend you re-read Pekka's emails a couple of times until they >> sink in. It is clear that you are extremely experienced in colour >> management; > > I think that applies in the

Re: [RFC wayland-protocols] Color management protocol

On Wednesday, 21 December 2016, 12:05:12 CET, Daniel Stone wrote: > Hi Chris, > > On 20 December 2016 at 20:49, Chris Murphy wrote: > > On Tue, Dec 20, 2016 at 11:33 AM, Daniel Stone wrote: > >> On 20 December 2016 at 18:11, Chris Murphy

Re: [RFC wayland-protocols] Color management protocol

Hi Niels, On 21 December 2016 at 11:21, Niels Ole Salscheider wrote: > Maybe the solution for profiling would then be to just use KMS for fullscreen > display and bypass the compositor completely? The profiling application could > do whatever it wants to the

Re: [RFC wayland-protocols] Color management protocol

Hi Chris, On 20 December 2016 at 20:49, Chris Murphy wrote: > On Tue, Dec 20, 2016 at 11:33 AM, Daniel Stone wrote: >> On 20 December 2016 at 18:11, Chris Murphy wrote: >>> We can't have multiple white points on the

Re: A solution for gamma-adjustment support in Wayland

Hi Mattias, On 21 December 2016 at 11:31, Mattias Andrée wrote: > On Wed, 21 Dec 2016 10:40:44 + Daniel Stone wrote: >> The point is that I'm extremely wary of copying X11 by >> way of encoding this into an API; it's a truly dizzying >> space to even

Re: [RFC wayland-protocols] Color management protocol

On Wed, 21 Dec 2016 11:38:41 +0200 Pekka Paalanen wrote: > On Wed, 21 Dec 2016 11:08:06 +1100 > Graeme Gill wrote: > > > Richard Hughes wrote: > > > Anything more and the application author will just > > > decide it's not worth the bother. To

Re: A solution for gamma-adjustment support in Wayland

On Wed, 21 Dec 2016 10:40:44 + Daniel Stone wrote: > Hi Mattias, > > On 14 December 2016 at 00:20, Mattias Andrée > wrote: > > There should also be a protocol for identifying > > whether a VDC have CLUT that can be edited, and whether > > the

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

On Wed, 21 Dec 2016 09:56:05 + Daniel Stone said: > Hi, > > On 21 December 2016 at 00:36, Carsten Haitzler wrote: > > On Tue, 20 Dec 2016 16:46:07 + Daniel Stone said: > >> On 19 December 2016 at 02:08, Carsten Haitzler

Re: [RFC wayland-protocols] Color management protocol

On Wednesday, 21 December 2016, 11:39:50 CET, Graeme Gill wrote: > 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

Re: [RFC wayland-protocols] Color management protocol

On Wed, 21 Dec 2016 10:30:50 + Richard Hughes wrote: > On 21 December 2016 at 09:14, Pekka Paalanen wrote: > > I suggest that compositors use the CMS you have spent so much time and > > effort perfecting, and you start with the assumption that they

Re: [RFC wayland-protocols] Color management protocol

Hey Richard, On 21 December 2016 at 10:30, Richard Hughes wrote: > On 21 December 2016 at 09:14, Pekka Paalanen wrote: >> so "just set the CLUT" is already an outdated approach > > This is another point: We're all talking about the >

Re: A solution for gamma-adjustment support in Wayland

Hi Mattias, On 14 December 2016 at 00:20, Mattias Andrée wrote: > There should also be a protocol for identifying whether a VDC have > CLUT that can be edited, and whether the compositor supports cooperative > gamma. The size and the depth of the CLUT should should also be >

A solution for gamma-adjustment support in Wayland

The following text is also available in PDF format at . Please CC me, I am not subscribed to the mailing-list. ### Abstract ### With the advent of Wayland, our display server has lost a functionality — access to the graphic cards’

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

Hi Graeme, On 21 December 2016 at 01:15, Graeme Gill wrote: > Daniel Stone wrote: >> However, another >> client could then come along and force your client off the plane, such >> that you land in the compositor's GPU pipeline before display: this >> rendering may be done

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

Hi, On 21 December 2016 at 00:36, Carsten Haitzler wrote: > On Tue, 20 Dec 2016 16:46:07 + Daniel Stone said: >> On 19 December 2016 at 02:08, Carsten Haitzler wrote: >> > so... here is my question - shouldn't the colorspace

Re: [RFC wayland-protocols] Color management protocol

On Wed, 21 Dec 2016 11:08:06 +1100 Graeme Gill wrote: > Richard Hughes wrote: > > Anything more and the application author will just > > decide it's not worth the bother. To calibrate we just ask for a > > surface that's not going to be tampered with, but we don't want to

Re: [RFC wayland-protocols] Color management protocol

On Wed, 21 Dec 2016 09:54:07 +1100 Graeme Gill wrote: > Pekka Paalanen wrote: > > > Why would you not let compositors use the CMS libraries people have > > developed? > > Nothing stopping them inventing their own color calibration and > profiling system. But can they

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

Hi, On 21-12-16 01:13, Peter Hutterer wrote: Signed-off-by: Peter Hutterer --- test/gestures.c | 55 +++ test/litest.c | 6 ++ test/litest.h | 3 +++ 3 files changed, 64 insertions(+) diff --git

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

Hi, On 21-12-16 01:12, 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 switched to two-finger scrolling based on the timeout, now we also do so for 3 and 4 finger gestures. This gives us