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

[The Rasterman]

On Wed, 21 Dec 2016 20:44:24 -0700 Chris Murphy  said:

> 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 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 are explicitly tagged and the
> >> compositor is doing display compensation with the help of e.g. lcms)?
> >> Or am I missing something about compositors?
> >
> > your choice of wm or desktop chooses your compositor. choose gnome? it'll be
> > mutter. choose enlightenment? it'll be enlightenment. choose kde? it'll be
> > kwin etc. etc. etc.
> 
> Aha OK. And how does Weston fit into it? Do any of them directly
> leverage Weston or is it just a reference to get Wayland support
> included?

it's the reference/test compositor. if you want a fully working desktop these
days it's gnome's mutter, enlightenment or more recently kde's kwin has been
catching up. there is a tiling wm called sway as well. that's the major
compositors that are actually meant for "every day" use. weston isn't something
i'd say is useful for day to day (not without a lot of extending/work).

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Chris Murphy]

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 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 are explicitly tagged and the
>> compositor is doing display compensation with the help of e.g. lcms)?
>> Or am I missing something about compositors?
>
> your choice of wm or desktop chooses your compositor. choose gnome? it'll be
> mutter. choose enlightenment? it'll be enlightenment. choose kde? it'll be 
> kwin
> etc. etc. etc.

Aha OK. And how does Weston fit into it? Do any of them directly
leverage Weston or is it just a reference to get Wayland support
included?

-- 
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

weston exits on HDMI unplug

[Francis Leblanc-Lebeau]

Hi !

I have built a Yocto image for the Aaeon EMB-BSW1 board  and for some unknown 
reason, weston quits when I disconnect the HDMI cable, even if there is an 
application running. I saw that it exited normally (not a segfault) by 
attaching the weston process with gdb. I am currently trying to add debug info 
to my setup...

Is there a reason for such behavior ? I search for such an bug/issue or config 
and I did not find anything.
I did found something about headless start support in the new 1.12 weston 
release, maybe it is related ?
Or maybe it is only a configuration issue ?

Setup info:
Weston 1.11.0
Wayland 1.11.0
Yocto Krogoth 2.1

Also see attachments weston.ini and weston.log (the disconnected HDMI is 
clearly seen with the timestamps).

Thanks a lot !
Francis Leblanc




weston.log
Description: weston.log


weston.ini
Description: weston.ini
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[The Rasterman]

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
> compositor: no-color management, assume sRGB color management, and
> full color management (all objects are explicitly tagged and the
> compositor is doing display compensation with the help of e.g. lcms)?
> Or am I missing something about compositors?

your choice of wm or desktop chooses your compositor. choose gnome? it'll be
mutter. choose enlightenment? it'll be enlightenment. choose kde? it'll be kwin
etc. etc. etc.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: A solution for gamma-adjustment support in Wayland

[Chris Murphy]

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 a compositor is unaware of how those pixels should be interpreted,
> then it is going to be destructive and do the wrong thing. If you want
> colour-accurate display, there is no good solution based on the
> premise that your display controller should have no idea about
> colours.

Sure but there is something to be said about making assumptions,
rather than requiring everything to be explicitly tagged. There are
advantages of compositing only in device RGB, even though blending in
non-linear encoded spaces has negative consequences.

For what it's worth on Windows with their newer GDI+ API uses scRGB as
the intermediate space, and since circa 2009 it supports a 48 bpc
float encoding for this; I'm not sure what the default is these days.
It has advantages for HDR and the simplicity that the primaries are
the same as Rec 709/sRGB, but it is in some sense a relic of a world
converging on sRGB. And that's not true anymore, clearly now there is
great divergence away from sRGB. Does that imply a need for a work
around and if so what would it be? In terms of quantization you can
pick almost any set of primaries if you're dedicating enough bits for
the transforms. That used to be expensive, and I'm not sure that's
true anymore either.

Pretty much anything that's going to involve any substantially complex
blending is going to need to do it in linear space, so that implies
everything has to be specified by the application in linear space, or
something has to intercept it and convert it to linear space before
compositing and blending. And linear space encoding also necessarily
implies high bit depth to avoid noticeable quantization.

It was about a decade ago I asked about encoding precision, so and so
is using 16 bit per channel, and a developer from a good sized company
said something like, "16 bits is so last decade we're only using 32
bpc float now". So now it's 10 years later and 32bpc float is now "so
last decade" but of course the orders of magnitude involved are quite
a bit greater. Not everything needs this many bits pushed around, but
if it's an architecture that could suitably replace what color managed
apps already do internally now, then it's needed at least as an option
that they can opt into.


-- 
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Kai-Uwe]

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
>> files or shared libraries. When using it to generate color profiles
>> for things like printers from gnome-color-manager I have to spawn the
>> binaries themselves (and only in a VT...) and then scrape the output.
>> https://git.gnome.org/browse/gnome-color-manager/tree/src/gcm-calibrate-argyll.c#n273
> 
> Oh, that's a huge surprise to me, being accustomed to open source.

At least the Oyranos CMS API is certainly able to integrate ArgyllCMS as
a CMM, despite Argyll providing only CLI interfaces. Oyranos CMS
provides libraries, tools. And GUIs and (X11) compositors use those
Oyranos libs.

>>> Yes! The CMS needs to provide the API that all compositors could use.  

> Sorry about the typo, I meant "an API", not "the API". We're not
> Khronos, indeed.
> 
> Just like programs can choose their toolkits, compositors should be
> able to choose their color management providers for calibration and
> color processing. We would still have the public and generic Wayland
> extension for providing color-managed content, so it would not affect
> normal application compatibility.

As a CMS author, who is much involved with the KDE community and working
as well for other DEs, I appreciate this openness. I wish to integrate
Oyranos CMS with Wayland/Weston.

colord is considerd very Gnome centric.

Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: A solution for gamma-adjustment support in Wayland

[Mattias Andrée]

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 defective colour
> > vision must be done in the compositor. This is not
> > a sustainable solution, an API is necessary. It's bad
> > enough that colour management is done by the
> > compositor.  
> 
> The compositor is a good place for doing color
> correction, as X11 and Wayland core developers had
> repeatedly suggested. I mentioned to you on the XDG list,
> that your API will be bypassed by any proper ICC based
> CMS and both might start fighting about
> resources/settings.

It will not. Each filter is given a priority that determines
the order the filters are applied. An ICC based colour
correction filter is given the priority 0. If the correction
is uses two filters, one for gamma and one for brightness
and contrast, the gamma has the priority 0 and the
brightness and contrast has the priority -0x4000   000.
Filters with higher priority are applied before filters with
lower priority. So their is a system in place to ensure that
it does not happen.

> That's no good I think. A ICC monitor
> profile has to set a calibration curve into the display
> pipeline. It does currently on X11 systems and Weston has
> some code to do as well CLUT setup. Without knowing each
> other that's a bug filler, which no one want (at least I
> hope).
> 
> For getting more specialised support into the compositor,
> the suggested surface device links for each output are
> very expressive [as discussed by Niels+Graeme+me in the
> color management thread]. A CMS can work with device
> links and add features without involving the application.
> So it can add device links on its discretion to surfaces,
> which do not have them already and support new features
> like the redshift curves or more advanced effects. That
> would be a big benefit for both communities I guess. For
> that to work seamless your curves, need to be abstracted
> and instead of curves are expressed as ICC profiles of
> type abstract. So a CMS can integrate them easily,
> without to know the bells and whistles redshift offers
> its users.
> 
> Kai-Uwe



pgpjHzHKy5KOJ.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] Color management protocol

[Kai-Uwe]

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 cannot do so. Why?
> 
> I think lcms2 is fine to use; it's widely used in other projects,
> tested, and already optionally used in weston.

For the simple shoot and forget interface for client color space
tagging, which Niels is thankfully working on, a CMS like littleCMS
might be well established, maintained, reviewed, audited and supported.

However as it is used in Weston, it has clipping and other not so good
side effects, but it is certainly valuable on its own for base color
correction. A different CMS can go beyond that and add more color
management features to the benefit of the while desktop not only some
esoteric clients, which support device links or other more powerful
expressions from their own GUIs.

Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: A solution for gamma-adjustment support in Wayland

[Kai-Uwe]

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 solution, an API is necessary. It's bad
> enough that colour management is done by the compositor.

The compositor is a good place for doing color correction, as X11 and
Wayland core developers had repeatedly suggested. I mentioned to you on
the XDG list, that your API will be bypassed by any proper ICC based CMS
and both might start fighting about resources/settings. That's no good I
think. A ICC monitor profile has to set a calibration curve into the
display pipeline. It does currently on X11 systems and Weston has some
code to do as well CLUT setup. Without knowing each other that's a bug
filler, which no one want (at least I hope).

For getting more specialised support into the compositor, the suggested
surface device links for each output are very expressive [as discussed
by Niels+Graeme+me in the color management thread]. A CMS can work with
device links and add features without involving the application. So it
can add device links on its discretion to surfaces, which do not have
them already and support new features like the redshift curves or more
advanced effects. That would be a big benefit for both communities I
guess. For that to work seamless your curves, need to be abstracted and
instead of curves are expressed as ICC profiles of type abstract. So a
CMS can integrate them easily, without to know the bells and whistles
redshift offers its users.

Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Chris Murphy]

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 are explicitly tagged and the
compositor is doing display compensation with the help of e.g. lcms)?
Or am I missing something about compositors?


Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Chris Murphy]

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 content with the user getting
something rather obviously less chromatic with less dynamic range on a
laptop, and rather more if they have a 4K TV, or a wide gamut display.
Do games typically draw through X or do they use DRM/KMS?

Video. This is such a rat hole of a mess right now. There are
different codecs with different color spaces, and some of the wrappers
imply different color handling on top of this, and then the user
agents all end up interpreting this mess differently so the same video
content can appear differently depending on user agent, and then
depending on platform. It's so bad. In ancient times Apple had
quicktime video pumped through ColorSync with very good performance.
I'm going to guess this involved simple matrix + TRC defined source
and destination color spaces for the transform. I know that Adobe
Flash, about 3-4 years ago, started to do on-the-fly display
compensation if the metadata in the source file enabled it. (I don't
remember if the tag says "I'm sRGB" and therefore Flash color managed
it, or if the tag says "color management me" and Flash assumes it's
sRGB and therefore color manages it.) And all of this would work in a
web browser's cut out area.

Web browsers. Right now all the web browsers are doing their own color
management, haphazardly. e.g. only images with embedded profiles are
color managed. Untagged images, html and css are deviceRGB, there is
no transformation, and thus no display compensation most of the time.
Browser developers have complained color managing every element in a
web page slows down rendering by a ton. Maybe they're doing it wrong.
:-D Also, browser plugins do their own thing, even if the browser has
full color management enabled, this doesn't affect plug-in content. I
don't know if there's any difference between NPAAPI vs PPAPI plug-ins
in this regard.

GIMP, Scribus, Krita, Digicam, Darktable - are all color managing
their content in advance (early binding) and supply device RGB, having
used the current display profile as the destination in a transform. So
they already do display compensation and don't need it to happen
again. So either they've got a bunch of work to do to rip that out if
Wayland is going to do it for them, or they need a passthrough. Web
browsers are a good example of programs that should probably rip out
what they have and have something else completely color manage all of
their content regardless of whether it's native elements or plug-in,
but I digress.

There has been a need for an explicit pass through to avoid any (or
additional) color management, and there are presently programs that
continue to expect that there will be.

On macOS this is achieved by tagging the content with the current
display profile, since source equals destination, the CMM sees this
and does a null transform, it's a noop. But there's no actual,
literal, off switch. If the content is not explicitly tagged, it's
assumed to be sRGB and hence color managed. So it's both opt in (if
you want something other than sRGB) and opt out (you want a pass
through).

On iOS there are no transforms, there is no need for display
compensation because all displays are either sRGB or (recently)
DCI-P3, and apparently they have the quality control to ensure this
level of consistency at a hardware level. Ironically, they've reverted
to closed loop hardware based calibration. Don't underestimate the
power of consistency and ancient ideas!

On Windows, ICC based color management is opt in, there is an API. If
a transform is not requested, it doesn't happen.

On Android, it's the same as Windows except no API, and display gamut,
dynamic range and tone response are all over the map. (And yet the
world isn't ending, even though if you view the same image on 10
Android phones or tablets you will have 10 different experiences).

I don't assume that on Linux any of these must be mimicked. But there
are distinct advantages with mimicking: we'll have a good idea where
the bodies are buried, rather than having something completely
different from any other platform.

-- 
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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
> > +weston_wm_window_is_positioned(struct weston_wm_window *window)
> > +{
> > +   if (window->map_request_x == INT_MIN ||
> > +   window->map_request_y == INT_MIN)
> > +   weston_log("XWM warning: win %d did not see map request\n",
> > +  window->id);
> > +
> > +   return window->map_request_x != 0 || window->map_request_y != 0;
> > +}  
> 
> Er, doesn't this break windows explicitly positioned at the origin?
> And I may be wrong, but won't OR windows avoid MapRequest to the WM,
> meaning that every OR window mapped would trigger this warning?
> 
> I'd assume this should just be 'return window->map_request_x !=
> INT_MIN || window->map_request_y != INT_MIN;' ...

Hi,

if you look at the caller:
- this is (supposedly) never called for OR windows
- legacy fullscreen windows (manually positioned at 0,0) get detected
  before this is called (either in xserver_map_shell_surface or after a
  later patch in MapRequest handler), so this will not be called.

You are right that positioning a normal window at 0,0 is not possible.
I do not know how to detect a window positioned at 0,0 from a window
without a position explicitly set. Any idea?

The map_request values are only unset if the MapRequest handler does
not run, i.e. for OR windows.


Thanks,
pq


pgpKKlvBVUcRX.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Daniel Stone]

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 ||
> +   window->map_request_y == INT_MIN)
> +   weston_log("XWM warning: win %d did not see map request\n",
> +  window->id);
> +
> +   return window->map_request_x != 0 || window->map_request_y != 0;
> +}

Er, doesn't this break windows explicitly positioned at the origin?
And I may be wrong, but won't OR windows avoid MapRequest to the WM,
meaning that every OR window mapped would trigger this warning?

I'd assume this should just be 'return window->map_request_x !=
INT_MIN || window->map_request_y != INT_MIN;' ...

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 time. However, MapRequest handler could not
set the pending state because the weston_surface did not exist at the
time, because it gets created only when Xwayland realizes the window,
which happens after XWM has forwarded the MapWindow in MapRequest
handler. Therefore set the pending state explicitly at the end.
Scheduling had it done much later anyway.

There is still the race between Xwayland committing and XWM setting the
pending state assuming the very next commit latches it in appropriately.
The race exists not because of Wayland, but because WL_SURFACE_ID comes
via X11, and could be processed after wl_compositor.create_surface and
wl_surface.commit. That commit/pending race is solved by a following patch.

For override-redirect windows weston_wm_window_schedule_repaint()
reduced into a call to weston_wm_window_set_pending_state_OR(), so we
can just call that directly. It should not matter that the call is moved
to the end of the function.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 38d530f..95164f9 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -2679,8 +2679,6 @@ xserver_map_shell_surface(struct weston_wm_window *window,
wl_signal_add(&window->surface->destroy_signal,
  &window->surface_destroy_listener);
 
-   weston_wm_window_schedule_repaint(window);
-
if (!xwayland_interface)
return;
 
@@ -2740,6 +2738,11 @@ xserver_map_shell_surface(struct weston_wm_window 
*window,
xwayland_interface->set_toplevel(window->shsurf);
}
}
+
+   if (window->frame_id == XCB_WINDOW_NONE)
+   weston_wm_window_set_pending_state_OR(window);
+   else
+   weston_wm_window_set_pending_state(window);
 }
 
 const struct weston_xwayland_surface_api surface_api = {
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 a/libweston-desktop/xwayland.c b/libweston-desktop/xwayland.c
index 449675a..d1566bd 100644
--- a/libweston-desktop/xwayland.c
+++ b/libweston-desktop/xwayland.c
@@ -135,6 +135,10 @@ weston_desktop_xwayland_surface_committed(struct 
weston_desktop_surface *dsurfac
 
assert(dsurface == surface->surface);
 
+#ifdef WM_DEBUG
+   weston_log("%s: xwayland surface %p\n", __func__, surface);
+#endif
+
if (surface->has_next_geometry) {
oldgeom = weston_desktop_surface_get_geometry(surface->surface);
sx -= surface->next_geometry.x - oldgeom.x;
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index cf616ec..89b879d 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -787,6 +787,8 @@ weston_wm_create_surface(struct wl_listener *listener, void 
*data)
if (wl_resource_get_client(surface->resource) != wm->server->client)
return;
 
+   wm_log("XWM: create weston_surface %p\n", surface);
+
wl_list_for_each(window, &wm->unpaired_window_list, link)
if (window->surface_id ==
wl_resource_get_id(surface->resource)) {
@@ -2685,8 +2687,8 @@ xserver_map_shell_surface(struct weston_wm_window *window,
   window->surface,
   &shell_client);
 
-   wm_log("XWM: map shell surface, win %d, xwayland surface %p\n",
-  window->id, window->shsurf);
+   wm_log("XWM: map shell surface, win %d, weston_surface %p, xwayland 
surface %p\n",
+  window->id, window->surface, window->shsurf);
 
if (window->name)
xwayland_interface->set_title(window->shsurf, window->name);
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 
---
 xwayland/window-manager.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 539387c..faeb9dd 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1175,8 +1175,6 @@ weston_wm_window_set_pending_state(struct 
weston_wm_window *window)
  window->height + 2);
}
 
-   pixman_region32_fini(&window->surface->pending.input);
-
if (window->decorate && !window->fullscreen) {
frame_input_rect(window->frame, &input_x, &input_y,
 &input_w, &input_h);
@@ -1190,11 +1188,13 @@ weston_wm_window_set_pending_state(struct 
weston_wm_window *window)
wm_log("XWM: win %d geometry: %d,%d %dx%d\n",
   window->id, input_x, input_y, input_w, input_h);
 
+   pixman_region32_fini(&window->surface->pending.input);
pixman_region32_init_rect(&window->surface->pending.input,
  input_x, input_y, input_w, input_h);
 
xwayland_interface->set_window_geometry(window->shsurf,
-   input_x, input_y, input_w, 
input_h);
+   input_x, input_y,
+   input_w, input_h);
if (window->name)
xwayland_interface->set_title(window->shsurf, window->name);
if (window->pid > 0)
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 creating the wl_surface and XWM receiving the
WL_SURFACE_ID ClientMessage, whichever came later. At that point the X11
client might still be setting things up in theory, though in practice
most of the X11 communication has already happened when
xserver_map_shell_surface() gets called.

The real reason for this is to clean up xserver_map_shell_surface() from
everything that would affect drawing the decorations. This patch is one
part of that clean-up.

The weston_output_weak_ref logic is not put into compositor.h, because
there are no other users for it at this time. We need to protect against
the output going away.

A side-effect of this patch is that saved_width and saved_height will
now get overwritten also for legacy fullscreen windows. Previously, they
were left to zero as far as I could tell.

NOTE: This stops override-redirect legacy fullscreen windows from being
detected as fullscreen. MapRequest processing does not happen for OR
windows. These windows get detected as type XWAYLAND instead.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 70 +++
 1 file changed, 65 insertions(+), 5 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 10bb390..02a44a7 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -126,6 +127,11 @@ struct motif_wm_hints {
 #define _NET_WM_MOVERESIZE_MOVE_KEYBOARD10   /* move via keyboard */
 #define _NET_WM_MOVERESIZE_CANCEL   11   /* cancel operation */
 
+struct weston_output_weak_ref {
+   struct weston_output *output;
+   struct wl_listener destroy_listener;
+};
+
 struct weston_wm_window {
struct weston_wm *wm;
xcb_window_t id;
@@ -152,6 +158,7 @@ struct weston_wm_window {
bool pos_dirty;
int map_request_x;
int map_request_y;
+   struct weston_output_weak_ref legacy_fullscreen_output;
int saved_width, saved_height;
int decorate;
int override_redirect;
@@ -174,6 +181,11 @@ weston_wm_set_net_active_window(struct weston_wm *wm, 
xcb_window_t window);
 static void
 weston_wm_window_schedule_repaint(struct weston_wm_window *window);
 
+static int
+legacy_fullscreen(struct weston_wm *wm,
+ struct weston_wm_window *window,
+ struct weston_output **output_ret);
+
 static void
 xserver_map_shell_surface(struct weston_wm_window *window,
  struct weston_surface *surface);
@@ -212,6 +224,47 @@ wm_log_continue(const char *fmt, ...)
 #endif
 }
 
+static void
+weston_output_weak_ref_init(struct weston_output_weak_ref *ref)
+{
+   ref->output = NULL;
+}
+
+static void
+weston_output_weak_ref_clear(struct weston_output_weak_ref *ref)
+{
+   if (!ref->output)
+   return;
+
+   wl_list_remove(&ref->destroy_listener.link);
+   ref->output = NULL;
+}
+
+static void
+weston_output_weak_ref_handle_destroy(struct wl_listener *listener, void *data)
+{
+   struct weston_output_weak_ref *ref;
+
+   ref = wl_container_of(listener, ref, destroy_listener);
+   assert(ref->output == data);
+
+   weston_output_weak_ref_clear(ref);
+}
+
+static void
+weston_output_weak_ref_set(struct weston_output_weak_ref *ref,
+  struct weston_output *output)
+{
+   weston_output_weak_ref_clear(ref);
+
+   if (!output)
+   return;
+
+   ref->destroy_listener.notify = weston_output_weak_ref_handle_destroy;
+   wl_signal_add(&output->destroy_signal, &ref->destroy_listener);
+   ref->output = output;
+}
+
 static bool __attribute__ ((warn_unused_result))
 wm_lookup_window(struct weston_wm *wm, xcb_window_t hash,
 struct weston_wm_window **window)
@@ -955,6 +1008,7 @@ weston_wm_handle_map_request(struct weston_wm *wm, 
xcb_generic_event_t *event)
xcb_map_request_event_t *map_request =
(xcb_map_request_event_t *) event;
struct weston_wm_window *window;
+   struct weston_output *output;
 
if (our_resource(wm, map_request->window)) {
wm_log("XCB_MAP_REQUEST (window %d, ours)\n",
@@ -982,6 +1036,12 @@ weston_wm_handle_map_request(struct weston_wm *wm, 
xcb_generic_event_t *event)
weston_wm_window_set_net_wm_state(window);
weston_wm_window_set_virtual_desktop(window, 0);
 
+   if (legacy_fullscreen(wm, window, &output)) {
+   window->fullscreen = 1;
+   weston_output_weak_ref_set(&window->legacy_fullscreen_output,
+  output);
+   }
+
xcb_map_window(wm->conn, map

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

[Pekka Paalanen]

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 window->name == NULL, because frame_set_title() handles
NULL just fine. Also, once window->name becomes set, it cannot become
NULL again unless strndup() fails. The name string can be reset to
the empty string in any case.

This change is prompted by future refactoring where at
weston_wm_window_read_properties() time the frame might not have been
created yet.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c4220ab..e2b1ebf 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -602,8 +602,6 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
 
if (window->shsurf && window->name)
xwayland_interface->set_title(window->shsurf, window->name);
-   if (window->frame && window->name)
-   frame_set_title(window->frame, window->name);
if (window->shsurf && window->pid > 0)
xwayland_interface->set_pid(window->shsurf, window->pid);
 }
@@ -1144,6 +1142,7 @@ weston_wm_window_draw_decoration(void *data)
if (wm->focus_window == window)
flags |= THEME_FRAME_ACTIVE;
 
+   frame_set_title(window->frame, window->name);
frame_repaint(window->frame, cr);
} else {
cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 created. Also OR
windows will never hit the normal set_pending_state() because
weston_wm_window_schedule_repaint() special-cased windows without a
frame window and returned early without scheduling.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 43 +++
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index faeb9dd..4127fa9 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1215,27 +1215,38 @@ weston_wm_window_do_repaint(void *data)
 }
 
 static void
+weston_wm_window_set_pending_state_OR(struct weston_wm_window *window)
+{
+   int width, height;
+
+   /* for override-redirect windows */
+   assert(window->frame_id == XCB_WINDOW_NONE);
+
+   if (!window->surface)
+   return;
+
+   weston_wm_window_get_frame_size(window, &width, &height);
+   pixman_region32_fini(&window->surface->pending.opaque);
+   if (window->has_alpha) {
+   pixman_region32_init(&window->surface->pending.opaque);
+   } else {
+   pixman_region32_init_rect(&window->surface->pending.opaque, 0, 
0,
+ width, height);
+   }
+}
+
+static void
 weston_wm_window_schedule_repaint(struct weston_wm_window *window)
 {
struct weston_wm *wm = window->wm;
-   int width, height;
 
if (window->frame_id == XCB_WINDOW_NONE) {
-   if (window->surface != NULL) {
-   /* Override-redirect windows go through here, but we
-* cannot assert(window->override_redirect); because
-* we do not deal with changing OR flag yet.
-* XXX: handle OR flag changes in message handlers
-*/
-   weston_wm_window_get_frame_size(window, &width, 
&height);
-   pixman_region32_fini(&window->surface->pending.opaque);
-   if (window->has_alpha) {
-   
pixman_region32_init(&window->surface->pending.opaque);
-   } else {
-   
pixman_region32_init_rect(&window->surface->pending.opaque, 0, 0,
- width, height);
-   }
-   }
+   /* Override-redirect windows go through here, but we
+* cannot assert(window->override_redirect); because
+* we do not deal with changing OR flag yet.
+* XXX: handle OR flag changes in message handlers
+*/
+   weston_wm_window_set_pending_state_OR(window);
return;
}
 
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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.

The new weston_wm_window_do_repaint() is the equivalent of the old
weston_wm_window_draw_decorations(), everything still happens the same
way as it was. Just some debug messages have been reworded.

weston_wm_window_read_properties() is moved into
weston_wm_window_do_repaint() because it is not strictly a part of
drawing decorations. The same with resetting repaint_source.

draw_decorations does not need the child position nor xwayland
interface. Also some convenience variables have been eliminated.

set_pending_state code has been un-indented by one level, so the change
is best viewed with whitespace changes ignored.

This patch makes the code more readable, and prepares for calling the
draw_decorations and set_pending_state from different places.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 115 ++
 1 file changed, 65 insertions(+), 50 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 9071598..539387c 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1119,25 +1119,14 @@ weston_wm_handle_unmap_notify(struct weston_wm *wm, 
xcb_generic_event_t *event)
 }
 
 static void
-weston_wm_window_draw_decoration(void *data)
+weston_wm_window_draw_decoration(struct weston_wm_window *window)
 {
-   struct weston_wm_window *window = data;
-   struct weston_wm *wm = window->wm;
-   struct theme *t = wm->theme;
cairo_t *cr;
-   int x, y, width, height;
-   int32_t input_x, input_y, input_w, input_h;
-   const struct weston_desktop_xwayland_interface *xwayland_interface =
-   wm->server->compositor->xwayland_interface;
-
-   wm_log("XWM: start draw decoration, win %d\n", window->id);
-
-   weston_wm_window_read_properties(window);
+   int width, height;
 
-   window->repaint_source = NULL;
+   wm_log("XWM: draw decoration, win %d\n", window->id);
 
weston_wm_window_get_frame_size(window, &width, &height);
-   weston_wm_window_get_child_position(window, &x, &y);
 
cairo_xcb_surface_set_size(window->cairo_surface, width, height);
cr = cairo_create(window->cairo_surface);
@@ -1152,50 +1141,77 @@ weston_wm_window_draw_decoration(void *data)
cairo_set_source_rgba(cr, 0, 0, 0, 0);
cairo_paint(cr);
 
-   render_shadow(cr, t->shadow, 2, 2, width + 8, height + 8, 64, 
64);
+   render_shadow(cr, window->wm->theme->shadow,
+ 2, 2, width + 8, height + 8, 64, 64);
}
 
cairo_destroy(cr);
+}
 
-   if (window->surface) {
-   pixman_region32_fini(&window->surface->pending.opaque);
-   if (window->has_alpha) {
-   pixman_region32_init(&window->surface->pending.opaque);
-   } else {
-   /* We leave an extra pixel around the X window area to
-* make sure we don't sample from the undefined alpha
-* channel when filtering. */
-   
pixman_region32_init_rect(&window->surface->pending.opaque,
- x - 1, y - 1,
- window->width + 2,
- window->height + 2);
-   }
+static void
+weston_wm_window_set_pending_state(struct weston_wm_window *window)
+{
+   int x, y, width, height;
+   int32_t input_x, input_y, input_w, input_h;
+   const struct weston_desktop_xwayland_interface *xwayland_interface =
+   window->wm->server->compositor->xwayland_interface;
 
-   pixman_region32_fini(&window->surface->pending.input);
+   if (!window->surface)
+   return;
 
-   if (window->decorate && !window->fullscreen) {
-   frame_input_rect(window->frame, &input_x, &input_y,
-&input_w, &input_h);
-   } else {
-   input_x = x;
-   input_y = y;
-   input_w = width;
-   input_h = height;
-   }
+   weston_wm_window_get_frame_size(window, &width, &height);
+   weston_wm_window_get_child_position(window, &x, &y);
 
-   pixman_region32_init_rect(&window->surface->pending.input,
- input_x, input_y, input_w, input_h);
+   pixman_region32_fini(&window->surface->pending.opaque);
+   if (window->has_alpha) {
+   pixman_region32_init(&window->surface->pending.opaque);
+   } else {
+   /* We leave an 

[PATCH weston v2 14/24] xwm: debug print deleted property name

[Pekka Paalanen]

From: Pekka Paalanen 

Use wm_log_continue() to avoid printing the timestamp in the middle of a
message.

Print the name of the property that got deleted.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 0a6417c..5466bc9 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1258,7 +1258,8 @@ weston_wm_handle_property_notify(struct weston_wm *wm, 
xcb_generic_event_t *even
 
wm_log("XCB_PROPERTY_NOTIFY: window %d, ", property_notify->window);
if (property_notify->state == XCB_PROPERTY_DELETE)
-   wm_log("deleted\n");
+   wm_log_continue("deleted %s\n",
+   get_atom_name(wm->conn, property_notify->atom));
else
read_and_dump_property(wm, property_notify->window,
   property_notify->atom);
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 a/xwayland/window-manager.c b/xwayland/window-manager.c
index 021b18a..9071598 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1129,7 +1129,6 @@ weston_wm_window_draw_decoration(void *data)
int32_t input_x, input_y, input_w, input_h;
const struct weston_desktop_xwayland_interface *xwayland_interface =
wm->server->compositor->xwayland_interface;
-   uint32_t flags = 0;
 
wm_log("XWM: start draw decoration, win %d\n", window->id);
 
@@ -1146,9 +1145,6 @@ weston_wm_window_draw_decoration(void *data)
if (window->fullscreen) {
/* nothing */
} else if (window->decorate) {
-   if (wm->focus_window == window)
-   flags |= THEME_FRAME_ACTIVE;
-
frame_set_title(window->frame, window->name);
frame_repaint(window->frame, cr);
} else {
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 time constants. We can as well just store
the pointer directly in the array.

Entries that did not use the offset had bogus offsets, producing
pointers to arbitrary fields. They are changed to have a NULL pointer.
If the code unintentionally used the pointer, it will now explode rather
than corrupt memory.

Also explain the use of the #defined constants and #undef them when they
get out of scope. This clearly documents that they are just a convenient
hack to avoid lots of special cases in the function.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 38 +++---
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 02a44a7..c4220ab 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -443,7 +443,10 @@ read_and_dump_property(struct weston_wm *wm,
free(reply);
 }
 
-/* We reuse some predefined, but otherwise useles atoms */
+/* We reuse some predefined, but otherwise useles atoms
+ * as local type placeholders that never touch the X11 server,
+ * to make weston_wm_window_read_properties() less exceptional.
+ */
 #define TYPE_WM_PROTOCOLS  XCB_ATOM_CUT_BUFFER0
 #define TYPE_MOTIF_WM_HINTSXCB_ATOM_CUT_BUFFER1
 #define TYPE_NET_WM_STATE  XCB_ATOM_CUT_BUFFER2
@@ -456,23 +459,23 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
const struct weston_desktop_xwayland_interface *xwayland_interface =
wm->server->compositor->xwayland_interface;
 
-#define F(field) offsetof(struct weston_wm_window, field)
+#define F(field) (&window->field)
const struct {
xcb_atom_t atom;
xcb_atom_t type;
-   int offset;
+   void *ptr;
} props[] = {
-   { XCB_ATOM_WM_CLASS, XCB_ATOM_STRING, F(class) },
-   { XCB_ATOM_WM_NAME, XCB_ATOM_STRING, F(name) },
-   { XCB_ATOM_WM_TRANSIENT_FOR, XCB_ATOM_WINDOW, F(transient_for) 
},
-   { wm->atom.wm_protocols, TYPE_WM_PROTOCOLS, F(protocols) },
-   { wm->atom.wm_normal_hints, TYPE_WM_NORMAL_HINTS, F(protocols) 
},
-   { wm->atom.net_wm_state, TYPE_NET_WM_STATE },
-   { wm->atom.net_wm_window_type, XCB_ATOM_ATOM, F(type) },
-   { wm->atom.net_wm_name, XCB_ATOM_STRING, F(name) },
-   { wm->atom.net_wm_pid, XCB_ATOM_CARDINAL, F(pid) },
-   { wm->atom.motif_wm_hints, TYPE_MOTIF_WM_HINTS, 0 },
-   { wm->atom.wm_client_machine, XCB_ATOM_WM_CLIENT_MACHINE, 
F(machine) },
+   { XCB_ATOM_WM_CLASS,   XCB_ATOM_STRING,
F(class) },
+   { XCB_ATOM_WM_NAME,XCB_ATOM_STRING,
F(name) },
+   { XCB_ATOM_WM_TRANSIENT_FOR,   XCB_ATOM_WINDOW,
F(transient_for) },
+   { wm->atom.wm_protocols,   TYPE_WM_PROTOCOLS,  NULL 
},
+   { wm->atom.wm_normal_hints,TYPE_WM_NORMAL_HINTS,   NULL 
},
+   { wm->atom.net_wm_state,   TYPE_NET_WM_STATE,  NULL 
},
+   { wm->atom.net_wm_window_type, XCB_ATOM_ATOM,  
F(type) },
+   { wm->atom.net_wm_name,XCB_ATOM_STRING,
F(name) },
+   { wm->atom.net_wm_pid, XCB_ATOM_CARDINAL,  
F(pid) },
+   { wm->atom.motif_wm_hints, TYPE_MOTIF_WM_HINTS,NULL 
},
+   { wm->atom.wm_client_machine,  XCB_ATOM_WM_CLIENT_MACHINE, 
F(machine) },
};
 #undef F
 
@@ -511,7 +514,7 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
continue;
}
 
-   p = ((char *) window + props[i].offset);
+   p = props[i].ptr;
 
switch (props[i].type) {
case XCB_ATOM_WM_CLIENT_MACHINE:
@@ -605,6 +608,11 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
xwayland_interface->set_pid(window->shsurf, window->pid);
 }
 
+#undef TYPE_WM_PROTOCOLS
+#undef TYPE_MOTIF_WM_HINTS
+#undef TYPE_NET_WM_STATE
+#undef TYPE_WM_NORMAL_HINTS
+
 static void
 weston_wm_window_get_frame_size(struct weston_wm_window *window,
int *width, int *height)
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 add calls.

weston_wm_handle_map_request(): can be called only on unmapped (in X11)
Windows, so no need to add calls.

weston_wm_window_draw_decoration(): window->shsurf and window->surface
are either both set or both NULL, so the check for window->shsurf is
removed when moving the set_title() and set_pid() calls under a
window->surface check.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index e2b1ebf..fb83795 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -456,8 +456,6 @@ static void
 weston_wm_window_read_properties(struct weston_wm_window *window)
 {
struct weston_wm *wm = window->wm;
-   const struct weston_desktop_xwayland_interface *xwayland_interface =
-   wm->server->compositor->xwayland_interface;
 
 #define F(field) (&window->field)
const struct {
@@ -599,11 +597,6 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
if (!window->machine || strcmp(window->machine, name))
window->pid = 0;
}
-
-   if (window->shsurf && window->name)
-   xwayland_interface->set_title(window->shsurf, window->name);
-   if (window->shsurf && window->pid > 0)
-   xwayland_interface->set_pid(window->shsurf, window->pid);
 }
 
 #undef TYPE_WM_PROTOCOLS
@@ -1027,6 +1020,19 @@ weston_wm_handle_map_request(struct weston_wm *wm, 
xcb_generic_event_t *event)
 
weston_wm_window_read_properties(window);
 
+   /* For a new Window, MapRequest happens before the Window is realized
+* in Xwayland. We do the real xcb_map_window() here as a response to
+* MapRequest. The Window will get realized (wl_surface created in
+* Wayland and WL_SURFACE_ID sent in X11) when it has been mapped for
+* real.
+*
+* MapRequest only happens for (X11) unmapped Windows. On UnmapNotify,
+* we reset shsurf to NULL, so even if X11 connection races far ahead
+* of the Wayland connection and the X11 client is repeatedly mapping
+* and unmapping, we will never have shsurf set on MapRequest.
+*/
+   assert(!window->shsurf);
+
window->map_request_x = window->x;
window->map_request_y = window->y;
 
@@ -1190,6 +1196,10 @@ weston_wm_window_draw_decoration(void *data)
 
xwayland_interface->set_window_geometry(window->shsurf,
input_x, input_y, 
input_w, input_h);
+   if (window->name)
+   xwayland_interface->set_title(window->shsurf, 
window->name);
+   if (window->pid > 0)
+   xwayland_interface->set_pid(window->shsurf, 
window->pid);
}
 }
 
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 a/xwayland/window-manager.c b/xwayland/window-manager.c
index 89b879d..38d530f 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -2657,6 +2657,15 @@ xserver_map_shell_surface(struct weston_wm_window 
*window,
wm->server->compositor->xwayland_interface;
struct weston_wm_window *parent;
 
+   /* This should be necessary only for override-redirected windows,
+* because otherwise MapRequest handler would have already updated
+* the properties. However, if X11 clients set properties after
+* sending MapWindow, here we can still process them. The decorations
+* have already been drawn once with the old property values, so if the
+* app changes something affecting decor after MapWindow, we glitch.
+* We only hit xserver_map_shell_surface() once per MapWindow and
+* wl_surface, so better ensure we get the window type right.
+*/
weston_wm_window_read_properties(window);
 
/* A weston_wm_window may have many different surfaces assigned
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 commit, so it's not available at
set_xwayland_position() time.

Regression: kcachegrind (Qt 4, X11), the first menu invocation will
slightly misplace the menu if the window has not been manually moved.

Problem: geometry is not taken into account due to a race between XWM
drawing decorations and Xwayland committing the first buffer.

Signed-off-by: Pekka Paalanen 
Reviewed-by: Quentin Glidic 
---
 desktop-shell/shell.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 3913f95..9b39933 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -134,6 +134,12 @@ struct shell_surface {
bool lowered;
} state;
 
+   struct {
+   bool is_set;
+   int32_t x;
+   int32_t y;
+   } xwayland;
+
int focus_count;
 
bool destroying;
@@ -2385,6 +2391,22 @@ set_maximized_position(struct desktop_shell *shell,
 }
 
 static void
+set_position_from_xwayland(struct shell_surface *shsurf)
+{
+   struct weston_geometry geometry;
+   float x;
+   float y;
+
+   assert(shsurf->xwayland.is_set);
+
+   geometry = weston_desktop_surface_get_geometry(shsurf->desktop_surface);
+   x = shsurf->xwayland.x - geometry.x;
+   y = shsurf->xwayland.y - geometry.y;
+
+   weston_view_set_position(shsurf->view, x, y);
+}
+
+static void
 map(struct desktop_shell *shell, struct shell_surface *shsurf,
 int32_t sx, int32_t sy)
 {
@@ -2399,6 +2421,8 @@ map(struct desktop_shell *shell, struct shell_surface 
*shsurf,
shell_map_fullscreen(shsurf);
} else if (shsurf->state.maximized) {
set_maximized_position(shell, shsurf);
+   } else if (shsurf->xwayland.is_set) {
+   set_position_from_xwayland(shsurf);
} else {
weston_view_set_initial_position(shsurf->view, shell);
}
@@ -2783,6 +2807,18 @@ desktop_surface_pong(struct weston_desktop_client 
*desktop_client,
end_busy_cursor(shell->compositor, desktop_client);
 }
 
+static void
+desktop_surface_set_xwayland_position(struct weston_desktop_surface *surface,
+ int32_t x, int32_t y, void *shell_)
+{
+   struct shell_surface *shsurf =
+   weston_desktop_surface_get_user_data(surface);
+
+   shsurf->xwayland.x = x;
+   shsurf->xwayland.y = y;
+   shsurf->xwayland.is_set = true;
+}
+
 static const struct weston_desktop_api shell_desktop_api = {
.struct_size = sizeof(struct weston_desktop_api),
.surface_added = desktop_surface_added,
@@ -2795,6 +2831,7 @@ static const struct weston_desktop_api shell_desktop_api 
= {
.minimized_requested = desktop_surface_minimized_requested,
.ping_timeout = desktop_surface_ping_timeout,
.pong = desktop_surface_pong,
+   .set_xwayland_position = desktop_surface_set_xwayland_position,
 };
 
 /*  *
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 prevents commits before the decorations have been drawn and the
initial pending state has been set. Commits are enabled right after
drawing and setting.

This ensures that the decorations are fully drawn when a window is
mapped. This also solves the initial commit/pending race, but the race
is on again after mapping.

If Xwayland does not implement the needed support, we are just setting a
window property with no effect.

This patch is the final piece for solving T7622, excluding the
_NET_WM_SYNC_REQUEST handling.

Task: https://phabricator.freedesktop.org/T7622
Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 40 ++--
 xwayland/xwayland.h   |  1 +
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 95164f9..5911897 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -873,6 +873,37 @@ weston_wm_window_activate(struct wl_listener *listener, 
void *data)
 
 }
 
+/** Control Xwayland wl_surface.commit behaviour
+ *
+ * This function sets the "_XWAYLAND_ALLOW_COMMITS" property of the frame 
window
+ * (not the content window!) to \p allow.
+ *
+ * If the property is set to \c true, Xwayland will commit whenever it likes.
+ * If the property is set to \c false, Xwayland will not commit.
+ * If the property is not set at all, Xwayland assumes it is \c true.
+ *
+ * \param window The XWM window to control.
+ * \param allow Whether Xwayland is allowed to wl_surface.commit for the 
window.
+ */
+static void
+weston_wm_window_set_allow_commits(struct weston_wm_window *window, bool allow)
+{
+   struct weston_wm *wm = window->wm;
+   uint32_t property[1];
+
+   assert(window->frame_id != XCB_WINDOW_NONE);
+
+   property[0] = allow ? 1 : 0;
+
+   xcb_change_property(wm->conn,
+   XCB_PROP_MODE_REPLACE,
+   window->frame_id,
+   wm->atom.allow_commits,
+   XCB_ATOM_CARDINAL,
+   32, /* format */
+   1, property);
+}
+
 #define ICCCM_WITHDRAWN_STATE  0
 #define ICCCM_NORMAL_STATE 1
 #define ICCCM_ICONIC_STATE 3
@@ -1048,6 +1079,7 @@ weston_wm_handle_map_request(struct weston_wm *wm, 
xcb_generic_event_t *event)
   window->width, window->height,
   window->map_request_x, window->map_request_y);
 
+   weston_wm_window_set_allow_commits(window, false);
weston_wm_window_set_wm_state(window, ICCCM_NORMAL_STATE);
weston_wm_window_set_net_wm_state(window);
weston_wm_window_set_virtual_desktop(window, 0);
@@ -2218,6 +2250,7 @@ weston_wm_get_resources(struct weston_wm *wm)
{ "XdndFinished",   F(atom.xdnd_finished) },
{ "XdndTypeList",   F(atom.xdnd_type_list) },
{ "XdndActionCopy", F(atom.xdnd_action_copy) },
+   { "_XWAYLAND_ALLOW_COMMITS",F(atom.allow_commits) },
{ "WL_SURFACE_ID",  F(atom.wl_surface_id) }
};
 #undef F
@@ -2739,10 +2772,13 @@ xserver_map_shell_surface(struct weston_wm_window 
*window,
}
}
 
-   if (window->frame_id == XCB_WINDOW_NONE)
+   if (window->frame_id == XCB_WINDOW_NONE) {
weston_wm_window_set_pending_state_OR(window);
-   else
+   } else {
weston_wm_window_set_pending_state(window);
+   weston_wm_window_set_allow_commits(window, true);
+   xcb_flush(wm->conn);
+   }
 }
 
 const struct weston_xwayland_surface_api surface_api = {
diff --git a/xwayland/xwayland.h b/xwayland/xwayland.h
index b1225f5..ca75f5b 100644
--- a/xwayland/xwayland.h
+++ b/xwayland/xwayland.h
@@ -154,6 +154,7 @@ struct weston_wm {
xcb_atom_t   xdnd_type_list;
xcb_atom_t   xdnd_action_copy;
xcb_atom_t   wl_surface_id;
+   xcb_atom_t   allow_commits;
} atom;
 };
 
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 
---
 xwayland/window-manager.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 4127fa9..cf616ec 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1039,6 +1039,7 @@ weston_wm_handle_map_request(struct weston_wm *wm, 
xcb_generic_event_t *event)
 
if (window->frame_id == XCB_WINDOW_NONE)
weston_wm_window_create_frame(window);
+   assert(window->frame_id != XCB_WINDOW_NONE);
 
wm_log("XCB_MAP_REQUEST (window %d, %p, frame %d, %dx%d @ %d,%d)\n",
   window->id, window, window->frame_id,
@@ -1057,6 +1058,11 @@ weston_wm_handle_map_request(struct weston_wm *wm, 
xcb_generic_event_t *event)
 
xcb_map_window(wm->conn, map_request->window);
xcb_map_window(wm->conn, window->frame_id);
+
+   /* Mapped in the X server, we can draw immediately.
+* Cannot set pending state though, no weston_surface until
+* xserver_map_shell_surface() time. */
+   weston_wm_window_schedule_repaint(window);
 }
 
 static void
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 dirtying did not
apply pending state.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 5466bc9..021b18a 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1130,7 +1130,6 @@ weston_wm_window_draw_decoration(void *data)
const struct weston_desktop_xwayland_interface *xwayland_interface =
wm->server->compositor->xwayland_interface;
uint32_t flags = 0;
-   struct weston_view *view;
 
wm_log("XWM: start draw decoration, win %d\n", window->id);
 
@@ -1175,8 +1174,6 @@ weston_wm_window_draw_decoration(void *data)
  window->width + 2,
  window->height + 2);
}
-   wl_list_for_each(view, &window->surface->views, surface_link)
-   weston_view_geometry_dirty(view);
 
pixman_region32_fini(&window->surface->pending.input);
 
@@ -1209,7 +1206,6 @@ static void
 weston_wm_window_schedule_repaint(struct weston_wm_window *window)
 {
struct weston_wm *wm = window->wm;
-   struct weston_view *view;
int width, height;
 
if (window->frame_id == XCB_WINDOW_NONE) {
@@ -1227,8 +1223,6 @@ weston_wm_window_schedule_repaint(struct weston_wm_window 
*window)

pixman_region32_init_rect(&window->surface->pending.opaque, 0, 0,
  width, height);
}
-   wl_list_for_each(view, &window->surface->views, 
surface_link)
-   weston_view_geometry_dirty(view);
}
return;
}
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 position whenever the geometry info changes.

Regression: This causes jumping when decorated Xwayland windows are
mapped.

This makes -geometry +x+y work, but -x or -y are not right for some
reason. Apparently needs an offset from geometry or decorations.

Signed-off-by: Pekka Paalanen 
Reviewed-by: Quentin Glidic 
---
 libweston-desktop/xwayland.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libweston-desktop/xwayland.c b/libweston-desktop/xwayland.c
index c64650d..449675a 100644
--- a/libweston-desktop/xwayland.c
+++ b/libweston-desktop/xwayland.c
@@ -131,8 +131,15 @@ weston_desktop_xwayland_surface_committed(struct 
weston_desktop_surface *dsurfac
  int32_t sx, int32_t sy)
 {
struct weston_desktop_xwayland_surface *surface = user_data;
+   struct weston_geometry oldgeom;
+
+   assert(dsurface == surface->surface);
 
if (surface->has_next_geometry) {
+   oldgeom = weston_desktop_surface_get_geometry(surface->surface);
+   sx -= surface->next_geometry.x - oldgeom.x;
+   sy -= surface->next_geometry.y - oldgeom.x;
+
surface->has_next_geometry = false;
weston_desktop_surface_set_geometry(surface->surface,
surface->next_geometry);
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 position is not 0,0 then it is explicitly
positioned. Legacy fullscreen windows are also at 0,0 but these are
detected earlier.

Explicitly store the window position at map request time to detect
client-positioned windows, and use it as the suggested initial position.
weston_wm_window::x and y have been overwritten due to reparenting when
we eventually need the initial position.

This patch requires that the new set_toplevel_with_position() hook is
implemented in the shell.

Note that this patch is about positioning xwayland toplevels, not
override-redirect windows which are already handled.

Signed-off-by: Pekka Paalanen 
Reviewed-by: Quentin Glidic 
---
 xwayland/window-manager.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 1830864..10bb390 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -146,8 +147,11 @@ struct weston_wm_window {
uint32_t protocols;
xcb_atom_t type;
int width, height;
-   int x, y;
+   int x;
+   int y;
bool pos_dirty;
+   int map_request_x;
+   int map_request_y;
int saved_width, saved_height;
int decorate;
int override_redirect;
@@ -963,12 +967,16 @@ weston_wm_handle_map_request(struct weston_wm *wm, 
xcb_generic_event_t *event)
 
weston_wm_window_read_properties(window);
 
+   window->map_request_x = window->x;
+   window->map_request_y = window->y;
+
if (window->frame_id == XCB_WINDOW_NONE)
weston_wm_window_create_frame(window);
 
wm_log("XCB_MAP_REQUEST (window %d, %p, frame %d, %dx%d @ %d,%d)\n",
   window->id, window, window->frame_id,
-  window->width, window->height, window->x, window->y);
+  window->width, window->height,
+  window->map_request_x, window->map_request_y);
 
weston_wm_window_set_wm_state(window, ICCCM_NORMAL_STATE);
weston_wm_window_set_net_wm_state(window);
@@ -1206,6 +1214,8 @@ weston_wm_window_create(struct weston_wm *wm,
window->x = x;
window->y = y;
window->pos_dirty = false;
+   window->map_request_x = INT_MIN; /* out of range for valid positions */
+   window->map_request_y = INT_MIN; /* out of range for valid positions */
 
geometry_reply = xcb_get_geometry_reply(wm->conn, geometry_cookie, 
NULL);
/* technically we should use XRender and check the visual format's
@@ -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 ||
+   window->map_request_y == INT_MIN)
+   weston_log("XWM warning: win %d did not see map request\n",
+  window->id);
+
+   return window->map_request_x != 0 || window->map_request_y != 0;
+}
+
+static bool
 weston_wm_window_type_inactive(struct weston_wm_window *window)
 {
struct weston_wm *wm = window->wm;
@@ -2592,6 +2613,10 @@ xserver_map_shell_surface(struct weston_wm_window 
*window,
xwayland_interface->set_xwayland(window->shsurf,
 window->x,
 window->y);
+   } else if (weston_wm_window_is_positioned(window)) {
+   
xwayland_interface->set_toplevel_with_position(window->shsurf,
+  
window->map_request_x,
+  
window->map_request_y);
} else {
xwayland_interface->set_toplevel(window->shsurf);
}
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 the OR flag after Window creation.

Signed-off-by: Pekka Paalanen 
---
 xwayland/window-manager.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index fb83795..0a6417c 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -741,10 +741,11 @@ weston_wm_handle_configure_notify(struct weston_wm *wm, 
xcb_generic_event_t *eve
(xcb_configure_notify_event_t *) event;
struct weston_wm_window *window;
 
-   wm_log("XCB_CONFIGURE_NOTIFY (window %d) %d,%d @ %dx%d\n",
+   wm_log("XCB_CONFIGURE_NOTIFY (window %d) %d,%d @ %dx%d%s\n",
   configure_notify->window,
   configure_notify->x, configure_notify->y,
-  configure_notify->width, configure_notify->height);
+  configure_notify->width, configure_notify->height,
+  configure_notify->override_redirect ? ", override" : "");
 
if (!wm_lookup_window(wm, configure_notify->window, &window))
return;
@@ -1069,7 +1070,8 @@ weston_wm_handle_map_notify(struct weston_wm *wm, 
xcb_generic_event_t *event)
return;
}
 
-   wm_log("XCB_MAP_NOTIFY (window %d)\n", map_notify->window);
+   wm_log("XCB_MAP_NOTIFY (window %d%s)\n", map_notify->window,
+  map_notify->override_redirect ? ", override" : "");
 }
 
 static void
@@ -1212,6 +1214,11 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
 
if (window->frame_id == XCB_WINDOW_NONE) {
if (window->surface != NULL) {
+   /* Override-redirect windows go through here, but we
+* cannot assert(window->override_redirect); because
+* we do not deal with changing OR flag yet.
+* XXX: handle OR flag changes in message handlers
+*/
weston_wm_window_get_frame_size(window, &width, 
&height);
pixman_region32_fini(&window->surface->pending.opaque);
if (window->has_alpha) {
@@ -1386,10 +1393,11 @@ weston_wm_handle_reparent_notify(struct weston_wm *wm, 
xcb_generic_event_t *even
(xcb_reparent_notify_event_t *) event;
struct weston_wm_window *window;
 
-   wm_log("XCB_REPARENT_NOTIFY (window %d, parent %d, event %d)\n",
+   wm_log("XCB_REPARENT_NOTIFY (window %d, parent %d, event %d%s)\n",
   reparent_notify->window,
   reparent_notify->parent,
-  reparent_notify->event);
+  reparent_notify->event,
+  reparent_notify->override_redirect ? ", override" : "");
 
if (reparent_notify->parent == wm->screen->root) {
weston_wm_window_create(wm, reparent_notify->window, 10, 10,
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 a/desktop-shell/shell.c b/desktop-shell/shell.c
index 9b39933..f53a49c 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2404,6 +2404,12 @@ set_position_from_xwayland(struct shell_surface *shsurf)
y = shsurf->xwayland.y - geometry.y;
 
weston_view_set_position(shsurf->view, x, y);
+
+#ifdef WM_DEBUG
+   weston_log("%s: XWM %d, %d; geometry %d, %d; view %f, %f\n",
+  __func__, shsurf->xwayland.x, shsurf->xwayland.y,
+  geometry.x, geometry.y, x, y);
+#endif
 }
 
 static void
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 
---
 xwayland/window-manager.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 56d65af..1830864 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1050,6 +1050,8 @@ weston_wm_window_draw_decoration(void *data)
uint32_t flags = 0;
struct weston_view *view;
 
+   wm_log("XWM: start draw decoration, win %d\n", window->id);
+
weston_wm_window_read_properties(window);
 
window->repaint_source = NULL;
@@ -1108,6 +1110,9 @@ weston_wm_window_draw_decoration(void *data)
pixman_region32_init_rect(&window->surface->pending.input,
  input_x, input_y, input_w, input_h);
 
+   wm_log("XWM: draw decoration, win %d geometry: %d,%d %dx%d\n",
+  window->id, input_x, input_y, input_w, input_h);
+
xwayland_interface->set_window_geometry(window->shsurf,
input_x, input_y, 
input_w, input_h);
}
@@ -1139,6 +1144,8 @@ weston_wm_window_schedule_repaint(struct weston_wm_window 
*window)
if (window->repaint_source)
return;
 
+   wm_log("XWM: schedule repaint, win %d\n", window->id);
+
window->repaint_source =
wl_event_loop_add_idle(wm->server->loop,
   weston_wm_window_draw_decoration,
@@ -2547,6 +2554,9 @@ xserver_map_shell_surface(struct weston_wm_window *window,
   window->surface,
   &shell_client);
 
+   wm_log("XWM: map shell surface, win %d, xwayland surface %p\n",
+  window->id, window->shsurf);
+
if (window->name)
xwayland_interface->set_title(window->shsurf, window->name);
if (window->pid > 0)
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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 entry set_xwayland_position
- implement set_toplevel_with_position() in xwayland internal interface

Once xwayland plugin starts calling set_toplevel_with_position(),
libweston-desktop can relay that information to a shell if the shell
wants to hear it.

If a shell does not implement the set_xwayland_position hook, the
old behaviour remains: the shell positions xwayland toplevels like any
other.

Signed-off-by: Pekka Paalanen 
Reviewed-by: Quentin Glidic 
---
 libweston-desktop/internal.h  |  5 +
 libweston-desktop/libweston-desktop.c | 10 ++
 libweston-desktop/libweston-desktop.h | 33 +
 libweston-desktop/xwayland.c  | 11 +++
 4 files changed, 59 insertions(+)

diff --git a/libweston-desktop/internal.h b/libweston-desktop/internal.h
index a9c974b..763355b 100644
--- a/libweston-desktop/internal.h
+++ b/libweston-desktop/internal.h
@@ -81,6 +81,11 @@ void
 weston_desktop_api_minimized_requested(struct weston_desktop *desktop,
   struct weston_desktop_surface *surface);
 
+void
+weston_desktop_api_set_xwayland_position(struct weston_desktop *desktop,
+struct weston_desktop_surface *surface,
+int32_t x, int32_t y);
+
 struct weston_desktop_seat *
 weston_desktop_seat_from_seat(struct weston_seat *wseat);
 
diff --git a/libweston-desktop/libweston-desktop.c 
b/libweston-desktop/libweston-desktop.c
index 0ee1139..48e9000 100644
--- a/libweston-desktop/libweston-desktop.c
+++ b/libweston-desktop/libweston-desktop.c
@@ -242,3 +242,13 @@ weston_desktop_api_minimized_requested(struct 
weston_desktop *desktop,
if (desktop->api.minimized_requested != NULL)
desktop->api.minimized_requested(surface, desktop->user_data);
 }
+
+void
+weston_desktop_api_set_xwayland_position(struct weston_desktop *desktop,
+struct weston_desktop_surface *surface,
+int32_t x, int32_t y)
+{
+   if (desktop->api.set_xwayland_position != NULL)
+   desktop->api.set_xwayland_position(surface, x, y,
+  desktop->user_data);
+}
diff --git a/libweston-desktop/libweston-desktop.h 
b/libweston-desktop/libweston-desktop.h
index f77ab55..03b04c7 100644
--- a/libweston-desktop/libweston-desktop.h
+++ b/libweston-desktop/libweston-desktop.h
@@ -80,6 +80,39 @@ struct weston_desktop_api {
bool maximized, void *user_data);
void (*minimized_requested)(struct weston_desktop_surface *surface,
void *user_data);
+
+   /** Position suggestion for an Xwayland window
+*
+* X11 applications assume they can position their windows as necessary,
+* which is not possible in Wayland where positioning is driven by the
+* shell alone. This function is used to relay absolute position wishes
+* from Xwayland clients to the shell.
+*
+* This is particularly used for mapping windows at specified locations,
+* e.g. via the commonly used '-geometry' command line option. In such
+* case, a call to surface_added() is immediately followed by
+* xwayland_position() if the X11 application specified a position.
+* The committed() call that will map the window occurs later, so it
+* is recommended to usually store and honour the given position for
+* windows that are not yet mapped.
+*
+* Calls to this function may happen also at other times.
+*
+* The given coordinates are in the X11 window system coordinate frame
+* relative to the X11 root window. Care should be taken to ensure the
+* window gets mapped to coordinates that correspond to the proposed
+* position from the X11 client perspective.
+*
+* \param surface The surface in question.
+* \param x The absolute X11 coordinate for x.
+* \param y The absolute X11 coordinate for y.
+* \param user_data The user_data argument passed in to
+* weston_desktop_create().
+*
+* This callback can be NULL.
+*/
+   void (*set_xwayland_position)(struct weston_desktop_surface *surface,
+ int32_t x, int32_t y, void *user_data);
 };
 
 void
diff --git a/libweston-desktop/xwayland.c b/libweston-desktop/xwayland.c
index 6b90c14..c64650d 100644
--- a/libweston-desktop/xwayland.c
+++ b/libweston-desktop/xwayland.c
@@ -254,6 +254,16 @@ set_toplevel(struct weston_desktop_xwayland_surface 
*surface)

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

[Pekka Paalanen]

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 window.

Following patches will implement this new entry in
libweston-desktop and start using it in XWM.

Signed-off-by: Pekka Paalanen 
Reviewed-by: Quentin Glidic 
---
 xwayland/xwayland-internal-interface.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xwayland/xwayland-internal-interface.h 
b/xwayland/xwayland-internal-interface.h
index e771730..1096444 100644
--- a/xwayland/xwayland-internal-interface.h
+++ b/xwayland/xwayland-internal-interface.h
@@ -38,6 +38,8 @@ struct weston_desktop_xwayland_interface {
  struct weston_surface 
*surface,
  const struct 
weston_xwayland_client_interface *client);
void (*set_toplevel)(struct weston_desktop_xwayland_surface *shsurf);
+   void (*set_toplevel_with_position)(struct 
weston_desktop_xwayland_surface *shsurf,
+  int32_t x, int32_t y);
void (*set_parent)(struct weston_desktop_xwayland_surface *shsurf,
   struct weston_surface *parent);
void (*set_transient)(struct weston_desktop_xwayland_surface *shsurf,
-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

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:
https://lists.freedesktop.org/archives/wayland-devel/2016-November/031976.html

This patch series is also available as a branch:
https://git.collabora.com/cgit/user/pq/weston.git/log/?h=x11-positioning-v2

In this v2, patches 1-6 are exactly the same as v1. The old patch 7 is
now patch 24.

The reason for the new patches 7-23 is the clean-up and the new
operating sequence called for in T7622. I tried to keep each patch as
simple and straightforward as possible, hence the number of them.

I have refactored xwayland/window-manager.c a lot around the window
MapRequest handling and decoration repainting, hopefully the code is
now also a little more readable. This was necessary so that the actual
behavioral changes would not drown in the churn.

The functionality in the final patch of this series depends on the
Xwayland series:
https://patchwork.freedesktop.org/series/16610/

However, the Xwayland patches are not a requirement - without them
things should still work, if a bit more glitchy than with.

Below is the debug log for starting 'xeyes'. It shows the end result
of the patch series (without --geometry). The log is an async mix of
prints from Weston and Xwayland. Particularly notice the "xwayland:
win 2097202 allow_commits = 0" from Xwayland in the middle of Weston
output.

Note, that in the log:
- decors are drawn only twice
- Xwayland does not commit before decor are drawn

When looking at timings in logs like this, it is important to note two things:
1) starting the very first X11 client will have wildly different timings than
any later one, and 2) whether Xwayland actually uses GLAMOR or not may play a
part.

This series should be a nice ground work for further XWM improvements,
_NET_WM_SYNC_REQUEST for instance. ;-)

Happy winter holidays everyone!
I'll be back mid-January or so.


Thanks,
pq

client(40): Reserved pid(27079).
client(40): Reserved cmdname(xeyes) and cmdargs(NULL).
AllocNewConnection: client index = 2, socket fd = 7
[16:03:30.562] XCB_CREATE_NOTIFY (window 4194314, at (0, 0), width 150, height 
100)
[16:03:30.562] XCB_PROPERTY_NOTIFY: window 4194314, WM_CLIENT_LEADER: 
WINDOW/32, length 4 (value_len 1): huh?
[16:03:30.563] XCB_MAP_REQUEST (window 4194314, 0x989f00, frame 2097202, 
150x100 @ 0,0)
[16:03:30.563] XWM: schedule repaint, win 4194314
[16:03:30.563] XCB_PROPERTY_NOTIFY: window 4194314, xwayland: win 2097202 
allow_commits = 0
WM_PROTOCOLS: ATOM/32, length 4 (value_len 1): WM_DELETE_WINDOW
[16:03:30.564] XCB_CREATE_NOTIFY (window 2097202, at (0, 0), width 226, height 
197, ours)
[16:03:30.564] XCB_REPARENT_NOTIFY (window 4194314, parent 2097202, event 624)
[16:03:30.564] XCB_REPARENT_NOTIFY (window 4194314, parent 2097202, event 
2097202)
[16:03:30.564] XCB_CONFIGURE_NOTIFY (window 4194314) 38,59 @ 150x100
[16:03:30.564] XCB_PROPERTY_NOTIFY: window 4194314, WM_STATE: WM_STATE/32, 
length 8 (value_len 2): huh?
[16:03:30.564] XCB_PROPERTY_NOTIFY: window 4194314, _NET_WM_STATE: ATOM/32, 
length 0 (value_len 0): 
[16:03:30.564] XCB_PROPERTY_NOTIFY: window 4194314, _NET_WM_DESKTOP: 
CARDINAL/32, length 4 (value_len 1): huh?
[16:03:30.564] XCB_MAP_NOTIFY (window 4194314)
[16:03:30.564] XCB_MAP_NOTIFY (window 2097202, ours)
[16:03:30.564] XCB_CLIENT_MESSAGE (WL_SURFACE_ID 37 0 0 0 0 win 2097202)
[16:03:30.564] XWM: draw decoration, win 4194314
[16:03:30.565] XWM: create weston_surface 0xe4cb20
[16:03:30.565] XWM: map shell surface, win 4194314, weston_surface 0xe4cb20, 
xwayland surface 0xe4cea0
[16:03:30.565] XWM: win 4194314 geometry: 32,32 162x133
xwayland: win 2097202 allow_commits = 1
[16:03:30.566] weston_desktop_xwayland_surface_committed: xwayland surface 
0xe4cea0
[16:03:30.566] XWM: schedule repaint, win 4194314
[16:03:30.566] XWM: draw decoration, win 4194314
[16:03:30.567] XWM: win 4194314 geometry: 32,32 162x133
[16:03:30.567] XCB_MAPPING_NOTIFY
[16:03:30.567] XCB_MAPPING_NOTIFY
[16:03:30.568] XCB_CONFIGURE_NOTIFY (window 2097202) 29,238 @ 226x197
[16:03:30.568] weston_desktop_xwayland_surface_committed: xwayland surface 
0xe4cea0
[16:03:30.639] weston_desktop_xwayland_surface_committed: xwayland surface 
0xe4cea0



Pekka Paalanen (24):
  xwayland: WM debug prints
  xwayland: add set_toplevel_with_position to internal API
  libweston-desktop: add set_xwayland_position API
  xwayland: detect initially positioned X11 windows
  shell: implement set_xwayland_position
  libweston-desktop/xwayland: react to geometry changes
  desktop-shell: debug set_position_from_xwayland
  libweston-desktop/xwayland: debug commits
  xwm: detect legacy fullscreen on MapRequest
  xwm: clarify props[] in weston_wm_window_read_properties()
  xwm: move frame_set_title() into draw_decoration()
  xwm: move set_title and set_pid
  xwm: debug changes to override-redirect flag
  xwm: debug 

[no subject]

[Sung-jae Park]

ㅣ

⁣--- 
What You Think Is What You Get. 
Software will make your dream come true. 
Welcome, http://nicesj.com 
--- ​___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

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 partial data loss is the dumb
>> > program that can open a JPEG but ignore EXIF color space metadata and
>> > an embedded ICC profile. What'd be nice is if the application doesn't
>> > have to know how to handle this: reading that data, and then tagging
>> > the image object with that color space metadata. Instead the
>> > application should use some API that already knows how to read files,
>> > knows what a JPEG is, knows all about the various metadata types and
>> > their ordering rules, and that library is what does the display
>> > request and knows it needs to attach the color space metadata. It's
>> > really the application that needs routing around.
>>
>> I agree (the specific JPEG case is something that's been bugging me
>> for some time), and it's something I want to build in to make it as
>> easy as possible for people to gradually build their clients to get
>> this right.
>
> This is really something that should be done by the toolkits (Qt, GTK, ...).
> I really hope that they start to read the profile from EXIF when opening an
> image. They can then either attach it to the subsurface that is used to
> display the image, or convert it to their blending space (which could match
> the blending space of the compositor) if blending is performed.

Sure. Complicated of course by things like embedded web views, but ...

>> Similarly, I'd like to park the discussion about surfaces split across
>> multiple displays; it's a red herring. Again, in X11, your pixel
>> content exists in one single flat buffer which is shared between
>> displays. This is not a restriction we have in Wayland, and a lot of
>> the discussion here has rat-holed on the specifics of how to achieve
>> this based on assumptions from X11. It's entirely possible that the
>> best solution to this (a problem shared with heterogeneous-DPI
>> systems) is to provide multiple buffers. Or maybe, as you suggest
>> below, normalised to an intermediate colour system of perhaps wider
>> gamut. Either way, there's a lot of ways to attack it, but how we
>> solve that is almost incidental to core colour-management design.
>
> Has there been any discussion about using a buffer per output to solve the
> heterogeneous-DPI problem? If we end up doing that we might as well use it for
> color correction. But otherwise I would prefer the device link profile
> solution.

No, it's something I've just thrown out here because I thought this
thread was too relentlessly productive and on-topic. It's _a_ possible
solution which doesn't seem immediately useless though, so that's
something. I was mostly using it though, to illustrate that there may
be better long-term solutions than are immediately obvious.

>> > So then I wonder where the real performance penalty is these days?
>> > Video card LUT is a simplistic 2D transform. Maybe the "thing" that
>> > ultimately pushes pixels to each display, can push those pixels
>> > through a software 2D LUT instead of the hardware one, and do it on 10
>> > bits per channel rather than on full bit data.
>>
>> Some of the LUTs/matrices in display controllers (see a partial
>> enumeration in reply to Mattias) can already handle wide-gamut colour,
>> with caveats. Sometimes they will be perfectly appropriate to use, and
>> sometimes the lack of granularity will destroy much of their value. If
>> the compositor is using the GPU for composition, then doing colour
>> transformations is extremely cheap, because we're rarely bound on the
>> GPU's ALU capacity.
>
> Yes, but as Graeme has pointed out doing it in a shader means lower precision
> when using a 8 bit framebuffer. How feasible is it to use a higher resolution
> framebuffer and how big would the performance impact be?

Well yeah, if you're using an 8-bit framebuffer then that caps your
effective precision. But even ignoring the fact that intermediate
calculations within shaders happen at vastly higher precision (often
32bpc) than either your source or destination buffer, I don't know of
hardware which supports 10bpc sampler targets but not render targets.
Meaning that sudden demotion to 8bpc precision doesn't just happen;
you either succeed or fail in the first.

(By way of example, Mesa does not usefully expose 10bpc formats for
non-Intel drivers right now; the hardware and underlying drivers do;
it's just a small bit of missing glue code. On the other hand, there
is no silent jump between precision; it just wouldn't work.)

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

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 other direction as well.

I would definitely benefit from seeing an expansion of some of the
terminology that is thrown around which can be subtly misleading. But
yes, as said, I've got some Christmas reading to do.

>> If you reduce Wayland's capabilities to that of X11, then some of
>> your suggestions may be less wildly unsuitable, but on the other hand,
>> we might as well be using X11 if that were the case.
>
> It's not my intent to do so, but to contrast the gap in
> capabilities that currently exists, and would like
> to see filled in a workman like manner.

Per my reply to Chris, some of those gaps can be filled in ways which
are not obvious when coming from other environments. Trying to solve
them in the exact same way would be bashing a square peg into a round
hole, so it can be useful to step back and have a think about
first-order requirements, rather than just jumping directly to deeply
specific solutions.

>> Let's say that the target here is a user for whom absolute colour
>> correctness is so critical, that they have deeply specialised
>> applications and hardware, monitors most people have never heard of,
>> secondary measurement and calibration hardware, and have sunk a great
>> deal of time into specifically configuring this.
>> For such a user to pick a compositor which was actively bad at colour
>> management would be rank stupidity.
>>
>> If you don't trust the compositor you're using to do the thing which
>> is above all else most important to you, maybe pick something else?
>
> If there is no capability or standardization in this area for Wayland based
> systems, I don't see how such a user has any other choice than to pick a
> "compositor" called Microsoft Windows or Apple OS X. That would be a shame.

Yes. No-one in this thread wants to see a solution which precludes
fully correct and accurate colour management.

>> You're painting a false dichotomy where either people use external
>> tools to allow colour-critical users to compensate for the damage
>> their known-bad compositors do, or there is no chance of ever having
>> colour management ever. If only there was a third option.
>
> I'm not sure what you mean by a "known-bad compositors",
> nor do I really understand how this paints a false dichotomy.

By 'known-bad compositor', I speak of a compositor which, when
processing information from clients, does so destructively. Such that
the final output from the compositor (to any connected display, or
screenshot/screencast, be it via means of direct scanout from a plane,
or intermediate GPU rendering, or an intermediate hardware composition
through a dedicated block, or software composition, or, or), produces
incorrect results.

A lot of the discussion on this thread seems aimed at ensuring
compositors are not involved in colour management and colour-critical
applications are forced to use external systems to route around them
in order to achieve the desired colour result. This is a
self-fulfilling prophecy.

> The external tools are a means of creating the data to
> allow for managing and compensating for their particular displays.
> A competent application to create this data is non-trivial.
> If a graphical systems makes implementation of such software
> difficult or awkward or laborious, then such software
> may be slow to be developed for such systems. Without
> these tools then either color management can't exist
> on those systems, or it is compromised (i.e. using EDID
> derived profiles, or stock profiles), or awkward workarounds
> are needed (switch to an X11 server, boot Windows etc.)

Completely understandable. Again though, I think it's important to
separate the discussion of how to create a calibrator, from how to
create a colour-aware application that can achieve its desired colour
results. The two may, at a very low level, share similar requirements
(along with that of managing the data and applying it to outputs etc),
but I expect them to look very different from a protocol point of
view. Some of it may, as said earlier, not involve Wayland at all.

>> This thread perhaps demonstrates why many projects which would
>> otherwise care about colour management have such difficulty supporting
>> colour management correctly.
>
> It's a difficult subject to get a grasp on at times. Many programmers
> get to the stage of knowing what RGB is, and thinking there is not
> much more.

Yes, but it's also how you work with people. Security had the same
issue for the longest time, where there were application/system
people, and then there were security people, and the only time they
met was to tell each other that they didn't live in the real world. I
desperately want to avoid colour management remaining a ghetto whe

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

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  
wrote:
> >>> We can't have multiple white points on the display at the same time;
> >>> it causes incomplete user adaptation and breaks color matching
> >>> everywhere in the workflow. The traditional way to make sure there is
> >>> only one white point for all programs is manipulating the video card
> >>> LUTs. It's probably not the only way to do it. But if it's definitely
> >>> not possible (for reasons I'm not really following) for a privileged
> >>> display calibration program to inject LUT data, and restore it at boot
> >>> up time as well as wake from sleep, then another way to make certain
> >>> there's normalized color rendering on the display is necessary.
> >> 
> >> Right: 'ensure whitepoint consistency' is an entirely worthwhile goal,
> >> and I think everyone agrees on the point. 'Give clients absolute
> >> control over display hardware LUT + CTM' is one way of achieving that
> >> goal, but not a first-order goal in itself.
> >> 
> >> The reason applications can't drive the LUT is because, as you say,
> >> there's not always just one. If there were only one application, then
> >> why not just write directly to KMS? There's little call for a window
> >> system in that case.
> > 
> > At least on Windows and macOS there is a significant dependence on
> > "the honor system" that applications don't go messing around with
> > video card LUTs unless they happen to be specifically a display
> > calibration program. It's not in the interest of these applications to
> > change the video card LUT. The way it works on macOS and Windows, only
> > a display calibration program will do this: measures the display with
> > a linear video card LUT, computes a correction curve to apply to the
> > LUT, then measures the display again with the LUT in place, creates an
> > ICC profile from that 2nd set of measurements, and registers the ICC
> > profile with the OS so programs can be made aware of it.
> > 
> > If a program were to change the LUT, the display profile becomes
> > invalid. So it's not in the interest of any program that doesn't
> > calibrate displays to modify video card LUTs. OK so maybe that means
> > such a program is either a display calibrator, or it's malicious. I
> > haven't heard of such a malicious program, but that's also like blind
> > faith in aviation's "big sky theory". But totally proscribing programs
> > that depend on changing video card LUTs just to avoid the next to
> > impossible malware vector seems a bit heavy weight, in particular
> > given that an alternative (full display compensation) doesn't yet
> > exist.
> 
> Understood. I'd perhaps misread some earlier discussions in the
> megathread (which I don't really wish to revisit) then; apologies.
> 
> For the purposes of this discussion, I'd like to park the topic of
> calibration for now. It goes without saying that providing facilities
> for non-calibration clients is useless without calibration existing,
> but the two are surprisingly different from a window-system-mechanism
> point of view; different enough that my current thinking tends towards
> a total compositor bypass for calibration, and just having it drive
> DRM/KMS directly. I'd like to attack and bottom out the
> non-calibration usecase without muddying those waters, though ...
> 
> >>> The holy grail is as Richard Hughes describes, late binding color
> >>> transforms. In effect every pixel that will go to a display is going
> >>> to be transformed. Every button, every bit of white text, for every
> >>> application. There is no such thing as opt in color management, the
> >>> dumbest program in the world will have its pixels intercepted and
> >>> transformed to make sure it does not really produce 255,255,255
> >>> (deviceRGB) white on the user display.
> >> 
> >> I agree that there's 'no such thing as an opt in', and equally that
> >> there's no such thing as an opt out. Something is always going to do
> >> something to your content, and if it's not aware of what it's doing,
> >> that something is going to be destructive. For that reason, I'm deeply
> >> skeptical that the option is routing around the core infrastructure.
> > 
> > There's ample evidence if it's easy to opt out, developers will do so.
> > It needs to be easier for them to just get it for free or nearly so,
> > with a layered approach where they get more functionality by doing
> > more work in their program, or using libraries that help them do that
> > work for them.
> 
> I completely agree with you! Not only on the 'opt in' point quoted
> just here, but on this. When I said 'opt out' in my reply, I was
> talking about several proposals in the discussion that applications be
> able to 'opt out of colour management' because they already had the
> perfect pipelin

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

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 hardware and the compositor would then restore the
> proper state when it is started again...

My working view at the moment is that whatever is doing calibration
should be directly in charge of the full insane complexity of the
display hardware, and that even enumerating this, let alone offering
control over it, is not tractable. Which leaves us with two options:
the compositor runs calibration, or external calibration apps do not
run under a Wayland session and just drive DRM/KMS directly.

This didn't make any sense when all display drivers were Xorg
components, but hey, we do have a universal API in DRM/KMS that you
can write applications directly towards, so I don't see why we should
bend over backwards making these compromises for special-purpose
clients which by definition do not interoperate with a regular desktop
environment.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Daniel Stone]

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 display at the same time;
>>> it causes incomplete user adaptation and breaks color matching
>>> everywhere in the workflow. The traditional way to make sure there is
>>> only one white point for all programs is manipulating the video card
>>> LUTs. It's probably not the only way to do it. But if it's definitely
>>> not possible (for reasons I'm not really following) for a privileged
>>> display calibration program to inject LUT data, and restore it at boot
>>> up time as well as wake from sleep, then another way to make certain
>>> there's normalized color rendering on the display is necessary.
>>
>> Right: 'ensure whitepoint consistency' is an entirely worthwhile goal,
>> and I think everyone agrees on the point. 'Give clients absolute
>> control over display hardware LUT + CTM' is one way of achieving that
>> goal, but not a first-order goal in itself.
>>
>> The reason applications can't drive the LUT is because, as you say,
>> there's not always just one. If there were only one application, then
>> why not just write directly to KMS? There's little call for a window
>> system in that case.
>
> At least on Windows and macOS there is a significant dependence on
> "the honor system" that applications don't go messing around with
> video card LUTs unless they happen to be specifically a display
> calibration program. It's not in the interest of these applications to
> change the video card LUT. The way it works on macOS and Windows, only
> a display calibration program will do this: measures the display with
> a linear video card LUT, computes a correction curve to apply to the
> LUT, then measures the display again with the LUT in place, creates an
> ICC profile from that 2nd set of measurements, and registers the ICC
> profile with the OS so programs can be made aware of it.
>
> If a program were to change the LUT, the display profile becomes
> invalid. So it's not in the interest of any program that doesn't
> calibrate displays to modify video card LUTs. OK so maybe that means
> such a program is either a display calibrator, or it's malicious. I
> haven't heard of such a malicious program, but that's also like blind
> faith in aviation's "big sky theory". But totally proscribing programs
> that depend on changing video card LUTs just to avoid the next to
> impossible malware vector seems a bit heavy weight, in particular
> given that an alternative (full display compensation) doesn't yet
> exist.

Understood. I'd perhaps misread some earlier discussions in the
megathread (which I don't really wish to revisit) then; apologies.

For the purposes of this discussion, I'd like to park the topic of
calibration for now. It goes without saying that providing facilities
for non-calibration clients is useless without calibration existing,
but the two are surprisingly different from a window-system-mechanism
point of view; different enough that my current thinking tends towards
a total compositor bypass for calibration, and just having it drive
DRM/KMS directly. I'd like to attack and bottom out the
non-calibration usecase without muddying those waters, though ...

>>> The holy grail is as Richard Hughes describes, late binding color
>>> transforms. In effect every pixel that will go to a display is going
>>> to be transformed. Every button, every bit of white text, for every
>>> application. There is no such thing as opt in color management, the
>>> dumbest program in the world will have its pixels intercepted and
>>> transformed to make sure it does not really produce 255,255,255
>>> (deviceRGB) white on the user display.
>>
>> I agree that there's 'no such thing as an opt in', and equally that
>> there's no such thing as an opt out. Something is always going to do
>> something to your content, and if it's not aware of what it's doing,
>> that something is going to be destructive. For that reason, I'm deeply
>> skeptical that the option is routing around the core infrastructure.
>
> There's ample evidence if it's easy to opt out, developers will do so.
> It needs to be easier for them to just get it for free or nearly so,
> with a layered approach where they get more functionality by doing
> more work in their program, or using libraries that help them do that
> work for them.

I completely agree with you! Not only on the 'opt in' point quoted
just here, but on this. When I said 'opt out' in my reply, I was
talking about several proposals in the discussion that applications be
able to 'opt out of colour management' because they already had the
perfect pipeline created. That 'opt out' is not a thing that exists,
because if the system is designed such that the compositor can only
guess or infer colour properties, then it will get it wrong, and it
will be destructive. That's not a system I'm interes

Re: A solution for gamma-adjustment support in Wayland

[Daniel Stone]

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 enumerate, let alone abstract.
>
> I think at the very least want I have suggested should
> be implemented. However, adding the functionality to
> transform the values via matrix multiplication as well
> is probably a good idea. If matrices and ramps are
> combined into the same chain, what more could possibly
> be added. Abstraction is easier than enumeration in this
> case, if the transformation can be handles by the
> graphics card, let it do it, otherwise, do it before.
>
> 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 solution, an API is necessary. It's bad
> enough that colour management is done by the compositor.

I fundamentally disagree on the difficulty of designing API,
especially when the API is already inadequate from the start.
Enumeration in particular is required to get the best results: a
client may sometimes wish to render in a wider but linear format in
order to avoid the loss of precision on LUT indexing when using
split-gamma modes.

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 a compositor is unaware of how those pixels should be interpreted,
then it is going to be destructive and do the wrong thing. If you want
colour-accurate display, there is no good solution based on the
premise that your display controller should have no idea about
colours.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

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 calibrate we just ask for a
> > > surface that's not going to be tampered with, but we don't want to
> > > optimize for this super-uncommon case.
> > 
> > I disagree - leave it to be an afterthought, and it will be
> > done badly or left out completely, crippling the practicality
> > of color management for the system.  
> 
> Designing that is trivial:
> 
> GLOBAL cms_calibrator
> - request: create_calibration_surface(wl_surface, new cms_calibration_surface)
>   # Assigns wl_surface role.
> 
> INTERFACE cms_calibration_surface
>   # Surfaces with this role will only be shown on the set output,
>   # with direct color path bypassing all color-management, and
>   # and the hardware has been reset to neutral/identity settings.
>   # (or whatever requirements are appropriate, you can decide
>   # what to write here)
> - request: set_output(wl_output)
>   # Which output this surface targets. The compositor replies
>   with a
>   # configure event.
> - event: configure(width, height)
>   # delivers the width and height the application needs to use
> 
> 
> How it operates from a client perspective:
> 
> 1. create a wl_surface
> 2. bind to cms_calibrator
> 3. send create_calibration_surface
> 4. send set_output
> 5. wait for configure
> 6. draw the calibration surface in the correct size
> 7. use Presentation feedback interface to ensure the calibration
>surface is show with the latest content
> 8. do what you want to do with the colorimeter
> 9. go to 6 to update the image if necessary
> 10. destroy cms_calibration_surface and wl_surface; the display
> automatically returns to normal
> 
> 
> To be user friendly, one probably wants to add an event in case the
> user denies the request to show the calibration window as it will have
> temporary global effects.
> 
> Whether the global needs to be privileged or not, and how privileges
> are implemented are an orthogonal matter.

Hi Niels,

I really should have CC'd you on this one.

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.

You'd also want an event telling that the user has interrupted the
showing of the calibration window, so that the calibration app cannot
hog the output indefinitely even if it freezes. That might be the same
event telling the user denied it in the first place.

This is something you cannot achieve with just a pass-through color
profile.


Thanks,
pq


pgpG5LeJ_tt4L.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: A solution for gamma-adjustment support in Wayland

[Mattias Andrée]

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 compositor supports cooperative gamma. The size and
> > the depth of the CLUT should should also be
> > retrievable. Since cooperative gamma is supported, the
> > size and depth of the CLUT can exceed the controller’s
> > CLUT for better results when output filters are chained
> > together.  
> 
> 'The size and depth' and 'the CLUT' are no longer
> applicable. Colour management units, incorporating two
> LUTs and a matrix (coarsely, degamma-transform-regamma)
> are becoming rather common now. These units can be
> present per-plane as well as per-output/pipe. Sometimes
> you have to make tradeoffs.
> 
> For instance, on recent Intel hardware, you can have the
> matrix with 10-bit LUTs on either side with 512 entries
> each, or you can have the matrix with only _one_ 10-bit
> LUT (either pre- or post-matrix) which can now contain
> 1024 entries. The weighting for interpolation between
> entries can be programmable, and the last entry in the
> post-matrix LUT is used to deal with overshoot, as the
> matrix can produce values in the range of [-3.0,3.0].
> 
> Tegra is pretty similar, except that its indexing into
> the LUT is very much non-uniform; the tradeoff for
> simplicity is that it's a fixed 8-bit -> 12-bit LUT
> pre-matrix, and the reverse post-matrix; wider colour
> modes are not supported. NVIDIA's desktop hardware is a
> black box to me, but their technical marketing material
> (if nothing else) very strongly suggests that they have
> something very similar. AMD hardware (CIK, at least) has
> roughly the same similar functionality, except it's not
> supported with the open driver.
> 
> 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 enumerate, let alone abstract.
> 
> Cheers,
> Daniel

I think at the very least want I have suggested should
be implemented. However, adding the functionality to
transform the values via matrix multiplication as well
is probably a good idea. If matrices and ramps are
combined into the same chain, what more could possibly
be added. Abstraction is easier than enumeration in this
case, if the transformation can be handles by the
graphics card, let it do it, otherwise, do it before.

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 solution, an API is necessary. It's bad
enough that colour management is done by the compositor.



pgpENGke0v0EO.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] Add the color-management protocol

[The Rasterman]

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 
> >> wrote:
> >> > so... here is my question - shouldn't the colorspace be tired to a
> >> > buffer? not a surface? yes. i know. the surface "displays" the buffer...
> >> > but the colorspace is intrinsic to the buffer content... right?
> >>
> >> Conceptually, buffer is a good shout, but buffers are hidden from you
> >> in EGL. Given that people will want to do (at least vaguely)
> >> colour-correct GL rendering, that makes surface rather than bufer the
> >> right choice.
> >
> > i actually meant wl_buffer which is really the abstraction on top of these
> > buffers... ?
> 
> No, I mean that client rendering looks like this in EGL:
> egl_dpy = eglGetPlatformDisplay(...);
> egl_cfg = eglChooseConfig(egl_dpy, ...);
> egl_surf = eglCreateWindowSurface(egl_dpy, egl_cfg, ...);
> egl_ctx = eglCreateContext(egl_dpy, egl_cfg, ...);
> (bool) eglMakeCurrent(egl_dpy, egl_surf, egl_surf, egl_ctx);
> {
> (void) gl*();
> (bool) eglSwapBuffers();
> }

oh yeah. i was not thinking if client is using egl and eglswapbuffers is hiding
everything. i was thinking clients explicitly sending buffers.

> At no point does an EGL client ever come into contact with the
> wl_buffers produced by EGL. They are utterly opaque, and hidden inside
> the EGL implementation. This means that, in order to get
> colour-correct rendering through EGL, you either have to have it
> attached to the surface (which the client can see and control), or you
> have to grow EGL API for the entire breadth of colour management. This
> is a lot of the reason why we have things like opaque region attached
> to the surface, with the commit latched, rather than buffers.
> 
> Cheers,
> Daniel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

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 and if the
> > compositor can set e.g. CLUTs, CMS can tell it what to set.
> 
> "cLUTS" are things in the ICC profile (Color, or multi-dimensional lookup
> tables.) and are typically used (as part of a conversion) to represent a
> device response or an overal color transformation.
> 
> VideoLUTs are in the graphics hardware (CRTC), and involve the setup
> ("calibration") of the display. ICC profile handle some aspects
> of the display badly - namely white point setting, which has
> been (deliberately) crippled in the ICC format, so setting the hardware
> per channel Lookup tables is the way to work around that,
> as well as having the benefits of ensuring that even non-color
> aware applications all have a consistent white point and visual
> transfer curve.
> Without this, mixed visual white adaptation will destroy the usefulness
> of the display.
> 
> An additional subtlety is that in typical hardware, the VideoLUT entry
> depth is greater than the frame buffer depth, so setting the overall
> visual transfer curve and neutral axis matching using
> the VideoLUT has the advantage of extra precision (typically 2 or
> more extra bits, quite noticeable on 8 BPP frame buffers). Because
> the VideoLUTs are global to each display, all the applications get
> the benefit of this, and it makes the profile more accurate by making
> the display better behaved
> 
> There is a de facto standard in ICC profiles that display
> profiles may include a tag that stores the display expected
> VideoLUT values ('vcgt' tag), and since the contents of
> the display profile are built on the assumption of that
> set of calibration curves, systems typically install
> that vcgt tag contents in the VideoLUTs when a profile
> is set to be the one for that display.
> 
> But, to actually create the calibration curves, a color
> calibration and profiling application needs to be able
> to set the VideoLUT contents to specific values. Other
> useful functions are to be able to read the VideoLUT
> values, to be able to verify that the calibration is as
> intended.
> 
> (A little more information is here:
>  )

If the resolution of the frame buffer was high enough we could just apply the 
VideoLUT in software when we also apply the display profile and leave the 
hardware LUT alone. You could then profile the screen by setting the device 
link profile of your surface to the identity mapping without any vcgt tag.

But I agree that we want to program the VideoLUT as long as we use 8 bit 
framebuffers. We normally do not want to allow applications to change the 
VideoLUT since that would have an influence on all applications and a broken 
application might mess with it in some unintended way.

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 hardware and the compositor would then restore the 
proper state when it is started again...

> > I am assuming that the compositor can interface with a CMS by calling
> > into a library offered by the CMS. If that interfacing was previously
> > done over X11, then you have to write that library. It will be more
> > efficient too, since you don't have to serialize and deserialize, and
> > asynchronicity (problems) appear only when you want to.
> 
> In X11 the VideoLUT setting/reading is done via XF86VidModeQueryExtension
> (old) or XRandR (current). Typically the system color management support
> will track the currently installed display profile, and set the
> VideoLUT hardware (Gnome colord), or users will invoke
> an equivalent utility at system startup (dispwin, xcalib etc.).
> Such utilities also typically set an X11 atom or Output property
> so that applications can obtain the display profile.
> 
> Note also that there are more things that an application
> may want out of the current display profile than simply
> the ability to transform into that space - they may
> want to determine the color gamut, they may wish
> to tag a window capture with the colorspace it is in, etc.
> 
> > I'm slowly starting to suspect that CMS designers need a slight paradigm
> > shift: the compositor is meant to integrate with the CMS, instead of
> > the CMS given low-level access to the hardware bypassing the window
> > manager. CMS is no longer something that can be bolted on externally,
> > like it is in X11. Embrace the idea of integration, and I belive and
> > hope that it will pay off as a much more reliable architecture and
> > polished user interfaces. Some of what used to go over X11 would
> > probably be much better as a library ABI, but in X11 tim

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

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 will not
> > or cannot do so. Why?  
> 
> I think lcms2 is fine to use; it's widely used in other projects,
> tested, and already optionally used in weston.
> 
> > Are you implying that the CMS you worked on so hard is impossible to use
> > from a compositor?  
> 
> I think that's basically correct, argyllcms doesn't have any header
> files or shared libraries. When using it to generate color profiles
> for things like printers from gnome-color-manager I have to spawn the
> binaries themselves (and only in a VT...) and then scrape the output.
> https://git.gnome.org/browse/gnome-color-manager/tree/src/gcm-calibrate-argyll.c#n273

Oh, that's a huge surprise to me, being accustomed to open source.

> > Yes! The CMS needs to provide the API that all compositors could use.  
> 
> I'm not a great fan of pluggable CMSs, it's a bit like designing a car
> that has a requirement that the engine is swappable with another
> whilst driving down the motorway. I'm a great fan at pointing people
> to http://www.islinuxaboutchoice.com/ when they ask about things like
> this.

Sorry about the typo, I meant "an API", not "the API". We're not
Khronos, indeed.

Just like programs can choose their toolkits, compositors should be
able to choose their color management providers for calibration and
color processing. We would still have the public and generic Wayland
extension for providing color-managed content, so it would not affect
normal application compatibility.


Thanks,
pq


pgpheaG31WGYS.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] Color management protocol

[Daniel Stone]

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
> least-common-denominator approach of setting the RGB 8-bit ramps on
> the logic it's the only way to set the white point without the
> overhead of a shader lookup. Most modern hardware actually supports
> some kind of *matrix* and LUT on the crtc output itself, although
> there is no common abstract interface that's provided by libdrm, yet.

Not quite correct; the split-gamma-plus-matrix approach is already
supported by KMS properties. It doesn't quite expose (or at least
enumerate; it might be there if you poke sharply enough) the full
spectrum of complexity that I just outlined in reply to Mattias, but
it'll get there I'm sure ...

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: A solution for gamma-adjustment support in Wayland

[Daniel Stone]

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
> retrievable. Since cooperative gamma is supported, the size and depth of
> the CLUT can exceed the controller’s CLUT for better results when output
> filters are chained together.

'The size and depth' and 'the CLUT' are no longer applicable. Colour
management units, incorporating two LUTs and a matrix (coarsely,
degamma-transform-regamma) are becoming rather common now. These units
can be present per-plane as well as per-output/pipe. Sometimes you
have to make tradeoffs.

For instance, on recent Intel hardware, you can have the matrix with
10-bit LUTs on either side with 512 entries each, or you can have the
matrix with only _one_ 10-bit LUT (either pre- or post-matrix) which
can now contain 1024 entries. The weighting for interpolation between
entries can be programmable, and the last entry in the post-matrix LUT
is used to deal with overshoot, as the matrix can produce values in
the range of [-3.0,3.0].

Tegra is pretty similar, except that its indexing into the LUT is very
much non-uniform; the tradeoff for simplicity is that it's a fixed
8-bit -> 12-bit LUT pre-matrix, and the reverse post-matrix; wider
colour modes are not supported. NVIDIA's desktop hardware is a black
box to me, but their technical marketing material (if nothing else)
very strongly suggests that they have something very similar. AMD
hardware (CIK, at least) has roughly the same similar functionality,
except it's not supported with the open driver.

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 enumerate, let
alone abstract.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[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 cannot do so. Why?

I think lcms2 is fine to use; it's widely used in other projects,
tested, and already optionally used in weston.

> Are you implying that the CMS you worked on so hard is impossible to use
> from a compositor?

I think that's basically correct, argyllcms doesn't have any header
files or shared libraries. When using it to generate color profiles
for things like printers from gnome-color-manager I have to spawn the
binaries themselves (and only in a VT...) and then scrape the output.
https://git.gnome.org/browse/gnome-color-manager/tree/src/gcm-calibrate-argyll.c#n273

> Yes! The CMS needs to provide the API that all compositors could use.

I'm not a great fan of pluggable CMSs, it's a bit like designing a car
that has a requirement that the engine is swappable with another
whilst driving down the motorway. I'm a great fan at pointing people
to http://www.islinuxaboutchoice.com/ when they ask about things like
this.

> so "just set the CLUT" is already an outdated approach

This is another point: We're all talking about the
least-common-denominator approach of setting the RGB 8-bit ramps on
the logic it's the only way to set the white point without the
overhead of a shader lookup. Most modern hardware actually supports
some kind of *matrix* and LUT on the crtc output itself, although
there is no common abstract interface that's provided by libdrm, yet.

Richard.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

A solution for gamma-adjustment support in Wayland

[Mattias Andrée]

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’ colour loop-up tables — that has been
used to implement, amongst other things, ergonomic functionality. But
we now have a chance to start from scratch and do it the right way.


### Background ###

Display servers have for a long time provided access to the graphics
cards’ colour look-up tables (CLUT), so the user can adjust the colour
output to more precisely match the intended output. Since then the
CLUT have used for other things, for example invert the output, dim
the output, adjusting the white point to make the output less blue,
and even cycles through the rainbow’s colours just for fun and rapidly
cycling between red, green, and blue to repair stuck pixels.

With the advent of Wayland, the CLUT are no longer available to
the user, instead the compositor uses colord to retrieve the profile
for the monitors and adjust, and any other feature that uses the CLUT
must be built into the compositor. This creates a numbers of problems:
developers that want to create a compositor — or just a part of the
compositor, like a window manager — must now also write the output
filters or find someone else to do it; the output filters become
coupled; a developer that wants to create a new output filter can no
longer do it as a stand-alone program, but rather must build it into
an existing program; users that want to use an output filter must
port it into the compositors they want to use that are missing that
output filter; and we run the risk that how the output filter is
controlled and configured depends on the want display server, if any,
and compositor is being used.


### Problems and Solutions ###

There are few problems that needs to be addressed when implementing
gamma support in a display server.

A concern with letting the user access CLUT is that a program could
make the screen unreadable. One solution is to add a minimal acceptable
ramp for each monitor, or a shared one. This has the advantage that the
screen can never become unreadable, but the disadvantage is that the
user cannot intentionally make the screen unreadable. For example,
before going to sleep the user can fade out the monitor to black, or
dark, pure red, and then fade it in during the morning. An alternative
solution to add a hotkey that disables all output filters accept the
colour correction. This has the advantage that the user can easily
disable all filters when working with colour, but it has the disadvantage
that the user may not be familiar with which key to use, even if set
manually (output filters could be disabled until a key is selected). It
is of course possible to use both alternatives.

Another concern, that is currently the case on X.org, is that if the
monitor becomes black, and the user is not familiar with how to make it
viewable again, switching virtual terminal (VT) will not save her. It is
easily solved by resetting to CLUT with only the gamma correction when a
VT-switch is requested. Similarly, this should be done when the server
is shut down or crashes. Furthermore, it is advantageous if the user is
able to SSH into the computer and reset the CLUT.

Another problem is when multiple programs want to change the CLUT,
and when programs to not properly reset the CLUT, often because of a
crash, and the ability for a program to set the CLUT and exit without
the CLUT being reset on exit. These are problems solved with cooperative
gamma.


### Cooperative Gamma ###

Cooperative gamma is a solution for letting multiple programs edit the
CLUT without overriding each other. It is already available, display
servers that expose access to the CLUT to clients, via coopgammad[1] and
libcoopgamma[2], and soon, all output filters and utilities are available
for this solution, primarily via cg-tools[3]. A compositor that provides
cooperative gamma will have all kinds of output filters available for
the simple work of porting one simple program and built it into the
compositor; and of course build the safe-guards discussed earlier.
Building cooperative gamma into compositors also mean that we do not
have to resort to ugly hacks like making a fork of colord that have
cooperative gamma.

With cooperative gamma, the display server chains together all
filters. Each filter is given a priority number which is used to
determine it’s position in the chain. Each filter is also given a name
so that it an be update or remove later, even by another process. A
program can add a filter and exit, and can then be restarted to update
or remove the filter. The program can tell the server to remove the
filter when the program exits, so the filter is cleaned up if the
program crashes or is killed.

-
[1] https://github.com/maandree/coopgammad
[2]

Problem With libwayland-cursor.so

[Ali Sarlak]

 Hi


 
When I configured the Wayland without --disable-scanner :

./configure  --disable-documentation --host=arm-linux-gnueabi 
--prefix=/home/ali/Desktop/Weston/waylanOut 
--with-sysroot=/home/ali/Desktop/rootfs/out/target 
--with-expat=/home/ali/Desktop/rootfs/out/target/usr

 
on make it complains:

make  all-recursive
make[1]: Entering directory `/home/ali/Desktop/Weston/wayland-1.0.3'
Making all in src
make[2]: Entering directory `/home/ali/Desktop/Weston/wayland-1.0.3/src'
  CC scanner.o
  CC wayland-os.lo
  CCLD   libwayland-util.la
  CCLD   wayland-scanner
  GENwayland-server-protocol.h
/bin/bash: ../src/wayland-scanner: cannot execute binary file: Exec format error
make[2]: *** [wayland-server-protocol.h] Error 126
make[2]: Leaving directory `/home/ali/Desktop/Weston/wayland-1.0.3/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ali/Desktop/Weston/wayland-1.0.3'
make: *** [all] Error 2

Yours,

 

 

-Original Message-
From: Ali Sarlak 
To: ppaalanen 
Sent: Tue, Dec 13, 2016 4:22 pm
Subject: Re: Problem With libwayland-cursor.so



 Dear pq,

When I configured the Wayland without --disable-scanner :

./configure  --disable-documentation --host=arm-linux-gnueabi 
--prefix=/home/ali/Desktop/Weston/waylanOut 
--with-sysroot=/home/ali/Desktop/rootfs/out/target 
--with-expat=/home/ali/Desktop/rootfs/out/target/usr

 
on make it complains:

make  all-recursive
make[1]: Entering directory `/home/ali/Desktop/Weston/wayland-1.0.3'
Making all in src
make[2]: Entering directory `/home/ali/Desktop/Weston/wayland-1.0.3/src'
  CC scanner.o
  CC wayland-os.lo
  CCLD   libwayland-util.la
  CCLD   wayland-scanner
  GENwayland-server-protocol.h
/bin/bash: ../src/wayland-scanner: cannot execute binary file: Exec format error
make[2]: *** [wayland-server-protocol.h] Error 126
make[2]: Leaving directory `/home/ali/Desktop/Weston/wayland-1.0.3/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ali/Desktop/Weston/wayland-1.0.3'
make: *** [all] Error 2

Yours,

 

-Original Message-
From: Pekka Paalanen 
To: Ali 
Cc: wayland-devel 
Sent: Tue, Dec 13, 2016 11:47 am
Subject: Re: Problem With libwayland-cursor.so

On Sat, 10 Dec 2016 22:09:29 +0330
Ali  wrote:

> Dear Wayland,
> 
> After I’ve read “Building Weston” doc I cross compiled the wayland and then I 
> tried to run Weston by :
> start-weston 
> 
> It complained:
> 
> [00:01:00.878] weston 1.0.3
>http://wayland.freedesktop.org/
>Bug reports to: 
> https://bugs.freedesktop.org/enter_bug.cgi?product=weston
>Build:  
> [00:01:00.878] OS: Linux, 3.0.35, #3 SMP PREEMPT Tue Nov 15 09:36:14 MST 
> 2016, armv7l
> [00:01:00.883] Loading module '/usr/lib/weston/gal2d-backend.so'
> [00:01:01.031] input device unknown, /dev/input/mice ignored: unsupported 
> device type
> [00:01:01.191] Loading module '/usr/lib/weston/desktop-shell.so'
> [00:01:01.199] libwayland: using socket /tmp_weston/wayland-0
> [00:01:01.200] launching '/usr/libexec/weston-desktop-shell'
> /usr/libexec/weston-desktop-shell: symbol lookup error: 
> /usr/lib/libwayland-cursor.so.0: undefined symbol: 
> wl_proxy_marshal_constructor


Hi,

this happens when you have built libwayland-cursor with a
wayland-scanner version that is higher than the libwayland-client you
built or are using at runtime.

It is recommended to always have wayland-scanner exactly the same
version as the libwayland you are building and running. It is ok to use
an older wayland-scanner than the libwayland you are running, but the
opposite is not guaranteed to work so far.


Thanks,
pq


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Daniel Stone]

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 in a 'lowest common denominator' colourspace,
>> such that the most optimal / least lossy output from your colour-aware
>> client would then _not_ correspond to your display device's native
>> characteristics.
>
> Some details make for possible disadvantages with color
> critical applications. Is a "lowest common denominator" space
> one with a gamut smaller than any attached display, ensuring
> that every color can be displayed without loss, while not
> allowing any use of a displays full gamut, or is it
> a colorspace that has a larger gamut than any attached
> display, meaning that colors will get clipped in
> ways the application has no control over, or may
> not want ? (i.e. the particular application may
> want some other intent such as perceptual or saturation
> gamut mapping).

I mean lowest common denominator _between clients_, whilst still being
tied to the output. So the gamut would ideally be as wide as (the
specific output + highest gamut buffer being painted during this
stage), but in taking multiple clients with potentially disparate
colour source attributes and producing a single flat buffer, you may
need to unpick some properties of the client's colour attributes.

This is quite a big difference from X11, in that there is no longer a
giant single buffer for all displays. One of the benefits of the
aggressive decoupling we've done ...

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Daniel Stone]

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 be tired to a buffer?
>> > not a surface? yes. i know. the surface "displays" the buffer... but the
>> > colorspace is intrinsic to the buffer content... right?
>>
>> Conceptually, buffer is a good shout, but buffers are hidden from you
>> in EGL. Given that people will want to do (at least vaguely)
>> colour-correct GL rendering, that makes surface rather than bufer the
>> right choice.
>
> i actually meant wl_buffer which is really the abstraction on top of these
> buffers... ?

No, I mean that client rendering looks like this in EGL:
egl_dpy = eglGetPlatformDisplay(...);
egl_cfg = eglChooseConfig(egl_dpy, ...);
egl_surf = eglCreateWindowSurface(egl_dpy, egl_cfg, ...);
egl_ctx = eglCreateContext(egl_dpy, egl_cfg, ...);
(bool) eglMakeCurrent(egl_dpy, egl_surf, egl_surf, egl_ctx);
{
(void) gl*();
(bool) eglSwapBuffers();
}

At no point does an EGL client ever come into contact with the
wl_buffers produced by EGL. They are utterly opaque, and hidden inside
the EGL implementation. This means that, in order to get
colour-correct rendering through EGL, you either have to have it
attached to the surface (which the client can see and control), or you
have to grow EGL API for the entire breadth of colour management. This
is a lot of the reason why we have things like opaque region attached
to the surface, with the commit latched, rather than buffers.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Daniel Stone]

Hi Kai-Uwe,

On 20 December 2016 at 19:38, Kai-Uwe  wrote:
> Am 20.12.2016 um 17:44 schrieb Daniel Stone:
>> On 20 December 2016 at 14:46, Kai-Uwe  wrote:
>>> PDF, SVG2 require handling of different blending color spaces. So the
>>> interface appears to be useful.
>>
>> I'm not quite sure how this response relates to my question, unless
>> you are discussing a Weston compositor which targets PDF and/or SVG.
>
> I am talking about source documents, which might be PDF or SVG. And in
> these the blending space can change. So a Wayland client might draw each
> PDF/SVG element to a Wayland surface and would come in need to switch
> the blending space for rendering the document. Doing it all in Wayland
> makes the server much more powerful.
>
>> In Niels's strawman proposal, there is only _one_ blending colourspace
>> for _every_ blending operation performed in the _entire_ compositor.
>
> Ah ok. So take my comment as the hint for a possible use case for
> multiple blending spaces ;-)

Yes, if you look at the request as written, it's about _retrieving_
the compositor's single blending space, not setting one. I don't think
that's adequate, and as you say, it may be a good solution for clients
to provide profiles enabling the compositor to transform for both
final display and for blending.

>>> My concern is that input == output color space => NULL conversion is
>>> flacky. A explicite opt out of color correction would be much appreciated.
>>
>> What does an explicit opt-out actually mean? Does it mean that the
>> compositor assumes sRGB? Linear? That a NULL transform is applied when
>> scanning out directly from that surface? When going through a GPU
>> composition pipeline, is the inverse transform from the output
>> colourspace to blending colourspace, or does 'opt out' mean that
>> blending is performed directly in the target colourspace?
>
> From the main use case of drawing channel values unaltered to the
> output, I would say the later. That is as well the current behavior,
> without any color correction and changed happening only while blending.
> There is no gamma conversion, no color space conversion. The conflict
> might be that blending ops work currently best for gamma encoded values
> and might be changed to work for linear gamma 1.0 . The transition from
> a gamma image to convert to linear gamma for blending should not be
> noticeable, perhaps measurable. Further there is the need to copy the
> surface for blending to linear gamma. For this case, do not touch the
> values, it appears appropriate.

But that means that blending (in non-linear space) will look pretty awful. :\

>> I'm also curious as to what you mean by it being flaky.
>
> Flaky - the client cant not know what happens to its values as
> output==output => NULL is a implicit rule. It might be optimised out or
> whatever at will of the server and the client is a real looser as it is
> only a weak suggestion. A Do Not Touch (or opt out) marker is pretty
> clear to everyone and the client can assume to remain in control like
> with a contract.

It can assume, but it really shouldn't. The client can make its
guesses and assumptions about what's going on, but the compositor is
free to do much more than what it was under X11, and what it can
express to the client. Given the diversity of what compositors do:
blending, surface transformation/displacement and cloning across
multiple outputs, cloned outputs, screenshots/streaming, etc, this
will always be a guess. And this makes me wince every time I see 'opt
out'; the intention when writing it is 'the client knows what's going
on so can get it right', but I read 'the client doesn't know what the
compositor's doing and the compositor doesn't know what the client
means, which guarantees that it's going to get it wrong at some
point'.

I'm still missing some subtlety in your point, but perhaps there's
language you could suggest for some part of Niels's strawman spec,
which would strengthen these guarantees to a point a client could be
assured the right thing was happening. I don't see any future for an
'opt out' flag ever though.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

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
> > optimize for this super-uncommon case.  
> 
> I disagree - leave it to be an afterthought, and it will be
> done badly or left out completely, crippling the practicality
> of color management for the system.

Designing that is trivial:

GLOBAL cms_calibrator
- request: create_calibration_surface(wl_surface, new cms_calibration_surface)
# Assigns wl_surface role.

INTERFACE cms_calibration_surface
# Surfaces with this role will only be shown on the set output,
# with direct color path bypassing all color-management, and
# and the hardware has been reset to neutral/identity settings.
# (or whatever requirements are appropriate, you can decide
# what to write here)
- request: set_output(wl_output)
# Which output this surface targets. The compositor replies
with a
# configure event.
- event: configure(width, height)
# delivers the width and height the application needs to use


How it operates from a client perspective:

1. create a wl_surface
2. bind to cms_calibrator
3. send create_calibration_surface
4. send set_output
5. wait for configure
6. draw the calibration surface in the correct size
7. use Presentation feedback interface to ensure the calibration
   surface is show with the latest content
8. do what you want to do with the colorimeter
9. go to 6 to update the image if necessary
10. destroy cms_calibration_surface and wl_surface; the display
automatically returns to normal


To be user friendly, one probably wants to add an event in case the
user denies the request to show the calibration window as it will have
temporary global effects.

Whether the global needs to be privileged or not, and how privileges
are implemented are an orthogonal matter.


Thanks,
pq


pgp2lSuoZ7cv1.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] Color management protocol

[Pekka Paalanen]

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 afford the development effort ?
> (My own color software has been developed over about 20 years).

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 cannot do so. Why?

> There may be source code available to them under licensing
> conditions that allow them to include it in the compositor,
> but do they want to maintain such a port, and is
> it really a good idea to want to include a full blown
> application of considerable size and complexity, within a
> compositor ? (All that color measurement instrument support!)
> Do users want to be locked into a single
> choice of such a built in application ?
> Is it really expected that the compositor has to
> be updated every time there is a bug or new feature in
> the color management code ?
> Maybe they can include a very stripped down
> version of color management applications
> (as Richard has done in Gnome), but that isn't
> going to satisfy color critical users, and
> seems rather contrary to open source philosophy to
> deny users any way of using something else instead.

Are you implying that the CMS you worked on so hard is impossible to use
from a compositor?

No, I do not mean forking the CMS and shoving the code into a compositor
project.

I mean libraries, services, daemons... does your CMS really not have
any such interfaces?

Now that I think of the history, that's likely true due to X11 and
having a single display server implementation ever that even declined to
integrate with CMS.

> Answer - this seems rather unlikely to be a viable path. It's
> not reasonable - color management applications need
> to be independent applications to be practical, and the
> alternative is fairly simply by comparison :-
> provide the API's needed as standard.

Yes! The CMS needs to provide the API that all compositors could use.

Even in the X11 case, simply shoving something into the CLUT directly
did not work. You can have multiple apps messing with the CLUT (e.g.
redshift, right?) without knowing about each other, leaving the user
clueless of the state of the display. I believe modern display hardware
start with a CLUT-matrix-CLUT pipeline and continuously invents more
ways, so "just set the CLUT" is already an outdated approach, not to
mention that each hardware plane might have its own pipeline setup
(Wayland compositors will use hardware planes at opportunity at their
own discretion, and completely transparently to any clients). The CMS
could control the X11 compositor or window manager only if that
compositor or WM actually listened, which requires explicit support
coded in it.

The situation on Wayland not that different. You still need the
{ display server, window manager, compositor } process to work *with*
CMS to produce best results, and it even offers significant benefits
like choosing a more appropriate blending space or automatic and
GPU-accelerated color mapping, plus preventing fighting over control.
You don't have X11 for communicating between the compositor and CMS,
now you need a library interface. It's not something one wants Wayland
for, because Wayland is IPC, implying the two parts are in separate
processes.

If you design the compositor-facing interface as a library ABI in your
CMS, then you have the power to design it right and tell compositor
developers how to do the right thing by using it.

Here, now, you have the opportunity to design how to integrate CMS with
Wayland compositors, in a mutually cooperative way between the two
software suites. You could aim for much much higher than just "I need
to control the hardware to begin with".

This, added with the power of adding implementation-specific Wayland
extensions at runtime(*) from within the CMS, should let you implement
much much more than you ever could if you stuck with the X11
architecture "I need to control hardware directly from a CMS tool that
is a Wayland client and the compositor has to stay out of the way".


Thanks,
pq

(*) Doing this requires a library ABI that the compositor will call into.


pgpHGMuIXclIx.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Hans de Goede]

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 a/test/gestures.c b/test/gestures.c
index 0b132c3..3a66afb 100644
--- a/test/gestures.c
+++ b/test/gestures.c
@@ -496,6 +496,58 @@ START_TEST(gestures_swipe_4fg_btntool)
 }
 END_TEST

+START_TEST(gestures_pinch_vertical_positon)
+{
+   struct litest_device *dev = litest_current_device();
+   struct libinput *li = dev->libinput;
+   struct libinput_event *event;
+   int nfingers = _i; /* ranged test */
+
+   if (libevdev_get_num_slots(dev->evdev) < nfingers ||
+   !libinput_device_has_capability(dev->libinput_device,
+   LIBINPUT_DEVICE_CAP_GESTURE))
+   return;
+
+   litest_disable_tap(dev->libinput_device);
+   litest_drain_events(li);
+
+   litest_touch_down(dev, 0, 40, 30);
+   litest_touch_down(dev, 1, 50, 70);
+   litest_touch_down(dev, 2, 60, 70);
+   if (nfingers > 3)
+   litest_touch_down(dev, 3, 70, 70);
+   libinput_dispatch(li);
+   litest_timeout_gesture_scroll();
+   libinput_dispatch(li);
+
+   /* This is actually a small swipe gesture, all three fingers moving
+* down but we're checking for the code that triggers based on
+* finger position. */
+   litest_touch_move_to(dev, 0, 40, 30, 40, 30.5, 1, 0);
+   litest_touch_move_to(dev, 1, 50, 70, 50, 70.5, 1, 0);
+   litest_touch_move_to(dev, 2, 60, 70, 60, 70.5, 1, 0);
+   if (nfingers > 3)
+   litest_touch_move_to(dev, 3, 70, 70, 70, 70.5, 1, 0);
+   libinput_dispatch(li);
+
+   event = libinput_get_event(li);
+   litest_is_gesture_event(event,
+   LIBINPUT_EVENT_GESTURE_PINCH_BEGIN,
+   nfingers);
+   libinput_event_destroy(event);
+
+   litest_touch_move_to(dev, 0, 40, 30.5, 40, 36, 5, 0);
+   litest_touch_move_to(dev, 1, 50, 70.5, 50, 76, 5, 0);
+   litest_touch_move_to(dev, 2, 60, 70.5, 60, 76, 5, 0);
+   if (nfingers > 3)
+   litest_touch_move_to(dev, 3, 70, 70.5, 60, 76, 5, 0);
+   libinput_dispatch(li);
+
+   litest_assert_only_typed_events(li,
+   LIBINPUT_EVENT_GESTURE_PINCH_UPDATE);
+}
+END_TEST
+
 START_TEST(gestures_pinch)
 {
struct litest_device *dev = litest_current_device();
@@ -1219,6 +1271,7 @@ litest_setup_tests_gestures(void)
 {
/* N, NE, ... */
struct range cardinals = { 0, 8 };
+   struct range fingers = { 3, 5 };

litest_add("gestures:cap", gestures_cap, LITEST_TOUCHPAD, 
LITEST_SINGLE_TOUCH);
litest_add("gestures:cap", gestures_nocap, LITEST_ANY, LITEST_TOUCHPAD);
@@ -1230,9 +1283,11 @@ litest_setup_tests_gestures(void)
litest_add_ranged("gestures:pinch", gestures_pinch, LITEST_TOUCHPAD, 
LITEST_SINGLE_TOUCH, &cardinals);
litest_add_ranged("gestures:pinch", gestures_pinch_3fg, LITEST_TOUCHPAD, 
LITEST_SINGLE_TOUCH, &cardinals);
litest_add_ranged("gestures:pinch", gestures_pinch_3fg_btntool, 
LITEST_TOUCHPAD, LITEST_SINGLE_TOUCH, &cardinals);
+   litest_add_ranged("gestures:pinch", gestures_pinch_3fg, LITEST_TOUCHPAD, 
LITEST_SINGLE_TOUCH, &cardinals);


Your doing the:

litest_add_ranged("gestures:pinch", gestures_pinch_3fg, LITEST_TOUCHPAD, 
LITEST_SINGLE_TOUCH, &cardinals);

Test twice now, otherwise LGTM, so with this fixed:

Reviewed-by: Hans de Goede 

Regards,

Hans




litest_add_ranged("gestures:pinch", gestures_pinch_4fg, LITEST_TOUCHPAD, 
LITEST_SINGLE_TOUCH, &cardinals);
litest_add_ranged("gestures:pinch", gestures_pinch_4fg_btntool, 
LITEST_TOUCHPAD, LITEST_SINGLE_TOUCH, &cardinals);
litest_add_ranged("gestures:pinch", gestures_spread, LITEST_TOUCHPAD, 
LITEST_SINGLE_TOUCH, &cardinals);
+   litest_add_ranged("gestures:pinch", gestures_pinch_vertical_positon, 
LITEST_TOUCHPAD, LITEST_SINGLE_TOUCH, &fingers);

litest_add("gestures:swipe", gestures_3fg_buttonarea_scroll, 
LITEST_CLICKPAD, LITEST_SINGLE_TOUCH);
litest_add("gestures:swipe", gestures_3fg_buttonarea_scroll_btntool, 
LITEST_CLICKPAD, LITEST_SINGLE_TOUCH);
diff --git a/test/litest.c b/test/litest.c
index 40029d6..0574c0a 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -2964,6 +2964,12 @@ litest_timeout_gesture(void)
 }

 void
+litest_timeout_gesture_scroll(void)
+{
+   msleep(180);
+}
+
+void
 litest_timeout_trackpoint(void)
 {
msleep(320);
diff --git a/test/litest.h b/test/litest.h
index 017a3d2..a707509 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -654,6 +654,9 @@ void
 litest_timeout_gesture(void);

 void
+litest_timeout_gesture_scroll(void);
+
+void
 litest_timeout_trackpoint(void);

 void


_

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

[Hans de Goede]

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 better reaction to small movements.

This also fixes previously unreachable code: the test for the finger position
required at least 3 fingers down but was within a condition that ensured only
2 fingers were down. This was introduced in 11917061fe320c.

Signed-off-by: Peter Hutterer 
---
Changes to v1:
- better commit message/comments
- dropped the finger_count > 2 check that was a dead condition before anyway


LGTM now:

Reviewed-by: Hans de Goede 

Regards,

Hans




 src/evdev-mt-touchpad-gestures.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/evdev-mt-touchpad-gestures.c b/src/evdev-mt-touchpad-gestures.c
index 08c179d..de3ec4f 100644
--- a/src/evdev-mt-touchpad-gestures.c
+++ b/src/evdev-mt-touchpad-gestures.c
@@ -331,21 +331,23 @@ tp_gesture_handle_state_unknown(struct tp_dispatch *tp, 
uint64_t time)
int yres = tp->device->abs.absinfo_y->resolution;
int vert_distance;

-   /* for two-finger gestures, if the fingers stay unmoving for a
-* while, assume (slow) scroll */
-   if (tp->gesture.finger_count == 2) {
-   if (time > (tp->gesture.initial_time + 
DEFAULT_GESTURE_2FG_SCROLL_TIMEOUT)) {
+   if (time > (tp->gesture.initial_time + 
DEFAULT_GESTURE_2FG_SCROLL_TIMEOUT)) {
+   /* for two-finger gestures, if the fingers stay unmoving for a
+* while, assume (slow) scroll */
+   if (tp->gesture.finger_count == 2) {
tp_gesture_set_scroll_buildup(tp);
return GESTURE_STATE_SCROLL;
}

-   /* Else check if one finger is > 20mm below the others */
+   /* for 3+ finger gestures, check if one finger is > 20mm
+  below the others */
vert_distance = abs(first->point.y - second->point.y);
if (vert_distance > 20 * yres &&
-   tp->gesture.finger_count > 2 &&
tp->gesture.enabled) {
tp_gesture_init_pinch(tp);
return GESTURE_STATE_PINCH;
+   } else {
+   return GESTURE_STATE_SWIPE;
}
}



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel