Re: [PATCH] xwm: Handle changing override redirect flag

[Scott Moreau]

Hi,

I think un-reparenting would involve reparenting to the whatever the parent
was before reparenting in the first place. I haven't given this too much
thought and I don't know if this case ever happens in practice but figured
I'd comment about it since Pekka mentioned possibly reviewing it soon.

Thanks,
Scott

On Thu, Mar 29, 2018 at 5:17 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:

> On Sun, 18 Mar 2018 12:22:15 -0600
> Scott Moreau <ore...@gmail.com> wrote:
>
> > Xwayland windows might be created with a different override redirect
> > flag than is given on map or configure notify. This causes confusion
> > about whether a window should be treated as override redirect or not.
> > Here we handle the changing override redirect flag in relevant notify
> > handlers so windows are treated appropriately. In particular, this
> > fixes positioning menus in clients like VLC, though it is not a
> > complete fix. If the window is moved, the menus are still positioned
> > as if the window wasn't moved.
> > ---
> >  xwayland/window-manager.c | 43 ++
> +
> >  1 file changed, 35 insertions(+), 8 deletions(-)
>
> Hi,
>
> this patch looks big enough that I'd consider it more a new feature
> than just a bug fix, so I'd like to postpone this after the 4.0.0
> release.
>
> I've marked this as deferred in Patchwork.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v4 2/2] xwm: Scale icon if size is not the target size

[Scott Moreau]

On Fri, Mar 23, 2018 at 2:15 PM, Derek Foreman <der...@osg.samsung.com>
wrote:

> On 2018-03-23 02:47 PM, Scott Moreau wrote:
> > This scales the icon cairo surface for the titlebar if it isn't the
> > target size.
> >
> > shared/cairo-util: Add surface resizing function to be used for this
> > case and other potential cases.
> > ---
> >
> > Changed in v2:
> >
> > - Rebase to [PATCH 1/1 v3] xwm: Choose icon closest to target size
> >
> > Changed in v3:
> >
> > - No changes
> >
> > Changed in v4:
> >
> > - Fixed whitespace problems
> > - Renamed cairo_resize_surface() to resize_cairo_surface()
> >
> >  shared/cairo-util.c   | 63 ++
> +
> >  shared/cairo-util.h   |  4 +++
> >  xwayland/window-manager.c |  4 +++
> >  3 files changed, 71 insertions(+)
> >
> > diff --git a/shared/cairo-util.c b/shared/cairo-util.c
> > index d71e0ed..442182b 100644
> > --- a/shared/cairo-util.c
> > +++ b/shared/cairo-util.c
> > @@ -365,6 +365,69 @@ load_cairo_surface(const char *filename)
> >  width, height, stride);
> >  }
> >
> > +static cairo_surface_t *
> > +scale_surface(cairo_surface_t *source, cairo_filter_t filter,
> > + double width, double height)
>
> Still have some whitespace issues here.
>

Hm, I have 5 * 8 wide tabs here and it seems to appear correct in my editor.
I'll wait for other potential comments/reviews before submitting another
patch.


>
> Otherwise, this is
> Reviewed-by: Derek Foreman <der...@osg.samsung.com>
>
> Does this + your leak fix close all known bugs in the icon code?
>

Well now that you mention it, I did notice one other thing.
weston_wm_handle_icon() can be called multiple times and sets
window->icon_surface from a newly created surface without destroying the
old one first, in the case where there isn't a frame yet. I haven't
submitted a patch for this at all.


>
> Thanks,
> Derek
>

Thanks,
Scott


>
> > +{
> > + cairo_surface_t *dest;
> > + cairo_t *cr;
> > + int old_width, old_height;
> > +
> > + old_width = cairo_image_surface_get_width(source);
> > + old_height = cairo_image_surface_get_height(source);
> > +
> > + dest = cairo_surface_create_similar(source,
> > + CAIRO_CONTENT_COLOR_ALPHA,
> > + width, height);
> > + cr = cairo_create (dest);
> > +
> > + cairo_scale (cr, width / old_width, height / old_height);
> > + cairo_set_source_surface (cr, source, 0, 0);
> > +
> > + cairo_pattern_set_extend (cairo_get_source(cr),
> > + CAIRO_EXTEND_REFLECT);
> > +
> > + cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
> > +
> > + cairo_paint (cr);
> > +
> > + cairo_destroy (cr);
> > +
> > + cairo_surface_destroy(source);
> > +
> > + return dest;
> > +}
> > +
> > +cairo_surface_t *
> > +resize_cairo_surface(cairo_surface_t *source, cairo_filter_t filter,
> > + int width, int height)
> > +{
> > + if (!filter)
> > + filter = CAIRO_FILTER_BEST;
> > +
> > + while((cairo_image_surface_get_width(source) / 2.0f) > width)
> > + source = scale_surface(source, filter,
> > + cairo_image_surface_get_width(source) / 2.0f,
> > + cairo_image_surface_get_height(source));
> > +
> > + while((cairo_image_surface_get_height(source) / 2.0f) > height)
> > + source = scale_surface(source, filter,
> > + cairo_image_surface_get_width(source),
> > + cairo_image_surface_get_height(source) / 2.0f);
> > +
> > + while((cairo_image_surface_get_width(source) * 2.0f) < width)
> > + source = scale_surface(source, filter,
> > + cairo_image_surface_get_width(source) * 2.0f,
> > + cairo_image_surface_get_height(source));
> > +
> > + while((cairo_image_surface_get_height(source) * 2.0f) < height)
> > + source = scale_surface(source, filter,
> > + cairo_image_surface_get_width(source),
> > + cairo_image_surface_get_height(source) * 2.0f);
> > +
> > + return scale_surface(source, filter, width, height);
> > +}
>

[PATCH v4 1/2] xwm: Choose icon closest to target size

[Scott Moreau]

Xwayland clients can offer multiple icon sizes in no particular order.
Previously xwm was selecting the first one unconditionally. This patch
selects the icon that matches the size closest to the target size. The
target size is hard coded to 16 since there is only one theme and the
data used to create the theme is hard coded.
---

Changed in v2:

- Fix typo setting width to height

Changed in v3:

- Move checks for malformed input into data handling function

Changed in v4:

- #define XWM_ICON_SIZE in this patch and do not #undef it
- Start with first icon found before choosing icon\
- Check for NULL data in get_icon_size_from_data()

 xwayland/window-manager.c | 84 +++
 1 file changed, 77 insertions(+), 7 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..5fb41bf 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -127,6 +127,8 @@ struct motif_wm_hints {
 #define _NET_WM_MOVERESIZE_MOVE_KEYBOARD10   /* move via keyboard */
 #define _NET_WM_MOVERESIZE_CANCEL   11   /* cancel operation */
 
+#define XWM_ICON_SIZE 16 /* width and height of frame icon */
+
 struct weston_output_weak_ref {
struct weston_output *output;
struct wl_listener destroy_listener;
@@ -1352,6 +1354,77 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
 }
 
+static uint32_t *
+get_icon_size_from_data(int target_width, int target_height,
+   uint32_t *width, uint32_t *height,
+   uint32_t length, uint32_t *data)
+{
+   uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
+   int num_sizes = 0, *sizes = NULL, a1, a2, a3;
+
+   if (!data)
+   return NULL;
+
+   *width = *height = 0;
+
+   while (d - data < length / 4) {
+   w = *d++;
+   h = *d++;
+
+   /* Some checks against malformed input. */
+   if (w == 0 || h == 0 || length < 2 + w * h)
+   goto out;
+
+   sizes = realloc(sizes, 2 * (num_sizes + 1) * sizeof(uint32_t));
+   if (!sizes) {
+   free(img);
+   return NULL;
+   }
+
+   img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
+   if (!img) {
+   free(sizes);
+   return NULL;
+   }
+
+   sizes[(num_sizes * 2) + 0] = w;
+   sizes[(num_sizes * 2) + 1] = h;
+   img[num_sizes] = d;
+
+   num_sizes++;
+   d += w * h;
+   }
+
+   /* Begin with first icon in list */
+   if (num_sizes) {
+   *width = sizes[0];
+   *height = sizes[1];
+   ret = img[0];
+   }
+
+   /* Choose closest match by comparing icon dimension areas */
+   a1 = target_width * target_height;
+
+   while (num_sizes--) {
+   w = sizes[(num_sizes * 2) + 0];
+   h = sizes[(num_sizes * 2) + 1];
+
+   a2 = w * h;
+   a3 = *width * *height;
+
+   if (abs(a2 - a1) < abs(a3 - a1)) {
+   *width = w;
+   *height = h;
+   ret = img[num_sizes];
+   }
+   }
+out:
+   free(sizes);
+   free(img);
+
+   return ret;
+}
+
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1361,9 +1434,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
uint32_t *data, width, height;
cairo_surface_t *new_surface;
 
-   /* TODO: icons don’t have any specified order, we should pick the
-* closest one to the target dimension instead of the first one. */
-
cookie = xcb_get_property(wm->conn, 0, window->id,
  wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
  UINT32_MAX);
@@ -1375,11 +1445,11 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
 
data = xcb_get_property_value(reply);
-   width = *data++;
-   height = *data++;
 
-   /* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height)
+   data = get_icon_size_from_data(XWM_ICON_SIZE, XWM_ICON_SIZE,
+   , , length, data);
+
+   if (!data)
return;
 
new_surface =
-- 
2.7.4

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

[PATCH v4 2/2] xwm: Scale icon if size is not the target size

[Scott Moreau]

This scales the icon cairo surface for the titlebar if it isn't the
target size.

shared/cairo-util: Add surface resizing function to be used for this
case and other potential cases.
---

Changed in v2:

- Rebase to [PATCH 1/1 v3] xwm: Choose icon closest to target size

Changed in v3:

- No changes

Changed in v4:

- Fixed whitespace problems
- Renamed cairo_resize_surface() to resize_cairo_surface()

 shared/cairo-util.c   | 63 +++
 shared/cairo-util.h   |  4 +++
 xwayland/window-manager.c |  4 +++
 3 files changed, 71 insertions(+)

diff --git a/shared/cairo-util.c b/shared/cairo-util.c
index d71e0ed..442182b 100644
--- a/shared/cairo-util.c
+++ b/shared/cairo-util.c
@@ -365,6 +365,69 @@ load_cairo_surface(const char *filename)
   width, height, stride);
 }
 
+static cairo_surface_t *
+scale_surface(cairo_surface_t *source, cairo_filter_t filter,
+   double width, double height)
+{
+   cairo_surface_t *dest;
+   cairo_t *cr;
+   int old_width, old_height;
+
+   old_width = cairo_image_surface_get_width(source);
+   old_height = cairo_image_surface_get_height(source);
+
+   dest = cairo_surface_create_similar(source,
+   CAIRO_CONTENT_COLOR_ALPHA,
+   width, height);
+   cr = cairo_create (dest);
+
+   cairo_scale (cr, width / old_width, height / old_height);
+   cairo_set_source_surface (cr, source, 0, 0);
+
+   cairo_pattern_set_extend (cairo_get_source(cr),
+   CAIRO_EXTEND_REFLECT);
+
+   cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
+
+   cairo_paint (cr);
+
+   cairo_destroy (cr);
+
+   cairo_surface_destroy(source);
+
+   return dest;
+}
+
+cairo_surface_t *
+resize_cairo_surface(cairo_surface_t *source, cairo_filter_t filter,
+   int width, int height)
+{
+   if (!filter)
+   filter = CAIRO_FILTER_BEST;
+
+   while((cairo_image_surface_get_width(source) / 2.0f) > width)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source) / 2.0f,
+   cairo_image_surface_get_height(source));
+
+   while((cairo_image_surface_get_height(source) / 2.0f) > height)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source),
+   cairo_image_surface_get_height(source) / 2.0f);
+
+   while((cairo_image_surface_get_width(source) * 2.0f) < width)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source) * 2.0f,
+   cairo_image_surface_get_height(source));
+
+   while((cairo_image_surface_get_height(source) * 2.0f) < height)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source),
+   cairo_image_surface_get_height(source) * 2.0f);
+
+   return scale_surface(source, filter, width, height);
+}
+
 void
 theme_set_background_source(struct theme *t, cairo_t *cr, uint32_t flags)
 {
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 6fd11f6..1c58f3b 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -49,6 +49,10 @@ rounded_rect(cairo_t *cr, int x0, int y0, int x1, int y1, 
int radius);
 cairo_surface_t *
 load_cairo_surface(const char *filename);
 
+cairo_surface_t *
+resize_cairo_surface(cairo_surface_t *source, cairo_filter_t filter,
+   int width, int height);
+
 struct theme {
cairo_surface_t *active_frame;
cairo_surface_t *inactive_frame;
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 5fb41bf..50c5855 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1463,6 +1463,10 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
}
 
+   if (width != XWM_ICON_SIZE || height != XWM_ICON_SIZE)
+   new_surface = resize_cairo_surface(new_surface, 0,
+   XWM_ICON_SIZE, XWM_ICON_SIZE);
+
if (window->frame)
frame_set_icon(window->frame, new_surface);
else /* We don’t have a frame yet */
-- 
2.7.4

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

[PATCH v3] xwm: Fix memory leak

[Scott Moreau]

A memory leak introduced by 6b58ea8c led to me finding a bigger leak,
which is xwm was calling frame_create() without calling frame_destroy().
This meant that the associated icon_surface was not being destroyed,
leaving the destroy handler for it broken. Here we fix this by calling
frame_destroy() when the window is destroyed and free the reply in
the icon_surface destroy handler.
---

Changed in v2:

- Setup destroy handler to free reply when surface is destroyed
- Call frame_destroy() for window->frame

Changed in v3:

- Fix whitespace
- Drop unnecessary cast in handle_icon_surface_destroy()

 xwayland/window-manager.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..77df8cf 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1353,6 +1353,12 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
 }
 
 static void
+handle_icon_surface_destroy(void *data)
+{
+   free(data);
+}
+
+static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
xcb_get_property_reply_t *reply;
@@ -1371,16 +1377,20 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
length = xcb_get_property_value_length(reply);
 
/* This is in 32-bit words, not in bytes. */
-   if (length < 2)
+   if (length < 2) {
+   free(reply);
return;
+   }
 
data = xcb_get_property_value(reply);
width = *data++;
height = *data++;
 
/* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height)
+   if (width == 0 || height == 0 || length < 2 + width * height) {
+   free(reply);
return;
+   }
 
new_surface =
cairo_image_surface_create_for_data((unsigned char *)data,
@@ -1390,9 +1400,13 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
/* Bail out in case anything wrong happened during surface creation. */
if (cairo_surface_status(new_surface) != CAIRO_STATUS_SUCCESS) {
cairo_surface_destroy(new_surface);
+   free(reply);
return;
}
 
+   cairo_surface_set_user_data(new_surface, NULL, reply,
+   _icon_surface_destroy);
+
if (window->frame)
frame_set_icon(window->frame, new_surface);
else /* We don’t have a frame yet */
@@ -1502,6 +1516,9 @@ weston_wm_window_destroy(struct weston_wm_window *window)
window->frame_id = XCB_WINDOW_NONE;
}
 
+   if (window->frame)
+   frame_destroy(window->frame);
+
if (window->surface_id)
wl_list_remove(>link);
 
-- 
2.7.4

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

Re: [PATCH v2] xwm: Fix memory leak

[Scott Moreau]

Hi Derek,

On Fri, Mar 23, 2018 at 12:22 PM, Derek Foreman <der...@osg.samsung.com>
wrote:

> On 2018-03-20 10:26 AM, Scott Moreau wrote:
> > A memory leak introduced by 6b58ea8c led to me finding a bigger
> > leak, which is xwm was calling frame_create() without calling
> > frame_destroy(). This meant that the associated icon_surface
> > was not being destroyed, leaving the destroy handler for it
> > broken. Here we fix this by calling frame_destroy() when the
> > window is destroyed and free the reply in the icon_surface
> > destroy handler.
>
> Ran valgrind memcheck to try to confirm this resolved a leak, found a
> lot more leaks. ugh. :)
>

Yes, I seem to find more and more too.


>
> > ---
> >  xwayland/window-manager.c | 23 +--
> >  1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> > index c307e19..9e61a67 100644
> > --- a/xwayland/window-manager.c
> > +++ b/xwayland/window-manager.c
> > @@ -1353,6 +1353,14 @@ weston_wm_window_schedule_repaint(struct
> weston_wm_window *window)
> >  }
> >
> >  static void
> > +handle_icon_surface_destroy(void *data)
> > +{
> > + xcb_get_property_reply_t *reply = (xcb_get_property_reply_t *)data;
> > +
> > + free(reply);
>
> free takes a void * anyway, so just free(data); should be fine.
>

Ok, great.


>
> > +}
> > +
> > +static void
> >  weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window
> *window)
> >  {
> >   xcb_get_property_reply_t *reply;
> > @@ -1371,16 +1379,20 @@ weston_wm_handle_icon(struct weston_wm *wm,
> struct weston_wm_window *window)
> >   length = xcb_get_property_value_length(reply);
> >
> >   /* This is in 32-bit words, not in bytes. */
> > - if (length < 2)
> > + if (length < 2) {
> > + free(reply);
> >   return;
> > + }
> >
> >   data = xcb_get_property_value(reply);
> >   width = *data++;
> >   height = *data++;
> >
> >   /* Some checks against malformed input. */
> > - if (width == 0 || height == 0 || length < 2 + width * height)
> > + if (width == 0 || height == 0 || length < 2 + width * height) {
> > + free(reply);
> >   return;
> > + }
> >
> >   new_surface =
> >   cairo_image_surface_create_for_data((unsigned char *)data,
> > @@ -1390,9 +1402,13 @@ weston_wm_handle_icon(struct weston_wm *wm,
> struct weston_wm_window *window)
> >   /* Bail out in case anything wrong happened during surface
> creation. */
> >   if (cairo_surface_status(new_surface) != CAIRO_STATUS_SUCCESS) {
> >   cairo_surface_destroy(new_surface);
> > + free(reply);
> >   return;
> >   }
> >
> > + cairo_surface_set_user_data(new_surface, NULL, reply,
>
> (wrong tab size again)
>

My editor was set to 4 wide tabs so this should be fixed now.


>
> Those nits resolved and this is
> Reviewed-by: Derek Foreman <der...@osg.samsung.com>
>

Great, thanks for the review.


>
> Thanks,
> Derek
>

Thanks,
Scott


>
> > +
>  _icon_surface_destroy);
> > +
> >   if (window->frame)
> >   frame_set_icon(window->frame, new_surface);
> >   else /* We don’t have a frame yet */
> > @@ -1502,6 +1518,9 @@ weston_wm_window_destroy(struct weston_wm_window
> *window)
> >   window->frame_id = XCB_WINDOW_NONE;
> >   }
> >
> > + if (window->frame)
> > + frame_destroy(window->frame);
> > +
> >   if (window->surface_id)
> >   wl_list_remove(>link);
> >
> >
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3] xwm: Choose icon closest to target size

[Scott Moreau]

Hi Derek,

On Fri, Mar 23, 2018 at 11:34 AM, Derek Foreman <der...@osg.samsung.com>
wrote:

> Thanks for this.  This particular feature is getting on my nerves
> because it seemed like a simple thing and has result in a lot of breakage.
>
> Would like to see it repaired or removed by late next week.
>

Thanks for reviewing this.


>
> This seems to be a good step towards repair, comments inline below.
>
> On 2018-03-22 12:47 AM, Scott Moreau wrote:
> > Xwayland clients can offer multiple icon sizes in no particular order.
> > Previously xwm was selecting the first one unconditionally. This patch
> > selects the icon that matches the size closest to the target size. The
> > target size is hard coded to 16 since there is only one theme and the
> > data used to create the theme is hard coded.
> > ---
> >
> > Changed in v2:
> >
> > - Fix typo setting width to height
> >
> > Changed in v3:
> >
> > - Move checks for malformed input into data handling function
> >
> >  xwayland/window-manager.c | 74 ++
> -
> >  1 file changed, 67 insertions(+), 7 deletions(-)
> >
> > diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> > index c307e19..30c4b1c 100644
> > --- a/xwayland/window-manager.c
> > +++ b/xwayland/window-manager.c
> > @@ -1352,6 +1352,70 @@ weston_wm_window_schedule_repaint(struct
> weston_wm_window *window)
> >  weston_wm_window_do_repaint,
> window);
> >  }
> >
> > +static uint32_t *
> > +get_icon_size_from_data(int target_width, int target_height,
> > + uint32_t *width, uint32_t
> *height,
> > + uint32_t length, uint32_t
> *data)
> > +{
> > + uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
> > + int num_sizes = 0, *sizes = NULL, a1, a2, a3;
> > +
> > + *width = *height = 0;
> > +
> > + while (d - data < length / 4) {
> > + w = *d++;
> > + h = *d++;
> > +
> > + /* Some checks against malformed input. */
> > + if (w == 0 || h == 0 || length < 2 + w * h) {
> > + free(sizes);
> > + free(img);
> > + return NULL;
> > + }
>
> I think since ret is init to NULL, and free(NULL) is a nop, all these
> checks could just goto out;  and an out label could be added immediately
> before free(sizes) at the end of function.
>
> Should shrink it a bit...
>

I had the same thought but shied away from using goto. I'll do it in the
next patch.


>
> > +
> > + sizes = realloc(sizes, 2 * (num_sizes + 1) *
> sizeof(uint32_t));
> > + if (!sizes) {
> > + free(img);
> > + return NULL;
> > + }
> > +
> > + img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
> > + if (!img) {
> > + free(sizes);
> > + return NULL;
> > + }
> > +
> > + sizes[(num_sizes * 2) + 0] = w;
> > + sizes[(num_sizes * 2) + 1] = h;
> > + img[num_sizes] = d;
> > +
> > + num_sizes++;
> > + d += w * h;
> > + }
> > +
> > + /* Choose closest match by comparing icon dimension areas */
> > + a1 = target_width * target_height;
> > +
> > + while (num_sizes--) {
> > + w = sizes[(num_sizes * 2) + 0];
> > + h = sizes[(num_sizes * 2) + 1];
> > +
> > + a2 = w * h;
> > + a3 = *width * *height;
> > +
> > + if (a2 != a3 && abs(a2 - a1) < abs(a3 - a1)) {
>
> When running terminology, which only provides a single 128x128 icon, I
> run through this and exit with ret == NULL, and no icon is displayed.
>

Ah yes, I can reproduce this.


>
> Without thinking too hard, I guess the initial 0x0 is closer to 16x16
> than 128x128 is. :)


Yes, this is the problem.


>   I guess maybe this should accept any icon if no
> icon has been picked yet (or just before this loop we could init to the
> first icon...)
>

That would probably be a good bet.


>
> > + *width = w;
> > + *height = h;
> > + ret = img[num_sizes];
> > + }
> > + }
> > +
> > + free(sizes);
> > + 

Re: [PATCH 2/2 v2] xwm: Scale icon if size is not the target size

[Scott Moreau]

Hi Derek,

On Fri, Mar 23, 2018 at 11:59 AM, Derek Foreman <der...@osg.samsung.com>
wrote:

> On 2018-03-22 01:04 AM, Scott Moreau wrote:
> > This scales the icon cairo surface for the titlebar if it isn't the
> > target size.
> >
> > shared/cairo-util: Add surface resizing function to be used for this
> > case and other potential cases.
> > ---
> >
> > Changed in v2:
> >
> > - Rebase to [PATCH 1/1 v3] xwm: Choose icon closest to target size
> >
> >  shared/cairo-util.c   | 61 ++
> +
> >  shared/cairo-util.h   |  4 
> >  xwayland/window-manager.c |  9 ++-
> >  3 files changed, 73 insertions(+), 1 deletion(-)
> >
> > diff --git a/shared/cairo-util.c b/shared/cairo-util.c
> > index d71e0ed..b91b5bc 100644
> > --- a/shared/cairo-util.c
> > +++ b/shared/cairo-util.c
> > @@ -142,6 +142,67 @@ blur_surface(cairo_surface_t *surface, int margin)
> >   return 0;
> >  }
> >
> > +static cairo_surface_t *
> > +scale_surface(cairo_surface_t *source, cairo_filter_t filter,
> > + double width,
> double height)
> > +{
> > + cairo_surface_t *dest;
> > + cairo_t *cr;
> > + int old_width, old_height;
> > +
> > + old_width = cairo_image_surface_get_width(source);
> > + old_height = cairo_image_surface_get_height(source);
> > +
> > + dest = cairo_surface_create_similar(source,
> CAIRO_CONTENT_COLOR_ALPHA,
> > + width,
> height);
> > + cr = cairo_create (dest);
> > +
> > + cairo_scale (cr, width / old_width, height / old_height);
> > + cairo_set_source_surface (cr, source, 0, 0);
> > +
> > + cairo_pattern_set_extend (cairo_get_source(cr),
> CAIRO_EXTEND_REFLECT);
> > +
> > + cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
> > +
> > + cairo_paint (cr);
> > +
> > + cairo_destroy (cr);
> > +
> > + cairo_surface_destroy(source);
>
> This function looks like it solves the problem without leaking anything
> - would love to see more review from others with cairo experience.
>
> > +
> > + return dest;
> > +}
> > +
> > +cairo_surface_t *
>
> I would prefer this function be named something else, so a casual reader
> with no knowledge of cairo API (like me!) doesn't think it looks like a
> cairo function name.
>

I agree it could use a rename from cairo_resize_surface to something else.
Any suggestions?


>
> > +cairo_resize_surface(cairo_surface_t *source, cairo_filter_t filter,
> > + int width, int
> height)
> > +{
> > + if (!filter)
> > + filter = CAIRO_FILTER_BEST;
> > +
> > + while((cairo_image_surface_get_width(source) / 2.0f) > width)
> > + source = scale_surface(source, filter,
> > + cairo_image_surface_get_width(source) /
> 2.0f,
> > + cairo_image_surface_get_height(source));
> > +
> > + while((cairo_image_surface_get_height(source) / 2.0f) > height)
> > + source = scale_surface(source, filter,
> > + cairo_image_surface_get_width(source),
> > + cairo_image_surface_get_height(source) /
> 2.0f);
> > +
> > + while((cairo_image_surface_get_width(source) * 2.0f) < width)
> > + source = scale_surface(source, filter,
> > + cairo_image_surface_get_width(source) *
> 2.0f,
> > + cairo_image_surface_get_height(source));
> > +
> > + while((cairo_image_surface_get_height(source) * 2.0f) < height)
> > + source = scale_surface(source, filter,
> > + cairo_image_surface_get_width(source),
> > + cairo_image_surface_get_height(source) *
> 2.0f);
>
> This chain of operations feels complicated - is it not possible to
> calculate the optimal target size and just call scale_surface once?
>

Yes it is possible, but the point of this is to yield a better quality.
Scaling directly to the target size can have undesirable results.


>
> > +
> > + return scale_surface(source, filter, width, height);
> > +}
> > +
> >  void
> >  render_shadow(cairo_t *cr, cairo_surface_t *surface,
> > int x, int y, int width, int height, int margin, int
> top_mar

[PATCH 2/2 v2] xwm: Scale icon if size is not the target size

[Scott Moreau]

This scales the icon cairo surface for the titlebar if it isn't the
target size.

shared/cairo-util: Add surface resizing function to be used for this
case and other potential cases.
---

Changed in v2:

- Rebase to [PATCH 1/1 v3] xwm: Choose icon closest to target size

 shared/cairo-util.c   | 61 +++
 shared/cairo-util.h   |  4 
 xwayland/window-manager.c |  9 ++-
 3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/shared/cairo-util.c b/shared/cairo-util.c
index d71e0ed..b91b5bc 100644
--- a/shared/cairo-util.c
+++ b/shared/cairo-util.c
@@ -142,6 +142,67 @@ blur_surface(cairo_surface_t *surface, int margin)
return 0;
 }
 
+static cairo_surface_t *
+scale_surface(cairo_surface_t *source, cairo_filter_t filter,
+   double width, double 
height)
+{
+   cairo_surface_t *dest;
+   cairo_t *cr;
+   int old_width, old_height;
+
+   old_width = cairo_image_surface_get_width(source);
+   old_height = cairo_image_surface_get_height(source);
+
+   dest = cairo_surface_create_similar(source, CAIRO_CONTENT_COLOR_ALPHA,
+   width, height);
+   cr = cairo_create (dest);
+
+   cairo_scale (cr, width / old_width, height / old_height);
+   cairo_set_source_surface (cr, source, 0, 0);
+
+   cairo_pattern_set_extend (cairo_get_source(cr), CAIRO_EXTEND_REFLECT);
+
+   cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
+
+   cairo_paint (cr);
+
+   cairo_destroy (cr);
+
+   cairo_surface_destroy(source);
+
+   return dest;
+}
+
+cairo_surface_t *
+cairo_resize_surface(cairo_surface_t *source, cairo_filter_t filter,
+   int width, int height)
+{
+   if (!filter)
+   filter = CAIRO_FILTER_BEST;
+
+   while((cairo_image_surface_get_width(source) / 2.0f) > width)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source) / 2.0f,
+   cairo_image_surface_get_height(source));
+
+   while((cairo_image_surface_get_height(source) / 2.0f) > height)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source),
+   cairo_image_surface_get_height(source) / 2.0f);
+
+   while((cairo_image_surface_get_width(source) * 2.0f) < width)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source) * 2.0f,
+   cairo_image_surface_get_height(source));
+
+   while((cairo_image_surface_get_height(source) * 2.0f) < height)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source),
+   cairo_image_surface_get_height(source) * 2.0f);
+
+   return scale_surface(source, filter, width, height);
+}
+
 void
 render_shadow(cairo_t *cr, cairo_surface_t *surface,
  int x, int y, int width, int height, int margin, int top_margin)
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 6fd11f6..3bd2b0c 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -49,6 +49,10 @@ rounded_rect(cairo_t *cr, int x0, int y0, int x1, int y1, 
int radius);
 cairo_surface_t *
 load_cairo_surface(const char *filename);
 
+cairo_surface_t *
+cairo_resize_surface(cairo_surface_t *source, cairo_filter_t filter,
+   int width, int height);
+
 struct theme {
cairo_surface_t *active_frame;
cairo_surface_t *inactive_frame;
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 30c4b1c..6057490 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1416,6 +1416,7 @@ get_icon_size_from_data(int target_width, int 
target_height,
return ret;
 }
 
+#define ICON_SIZE 16
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1437,7 +1438,8 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
 
data = xcb_get_property_value(reply);
 
-   data = get_icon_size_from_data(16, 16, , , length, data);
+   data = get_icon_size_from_data(ICON_SIZE, ICON_SIZE,
+   , 
, length, data);
 
if (!data)
return;
@@ -1453,11 +1455,16 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
}
 
+   if (width != ICON_SIZE || height != ICON_SIZE)
+   new_surface =
+   cairo_resize_surface(new_surface, 0, ICON_SIZE, 
ICON_SIZE);
+
if (window->frame)
frame_set_icon(window->frame, new_surface);
   

[PATCH v3] xwm: Choose icon closest to target size

[Scott Moreau]

Xwayland clients can offer multiple icon sizes in no particular order.
Previously xwm was selecting the first one unconditionally. This patch
selects the icon that matches the size closest to the target size. The
target size is hard coded to 16 since there is only one theme and the
data used to create the theme is hard coded.
---

Changed in v2:

- Fix typo setting width to height

Changed in v3:

- Move checks for malformed input into data handling function

 xwayland/window-manager.c | 74 ++-
 1 file changed, 67 insertions(+), 7 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..30c4b1c 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1352,6 +1352,70 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
 }
 
+static uint32_t *
+get_icon_size_from_data(int target_width, int target_height,
+   uint32_t *width, uint32_t 
*height,
+   uint32_t length, uint32_t *data)
+{
+   uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
+   int num_sizes = 0, *sizes = NULL, a1, a2, a3;
+
+   *width = *height = 0;
+
+   while (d - data < length / 4) {
+   w = *d++;
+   h = *d++;
+
+   /* Some checks against malformed input. */
+   if (w == 0 || h == 0 || length < 2 + w * h) {
+   free(sizes);
+   free(img);
+   return NULL;
+   }
+
+   sizes = realloc(sizes, 2 * (num_sizes + 1) * sizeof(uint32_t));
+   if (!sizes) {
+   free(img);
+   return NULL;
+   }
+
+   img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
+   if (!img) {
+   free(sizes);
+   return NULL;
+   }
+
+   sizes[(num_sizes * 2) + 0] = w;
+   sizes[(num_sizes * 2) + 1] = h;
+   img[num_sizes] = d;
+
+   num_sizes++;
+   d += w * h;
+   }
+
+   /* Choose closest match by comparing icon dimension areas */
+   a1 = target_width * target_height;
+
+   while (num_sizes--) {
+   w = sizes[(num_sizes * 2) + 0];
+   h = sizes[(num_sizes * 2) + 1];
+
+   a2 = w * h;
+   a3 = *width * *height;
+
+   if (a2 != a3 && abs(a2 - a1) < abs(a3 - a1)) {
+   *width = w;
+   *height = h;
+   ret = img[num_sizes];
+   }
+   }
+
+   free(sizes);
+   free(img);
+
+   return ret;
+}
+
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1361,9 +1425,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
uint32_t *data, width, height;
cairo_surface_t *new_surface;
 
-   /* TODO: icons don’t have any specified order, we should pick the
-* closest one to the target dimension instead of the first one. */
-
cookie = xcb_get_property(wm->conn, 0, window->id,
  wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
  UINT32_MAX);
@@ -1375,11 +1436,10 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
 
data = xcb_get_property_value(reply);
-   width = *data++;
-   height = *data++;
 
-   /* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height)
+   data = get_icon_size_from_data(16, 16, , , length, data);
+
+   if (!data)
return;
 
new_surface =
-- 
2.7.4

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

[PATCH v2] xwm: Choose icon closest to target size

[Scott Moreau]

Xwayland clients can offer multiple icon sizes in no particular order.
Previously xwm was selecting the first one unconditionally. This patch
selects the icon that matches the size closest to the target size. The
target size is hard coded to 16 since there is only one theme and the
data used to create the theme is hard coded.
---

Changed in v2:

- Fix typo setting width to height

 xwayland/window-manager.c | 66 ++-
 1 file changed, 60 insertions(+), 6 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..327b4b9 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1352,6 +1352,63 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
 }
 
+static uint32_t *
+get_icon_size_from_data(int target_width, int target_height,
+   uint32_t *width, uint32_t 
*height,
+   uint32_t length, uint32_t *data)
+{
+   uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
+   int num_sizes = 0, *sizes = NULL, a1, a2, a3;
+
+   *width = *height = 0;
+
+   while (d - data < length / 4) {
+   w = *d++;
+   h = *d++;
+
+   sizes = realloc(sizes, 2 * (num_sizes + 1) * sizeof(uint32_t));
+   if (!sizes) {
+   free(img);
+   return NULL;
+   }
+
+   img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
+   if (!img) {
+   free(sizes);
+   return NULL;
+   }
+
+   sizes[(num_sizes * 2) + 0] = w;
+   sizes[(num_sizes * 2) + 1] = h;
+   img[num_sizes] = d;
+
+   num_sizes++;
+   d += w * h;
+   }
+
+   /* Choose closest match by comparing icon dimension areas */
+   a1 = target_width * target_height;
+
+   while (num_sizes--) {
+   w = sizes[(num_sizes * 2) + 0];
+   h = sizes[(num_sizes * 2) + 1];
+
+   a2 = w * h;
+   a3 = *width * *height;
+
+   if (a2 != a3 && abs(a2 - a1) < abs(a3 - a1)) {
+   *width = w;
+   *height = h;
+   ret = img[num_sizes];
+   }
+   }
+
+   free(sizes);
+   free(img);
+
+   return ret;
+}
+
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1361,9 +1418,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
uint32_t *data, width, height;
cairo_surface_t *new_surface;
 
-   /* TODO: icons don’t have any specified order, we should pick the
-* closest one to the target dimension instead of the first one. */
-
cookie = xcb_get_property(wm->conn, 0, window->id,
  wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
  UINT32_MAX);
@@ -1375,11 +1429,11 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
 
data = xcb_get_property_value(reply);
-   width = *data++;
-   height = *data++;
+
+   data = get_icon_size_from_data(16, 16, , , length, data);
 
/* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height)
+   if (!data || width == 0 || height == 0 || length < 2 + width * height)
return;
 
new_surface =
-- 
2.7.4

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

[PATCH 1/2] xwm: Choose icon closest to target size

[Scott Moreau]

Xwayland clients can offer multiple icon sizes in no particular order.
Previously xwm was selecting the first one unconditionally. This patch
selects the icon that matches the size closest to the target size. The
target size is hard coded to 16 since there is only one theme and the
data used to create the theme is hard coded.
---
 xwayland/window-manager.c | 66 ++-
 1 file changed, 60 insertions(+), 6 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..8b7d2f6 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1352,6 +1352,63 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
 }
 
+static uint32_t *
+get_icon_size_from_data(int target_width, int target_height,
+   uint32_t *width, uint32_t 
*height,
+   uint32_t length, uint32_t *data)
+{
+   uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
+   int num_sizes = 0, *sizes = NULL, a1, a2, a3;
+
+   *width = *height = 0;
+
+   while (d - data < length / 4) {
+   w = *d++;
+   h = *d++;
+
+   sizes = realloc(sizes, 2 * (num_sizes + 1) * sizeof(uint32_t));
+   if (!sizes) {
+   free(img);
+   return NULL;
+   }
+
+   img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
+   if (!img) {
+   free(sizes);
+   return NULL;
+   }
+
+   sizes[(num_sizes * 2) + 0] = w;
+   sizes[(num_sizes * 2) + 1] = h;
+   img[num_sizes] = d;
+
+   num_sizes++;
+   d += w * h;
+   }
+
+   /* Choose closest match by comparing icon dimension areas */
+   a1 = target_width * target_height;
+
+   while (num_sizes--) {
+   w = sizes[(num_sizes * 2) + 0];
+   h = sizes[(num_sizes * 2) + 1];
+
+   a2 = w * h;
+   a3 = *width * *height;
+
+   if (a2 != a3 && abs(a2 - a1) < abs(a3 - a1)) {
+   *width = w;
+   *height = w;
+   ret = img[num_sizes];
+   }
+   }
+
+   free(sizes);
+   free(img);
+
+   return ret;
+}
+
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1361,9 +1418,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
uint32_t *data, width, height;
cairo_surface_t *new_surface;
 
-   /* TODO: icons don’t have any specified order, we should pick the
-* closest one to the target dimension instead of the first one. */
-
cookie = xcb_get_property(wm->conn, 0, window->id,
  wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
  UINT32_MAX);
@@ -1375,11 +1429,11 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
 
data = xcb_get_property_value(reply);
-   width = *data++;
-   height = *data++;
+
+   data = get_icon_size_from_data(16, 16, , , length, data);
 
/* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height)
+   if (!data || width == 0 || height == 0 || length < 2 + width * height)
return;
 
new_surface =
-- 
2.7.4

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

[PATCH 2/2] xwm: Scale icon if size is not the target size

[Scott Moreau]

This scales the icon cairo surface for the titlebar if it isn't the
right size.

shared/cairo-util: Add surface resizing function to be used for this
case and other potential cases.
---
 shared/cairo-util.c   | 61 +++
 shared/cairo-util.h   |  4 
 xwayland/window-manager.c |  9 ++-
 3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/shared/cairo-util.c b/shared/cairo-util.c
index d71e0ed..b91b5bc 100644
--- a/shared/cairo-util.c
+++ b/shared/cairo-util.c
@@ -142,6 +142,67 @@ blur_surface(cairo_surface_t *surface, int margin)
return 0;
 }
 
+static cairo_surface_t *
+scale_surface(cairo_surface_t *source, cairo_filter_t filter,
+   double width, double 
height)
+{
+   cairo_surface_t *dest;
+   cairo_t *cr;
+   int old_width, old_height;
+
+   old_width = cairo_image_surface_get_width(source);
+   old_height = cairo_image_surface_get_height(source);
+
+   dest = cairo_surface_create_similar(source, CAIRO_CONTENT_COLOR_ALPHA,
+   width, height);
+   cr = cairo_create (dest);
+
+   cairo_scale (cr, width / old_width, height / old_height);
+   cairo_set_source_surface (cr, source, 0, 0);
+
+   cairo_pattern_set_extend (cairo_get_source(cr), CAIRO_EXTEND_REFLECT);
+
+   cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
+
+   cairo_paint (cr);
+
+   cairo_destroy (cr);
+
+   cairo_surface_destroy(source);
+
+   return dest;
+}
+
+cairo_surface_t *
+cairo_resize_surface(cairo_surface_t *source, cairo_filter_t filter,
+   int width, int height)
+{
+   if (!filter)
+   filter = CAIRO_FILTER_BEST;
+
+   while((cairo_image_surface_get_width(source) / 2.0f) > width)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source) / 2.0f,
+   cairo_image_surface_get_height(source));
+
+   while((cairo_image_surface_get_height(source) / 2.0f) > height)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source),
+   cairo_image_surface_get_height(source) / 2.0f);
+
+   while((cairo_image_surface_get_width(source) * 2.0f) < width)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source) * 2.0f,
+   cairo_image_surface_get_height(source));
+
+   while((cairo_image_surface_get_height(source) * 2.0f) < height)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source),
+   cairo_image_surface_get_height(source) * 2.0f);
+
+   return scale_surface(source, filter, width, height);
+}
+
 void
 render_shadow(cairo_t *cr, cairo_surface_t *surface,
  int x, int y, int width, int height, int margin, int top_margin)
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 6fd11f6..3bd2b0c 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -49,6 +49,10 @@ rounded_rect(cairo_t *cr, int x0, int y0, int x1, int y1, 
int radius);
 cairo_surface_t *
 load_cairo_surface(const char *filename);
 
+cairo_surface_t *
+cairo_resize_surface(cairo_surface_t *source, cairo_filter_t filter,
+   int width, int height);
+
 struct theme {
cairo_surface_t *active_frame;
cairo_surface_t *inactive_frame;
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 8b7d2f6..741fa1e 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1409,6 +1409,7 @@ get_icon_size_from_data(int target_width, int 
target_height,
return ret;
 }
 
+#define ICON_SIZE 16
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1430,7 +1431,8 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
 
data = xcb_get_property_value(reply);
 
-   data = get_icon_size_from_data(16, 16, , , length, data);
+   data = get_icon_size_from_data(ICON_SIZE, ICON_SIZE,
+   , 
, length, data);
 
/* Some checks against malformed input. */
if (!data || width == 0 || height == 0 || length < 2 + width * height)
@@ -1447,11 +1449,16 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
}
 
+   if (width != ICON_SIZE || height != ICON_SIZE)
+   new_surface =
+   cairo_resize_surface(new_surface, 0, ICON_SIZE, 
ICON_SIZE);
+
if (window->frame)
frame_set_icon(window->frame, new_surface);
  

[PATCH v2] xwm: Fix memory leak

[Scott Moreau]

A memory leak introduced by 6b58ea8c led to me finding a bigger
leak, which is xwm was calling frame_create() without calling
frame_destroy(). This meant that the associated icon_surface
was not being destroyed, leaving the destroy handler for it
broken. Here we fix this by calling frame_destroy() when the
window is destroyed and free the reply in the icon_surface
destroy handler.
---
 xwayland/window-manager.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..9e61a67 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1353,6 +1353,14 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
 }
 
 static void
+handle_icon_surface_destroy(void *data)
+{
+   xcb_get_property_reply_t *reply = (xcb_get_property_reply_t *)data;
+
+   free(reply);
+}
+
+static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
xcb_get_property_reply_t *reply;
@@ -1371,16 +1379,20 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
length = xcb_get_property_value_length(reply);
 
/* This is in 32-bit words, not in bytes. */
-   if (length < 2)
+   if (length < 2) {
+   free(reply);
return;
+   }
 
data = xcb_get_property_value(reply);
width = *data++;
height = *data++;
 
/* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height)
+   if (width == 0 || height == 0 || length < 2 + width * height) {
+   free(reply);
return;
+   }
 
new_surface =
cairo_image_surface_create_for_data((unsigned char *)data,
@@ -1390,9 +1402,13 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
/* Bail out in case anything wrong happened during surface creation. */
if (cairo_surface_status(new_surface) != CAIRO_STATUS_SUCCESS) {
cairo_surface_destroy(new_surface);
+   free(reply);
return;
}
 
+   cairo_surface_set_user_data(new_surface, NULL, reply,
+   
_icon_surface_destroy);
+
if (window->frame)
frame_set_icon(window->frame, new_surface);
else /* We don’t have a frame yet */
@@ -1502,6 +1518,9 @@ weston_wm_window_destroy(struct weston_wm_window *window)
window->frame_id = XCB_WINDOW_NONE;
}
 
+   if (window->frame)
+   frame_destroy(window->frame);
+
if (window->surface_id)
wl_list_remove(>link);
 
-- 
2.7.4

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

Re: [PATCH] xwm: Fix memory leak

[Scott Moreau]

Hi Pekka,

On Tue, Mar 20, 2018 at 2:21 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:

> On Mon, 19 Mar 2018 18:06:03 -0600
> Scott Moreau <ore...@gmail.com> wrote:
>
> > Fix memory leak introduced by 6b58ea8c. weston_wm_handle_icon() was
> > calling xcb_get_property_reply() without freeing the reply.
> > ---
> >  xwayland/window-manager.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> > index c307e19..24e7213 100644
> > --- a/xwayland/window-manager.c
> > +++ b/xwayland/window-manager.c
> > @@ -1387,6 +1387,8 @@ weston_wm_handle_icon(struct weston_wm *wm, struct
> weston_wm_window *window)
> >   CAIRO_FORMAT_ARGB32,
> >   width, height, width *
> 4);
> >
> > + free(reply);
> > +
> >   /* Bail out in case anything wrong happened during surface
> creation. */
> >   if (cairo_surface_status(new_surface) != CAIRO_STATUS_SUCCESS) {
> >   cairo_surface_destroy(new_surface);
>
> Hi,
>
> this is strictly an improvement, so I pushed it:
>dc402462..d2cb711d  master -> master
>

Thanks for picking it up, I thought this was a simple one at first too.


>
> It does still miss the early error returns the function, though, so
> it's only a partial solution.
>
> A few seconds later, I thought of a problem with this patch, so I had
> to push a revert immediately (no force-pushing allowed):
>d2cb711d..9fe5d5fa  master -> master
>
> I explained the issue in the revert, and it boils down to
> cairo_image_surface_create_for_data() not making a copy of the memory
> it is passed in, instead it will just keep using the pointer passed in,
> which means we cannot free the data until the cairo surface is
> destroyed. So while there is a leak to fix, the fix needs to be more
> involved.
>

Yes it does need a more involved fix. After hooking up a destroy listener
for the cairo surface, I noticed that window->icon_surface is never being
destroyed either, and there isn't a straight forward fix especially since
window->icon_surface being set to NULL in weston_wm_window_create_frame().

Also as a side note, I notice some strange effect sometimes where the icon
will appear where the mouse cursor is for a split second when opening a
window with an icon, and quickly do fade out animation on it.

Thanks,
Scott


>
> This happens when I try to rush things. Sorry.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] xwm: Fix memory leak

[Scott Moreau]

Fix memory leak introduced by 6b58ea8c. weston_wm_handle_icon() was
calling xcb_get_property_reply() without freeing the reply.
---
 xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..24e7213 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1387,6 +1387,8 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
CAIRO_FORMAT_ARGB32,
width, height, width * 4);
 
+   free(reply);
+
/* Bail out in case anything wrong happened during surface creation. */
if (cairo_surface_status(new_surface) != CAIRO_STATUS_SUCCESS) {
cairo_surface_destroy(new_surface);
-- 
2.7.4

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

Re: [PATCH v2] xwm: Update input region on resize

[Scott Moreau]

On Mon, Mar 19, 2018 at 1:13 PM, Derek Foreman <der...@osg.samsung.com>
wrote:

> On 2018-03-16 06:42 PM, Scott Moreau wrote:
>
>> Hi Pekka,
>>
>> On Fri, Mar 16, 2018 at 9:20 AM, Pekka Paalanen <ppaala...@gmail.com
>> <mailto:ppaala...@gmail.com>> wrote:
>>
>> On Tue, 13 Mar 2018 21:22:04 -0600
>> Scott Moreau <ore...@gmail.com <mailto:ore...@gmail.com>> wrote:
>>
>> > Commit 332d1892 introduced a bug because the window was
>> > shaped only when the frame was created, leaving the input
>> > region unchanged regardless if the window was resized.
>> > This patch updates the input region shape on resize,
>> > fixing the problem.
>> >
>> > ---
>> >
>> > Changed in v2:
>> >
>> > - Bail in shape function if (window->override_redirect ||
>> !window->frame)
>> > - Call shape function from send_configure()
>> >
>> >  xwayland/window-manager.c | 53 +-
>> -
>> >  1 file changed, 33 insertions(+), 20 deletions(-)
>>
>> Hi,
>>
>> while trying to wrap my head around this, I started feeling dizzy. For
>> real. So I have to keep this short.
>>
>>
>> I think this is what happens when trying to sync two display servers.
>>
>>
>> The first decision we should make is, do we want a quick patch for an
>> immediate issue at hand, or do we want to make things better in the
>> long
>> run. Taking in this patch as is seems to be the former to me, and
>> given
>> the phase of the release cycle can be justified.
>>
>> The following mind flow is for a long term solution, and the comments
>> inlined with the code below are for the quick patch.
>>
>
> FWIW, I'd be open to landing something quick at this point.  The bug it
> fixes seems hugely annoying.  I resize an xterm, and I can't click in the
> new area.
>
> Alternately, I'm wondering if we should consider reverting the patch that
> introduced this bug?  I guess it wasn't tested well enough, and this
> behaviour seems more painful than what it was intended to fix?


I think a revert would be a good place to start. The patch also has
whitespace that does not match surrounding code.

To clarify the bug, start an xwayland window and resize it to a larger
dimension. Mouse input will only work for the size of the window before
resize. The rest of the window does not respond to input.

Thanks,
Scott


>
>
>
>> Taking a step back, the aim to keep the input shape up-to-date
>> whenever
>> something happens.
>>
>> If we have a frame window with decorations, then we call
>> frame_resize_inside() to adjust its size. Would it not be logical to
>> set the input shape in at least all those cases?
>>
>>
>> Yes, maybe there can be a function that calls frame_resize_inside and the
>> shape function to replace calls to frame_resize_inside.
>>
>>
>> Except it looks like we can have decorated O-R windows, and those
>> should be exempt? Oh, I'm told decorated O-R windows don't make sense,
>> but I see some code in weston that would only apply in such case...
>> if (window->override_redirect) { ... if (window->frame)
>> frame_resize_inside(...)
>>
>> All windows that go through map_request handler will get the frame
>> window (window->frame_id) and the frame (window->frame) created. The
>> only windows that don't get this treatment are therefore windows that
>> are O-R at the time of mapping them. It's somewhat complicated by the
>> fact that XWM does not support dynamically changing O-R flag... or
>> maybe it makes it easier.
>>
>> Now, we have configure_request and configure_notify handlers. O-R
>> windows will not hit configure_request handler, and the X server
>> processes XWM's configure commands immediately. This sounds like
>> configure_request handler would be a good place to update the input
>> shape.
>>
>>
>> Yes
>>
>>
>> configure_notify handler gets called for O-R as well, and it happens
>> after the fact, so updating there would be a tiny bit late. Would you
>> agree?
>>
>> I was thinking there might be some change that comes in configure notify
>> that we don't know about until the event happens.
>>
>>
>> That leaves the XWM originated resizes, which boils down to.

[PATCH] xwm: Send configure event when moving

[Scott Moreau]

Send a synthetic configure notify event to the reparented window to
update the position in Xwayland. This fixes menu positioning in clients
like VLC after moving the window.
---
 xwayland/window-manager.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..542e9fb 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -659,13 +659,12 @@ weston_wm_window_get_input_rect(struct weston_wm_window 
*window,
 }
 
 static void
-weston_wm_window_send_configure_notify(struct weston_wm_window *window)
+weston_wm_window_send_configure_notify(struct weston_wm_window *window,
+   
int x, int y)
 {
xcb_configure_notify_event_t configure_notify;
struct weston_wm *wm = window->wm;
-   int x, y;
 
-   weston_wm_window_get_child_position(window, , );
configure_notify.response_type = XCB_CONFIGURE_NOTIFY;
configure_notify.pad0 = 0;
configure_notify.event = window->id;
@@ -702,7 +701,7 @@ weston_wm_handle_configure_request(struct weston_wm *wm, 
xcb_generic_event_t *ev
return;
 
if (window->fullscreen) {
-   weston_wm_window_send_configure_notify(window);
+   weston_wm_window_send_configure_notify(window, 0, 0);
return;
}
 
@@ -2734,6 +2733,7 @@ send_position(struct weston_surface *surface, int32_t x, 
int32_t y)
struct weston_wm_window *window = get_wm_window(surface);
struct weston_wm *wm;
uint32_t mask, values[2];
+   int sx, sy;
 
if (!window || !window->wm)
return;
@@ -2750,6 +2750,10 @@ send_position(struct weston_surface *surface, int32_t x, 
int32_t y)
mask = XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y;
 
xcb_configure_window(wm->conn, window->frame_id, mask, values);
+
+   weston_wm_window_get_child_position(window, , );
+   weston_wm_window_send_configure_notify(window, x + sx, y + sy);
+
xcb_flush(wm->conn);
}
 }
-- 
2.7.4

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

[PATCH] xwm: Fix wrong input offset for certain clients

[Scott Moreau]

Some windows might get a create_notify event without the
override redirect flag set and then get a confiure_notify
event before map_request is received. This means that when
weston_wm_window_get_child_position is called in response
to configure_notify, the wrong offsets are computed resulting
in wrong input offsets for some clients like steam.
---
 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 c307e19..2307f1a 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -711,10 +711,12 @@ weston_wm_handle_configure_request(struct weston_wm *wm, 
xcb_generic_event_t *ev
if (configure_request->value_mask & XCB_CONFIG_WINDOW_HEIGHT)
window->height = configure_request->height;
 
-   if (window->frame)
+   if (window->frame) {
frame_resize_inside(window->frame, window->width, 
window->height);
+   weston_wm_window_get_child_position(window, , );
+   } else
+   x = y = 0;
 
-   weston_wm_window_get_child_position(window, , );
values[i++] = x;
values[i++] = y;
values[i++] = window->width;
-- 
2.7.4

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

[PATCH] xwm: Handle changing override redirect flag

[Scott Moreau]

Xwayland windows might be created with a different override redirect
flag than is given on map or configure notify. This causes confusion
about whether a window should be treated as override redirect or not.
Here we handle the changing override redirect flag in relevant notify
handlers so windows are treated appropriately. In particular, this
fixes positioning menus in clients like VLC, though it is not a
complete fix. If the window is moved, the menus are still positioned
as if the window wasn't moved.
---
 xwayland/window-manager.c | 43 +++
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..353bcbb 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -754,6 +754,9 @@ our_resource(struct weston_wm *wm, uint32_t id)
 }
 
 static void
+weston_wm_window_create_frame(struct weston_wm_window *window);
+
+static void
 weston_wm_handle_configure_notify(struct weston_wm *wm, xcb_generic_event_t 
*event)
 {
xcb_configure_notify_event_t *configure_notify =
@@ -775,6 +778,14 @@ weston_wm_handle_configure_notify(struct weston_wm *wm, 
xcb_generic_event_t *eve
window->y = configure_notify->y;
window->pos_dirty = false;
 
+   if (window->override_redirect != configure_notify->override_redirect) {
+   if (window->override_redirect)
+   weston_wm_window_create_frame(window);
+   else
+   wm_log("%s: Unhandled override redirect flag change\n", 
__func__);
+   window->override_redirect = configure_notify->override_redirect;
+   }
+
if (window->override_redirect) {
window->width = configure_notify->width;
window->height = configure_notify->height;
@@ -987,6 +998,9 @@ weston_wm_window_create_frame(struct weston_wm_window 
*window)
int x, y, width, height;
int buttons = FRAME_BUTTON_CLOSE;
 
+   if (window->frame_id != XCB_WINDOW_NONE)
+   return;
+
if (window->decorate & MWM_DECOR_MAXIMIZE)
buttons |= FRAME_BUTTON_MAXIMIZE;
 
@@ -1060,6 +1074,8 @@ weston_wm_window_create_frame(struct weston_wm_window 
*window)
 );
 
hash_table_insert(wm->window_hash, window->frame_id, window);
+
+   assert(window->frame_id != XCB_WINDOW_NONE);
 }
 
 /*
@@ -1120,9 +1136,7 @@ weston_wm_handle_map_request(struct weston_wm *wm, 
xcb_generic_event_t *event)
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); /* sets frame_id */
-   assert(window->frame_id != XCB_WINDOW_NONE);
+   weston_wm_window_create_frame(window); /* sets frame_id */
 
wm_log("XCB_MAP_REQUEST (window %d, %p, frame %d, %dx%d @ %d,%d)\n",
   window->id, window, window->frame_id,
@@ -1153,6 +1167,7 @@ static void
 weston_wm_handle_map_notify(struct weston_wm *wm, xcb_generic_event_t *event)
 {
xcb_map_notify_event_t *map_notify = (xcb_map_notify_event_t *) event;
+   struct weston_wm_window *window;
 
if (our_resource(wm, map_notify->window)) {
wm_log("XCB_MAP_NOTIFY (window %d, ours)\n",
@@ -1162,6 +1177,17 @@ weston_wm_handle_map_notify(struct weston_wm *wm, 
xcb_generic_event_t *event)
 
wm_log("XCB_MAP_NOTIFY (window %d%s)\n", map_notify->window,
   map_notify->override_redirect ? ", override" : "");
+
+   if (!wm_lookup_window(wm, map_notify->window, ))
+   return;
+
+   if (window->override_redirect != map_notify->override_redirect) {
+   if (window->override_redirect)
+   weston_wm_window_create_frame(window);
+   else
+   wm_log("%s: Unhandled override redirect flag change\n", 
__func__);
+   window->override_redirect = map_notify->override_redirect;
+   }
 }
 
 static void
@@ -1333,11 +1359,12 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
struct weston_wm *wm = window->wm;
 
if (window->frame_id == XCB_WINDOW_NONE) {
-   /* 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
-*/
+   /* Ignore if the window isn't mapped */
+   if (!window->shsurf)
+   return;
+
+   assert(window->override_redirect);
+
weston_wm_window_set_pending_state_OR(window);
return;
}
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

Re: [PATCH v2] xwm: Update input region on resize

[Scott Moreau]

Hi Pekka,

On Fri, Mar 16, 2018 at 9:20 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:

> On Tue, 13 Mar 2018 21:22:04 -0600
> Scott Moreau <ore...@gmail.com> wrote:
>
> > Commit 332d1892 introduced a bug because the window was
> > shaped only when the frame was created, leaving the input
> > region unchanged regardless if the window was resized.
> > This patch updates the input region shape on resize,
> > fixing the problem.
> >
> > ---
> >
> > Changed in v2:
> >
> > - Bail in shape function if (window->override_redirect || !window->frame)
> > - Call shape function from send_configure()
> >
> >  xwayland/window-manager.c | 53 +-
> -
> >  1 file changed, 33 insertions(+), 20 deletions(-)
>
> Hi,
>
> while trying to wrap my head around this, I started feeling dizzy. For
> real. So I have to keep this short.
>

I think this is what happens when trying to sync two display servers.


>
> The first decision we should make is, do we want a quick patch for an
> immediate issue at hand, or do we want to make things better in the long
> run. Taking in this patch as is seems to be the former to me, and given
> the phase of the release cycle can be justified.
>
> The following mind flow is for a long term solution, and the comments
> inlined with the code below are for the quick patch.
>
>
> Taking a step back, the aim to keep the input shape up-to-date whenever
> something happens.
>
> If we have a frame window with decorations, then we call
> frame_resize_inside() to adjust its size. Would it not be logical to
> set the input shape in at least all those cases?
>

Yes, maybe there can be a function that calls frame_resize_inside and the
shape function to replace calls to frame_resize_inside.


>
> Except it looks like we can have decorated O-R windows, and those
> should be exempt? Oh, I'm told decorated O-R windows don't make sense,
> but I see some code in weston that would only apply in such case...
> if (window->override_redirect) { ... if (window->frame)
> frame_resize_inside(...)
>
> All windows that go through map_request handler will get the frame
> window (window->frame_id) and the frame (window->frame) created. The
> only windows that don't get this treatment are therefore windows that
> are O-R at the time of mapping them. It's somewhat complicated by the
> fact that XWM does not support dynamically changing O-R flag... or
> maybe it makes it easier.
>
> Now, we have configure_request and configure_notify handlers. O-R
> windows will not hit configure_request handler, and the X server
> processes XWM's configure commands immediately. This sounds like
> configure_request handler would be a good place to update the input
> shape.
>

Yes

>
> configure_notify handler gets called for O-R as well, and it happens
> after the fact, so updating there would be a tiny bit late. Would you
> agree?
>
I was thinking there might be some change that comes in configure notify
that we don't know about until the event happens.

>
> That leaves the XWM originated resizes, which boils down to...
> send_configure(), or actually weston_wm_window_configure()?
>
Yes

>
> It looks like configure_request handler is open-coding all of
> weston_wm_window_configure() but it also adds some bits specific to the
> configure request.
>
> Am I making sense?
>
Yes, and thanks for taking the time to try and help unravel this.


>
> > diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> > index c307e19..cd72a59 100644
> > --- a/xwayland/window-manager.c
> > +++ b/xwayland/window-manager.c
> > @@ -659,6 +659,33 @@ weston_wm_window_get_input_rect(struct
> weston_wm_window *window,
> >  }
> >
> >  static void
> > +weston_wm_window_shape(struct weston_wm_window *window)
> > +{
> > + struct weston_wm *wm = window->wm;
> > + xcb_rectangle_t rect;
> > + int x, y, width, height;
> > +
> > + if (window->override_redirect || !window->frame)
> > + return;
> > +
> > + weston_wm_window_get_input_rect(window, , , , );
> > +
> > + rect.x = x;
> > + rect.y = y;
> > + rect.width = width;
> > + rect.height = height;
> > +
> > + /* The window frame was created with position and size which
> include
> > +  * an offset for margins and shadow. Set the input region to ignore
> > +  * shadow. */
> > + xcb_shape_rectangles(wm->conn,
> > +  XCB_SHAPE_SO_SET,
> > +  XCB_SHAPE_SK_INPUT,
> 

[PATCH v2] xwm: Update input region on resize

[Scott Moreau]

Commit 332d1892 introduced a bug because the window was
shaped only when the frame was created, leaving the input
region unchanged regardless if the window was resized.
This patch updates the input region shape on resize,
fixing the problem.

---

Changed in v2:

- Bail in shape function if (window->override_redirect || !window->frame)
- Call shape function from send_configure()

 xwayland/window-manager.c | 53 +--
 1 file changed, 33 insertions(+), 20 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..cd72a59 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -659,6 +659,33 @@ weston_wm_window_get_input_rect(struct weston_wm_window 
*window,
 }
 
 static void
+weston_wm_window_shape(struct weston_wm_window *window)
+{
+   struct weston_wm *wm = window->wm;
+   xcb_rectangle_t rect;
+   int x, y, width, height;
+
+   if (window->override_redirect || !window->frame)
+   return;
+
+   weston_wm_window_get_input_rect(window, , , , );
+
+   rect.x = x;
+   rect.y = y;
+   rect.width = width;
+   rect.height = height;
+
+   /* The window frame was created with position and size which include
+* an offset for margins and shadow. Set the input region to ignore
+* shadow. */
+   xcb_shape_rectangles(wm->conn,
+XCB_SHAPE_SO_SET,
+XCB_SHAPE_SK_INPUT,
+0, window->frame_id,
+0, 0, 1, );
+}
+
+static void
 weston_wm_window_send_configure_notify(struct weston_wm_window *window)
 {
xcb_configure_notify_event_t configure_notify;
@@ -789,6 +816,8 @@ weston_wm_handle_configure_notify(struct weston_wm *wm, 
xcb_generic_event_t *eve
xwayland_api->set_xwayland(window->shsurf,
   window->x, window->y);
}
+
+   weston_wm_window_shape(window);
 }
 
 static void
@@ -983,7 +1012,6 @@ weston_wm_window_create_frame(struct weston_wm_window 
*window)
 {
struct weston_wm *wm = window->wm;
uint32_t values[3];
-   xcb_rectangle_t rect;
int x, y, width, height;
int buttons = FRAME_BUTTON_CLOSE;
 
@@ -1040,26 +1068,9 @@ weston_wm_window_create_frame(struct weston_wm_window 
*window)
 >format_rgba,
 width, height);
 
-   weston_wm_window_get_input_rect(window, , , , );
-   rect.x = x;
-   rect.y = y;
-   rect.width = width;
-   rect.height = height;
-
-   /* The window frame was created with position and size which include
-* an offset for margins and shadow. Set the input region to ignore
-* shadow. */
-   xcb_shape_rectangles(wm->conn,
-XCB_SHAPE_SO_SET,
-XCB_SHAPE_SK_INPUT,
-0,
-window->frame_id,
-0,
-0,
-1,
-);
-
hash_table_insert(wm->window_hash, window->frame_id, window);
+
+   weston_wm_window_shape(window);
 }
 
 /*
@@ -2726,6 +2737,8 @@ send_configure(struct weston_surface *surface, int32_t 
width, int32_t height)
window->configure_source =
wl_event_loop_add_idle(wm->server->loop,
   weston_wm_window_configure, window);
+
+   weston_wm_window_shape(window);
 }
 
 static void
-- 
2.7.4

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

[PATCH] xwm: Update input region on resize

[Scott Moreau]

Commit 332d1892 introduced a bug because the window was
shaped only when the frame was created, leaving the input
region unchanged regardless if the window was resized.
This patch updates the input region shape on resize,
fixing the problem.
---
 xwayland/window-manager.c | 46 +++---
 1 file changed, 27 insertions(+), 19 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..5588166 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -659,6 +659,30 @@ weston_wm_window_get_input_rect(struct weston_wm_window 
*window,
 }
 
 static void
+weston_wm_window_shape(struct weston_wm_window *window)
+{
+   struct weston_wm *wm = window->wm;
+   xcb_rectangle_t rect;
+   int x, y, width, height;
+
+   weston_wm_window_get_input_rect(window, , , , );
+
+   rect.x = x;
+   rect.y = y;
+   rect.width = width;
+   rect.height = height;
+
+   /* The window frame was created with position and size which include
+* an offset for margins and shadow. Set the input region to ignore
+* shadow. */
+   xcb_shape_rectangles(wm->conn,
+XCB_SHAPE_SO_SET,
+XCB_SHAPE_SK_INPUT,
+0, window->frame_id,
+0, 0, 1, );
+}
+
+static void
 weston_wm_window_send_configure_notify(struct weston_wm_window *window)
 {
xcb_configure_notify_event_t configure_notify;
@@ -789,6 +813,8 @@ weston_wm_handle_configure_notify(struct weston_wm *wm, 
xcb_generic_event_t *eve
xwayland_api->set_xwayland(window->shsurf,
   window->x, window->y);
}
+
+   weston_wm_window_shape(window);
 }
 
 static void
@@ -983,7 +1009,6 @@ weston_wm_window_create_frame(struct weston_wm_window 
*window)
 {
struct weston_wm *wm = window->wm;
uint32_t values[3];
-   xcb_rectangle_t rect;
int x, y, width, height;
int buttons = FRAME_BUTTON_CLOSE;
 
@@ -1040,24 +1065,7 @@ weston_wm_window_create_frame(struct weston_wm_window 
*window)
 >format_rgba,
 width, height);
 
-   weston_wm_window_get_input_rect(window, , , , );
-   rect.x = x;
-   rect.y = y;
-   rect.width = width;
-   rect.height = height;
-
-   /* The window frame was created with position and size which include
-* an offset for margins and shadow. Set the input region to ignore
-* shadow. */
-   xcb_shape_rectangles(wm->conn,
-XCB_SHAPE_SO_SET,
-XCB_SHAPE_SK_INPUT,
-0,
-window->frame_id,
-0,
-0,
-1,
-);
+   weston_wm_window_shape(window);
 
hash_table_insert(wm->window_hash, window->frame_id, window);
 }
-- 
2.7.4

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

Re: [PATCH 2/3] xwayland: Shape window region to clip shadow area from input

[Scott Moreau]

On Tue, Dec 5, 2017 at 7:31 AM, Daniel Stone <dan...@fooishbar.org> wrote:

> Hi Scott,
>
> On 24 June 2017 at 08:18, Scott Moreau <ore...@gmail.com> wrote:
> > Decorated windows were getting the size of the window including the
> > shadow which is correct, but causing some confusion for motion input
> > events. This was exhibited when one xwayland window overlaps another,
> > hovering over the window beneath recieves no events if within the 32
> > pixel shadow border area of the window above.
>
> Seems correct, but can't this just use frame_input_rect() instead of
> hard-coding the sizes?
>

Yes it can, which is what we're discussing at
https://lists.freedesktop.org/archives/wayland-devel/2017-December/036402.html
Ian's patch fixes this problem.


>
> Cheers,
> Daniel
>

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

Re: [PATCH weston 1/1] xwayland - input size calculation correction

[Scott Moreau]

Hi Ian and Nandor,

I tested the initial patch and verified it does not fix the scenario I'm
trying, which is with two partially overlapping xcalc windows and hovering
the mouse over the buttons of the one below.

Ian:

The patch you submitted fixes the problem. A couple topical things I
noticed are:


On Thu, Dec 21, 2017 at 4:03 AM, Ray, Ian (GE Healthcare) 
wrote:

> On 20/12/2017, 13.19, "Daniel Stone"  wrote:
> >
> > Hi Ian and Nandor,
> >
> > On 20 December 2017 at 10:09, Ian Ray  wrote:
> > > The input area for an undecorated non-fullscreen window is based on the
> > > window size itself.
> > >
> > > Fixes a case where mouse events in the `invisible' window margin failed
> > > to reach the window behind.
> >
> > Scott sent some patches to fix similar issues a while ago:
> > https://lists.freedesktop.org/archives/wayland-devel/2017-
> June/thread.html#34332
> >
> > I had some questions here:
> > https://lists.freedesktop.org/archives/wayland-devel/2017-
> December/036116.html
> > https://lists.freedesktop.org/archives/wayland-devel/2017-
> December/036117.html
> >
> > Would you have any input on these?
>
> Hi Daniel,
>
> After checking Scott's earlier work, and review comments, together with
> testing decorated and undecorated windows, it *seems* like the input
> region change is the thing that is needed.
>
> RFC pasted below.
>
> Tested that X cursor changes shape at expected boundaries for both
> decorated and undecorated windows.
>
> Tested that mouse clicks in the shadow are received by the window
> underneath.
>
> However, clicks in the shadow region do not cause focus to change.
> This suggests that there is some other transformation that I have
> not found...
>
> The other reason for the RFC is that it is clear that shared/frame.c
> does not consider the case where there are no decorations.  I'm not
> sure if it should.
>
>
> > Cheers,
> > Daniel
>
> Thanks,
> Ian
>
> 8<
>
> Subject: [RFC PATCH weston 1/1] xwm: do not include shadow in input region
>
> The window frame was created with position and size which include
> an offset for margins and shadow.  Set the input region to ignore
> shadow.
>
> Signed-off-by: Ian Ray 
> ---
>  xwayland/window-manager.c | 32 
>  1 file changed, 32 insertions(+)
>
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index d529d41..884f0f4 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -707,6 +707,22 @@ weston_wm_window_get_child_position(struct
> weston_wm_window *window,
>  }
>
>  static void
> +weston_wm_window_get_input_rect(struct weston_wm_window *window,
> +   int32_t *x, int32_t *y,
> +   int32_t *width, int32_t *height)
> +{
> +   struct theme *t = window->wm->theme;
>

t is an unused variable.


> +
> +   if (!window->decorate) {
> +   weston_wm_window_get_child_position(window, x, y);
> +   *width = window->width;
> +   *height = window->height;
> +   } else {
> +   frame_input_rect(window->frame, x, y, width, height);
> +   }
> +}
> +
> +static void
>  weston_wm_window_send_configure_notify(struct weston_wm_window *window)
>  {
> xcb_configure_notify_event_t configure_notify;
> @@ -1031,6 +1047,7 @@ static void
>  weston_wm_window_create_frame(struct weston_wm_window *window)
>  {
> struct weston_wm *wm = window->wm;
> +   xcb_rectangle_t rect;
> uint32_t values[3];
> int x, y, width, height;
> int buttons = FRAME_BUTTON_CLOSE;
> @@ -1086,6 +1103,21 @@ weston_wm_window_create_frame(struct
> weston_wm_window *window)
>
>  >format_rgba,
>  width,
> height);
>
> +   weston_wm_window_get_input_rect(window, , ,
> , );
>

Perhaps a cast could be used when calling weston_wm_window_get_input_rect()
something like

weston_wm_window_get_input_rect(window, (int32_t *), (int32_t
*),
(int32_t *), (int32_t
*));

+
> +   /* The window frame was created with position and size which
> include
> +* an offset for margins and shadow.  Set the input region to
> ignore
> +* shadow. */
> +   xcb_shape_rectangles(wm->conn,
> +XCB_SHAPE_SO_SET,
> +XCB_SHAPE_SK_INPUT,
> +0,
> +window->frame_id,
> +0,
> +0,
> +1,
> +);
> +
> hash_table_insert(wm->window_hash, window->frame_id, window);
>  }
>
> --
> 2.10.1
>
>
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>


Thanks,

Re: [PATCH 3/3] xwayland: Fix override redirect window positioning

[Scott Moreau]

On Sat, Jun 24, 2017 at 1:18 AM, Scott Moreau <ore...@gmail.com> wrote:

> When override redirect windows are created, the x/y offsets
> provided at map time may be incorrect. The correct offsets are
> sent in a configure event from the xserver some time later.
> Here we fix the positions by delaying the call to set_xwayland()
> from map time to the needed configure event in the case where x/y
> are both 0 for override redirect windows.
> ---
>  xwayland/window-manager.c | 23 ---
>  xwayland/xwayland.h   |  1 +
>  2 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index 951a7cf..2e61ea4 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -169,6 +169,7 @@ struct weston_wm_window {
> int maximized_horz;
> struct wm_size_hints size_hints;
> struct motif_wm_hints motif_hints;
> +   struct wl_list or_link;
> struct wl_list link;
>  };
>
> @@ -737,9 +738,11 @@ our_resource(struct weston_wm *wm, uint32_t id)
>  static void
>  weston_wm_handle_configure_notify(struct weston_wm *wm,
> xcb_generic_event_t *event)
>  {
> +   const struct weston_desktop_xwayland_interface *xi =
> +   wm->server->compositor->xwayland_interface;
> xcb_configure_notify_event_t *configure_notify =
> (xcb_configure_notify_event_t *) event;
> -   struct weston_wm_window *window;
> +   struct weston_wm_window *window, *w, *next;
>
> wm_log("XCB_CONFIGURE_NOTIFY (window %d) %d,%d @ %dx%d%s\n",
>configure_notify->window,
> @@ -760,6 +763,16 @@ weston_wm_handle_configure_notify(struct weston_wm
> *wm, xcb_generic_event_t *eve
> if (window->frame)
> frame_resize_inside(window->frame,
> window->width, window->height);
> +   if (window->x != 0 || window->y != 0) {
> +   wl_list_for_each_safe(w, next,
> >or_window_list, or_link) {
> +   if (w == window) {
> +   if (w->shsurf)
> +
>  xi->set_xwayland(w->shsurf, w->x, w->y);
> +   wl_list_remove(>or_link);
> +   break;
> +   }
> +   }
> +   }
> }
>  }
>
> @@ -2478,6 +2491,7 @@ weston_wm_create(struct weston_xserver *wxs, int fd)
> wl_signal_add(>compositor->kill_signal,
>   >kill_listener);
> wl_list_init(>unpaired_window_list);
> +   wl_list_init(>or_window_list);
>
> weston_wm_create_cursors(wm);
> weston_wm_window_set_cursor(wm, wm->screen->root,
> XWM_CURSOR_LEFT_PTR);
> @@ -2761,8 +2775,11 @@ xserver_map_shell_surface(struct weston_wm_window
> *window,
>
>  window->legacy_fullscreen_output.output);
> return;
> } else if (window->override_redirect) {
> -   xwayland_interface->set_xwayland(window->shsurf,
> -window->x, window->y);
> +   if (window->x == 0 && window->y == 0)
> +   wl_list_insert(>or_window_list,
> >or_link);
> +   else
> +   xwayland_interface->set_xwayland(window->shsurf,
> +
>  window->x, window->y);
> } else if (window->transient_for && window->transient_for->surface)
> {
> parent = window->transient_for;
> if (weston_wm_window_type_inactive(window)) {
> diff --git a/xwayland/xwayland.h b/xwayland/xwayland.h
> index ca75f5b..54e8908 100644
> --- a/xwayland/xwayland.h
> +++ b/xwayland/xwayland.h
> @@ -72,6 +72,7 @@ struct weston_wm {
> struct wl_listener activate_listener;
> struct wl_listener kill_listener;
> struct wl_list unpaired_window_list;
> +   struct wl_list or_window_list;
>
> xcb_window_t selection_window;
> xcb_window_t selection_owner;
> --
> 2.7.4
>
>

The problem fixed by this patch is also fixed with
https://lists.freedesktop.org/archives/wayland-devel/2017-June/034357.html
which is a much cleaner solution.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 2/3] xwayland: Shape window region to clip shadow area from input

[Scott Moreau]

Decorated windows were getting the size of the window including the
shadow which is correct, but causing some confusion for motion input
events. This was exhibited when one xwayland window overlaps another,
hovering over the window beneath recieves no events if within the 32
pixel shadow border area of the window above.
---
 xwayland/window-manager.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 1663ad0..951a7cf 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -954,6 +954,8 @@ static void
 weston_wm_window_create_frame(struct weston_wm_window *window)
 {
struct weston_wm *wm = window->wm;
+   struct theme *t = window->wm->theme;
+   xcb_rectangle_t rect;
uint32_t values[3];
int x, y, width, height;
int buttons = FRAME_BUTTON_CLOSE;
@@ -1009,6 +1011,15 @@ weston_wm_window_create_frame(struct weston_wm_window 
*window)
 >format_rgba,
 width, height);
 
+   rect.x = t->margin;
+   rect.y = t->margin;
+   rect.width = width - t->margin * 2;
+   rect.height = height - t->margin * 2;
+
+   xcb_shape_rectangles(wm->conn,
+   XCB_SHAPE_SO_SET, 
XCB_SHAPE_SK_INPUT,
+   0, window->frame_id, 0, 0, 1, 
);
+
hash_table_insert(wm->window_hash, window->frame_id, window);
 }
 
-- 
2.7.4

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

[PATCH 3/3] xwayland: Fix override redirect window positioning

[Scott Moreau]

When override redirect windows are created, the x/y offsets
provided at map time may be incorrect. The correct offsets are
sent in a configure event from the xserver some time later.
Here we fix the positions by delaying the call to set_xwayland()
from map time to the needed configure event in the case where x/y
are both 0 for override redirect windows.
---
 xwayland/window-manager.c | 23 ---
 xwayland/xwayland.h   |  1 +
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 951a7cf..2e61ea4 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -169,6 +169,7 @@ struct weston_wm_window {
int maximized_horz;
struct wm_size_hints size_hints;
struct motif_wm_hints motif_hints;
+   struct wl_list or_link;
struct wl_list link;
 };
 
@@ -737,9 +738,11 @@ our_resource(struct weston_wm *wm, uint32_t id)
 static void
 weston_wm_handle_configure_notify(struct weston_wm *wm, xcb_generic_event_t 
*event)
 {
+   const struct weston_desktop_xwayland_interface *xi =
+   wm->server->compositor->xwayland_interface;
xcb_configure_notify_event_t *configure_notify =
(xcb_configure_notify_event_t *) event;
-   struct weston_wm_window *window;
+   struct weston_wm_window *window, *w, *next;
 
wm_log("XCB_CONFIGURE_NOTIFY (window %d) %d,%d @ %dx%d%s\n",
   configure_notify->window,
@@ -760,6 +763,16 @@ weston_wm_handle_configure_notify(struct weston_wm *wm, 
xcb_generic_event_t *eve
if (window->frame)
frame_resize_inside(window->frame,
window->width, window->height);
+   if (window->x != 0 || window->y != 0) {
+   wl_list_for_each_safe(w, next, >or_window_list, 
or_link) {
+   if (w == window) {
+   if (w->shsurf)
+   xi->set_xwayland(w->shsurf, 
w->x, w->y);
+   wl_list_remove(>or_link);
+   break;
+   }
+   }
+   }
}
 }
 
@@ -2478,6 +2491,7 @@ weston_wm_create(struct weston_xserver *wxs, int fd)
wl_signal_add(>compositor->kill_signal,
  >kill_listener);
wl_list_init(>unpaired_window_list);
+   wl_list_init(>or_window_list);
 
weston_wm_create_cursors(wm);
weston_wm_window_set_cursor(wm, wm->screen->root, XWM_CURSOR_LEFT_PTR);
@@ -2761,8 +2775,11 @@ xserver_map_shell_surface(struct weston_wm_window 
*window,
   
window->legacy_fullscreen_output.output);
return;
} else if (window->override_redirect) {
-   xwayland_interface->set_xwayland(window->shsurf,
-window->x, window->y);
+   if (window->x == 0 && window->y == 0)
+   wl_list_insert(>or_window_list, >or_link);
+   else
+   xwayland_interface->set_xwayland(window->shsurf,
+   
window->x, window->y);
} else if (window->transient_for && window->transient_for->surface) {
parent = window->transient_for;
if (weston_wm_window_type_inactive(window)) {
diff --git a/xwayland/xwayland.h b/xwayland/xwayland.h
index ca75f5b..54e8908 100644
--- a/xwayland/xwayland.h
+++ b/xwayland/xwayland.h
@@ -72,6 +72,7 @@ struct weston_wm {
struct wl_listener activate_listener;
struct wl_listener kill_listener;
struct wl_list unpaired_window_list;
+   struct wl_list or_window_list;
 
xcb_window_t selection_window;
xcb_window_t selection_owner;
-- 
2.7.4

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

[PATCH 1/3] xwayland: Fix input coordinates of non-decorated windows

[Scott Moreau]

Windows without decorations drawn by the xwayland window manager had
wrong input coordinates because weston_wm_window_get_child_position was
giving wrong x/y offsets. Set the offsets to 0 for windows without
system decorations.
---
 xwayland/window-manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 2500853..1663ad0 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -628,7 +628,7 @@ weston_wm_window_get_child_position(struct weston_wm_window 
*window,
 {
struct theme *t = window->wm->theme;
 
-   if (window->fullscreen) {
+   if (window->fullscreen || (!window->decorate && !window->frame)) {
*x = 0;
*y = 0;
} else if (window->decorate && window->frame) {
-- 
2.7.4

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

Re: [PATCH] xwayland: Fix input coordinates of shadowless CSD windows

[Scott Moreau]

On Thu, May 18, 2017 at 6:26 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:

> On Tue,  2 May 2017 10:24:17 -0600
> Scott Moreau <ore...@gmail.com> wrote:
>
> > This fixes wrong input coordinates when using clients like steam,
> > that draw their own decorations and have no shadows.
> > ---
> >  xwayland/window-manager.c | 30 +-
> >  1 file changed, 17 insertions(+), 13 deletions(-)
> >
> > diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> > index 2608075..7cb60d1 100644
> > --- a/xwayland/window-manager.c
> > +++ b/xwayland/window-manager.c
> > @@ -610,15 +610,17 @@ weston_wm_window_get_frame_size(struct
> weston_wm_window *window,
> >  {
> >   struct theme *t = window->wm->theme;
> >
> > - if (window->fullscreen) {
> > + if (window->decorate) {
> > + if (window->frame) {
> > + *width = frame_width(window->frame);
> > + *height = frame_height(window->frame);
> > + } else {
> > + *width = window->width + t->margin * 2;
> > + *height = window->height + t->margin * 2;
> > + }
> > + } else {
> >   *width = window->width;
> >   *height = window->height;
> > - } else if (window->decorate && window->frame) {
> > - *width = frame_width(window->frame);
> > - *height = frame_height(window->frame);
> > - } else {
> > - *width = window->width + t->margin * 2;
> > - *height = window->height + t->margin * 2;
> >   }
> >  }
> >
> > @@ -628,14 +630,16 @@ weston_wm_window_get_child_position(struct
> weston_wm_window *window,
> >  {
> >   struct theme *t = window->wm->theme;
> >
> > - if (window->fullscreen) {
> > + if (window->decorate) {
> > + if (window->frame)
> > + frame_interior(window->frame, x, y, NULL, NULL);
> > + else {
> > + *x = t->margin;
> > + *y = t->margin;
> > + }
> > + } else {
> >   *x = 0;
> >   *y = 0;
> > - } else if (window->decorate && window->frame) {
> > - frame_interior(window->frame, x, y, NULL, NULL);
> > - } else {
> > - *x = t->margin;
> > - *y = t->margin;
> >   }
> >  }
> >
>
> Hi Scott,
>
> thanks for this, the handling of non-decorated, non-fullscreen, non-OR
> windows has probably been broken for a good while if not forever.
>

Hi Pekka,

Thanks for the review.


>
> I tested with google-chrome-browser as that's what I had at hand, both
> with and without system decorations. Without system decorations, this
> patch indeed fixes both the input region (the shadow area was not
> click-through as it should have been) and removes shadows (that I
> assume should not have been there).
>

I'm glad you mentioned this because I hadn't noticed, but this patch wasn't
intended to remove decorations. I have a few other patches I'll submit soon
to fix the input offset problem as well as a couple others I noticed.
Hopefully they fix the input region for things like google-chrome shadow
area problem as you describe.


>
> Is the above exactly what you wanted to say in the commit message, or
> did Steam really get wrong input coordinates, i.e. clicks were off also
> inside the window?
>

The commit message is poor at best; I've updated commit messages in the new
patches.


>
> Does this patch remove unwanted shadows from Steam or was Steam without
> shadows to begin with?
>

It's not meant to remove any shadows. The new patch doesn't adjust size at
all.


>
> The commit message is a little ambiguous on these terms, so I'd like
> (someone) to re-word it.
>
> When using system decorations in Chrome, the decorations look and work
> just fine also after the patch.
>

The thing that doesn't work is toggling the system decoration switch
without having to restart chrome. Also as a side note, moving a window from
its original starting position causes override redirect windows to be
placed as if the window were never moved.


>
> Maximizing xterm works ok.
>
> I'm a little worried about removing the checks for window->fullscreen,
> because e.g. weston_wm_window_draw_decoration() looks at
> window->fullscreen and does nothing. It would feel more logical for
> draw_

[PATCH] xwayland: Fix input coordinates of shadowless CSD windows

[Scott Moreau]

This fixes wrong input coordinates when using clients like steam,
that draw their own decorations and have no shadows.
---
 xwayland/window-manager.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 2608075..7cb60d1 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -610,15 +610,17 @@ weston_wm_window_get_frame_size(struct weston_wm_window 
*window,
 {
struct theme *t = window->wm->theme;
 
-   if (window->fullscreen) {
+   if (window->decorate) {
+   if (window->frame) {
+   *width = frame_width(window->frame);
+   *height = frame_height(window->frame);
+   } else {
+   *width = window->width + t->margin * 2;
+   *height = window->height + t->margin * 2;
+   }
+   } else {
*width = window->width;
*height = window->height;
-   } else if (window->decorate && window->frame) {
-   *width = frame_width(window->frame);
-   *height = frame_height(window->frame);
-   } else {
-   *width = window->width + t->margin * 2;
-   *height = window->height + t->margin * 2;
}
 }
 
@@ -628,14 +630,16 @@ weston_wm_window_get_child_position(struct 
weston_wm_window *window,
 {
struct theme *t = window->wm->theme;
 
-   if (window->fullscreen) {
+   if (window->decorate) {
+   if (window->frame)
+   frame_interior(window->frame, x, y, NULL, NULL);
+   else {
+   *x = t->margin;
+   *y = t->margin;
+   }
+   } else {
*x = 0;
*y = 0;
-   } else if (window->decorate && window->frame) {
-   frame_interior(window->frame, x, y, NULL, NULL);
-   } else {
-   *x = t->margin;
-   *y = t->margin;
}
 }
 
-- 
2.7.4

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

[PATCH 1/2] Restore zoom-follows-text-cursor functionality

[Scott Moreau]

This restores the functionality removed by a7af70436. It demonstrates
text-cursor-position protocol that can be seen when typing in
weston-terminal while zoomed in.
---
 desktop-shell/shell.c  |   3 +-
 libweston/compositor.c |   2 +-
 libweston/compositor.h |  18 +++-
 libweston/zoom.c   | 118 +++--
 4 files changed, 134 insertions(+), 7 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f1577c1..429360a 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3404,7 +3404,7 @@ do_zoom(struct weston_seat *seat, uint32_t time, uint32_t 
key, uint32_t axis,
 
output->zoom.spring_z.target = output->zoom.level;
 
-   weston_output_update_zoom(output);
+   weston_output_update_zoom(output, ZOOM_FOCUS_POINTER);
}
}
 }
@@ -5032,6 +5032,7 @@ wet_shell_init(struct weston_compositor *ec,
wl_signal_add(>output_resized_signal, >resized_listener);
 
screenshooter_create(ec);
+   text_cursor_position_notifier_create(ec);
 
shell_add_bindings(ec, shell);
 
diff --git a/libweston/compositor.c b/libweston/compositor.c
index 2bca19c..fa82e60 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4349,7 +4349,7 @@ weston_output_update_matrix(struct weston_output *output)
 
if (output->zoom.active) {
magnification = 1 / (1 - output->zoom.spring_z.current);
-   weston_output_update_zoom(output);
+   weston_output_update_zoom(output, ZOOM_FOCUS_CURRENT);
weston_matrix_translate(>matrix, -output->zoom.trans_x,
-output->zoom.trans_y, 0);
weston_matrix_scale(>matrix, magnification,
diff --git a/libweston/compositor.h b/libweston/compositor.h
index 6070c77..07ab616 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -123,8 +123,15 @@ struct weston_spring {
uint32_t clip;
 };
 
+enum {
+   ZOOM_FOCUS_CURRENT,
+   ZOOM_FOCUS_POINTER,
+   ZOOM_FOCUS_TEXT
+};
+
 struct weston_output_zoom {
bool active;
+   uint32_t type;
float increment;
float level;
float max_level;
@@ -132,6 +139,9 @@ struct weston_output_zoom {
struct {
double x, y;
} current;
+   struct {
+   double x, y;
+   } text_cursor;
struct weston_seat *seat;
struct weston_animation animation_z;
struct weston_spring spring_z;
@@ -1705,11 +1715,14 @@ weston_compositor_exit_with_code(struct 
weston_compositor *compositor,
 void
 weston_output_init_zoom(struct weston_output *output);
 void
-weston_output_update_zoom(struct weston_output *output);
+weston_output_update_zoom(struct weston_output *output, uint32_t type);
 void
 weston_output_activate_zoom(struct weston_output *output,
struct weston_seat *seat);
 void
+weston_text_cursor_position_notify(struct weston_surface *surface,
+   wl_fixed_t x, wl_fixed_t y);
+void
 weston_output_update_matrix(struct weston_output *output);
 void
 weston_output_move(struct weston_output *output, int x, int y);
@@ -1805,6 +1818,9 @@ weston_recorder_stop(struct weston_recorder *recorder);
 struct clipboard *
 clipboard_create(struct weston_seat *seat);
 
+void
+text_cursor_position_notifier_create(struct weston_compositor *ec);
+
 struct weston_view_animation;
 typedefvoid (*weston_view_animation_done_func_t)(struct 
weston_view_animation *animation, void *data);
 
diff --git a/libweston/zoom.c b/libweston/zoom.c
index a1a1ab2..d3a2f55 100644
--- a/libweston/zoom.c
+++ b/libweston/zoom.c
@@ -34,6 +34,106 @@
 #include "text-cursor-position-server-protocol.h"
 #include "shared/helpers.h"
 
+
+struct text_cursor_position {
+   struct weston_compositor *ec;
+   struct wl_global *global;
+   struct wl_listener destroy_listener;
+};
+
+static void
+text_cursor_position_notify(struct wl_client *client,
+   struct wl_resource *resource,
+   struct wl_resource *surface_resource,
+   wl_fixed_t x, wl_fixed_t y)
+{
+   struct weston_surface *surface =
+   wl_resource_get_user_data(surface_resource);
+
+   weston_text_cursor_position_notify(surface, x, y);
+}
+
+struct text_cursor_position_interface text_cursor_position_implementation = {
+   text_cursor_position_notify
+};
+
+static void
+bind_text_cursor_position(struct wl_client *client,
+void *data, uint32_t version, uint32_t id)
+{
+   struct wl_resource *resource;
+
+   resource = wl_resource_create(client,
+ _cursor_position_interface, 1, id);
+   if (resource)
+   wl_resource_set_implementation(resource,
+  

Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

[Scott Moreau]

:

Kristian, I want you to know that I think you are an incredible
developer and I have nothing but respect for you and all of your
works. I hope you understand that this is nothing *against* anyone or
anything, instead it's *for* everyone and everything. I also would
like to see you embrace these efforts and offer suggestions for things
you might like to see in weston. The community is a powerful resource
that should not be neglected. I would like this to be accepted as a
friendly effort to help make weston more fun to use, but first, usable
at all. So all things said, let the games begin! :-)

QA:

Q: Wont this cause more diversity in the community?
A: I hope not significantly. It will provide an outlet for some and
might possibly cause some minor disruptions. This is mostly an
underground project at this point so it's actual effects are TBD. The
important part is, that the code will be developed with a future
re-merge in mind. It will not diverge into using any driver
implementation other than the one wayland uses. Perhaps it will come
to stand on its own as a new wayland compositor, but not a new core
protocol as is the case with Mir.

Q: Why can't you just work on things in your repositories and submit
them to the mailing list when they are ready?
A: This is what I've been doing for the past several months and it
works, except when the patches remain stagnant after hitting the list.
Basically, there are a few(+) things needed to get weston/norwood fit
for everyday usage. Weston's intent is not that of a Desktop
Environment but it really already is, save a little polish and
finishing touches.

Q: Why are you going against wayland devs?
A: We're not. This projects' goals are about forwarding the wayland
project as a whole.

Q: But why are you doing this at all?
A: Several reasons. 1) It's a fun project 2) It might cause useful
things to happen 3) It might help give me a taste of what project
management feels like 4) Linus Torvalds wants to see Linux take over
the Desktop platform as the understood worldwide default operating
system. We are never going to get there if our desktop sucks.

Q: Are you nuts?
A: Yes, I am a little crazy. But you need to be in order to be
interested in compositing environments at the level I am.



I would like to thank all the developers involved and the core
community that represents the greater good force in the world, for
making this possible.



Sincerely,

Scott Moreau
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

[Scott Moreau]

Hi Casey,

On Mon, Mar 25, 2013 at 12:00 PM, Casey Dahlin cdah...@redhat.com wrote:
 On Mon, Mar 25, 2013 at 02:43:27AM -0600, Scott Moreau wrote:
 What Northfield *is not*
 - A fork that will change protocol in fundamental ways that diverts
 from the wayland EGL spec
 - A project that aims to cause divisions in the community or the Linux
 Desktop code
 - A project that breaks core wayland protocol in unrepairable ways
 - Diverting significantly from wayland
 - An unfriendly 'takeover'
 - Unnecessary

 The key point to understand is, that this is not a new protocol in its
 own right. It *is* the wayland protocol, with a few minor additions
 that make it possible to do new interesting things. It uses the same
 EGL drivers in Mesa implementing the wayland-egl specification. This
 will not change. Northfield will always use the same driver stack as
 wayland. The difference is, that I now have the time to dedicate to
 being a (hopefully very) responsive maintainer.


 Then fork Weston and leave Wayland alone.

 More and different and better compositors have always been expected. Forking
 the wayland libs itself is just creating confusion and giving yourself the
 opportunity to break the protocol (which is extensible by default, and Weston
 already adds features to it).

 This is just making a mess after Canonical has already confused things with
 Mir. I'm already cringing at the thought of how Phoronix is going to cover 
 this.

 --CJD

I know the post is long winded, but please read it in its entirety
before jumping to conclusions. These excerpts from the original post
should have alleviated your concern:

The key point to understand is, that this is not a new protocol in its
own right. It *is* the wayland protocol, with a few minor additions
that make it possible to do new interesting things.

What Northfield *is not*
- A fork that will change protocol in fundamental ways that diverts
from the wayland EGL spec
- A project that aims to cause divisions in the community or the Linux
Desktop code
- A project that breaks core wayland protocol in unrepairable ways
- Diverting significantly from wayland

Perhaps it will come
to stand on its own as a new wayland compositor, but not a new core
protocol as is the case with Mir.


Thanks,

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

Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

[Scott Moreau]

Hey Casey,

On Mon, Mar 25, 2013 at 12:46 PM, Casey Dahlin cdah...@redhat.com wrote:
 On Mon, Mar 25, 2013 at 12:41:59PM -0600, Scott Moreau wrote:
 The key point to understand is, that this is not a new protocol in its
 own right. It *is* the wayland protocol, with a few minor additions
 that make it possible to do new interesting things.

 Then don't fork the library.

I did not want to call it a fork since I don't feel that it is.
However, I have now changed the name and announced it as a fork at
Kristian's request.


 A few minor additions can exist outside the codebase. Hell, all of the shell
 protocol exists outside the wayland codebase. All of THE DRM CODE exists
 outside of the wayland codebase.

 If what you say is true about not forking the protocol then there is NO reason
 to fork libwayland.

 --CJD

Yes, there is no reason to fork libwayland. And I don't feel this is a
true fork, just a temporary rename to avoid the confusion it might
otherwise cause, remaining under the 'wayland' name. Wayland has been
in my github repo since I've uploaded it there. The only difference
now is, the name has been changed and an official fork announcement
has been made by request.

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

Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

[Scott Moreau]

On Mon, Mar 25, 2013 at 1:11 PM, Casey Dahlin cdah...@redhat.com wrote:
 On Mon, Mar 25, 2013 at 12:59:22PM -0600, Scott Moreau wrote:
 Hi Casey,

 On Mon, Mar 25, 2013 at 12:53 PM, Casey Dahlin cdah...@redhat.com wrote:
  On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote:
  Yes, there is no reason to fork libwayland. And I don't feel this is a
  true fork, just a temporary rename to avoid the confusion it might
  otherwise cause, remaining under the 'wayland' name. Wayland has been
  in my github repo since I've uploaded it there. The only difference
  now is, the name has been changed and an official fork announcement
  has been made by request.
 
  ...ok. I'll leave how exactly that's less confusing as an exercise to the
  reader.
 
  Seriously, if you'd just forked Weston and left Wayland alone I'd be on 
  your
  side. Even happy. This, however, is just making a political mess.
 
  --CJD

 I'm not sure where the confusion is. Northfield == Wayland but with a
 few changes to wl_shell_surface interface for minimize/maximize/close
 stuff. These changes are actually being discussed on the mailing list
 for possible review and inclusion. Once these basic events/requests go
 upstream, there will not be a need for northfield as a patched version
 of wayland. In reality, this is just a project name that !wayland. The
 need for this custom libwayland is only necessary until the new
 protocol is pushed upstream at which point, this need should be
 eliminated.


 Shell surface was in weston for awhile. Why not just wl_new_shell_surface in
 your forked weston's protocol extensions?

 --CJD

There are multiple parts to the shell in the code. You have the core
protocol in wayland, weston's shell plugin and the desktop-shell
client also in weston. The wl_shell_surface is somewhat of a catch-all
interface for any client that wants to display its surface in a
wayland compositor. In order to do basic features such as move,
resize, maximize, minimize, etc you need certain event/requests, often
times in pairs. Currently, maximize is in core wayland
wl_shell_surface interface protocol and it only makes sense, to put
minimize in the same place as maximize, in the code. You could do it
as a local weston protocol and have clients connect to this, yes.
However, this is a core desktop functionality and belongs in the core.
Also, more work would be required to move the code from weston to
wayland. The amount of work is negligible but it still has to be done.
This could possibly be error prone. Also, the discussion about this
protocol should be done in the light and realization by all, that this
is in fact a core functionality and an expected part of todays desktop
functionality per specs. However, I think you're not seeing the bigger
picture here, so please allow me to explain a bit.

There are certain implications that we've had with X that make it very
difficult to do certain things in a compositing manager for X. For
example, Sam Spilsbury was one of the very first people to try and get
input redirection (IR) work in X, under compiz. He worked very
diligently with IRL colleague Joel Bosveld to try and convince X to
fake certain input events so that you could use a transformed surface.
See http://www.youtube.com/watch?v=YHEisy-ORvY and take note of the
date. This is extremely problematic in X, yet I think people don't
realize that we've never been able to do IR properly in X. There are
other things that wayland makes far simpler than the X+compiz model.
Yet, we still have the same capabilities.

It is noteworthy here, that not only did Sam Spilsbury work on IR, but
we also worked on a ton of other cool things for compiz, including a
Head Tracking plugin when wiimotes first came out
http://www.youtube.com/watch?v=5M7ejHp2NM8 again, notice the date. Sam
Spilbury pushed compiz forward immensely and drove compiz development
with massive contribution including but not limited to:

- Awesome Compiz Videos
These videos were not particularly easy to shoot. It was not as easy
as it is today with weston's built-in wcap recorder. You'd have to 1)
Acquire the right hardware. 2) Install your drivers. This could be
absolute nightmare depending on whether or not you needed XGL and what
hardware you had. 3) Install compiz/beryl. Even with the code
installed, documentation was scarce and developers had to figure
things out for themselves. 3) Shoot the video. There was a special
vidcap recorder plugin introduced in Beryl that allowed shooting a
video (even with optional watermark image). He would do all editing to
make the video stellar as an advertisement
https://www.youtube.com/user/smSpillaz/videos?query=compiz
- Driving Development
He single handedly drove development by keeping the channels alive,
upbeat and active, asking all of the pertinent thought provoking
questions and submitting countless patches and ideas.
- Countless Plugins
Sam also wrote tons of plugins, some of which can be seen here
http://cgit.compiz.org

Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

[Scott Moreau]

 Casey: The point is, this isn't just a frivolous fork. This isn't
 about wayland.

Sorry, I misspoke here. What I meant was, This isn't about the
wayland core protocol, the core wayland developers have this part
covered. This is about raising the bar on the effects users expect to
see in a wayland compositor and thus, forwarding wayland indirectly as
Beryl did with Compiz.

 It's about focusing the energy of a collective group of
 people who want to see and do cool things on the Linux Desktop.

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

Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

[Scott Moreau]

On Mon, Mar 25, 2013 at 3:08 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
 On segunda-feira, 25 de março de 2013 14.45.21, Scott Moreau wrote:
 Northfield stands on the shoulders of giants, years worth of work and
 history to get to the point where we are today. It has been some 8
 years since compiz has exposed these many restrictions found in X
 protocol. We want certain effects to be readily possible and are not
 inherently restricted by certain caveats of the display server
 protocol. I expect that wayland core protocol will be added to support
 the basic functionalities expected as part of todays Linux Desktop. I
 believe that there wont be any problems with this particular effect
 and others. However, I want to make absolutely sure of that.

 Scott,

 What we're asking is that you avoid forking Wayland at all. Don't change the
 library, don't change the default extensions (including wl_shell), don't add
 new default extensions. You said you want to avoid incompatible changes: well,
 avoiding the fork also avoids the temptation.

 Try to do your changes in a different extension. Copy the current wl_shell 
 into
 a new one and modify it to your heart's desire. If, at the end of your
 experiment, you conclude that the current wl_shell is flawed by design, then
 Wayland should deprecate it and adopt yours. On the other hand, if we conclude
 that your improvements can be added incrementally, we can simply do exactly
 that.

This sounds great but this is not the solution I have come up with.


 I'll ping you on IRC to discuss this. Several people have asked you to do it
 and you have either missed the point or failed to explain to us why the fork
 is necessary.

 PS: compiz is also a bad example. It might have been a great experiment and
 resulted in improvements in most existing WMs, but it was a horrible WM. It
 had bugs with its core WM functionality that went unfixed for years.

I think compiz is in fact the very model example of what a compositing
manager for the Linux Desktop should be. Yes, it has had many bugs
over the years but many of these are because the X protocol is
extremely difficult to work with and inherently problematic. We can do
the same things now, but this time, uninhibited, thanks to the driver
situation. I am sorry that you feel this is unnecessary but I
disagree.

- Scott


 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center

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

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

Scott Moreau Banned From Official Wayland IRC Channel

[Scott Moreau]

I wanted to make it public, that I have been officially banned from
#wayland on irc.frenode.net by krh. I have never seen him ban anyone
from his channel and I do not believe he has any intention of lifting
the ban.
This goes to show, that my efforts are in fact completely unwelcome by
Kristian. I was hoping that we could work things out from the start,
but maybe over time things will work themselves out.


Thanks,

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

Re: Scott Moreau Banned From Official Wayland IRC Channel

[Scott Moreau]

On Mon, Mar 25, 2013 at 4:34 PM, Dave Airlie airl...@gmail.com wrote:
 On Tue, Mar 26, 2013 at 8:10 AM, Scott Moreau ore...@gmail.com wrote:
 I wanted to make it public, that I have been officially banned from
 #wayland on irc.frenode.net by krh. I have never seen him ban anyone
 from his channel and I do not believe he has any intention of lifting
 the ban.
 This goes to show, that my efforts are in fact completely unwelcome by
 Kristian. I was hoping that we could work things out from the start,
 but maybe over time things will work themselves out.


 Can you unsubscribe from the mailing list as well?

 Dave.

May I ask why it is you're making this request?

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

GH-Next Feature Update

[Scott Moreau]

Hi all,

I announced about a week ago that I was starting a series of branches
on github labeled next, as a staging area for new features and patch
sets. The response is continually surprising and we've got a lot done
in just one week. I wanted to share an update with everyone and
explain a little more about the purposes behind my efforts.

So we all know wayland is awesome because it allows ways to use the
new Linux graphics driver stack to its full potential. This is
exciting for several reasons. It means 1) an alternative to X 2) a
potentially faster and smoother desktop experience 3) a possibility
for more interesting effects. It is interesting for technical
audiences and users alike. Until now, we haven't known any capable
display server on Linux except X. Accelerated compositing has become
the expected norm since Compiz. With that, I'd like to introduce some
history.

We all know X has been around and it's X. It has served as the de
facto standard Linux display server for many years. It has also served
as a fertile bed for exciting projects, one of most important being
Compiz.

Before compiz, there was just X and some window managers. Around 2004,
Novell contracted David Reveman to begin work on what we know today as
compiz. In order to do what was required for compiz as an X window
manager, a new extension was introduced called
GLX_EXT_texture_from_pixmap. This is the key spec used to make compiz
magic happen. During early developments, the community was bursting
with excitement to see and and play with these newly conceived
features. Unfortunately, Reveman was not easy to communicate with and
soon the project was forked under the name Beryl. This was an exciting
time because not only were there new possibilities never before seen
in X but now there was a rather large flamewar driving Beryl and
Compiz development. Compiz was all about the core initially, while
Beryl exhibited more fun and candy features. In fact, a large majority
of the many compiz plugins we all know and love today were developed
under the Beryl project. After flaming for a long time, finally the
two sides came to terms and the two projects were merged as
compiz-fusion. Today, only a select few remember Beryl but it's legacy
lives on through the code that was ultimately adopted by the compiz
project. After this happened in about '06-'07, the compiz-fusion
developers maintained the project and distributions packaged it. It
has been a great success for many years. Many people have written
their own plugins for compiz, some of them never published.

With compiz, there were some interesting doors opened. This revealed
certain possibilities that may have not otherwise been considered.
This also revealed many bugs in X, some still standing, like the input
redirection problem. Now today, we have wayland. The problem is the
same as it was with Compiz. The community wants to play with the toys
and make new ones now, while most of the core developers want to work
mainly on core and not flesh out 'the rest of it'. I have been
studying compiz ever since it first came out. I've helped on the
project but I also listened to many users. I noticed that you can't
possibly satisfy every possible case but you can make good guesses and
put the user in control where appropriate. I think Compiz does a
pretty good job of this, all things considered. These are some things
I noticed through working on compiz:

- People get really excited by eye candy and visuals
- The community is a much more powerful force than given credit for
- X was not built for accelerated compositing managers

Now today, we have a more interesting situation. With compiz and
beryl, it didn't matter what or which, because everything just uses X
'as normal'. However today, we have the same problem of the community
ready to move forward to make some interesting toys. It was fine
because X protocol was already vetted and no changes were required to
existing X clients. However with today's situation, it's different.
The protocol is most certainly not vetted, largely incomplete and
doesn't have basic items you'd expect to use for any reasonably sane,
usable implementation. A random example is minimize effect animation.
How can you program this type of effect, when the protocol to minimize
does not exist yet? Pretty difficult. Wayland is awesome at the core
but the protocol to do everyday desktop stuff is lacking at best. The
community wants to move forward but development is taking too long.
Everyone would like to see everyone else agree with everyone but..
when's the last time that ever happened? So, gh next is going to sort
of 'run ahead' and see what we can do and what problems we uncover in
the process. I've done enough fighting over the past year to get basic
protocol upstream to wayland core and it's time to move forward.
Anyone interested in discussing the wayland protocol and all the
semantic details can continue and try to figure out what is best for
wayland. Meanwhile, gh next 

Re: GH-Next Feature Update

[Scott Moreau]

Hi Daniels,

On Sun, Mar 24, 2013 at 5:13 AM, Daniel Stone dan...@fooishbar.org wrote:
 On 24 March 2013 10:27, Scott Moreau ore...@gmail.com wrote:

 - Working xwayland titlebar buttons


 Did that patchset get submitted to the list for review? If not, will it be?

No. These patches breaks many of the core goals of wayland/weston with
DE-like features.

krh weston isn't going to be a full DE, starting a new DE is
specifically a non-goal of wayland
krh and I've always said that fleshing out wl_shell will have to
wait until we have at least one real DE to driver the work
krh otherwise it's all just going to be guesswork

So we're going to be doing a lot of guessing. As it turns out, the
best way to have a good idea is to have a lot of ideas. So we're going
to try and guess what some of the better ideas might be.

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

Re: GH-Next Feature Update

[Scott Moreau]

On Sun, Mar 24, 2013 at 6:17 AM, Daniel Stone dan...@fooishbar.org wrote:
 Hi,

 On 24 March 2013 11:29, Scott Moreau ore...@gmail.com wrote:

 On Sun, Mar 24, 2013 at 5:13 AM, Daniel Stone dan...@fooishbar.org
 wrote:
  On 24 March 2013 10:27, Scott Moreau ore...@gmail.com wrote:
  - Working xwayland titlebar buttons
 
  Did that patchset get submitted to the list for review? If not, will it
  be?

 No. These patches breaks many of the core goals of wayland/weston with
 DE-like features.

 krh weston isn't going to be a full DE, starting a new DE is
 specifically a non-goal of wayland
 krh and I've always said that fleshing out wl_shell will have to
 wait until we have at least one real DE to driver the work
 krh otherwise it's all just going to be guesswork

 So we're going to be doing a lot of guessing. As it turns out, the
 best way to have a good idea is to have a lot of ideas. So we're going
 to try and guess what some of the better ideas might be.


 I definitely don't see it that way, and without being able to speak for
 Kristian, I daresay he doesn't either.  There's a big gap between not
 wanting to start a competitor to GNOME, KDE, Enlightenment, XFCE, LXDE and
 the myriad other environments, and adding titlebar buttons to XWayland.  The
 example clients shipped with Weston have titlebar buttons, so I think it's
 fairly safe to say that a) extending the same support to X11 clients is a
 useful goal, and b) including titlebar buttons is clearly not a non-goal for
 Weston.

 Cheers,
 Daniel

Yea, these are seemingly basic features - titlebar buttons and
resizing top/left fixed. However I think X will be around for a long
time and xwayland should get a lot more attention. It's been
barely-unusable for far too long now. Also, reviewing my own code
thinking about everything Kristian has told me, he doesn't want these
hacky patches at all. I'm pretty sure the code horribly far less than
acceptable. Anyone is welcome to grab patches from gh and discuss them
or apply them wherever. I myself am not going to waste my time and
effort as I have done for the past several months, trying to get even
the simplest things pushed upstream. So even if these patches were
acceptable, I don't have plans to put forth a large amount of effort
to see them upstream. If you want the code, great. It's FOSS, grab it.
The general point here is, I don't really plan on going to be making
special time to bug upstream anymore because my efforts so far have
been shunned, shot down, trolled and ultimately,
less-than-appreciated. It's been a year, now I've had enough of the
nonsense.

I would like to thank Community member Martin Minarik for putting
forth the original effort with his titlebar button implementation, on
which xwm buttons are based. Thanks min2 for all your work and
continued contributions.


Thanks,

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

Re: GH-Next Feature Update

[Scott Moreau]

On Sun, Mar 24, 2013 at 9:00 AM, Jonas Kulla nyocu...@gmail.com wrote:
 2013/3/24 Scott Moreau ore...@gmail.com



 Hi,

 the video you uploaded is blocked in Germany due to music related copyright
 stuff.
 Is there any way you could upload it without that music? I'd really like to
 see it! Thanks.

 Jonas

Wow really? That is completely ridiculous. In what world do we live,
where everyone just accepts to be told what music to listen to and in
what country it's 'ok' to listen to it? Eyes were designed for sight,
ears for sound. This crazy messed up world is designed to waste as
much of people's time as possible. Here, see if this will work
http://www.speedyshare.com/aSR5G/weston-feature-updates-2m.h264 Sorry
about that.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: GH-Next Feature Update

[Scott Moreau]

Hi Daniels,


 OK, I guess it's no longer Wayland/Weston then (in which case the repo  IRC
 channel names are pretty misleading - if you don't plan on submitting
 anything, it's hard to see how it could be 'next').

Yes, I am not very content with this either. The very initial goal was
simply to start #wayland-dev to give a place for the core wayland
developers to have a 'quiet place' where they could get to know one
another better and focus on protocol specific semantic details.
Unfortunately, this channel was deemed unnecessary by Kristian, so
many have also rejected it as being useful or serving any purpose.

 Shame, but oh well.
 Next time I get some time to poke at XWayland I'll try to dig through your
 fork and try to work out which patches are relevant, and hope I don't miss
 any patches.

Yea, it's kinda intermingled with other new ideas too. When I started
on wayland one year ago, one of my goals was to get enough protocol in
place to support basic compiz effects. Then I wanted to try
implementing more compiz-like features in weston. Unfortunately, my
plans have been stifled by lack of even the first building block to be
set in place. I don't really care what reasons there might be for slow
wayland development. I know there are plenty of valid real-world
reasons which are beyond anyone's control. This does not change the
fact that the community is and always has been ready to move forward.
We need basics on which to build and weston is just *right* there. It
just needs a little time, love and candy.


 Best of luck with it.

Thanks.


 Cheers,
 Daniel

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

Re: [PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

 protocol
but specifically, the implementation in weston is in fact important.
Again, not saying my solution is correct or absolute in any way, just
that we can't say 'let us make the protocol first, push it and then
figure out how or if it works, later'


 Finally, this is about the Wayland protocol, not the Weston protocol.
 This means that we don't just throw a bunch of undocumented
 events/requests into the protocol file, start implementing it in
 Weston, and document how we ended up implementing it.  That is exactly
 backwards of how the protocol should be developed.  I'm not saying
 that implementing it in Weston isn't useful for getting the kinks out.
  What I'm saying is that the protocol comes first and then we
 implement it to make sure it works.

I think that you are completely wrong here. We *definitely* want to
get new protocol in place and try it out. The policy of wayland/weston
has been, that when new protocol is added, the example implementations
are added to weston and other relevant components. As I explained, the
min/max descriptions were intentionally and thoughtfully left blank
because there is a whole lot involved for the expected desktop cases
and it's a touchy subject too. However, you don't have to overthink
this. The best solution is to add protocol for everyone, not just
isolating to the immediate use cases that you see and disregard
everyone elses ideas as unneeded/crazy.


 One more thing before I go onto the technical details: Bill Spitzak.
 Just because he gets on your nerves doesn't mean you should just
 ignore him.  You are very much into the implementation details whereas
 Bill tends to come at things from a perspective that is more
 high-level and theoretical.  This is a very useful perspective when
 discussing a protocol because the protocol should transcend the
 details as much as possible.  Bill does read the e-mails and he
 frequently points out potential pitfalls that other people miss.  He
 is also usually very clear in his examples (in his first e-mail in
 this series he drew you an ASCII-art picture to demonstrate what he
 meant).  You need to stop ignoring him and writing off everything he
 says as worthless.  At the very least you need to act towards him in a
 more professional manner.

Don't care about Bill. He doesn't contribute, he wastes time. You are
beginning to do the same thing by trolling me here. I really don't
appreciate it.


 Technical comments follow.

 On Fri, Mar 22, 2013 at 6:29 PM, Scott Moreau ore...@gmail.com wrote:
 Hi Pekka, thanks for your comments here.


 Scott,

 do you mean that these unminimize, unmaximize, etc. requests would
 actually work like undo? Unmaximize would undo what the last
 maximization did, as opposed to just set_normal which might do
 something slightly different since its aim is to make the window
 normal, not undo something?

 Right, I am asking if there is a case for such functionality. The more
 I think about it, it seems like it might seem like a bug in normal
 desktop usage. But if you happen to have another external program that
 you might want to use to manipulate window states, maybe you'd want a
 finer grain control there. I'm not sure of all the possible cases,
 which is why I'm asking for input.


 If so, does it make sense to have state specific undo requests?

 Consider this sequence, driven by the client:
 1. the window is normal
 2. maximize the window
 3. minimize the window
 4. unmaximize the window

 What happens at step 4? Is it possible to define the outcome of
 such cases in an intuitive way?

 This illustrates the point perfectly. This is definitely all about
 semantics and expected behavior. This must be clearly documented in
 the protocol description. I had it working so you could do this. You
 could minimize, toggle maximized state and unmaximize with the correct
 state. This works fine when doing
 maximize-minimize-unmaximize-unminimize but causes a frame glitch
 when doing unmaximize-minimize-maximize-unminimize. The frame
 glitch is probably easily worked around. However, it is noteworthy
 that if you have this behavior, then you can't assume that maximize
 and toplevel will be counterparts, but instead, that you'd need
 explicit unmaximize notification.

 The last thing we want is a protocol full of semantics and expected
 behaviour.  If implementing this correctly requires a lot of expected
 behaviour, we need to re-think the protocol.

 To solve this problem I suggested above that we simply replace all of
 the set_X and unset_X requests with set_X requests and one
 set_normal or whatever that returns to a default window state.  This
 way, instead of having to worry about what to set/unset to get to a
 desired state, the client simply tells the compositor what the next
 state should be.  In order to do things correctly, the client is going
 to have to track state anyway, so it might as well explicitly tell the
 compositor what state it wants next.  (This suggestion has gone
 completely

Re: [PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

Hi Pekka, thanks for your comments here.


 Scott,

 do you mean that these unminimize, unmaximize, etc. requests would
 actually work like undo? Unmaximize would undo what the last
 maximization did, as opposed to just set_normal which might do
 something slightly different since its aim is to make the window
 normal, not undo something?

Right, I am asking if there is a case for such functionality. The more
I think about it, it seems like it might seem like a bug in normal
desktop usage. But if you happen to have another external program that
you might want to use to manipulate window states, maybe you'd want a
finer grain control there. I'm not sure of all the possible cases,
which is why I'm asking for input.


 If so, does it make sense to have state specific undo requests?

 Consider this sequence, driven by the client:
 1. the window is normal
 2. maximize the window
 3. minimize the window
 4. unmaximize the window

 What happens at step 4? Is it possible to define the outcome of
 such cases in an intuitive way?

This illustrates the point perfectly. This is definitely all about
semantics and expected behavior. This must be clearly documented in
the protocol description. I had it working so you could do this. You
could minimize, toggle maximized state and unmaximize with the correct
state. This works fine when doing
maximize-minimize-unmaximize-unminimize but causes a frame glitch
when doing unmaximize-minimize-maximize-unminimize. The frame
glitch is probably easily worked around. However, it is noteworthy
that if you have this behavior, then you can't assume that maximize
and toplevel will be counterparts, but instead, that you'd need
explicit unmaximize notification.


 Does it ever make sense to send a unBAR when the previous operation
 was FOO, not BAR? Could you do with just one undo request for all
 the un* cases? (If not, why?)

 What if a client undoes twice? N times?

 Add this to the above sequence:
 5. unminimize the window

 Is the window now in normal state or maximized state?

Since this email, I have made it so you cannot toggle maximize while
in a minimized state. This is the way xfce works and it's reasonably
sane behavior.



 I'm thinking this purely from the compositor point of view, and I
 don't have any tangible suggestions here, but the above just
 seems to generate more illegal than legal sequences, which also
 means the code in the compositor must be checking for all the
 illegal cases, and emit errors. The illegal sequences might not
 make any sense to use, but the compositor (and the protocol spec)
 must be aware of what happens when they are received. It might be
 worth to actually draw (as on paper) the state machine with all the
 requests you might get in each state.

 Is there any way this protocol could be designed in a way, that
 illegal sequences would not exist, or at least would be in the
 minority?

I would like to dismiss the term 'illegal' here in it's entirety
because it is biased by definition. I prefer 'possibly problematic'.


 As such, having only the set-requests without corresponding
 un-requests would cut down the number of illegal (or just
 unintuitive) sequences a lot. Adding a single undo request won't make
 it much worse, the only suspicious case is undoing multiple times
 in a row, I think. Adding corresponding un-request for each state
 request leads to a minor combinatorial explosion of possible
 sequences for which there is no obvious idea on what should happen.

Yes, this is an orchestration between the clients and shell. It
doesn't sound too complicated until you take a look at what's actually
going on. I did not have time to draw a picture but mainly, you have
to keep everyone in sync. And by everyone I mean:

1) The shell plugin
2) The wl_shell_surface clients
3) The xwayland clients
4) The desktop-shell client

These all must be 'on board', for everything to go as intended.


 Btw. how do you intend to restore the stacking order on undo, in
 practice, in the Weston implementation? It is possible other
 windows have been deleted, created, and shuffled between set and
 undo, so what will you use as the anchor to go back to?

I am using gh next as a testbed to work out many of the details.



 As for the whole idea of undoing stacking order changes; you seem
 to assume that set_state requests will change the stacking order.
 Is that right?

The stacking order is (optionally) only changed when a state is restored.


 Or is that just a convenient workaround for the fact, that we do
 not have protocol for explicitly controlling stacking order? So you
 just add implicit stacking side-effects to unrelated requests?

There's a lot of missing protocol, again, gh next is the testbed for
the current implementation I have.


 If we had orthogonal requests for controlling stacking order, then
 set_state requests would not need to touch stacking order at all.
 Excluding stacking order, is there something else you would want to
 undo, or would the whole 

Re: [PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

On Fri, Mar 22, 2013 at 7:09 PM, Bill Spitzak spit...@gmail.com wrote:
 The underlying problem is that if a window is full-screen or maximized, and
 you minimize it, then un-minimize should put it back to full-screen or
 maximized. Thus un-minimize cannot be the normal state.

 The compositor could track the previous state and set that but then the
 client can't change the previous state while minimized.

 The proposed un-minimize request means the compositor does not know what
 state will result after the un-minimize.

 I think this can be solved by merging all these states into a single integer
 as bits:

 MAXIMIZED = 1;
 FULL_SCREEN = 2;
 MINIMIZED = 4;
 ...

 The rules are that if MINIMIZED is on then it is minimized, and the other
 bits are ignored. If not then FULL_SCREEN is on it is fullscreen and
 MAXIMIZED is ignored. Etc.

 The compositor can send an event to a surface saying that the state should
 change to a new set of values. Un-minimize just means it turns off the
 minimize bit and sends the new value.

 The client can send commands changing the state of surfaces. If it wants to
 turn off maximize while minimized, it just turns off the bit.

 This has a number of advantages:

  1. greatly reduces the api count

  2. Easy to add some new state to existing shell api

  3. All plausable implementations of clients and shells I can think of would
 end up storing a set of flags just like this anyway and tracking the state.

I don't know what your problem is but you simply do not read or think
about anything you type, do you? You are wasting people's time here,
please find something better to do with yours. I am not going to be
using a single semantic you state because you're assumptions make it
sound like your word is absolute when it is in fact frivolous and
largely unnecessary. If you want it done your way, then write it
yourself.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

Hi Jason,

On Thu, Mar 21, 2013 at 9:39 AM, Jason Ekstrand ja...@jlekstrand.net wrote:
 Hi Scott,

 One important thing to note here is that client != surface. In fact,
 clients can have multiple surfaces. We might need to keep this in mind
 for things like closing single surfaces demonstrated here
 https://github.com/soreau/wayland/commit/65f8a3f5f683c3a91913a26496cc373633f01896

 Yes, particularly for the closing case.

 This allows us to tell a client that 'the user has indicated that they
 would like one of your surfaces to be closed (this one)'. By way of
 contrast, the current code kills the entire client and all of its
 surfaces. Unless I am not understanding correctly, we don't have a way
 to tell a client to kill only one (or more) of its surfaces with the
 current protocol. It might be a good idea to write a test client that
 simply has two surfaces from the same client to exercise these cases
 (unless there isn't one already). We've been testing with
 google-chrome mostly.

 This should be taken care of by the adding a request_close surface
 event (see previous email).

No, actually see Giulio Camuffo's existing patch here
https://github.com/soreau/wayland/commit/65f8a3f5f683c3a91913a26496cc373633f01896


 The point here is that none of this should get
 implemented by the client removing the buffer from the surface in
 order to unmap it.  That's unacceptable.  Instead, it should happen in
 terms of modes.

 I don't know what you mean by this really. Two questions at least:
 1) What do you mean by modes exactly?
 2) What would you do instead of placing it from the drawn list to a
 dedicated minimized surface list?

 This comment merely meant that the client shouldn't minimize a window
 by attaching a null buffer.  Instead, it should still be a
 fully-functioning window (possibly receiving frame events) even though
 it's minimized.

I'm not sure why you would ever want to do this, though clients can do
whatever they want.


 There is one more question that I think needs to be answered.  And
 that is: do we handle things in terms of set/unset or in terms of
 set_maximized, set_fullscreen, set_minimized, and set_normal (probably
 want a better name for that one).  Really, which of those two we do
 doesn't matter that much because the toolkit can force it either way.
 It's mostly a matter of who tracks the state and handles it.  I think
 I like simply setting the state instead of keeping track of set/unset
 better, but I'm open to discussion on that.

 I have this all working in gh next. The only thing left to consider
 that I can think of is: Do we want to support 'unmaximizing or
 unminimizing (or unfullscreening) a surface retains stacking state'.
 So basically if there is a bottom-level surface and you state change
 it then toggle it back, do we always want it on top no matter what? Or
 do we want to optionally support retaining stacking order on state
 restore (setting back to 'normal'). If we want to support this
 feature, then a new un* request is required for each state set
 request. I move that we do support this feature and I'm working on
 this in gh next.

 I think stacking should be an orthogonal interface.  If we want client
 control for it, we need an interface.  Otherwise, it should be left as
 an implementation detail.  I don't think we want to dirty the min/max
 protocol with stacking details.

Alright, you do the one for no stacking. I think I'm going to see how
the with-stacking pans out. It seems like an interesting feature to
me.


 One other question, do we want to support fullscreen
 from a source other than the client? For instance we could have
 fullscreen as a selection in the drop down menu? I guess maximize and
 minimize are expected features, fullscreen is optional. For this, we'd
 need (un)fullscreen events.  Hm, I wonder if there's a way to have the
 client tell us what states it actually supports so we can correctly
 represent this in the panel taskbar menus..

 There's no precedent for the compositor full-screening things. Also,
 unless the client is specifically designed to full-screen, you won't
 be able to get out of it.  For these two reasons, I think we should
 leave that entirely up to the client.

You can always get out of fullscreen with Alt+Tab IIRC. (but what
happens if you're accepting raw input in the fullscreen client?).


 After looking at the code in a working state, it's far clearer to have
 explicit $state and un$state events/request because there are a lot of
 paths in the code we have to run through to make this all syn up and
 work out properly. Using a state variable to simplify the protocol
 will likely complicate the description in the protocol and complicate
 the code.

 Ok, I think you completely misunderstood what I was trying to say
 here.  My point is that min/max is a state machine.  A window, from
 the user's perspective, is minimized, maximized, fullscreen, or
 normal.  It is never two of those at the same time.  My question was
 about 

[PATCH weston] shell: Shorten some of the longer lines

[Scott Moreau]

Function declarations that were spilling way over the 82 char limit
are split up into multiple lines to better adhere to line length limit.
---
 src/shell.c |   27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/src/shell.c b/src/shell.c
index 541cb76..6a861a7 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2101,7 +2101,8 @@ shell_surface_set_minimized(struct wl_client *client,
 }
 
 static void
-black_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy, 
int32_t width, int32_t height);
+black_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy,
+  int32_t width, int32_t 
height);
 
 static struct weston_surface *
 create_black_surface(struct weston_compositor *ec,
@@ -2693,7 +2694,8 @@ terminate_screensaver(struct desktop_shell *shell)
 }
 
 static void
-configure_static_surface(struct weston_surface *es, struct weston_layer 
*layer, int32_t width, int32_t height)
+configure_static_surface(struct weston_surface *es, struct weston_layer *layer,
+   int32_t width, int32_t height)
 {
struct weston_surface *s, *next;
 
@@ -2716,7 +2718,8 @@ configure_static_surface(struct weston_surface *es, 
struct weston_layer *layer,
 }
 
 static void
-background_configure(struct weston_surface *es, int32_t sx, int32_t sy, 
int32_t width, int32_t height)
+background_configure(struct weston_surface *es, int32_t sx, int32_t sy,
+   int32_t width, int32_t height)
 {
struct desktop_shell *shell = es-private;
 
@@ -2749,7 +2752,8 @@ desktop_shell_set_background(struct wl_client *client,
 }
 
 static void
-panel_configure(struct weston_surface *es, int32_t sx, int32_t sy, int32_t 
width, int32_t height)
+panel_configure(struct weston_surface *es, int32_t sx, int32_t sy,
+  int32_t width, int32_t height)
 {
struct desktop_shell *shell = es-private;
 
@@ -2782,7 +2786,8 @@ desktop_shell_set_panel(struct wl_client *client,
 }
 
 static void
-lock_surface_configure(struct weston_surface *surface, int32_t sx, int32_t sy, 
int32_t width, int32_t height)
+lock_surface_configure(struct weston_surface *surface, int32_t sx, int32_t sy,
+  int32_t width, int32_t 
height)
 {
struct desktop_shell *shell = surface-private;
 
@@ -3295,7 +3300,8 @@ activate(struct desktop_shell *shell, struct 
weston_surface *es,
 
 /* no-op func for checking black surface */
 static void
-black_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy, 
int32_t width, int32_t height)
+black_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy,
+  int32_t width, int32_t 
height)
 {
 }
 
@@ -3747,7 +3753,8 @@ configure(struct desktop_shell *shell, struct 
weston_surface *surface,
 }
 
 static void
-shell_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy, 
int32_t width, int32_t height)
+shell_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy,
+  int32_t width, int32_t 
height)
 {
struct shell_surface *shsurf = get_shell_surface(es);
struct desktop_shell *shell = shsurf-shell;
@@ -3914,7 +3921,8 @@ bind_surface_data_manager(struct wl_client *client,
 }
 
 static void
-screensaver_configure(struct weston_surface *surface, int32_t sx, int32_t sy, 
int32_t width, int32_t height)
+screensaver_configure(struct weston_surface *surface, int32_t sx, int32_t sy,
+ int32_t width, int32_t 
height)
 {
struct desktop_shell *shell = surface-private;
 
@@ -3988,7 +3996,8 @@ bind_screensaver(struct wl_client *client,
 }
 
 static void
-input_panel_configure(struct weston_surface *surface, int32_t sx, int32_t sy, 
int32_t width, int32_t height)
+input_panel_configure(struct weston_surface *surface, int32_t sx, int32_t sy,
+ int32_t width, int32_t 
height)
 {
struct weston_mode *mode;
float x, y;
-- 
1.7.10.4

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

Re: [PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

Hi Jason,

On Wed, Mar 20, 2013 at 7:56 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
 Scott et. al,
 I'm not going to try and answer everything because a lot has happened
 on this topic and I think we're on the same page on most of the
 technical details.


 Here is how I think I would have such a protocol work. (Perhaps this
 is what you intend, but, like I said, it's kind of hard to tell.)

 If the minimize event comes from compositor-side:
 1. The compositor sends a request_minimize event to the client (or
 just minimize, but I like the other a little better)
 2. The client responds with set_minimized events on any number of
 top-level surfaces.
 3. The compositor minimizes the top-level surfaces as requested by the 
 client

 If the minimize event originates client-side:
 1. The client sends calls set_minimized on any number of top-level 
 surfaces
 2. The compositor minimizes the top-level surfaces as requested by the 
 client

Yes, I completely agree. This is the same semantics of the current
maximize implementation.

 Ok, I think we're on the same page: The compositor gives the request
 to the client - client tells the compositor what windows need
 changing - compositor performs changes.

Yes that's 1). Or 2) the client acts on its own and requests a state
change (client-compositor) 3) A surface_data request is received to
ask the shell to perform a state change on a particular surface_data
object (shell_client-compositor-client)

One important thing to note here is that client != surface. In fact,
clients can have multiple surfaces. We might need to keep this in mind
for things like closing single surfaces demonstrated here
https://github.com/soreau/wayland/commit/65f8a3f5f683c3a91913a26496cc373633f01896

This allows us to tell a client that 'the user has indicated that they
would like one of your surfaces to be closed (this one)'. By way of
contrast, the current code kills the entire client and all of its
surfaces. Unless I am not understanding correctly, we don't have a way
to tell a client to kill only one (or more) of its surfaces with the
current protocol. It might be a good idea to write a test client that
simply has two surfaces from the same client to exercise these cases
(unless there isn't one already). We've been testing with
google-chrome mostly.


 As far as frame callbacks go, like pq said, that's pretty much
 orthogonal.  I think we should just let the compositor implementation
 take care of that.

Yes I meant to comment on this, acknowledging that I understand and
agree with Paalanen's point. Hope you get well soon pq.


 The point here is that none of this should get
 implemented by the client removing the buffer from the surface in
 order to unmap it.  That's unacceptable.  Instead, it should happen in
 terms of modes.

I don't know what you mean by this really. Two questions at least:
1) What do you mean by modes exactly?
2) What would you do instead of placing it from the drawn list to a
dedicated minimized surface list?



 There is one more question that I think needs to be answered.  And
 that is: do we handle things in terms of set/unset or in terms of
 set_maximized, set_fullscreen, set_minimized, and set_normal (probably
 want a better name for that one).  Really, which of those two we do
 doesn't matter that much because the toolkit can force it either way.
 It's mostly a matter of who tracks the state and handles it.  I think
 I like simply setting the state instead of keeping track of set/unset
 better, but I'm open to discussion on that.

I have this all working in gh next. The only thing left to consider
that I can think of is: Do we want to support 'unmaximizing or
unminimizing (or unfullscreening) a surface retains stacking state'.
So basically if there is a bottom-level surface and you state change
it then toggle it back, do we always want it on top no matter what? Or
do we want to optionally support retaining stacking order on state
restore (setting back to 'normal'). If we want to support this
feature, then a new un* request is required for each state set
request. I move that we do support this feature and I'm working on
this in gh next. One other question, do we want to support fullscreen
from a source other than the client? For instance we could have
fullscreen as a selection in the drop down menu? I guess maximize and
minimize are expected features, fullscreen is optional. For this, we'd
need (un)fullscreen events.  Hm, I wonder if there's a way to have the
client tell us what states it actually supports so we can correctly
represent this in the panel taskbar menus..

A note on 'request ($state_type) and request (un$state_type)' vs
'request ($state_type, 1) and request ($state_type, 0)':

After looking at the code in a working state, it's far clearer to have
explicit $state and un$state events/request because there are a lot of
paths in the code we have to run through to make this all syn up and
work out properly. Using a state variable to simplify the 

Re: Auto key repeat in wayland.

[Scott Moreau]

Hi Brenden,

On Tue, Mar 19, 2013 at 9:01 AM, Friar friar...@gmail.com wrote:
 Please also consider the case of video games that are running in
 non-full-screen mode that don't WANT key auto-repeat.  They should have a
 way to turn off repeated notifications.  Having to wade through a ton of
 auto-repeated keyboard events to find the actual up/down signals is likely
 to cause some input lag and even a few milliseconds can affect performance.
 Clients shouldn't be forced to create crazy outside connections directly to
 input devices to get primitive input handling.

This is a good point. I think the plan here as discussed before is
that, eventually we'll have a way for clients to request 'raw events'
which means the compositor will hand events to the client with minimal
or no processing (including key repeat). So key repeat would still be
handled by the compositor but clients would have a way to not care
about any such things. With weston, I believe that alt+tab is reserved
for switching away from fullscreen windows but I'm not sure how this
would work for a 'raw input grab'. Currently, no such implementation
exists to my knowledge.

- Scott


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

Re: [PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

.


 3. A window that, when you maximize it, responds by maximizing
 something else.  Consider a video player.  It may be using a
 subsurface to display its video and then, when you press the maximize
 button it actually detaches the video surface and sets it to
 fullscreen.  Again, in a compositor-dominated environment this would
 really confuse the compositor.

I am thinking this is another non-issue. Clients are in control of
sending fullscreen or maximize events for their surfaces and setting
them back (toplevel).


 Hopefully this is concrete enough to demonstrate my point.

Yes and again, I would like to thank you for taking the time out to
address this. I now have a couple of other outstanding cases I would
like to introduce to the discussion. These are cases to consider when
thinking about what descriptions should be used for the minimize
protocol documentation.

1) We want live minimized surface previews. This means that we want to
be able to display a minimized surface in several cases and have the
client still rendering frames of whatever it draws. For example, a
hover action on the panel's window list item could pop-up a scaled
down preview of the surface. Another use case is for 'scale' (compiz)
or 'expose' (osx) effect. We want to be able to view minimized surface
in this mode as well. There are plenty of other use cases as well. The
question is, how should the semantics work here? Should the client
become unminimized for this case? Or should the client do nothing but
just always keep rendering and attaching frames even in the minimized
case?

2) Minimized surfaces do not receive frame events. The current
implementation removes the surface from the compositor render list of
surfaces to draw. This means that a) the surface has no assigned
output and b) does not get sent frame events while minimized. I
thought about this and ended up with a separate minimized surface list
that contains the list of currently minimized surfaces. Should output
repaint send frame events to minimized surfaces as well?

3) Currently, most all wayland clients depend on frame events to drive
their rendering. If the clients are not sent these frame events, the
client rendering will stall. This causes problems for video players
reliant on the frame event. Should we expect all clients to render not
depending on the frame events? It is not clear from the frame event
protocol description. if this is the case, we should add it to the
protocol description and change the clients accordingly. As I
understand, eglSwapBuffers() automatically blocks on each call to sync
properly. So even if you called it at the 'wrong' time (i.e. outside
of the frame event handler) it would still sync in the egl case. I'm
not sure about how shm would work here.


Thanks,

Scott


 On Sun, Mar 17, 2013 at 9:02 PM, Scott Moreau ore...@gmail.com wrote:
 I am not really sure what you are talking about but I'm also not sure I 
 have
 time for it. The fact is that this is only a basic implementation to
 exercise the new protocol. If you would like to contribute code, the policy
 is that patches are welcome. A working implementation of what you think is
 better might also help to illustrate your points better.

 That's not really a good answer when we're talking about the core
 protocol.

Yes you are right. Unfortunately, I typically disregard Bill's
opinions because they are not well organized, often over-thought and
he never submits any code at all. I don't really have time for it.

  If this is so experimental, it should be added as a weston
 extension, not to the wayland core.  Before we start adding things to
 the wayland core protocol, we need to get it right.

 This series provides a complete example implementation in weston.
 Maximize and fullscreen are part of wl_shell_interface. It wouldn't
 make sense to put it anywhere else, than the same place as these
 existing events/requests.

 Yes, it is an implementation.  However, I think there are some
 corner-cases and things that need to be thought about.  Part of my
 point above is that you can't blow off the people who review your code
 with I don't have time and then expect Kristian to apply your
 patches.

I never expect my patches are pushed upstream to the official repos
without proper review. It is the review I'm looking for, so that
problems can be addressed and fixed, for eventual potential inclusion
and use for all. Unfortunately, since Kristian has finally announced
that he is not interested in any patches with DE-like goals from
anyone other than DE developers. The DE part here is the window list
and surface_data protocol. However, the surface_data protocol is just
local weston protocol. The minimize/maximize items are things that
should be in core protocol regardless if they provide DE-like
functionality or not.

 We need to be careful with the core protocol and make sure
 we get it right.

Yes, I fully agree. And *again* I want to thank for your time and
attention to this. I have been

Re: [PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

On Mon, Mar 18, 2013 at 3:29 PM, Bill Spitzak spit...@gmail.com wrote:
 Scott Moreau wrote:

 Note to Bill Spitzac: I find your posts to be often frivolous and
 incoherent. I don't mean to be rude here but I have tried to consider
 many of your points and you often go on long tangents about some
 problem that doesn't exist in reality or a highly isolated use case.
 Many times I see your postings as a frivolous spec in a ml paragraph
 of how you think something should work. My point here is, if you want
 something to work a certain way, then write the code. This way, people
 can review and comment on your code (not your random comments) or you
 can just use it for yourself. I would like to ask that if you do
 respond, please put in the time and effort to make your thoughts
 coherent and in the scope of the wayland reference compositor.


 I have gotten zero feedback (not even somebody saying this is incorrect)
 for any patches I have submitted so far. I have to say this is a little
 discouraging.

Yes I have found the lack of feedback for patches on the list very
discouraging. It is discouraging to all community members who would
like to contribute.


 I agree my posts tend to specify an implementation rather than the desired
 results, though it would seem that source code is going even further in that
 direction.

Right. The point is, that if you have something laid out in your head
how exactly it should work, then rather than trying to convey these
explicit details to another human over a mailing list and expect them
to read your view, and then accept it as correct and start coding it
for you, the way you dictate, is completely unrealistic. If you
already know precisely how it should work, then you are the one that
should write the code.


 I can try some pictures to show what I think the minimize must be able to
 support:

 #1:
++
||
| MAIN1  |-+
|| |
|++|
|| DIALOG ||
|++|
++ MAIN 2  |
+--+

 After minimize of MAIN1, this is the desired result:

 #2:
+--+
|  |
 ++|
 | DIALOG ||
 ++|
|  MAIN 2  |
+--+

 After minimize of MAIN 2 this is the desired result:

 #3:
 blank

 The API must be designed so that no composite other than the initial and
 final is ever produced, even for a split second, for each of these
 transitions. By other composite I mean any different stacking order or any
 where the set of visibility of surfaces is different.

 For instance if minimize hid the dialog but the client could put it back,
 this would make the transition from #1 to #2 have an intermediate composite
 where MAIN 2 was visible but not the dialog.

 If the compositor did not hide the dialog but the client did it in response
 to the minimize, then the transition from #2 to #3 would result in an
 intermediate display where only the dialog is visible.

 I believe the only solution is for the compostior to send minimize-request
 to the client, and the client then has to minimize the window (and the
 dialog if it wants) and then to a commit to make it atomic. However I agree
 that trying to specify a solution would be better with source code.


Patches welcome.

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

Re: Auto key repeat in wayland.

[Scott Moreau]

On Sun, Mar 17, 2013 at 5:36 PM, Yichao Yu yyc1...@gmail.com wrote:
 Hi,

 Seems that weston uses a client side keyboard auto-repeat that is
 HARD-CODED in `window.c` and I haven't seen anywhere in wayland's
 mentioning how this should be done in wayland. There doesn't seem to
 be a place where the client can get a recommended repeat delay and
 frequency from the server either. Does it mean each program/toolkit
 will then have it's own key repeat setting or even hard coded in the
 code that cannot be change without a recompiling (and in either case
 it is not possible to set it globally anymore)???

 Why can't this be done in the server or shouldn't a least a
 recommended value that can also be set from client be added?

 Yichao Yu

Hi Yichao,

I have asked about this several months ago and the decision was made
by wayland developers that each toolkit should implement this feature
if they would like to have it. My position is that the key repeat
events should originate from compositor side. Not only would this give
this expected behavior of a consistent key repeat timing and always be
available by default, but it would let us have things such as key
repeat for key bindings in the compositor. Martin also expressed that
even the Linux kernel has key repeat functionality. Here is a quote
from Martin on IRC:

min2_ there is a key repeat functionality in kernel btw, no need to
recreate in toytoolkit

There's no reason this should be a client-side implementation. It is
hard to get wrong in a single implementation but having a desktop with
each client supporting it differently or not at all is just
ridiculous. The sheer code and effort duplication that would be
required is entirely unacceptable. I don't think this is an option, I
think this is a requirement of any sane display server for a desktop
platform.

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

Re: [PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

Hi Jason,

Thanks for your reply.

On Sun, Mar 17, 2013 at 7:24 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
 On Fri, Mar 8, 2013 at 4:39 PM, Scott Moreau ore...@gmail.com wrote:


 On Fri, Mar 8, 2013 at 3:28 PM, Bill Spitzak spit...@gmail.com wrote:

 Scott Moreau wrote:

 Further, the term minimize is relatively subjective and defined by the
 implementation. Clients should not expect that minimized means the
 surface
 will be invisable to the user. There are several use cases where
 displaying
 minimized surfaces will be useful.

 Minimize can be handled differently by each compositor. The protocol does
 not define minimize explicitly. The important part is that the protocol is
 in place so that the compositor and clients can communicate minimize state
 information, not unlike maximize. The comment you're looking at does not
 represent any protocol restriction, it's merely a reminder that suggests a
 minimize surface might not be unmapped. We might want to view 'live'
 minimized surfaces in a window preview, graphical window switcher or 
 scaling
 feature. It seems that you're misinterpreting this specific text but I'm 
 not
 really sure what you mean. Just know that the weston implementation is a
 reference with working proof-of-concepts, exercising and demonstrating the
 protocol. A different wayland compositor can handle all of these events and
 requests differently.


 Actually perhaps I am misunderstanding it. Does it just send an unmap
 request from the shell to the client? From the code it seems to cause the
 compositor to stop showing the minimized window without any indication being
 sent to the client at all, which I absolutely disagree with!

 If in fact the window will not vanish until the client responds to the
 unmap request, that will allow the client to atomically unmap child windows
 if wanted.

 I'm not sure if that is a good idea to have the unmap request without an
 indication that it is due to a minimize, though. Maybe there are multiple
 reasons for an unmap request and clients may want to respond differently to
 them.



 I am not really sure what you are talking about but I'm also not sure I have
 time for it. The fact is that this is only a basic implementation to
 exercise the new protocol. If you would like to contribute code, the policy
 is that patches are welcome. A working implementation of what you think is
 better might also help to illustrate your points better.

 That's not really a good answer when we're talking about the core
 protocol.  If this is so experimental, it should be added as a weston
 extension, not to the wayland core.  Before we start adding things to
 the wayland core protocol, we need to get it right.

This series provides a complete example implementation in weston.
Maximize and fullscreen are part of wl_shell_interface. It wouldn't
make sense to put it anywhere else, than the same place as these
existing events/requests.


 Also, I think I have to agree with Bill that this is a bit simplistic.
  The clients should have control over how things get minimized.

What do you mean by this? Is there something more to minimize than
either minimized/iconified or not?

  Also,
 we probably don't want to simply unmap the surface.  As I understand,
 unmapping is currently done by removing the buffer from the surface.
 Many desktop environments have a window preview in the switcher or
 somewhere else.  If you want to be able to preview minimized windows,
 it needs to remain mapped.

Yes, we probably want to make sure that clients wont be starved for
frame events, which is the case currently when pulling the surface
from the render list. It does not do an official 'unmap' though, i.e.
it does not use the unmap call in the weston shell plugin.


 I guess I don't necessarily have a problem with the events/requests
 specified, simply that I think thinks need to be clarified and thought
 out more.  For example, does the compositor send a minimize event to
 the client and expect it to minimize windows or does it simply
 minimize it?  I don't think we want the compositor hiding client
 windows without letting the client override it.

Yes, this is another catch. Minimize actually doesn't require client
support, the compositor can just 'unmap' it (using the term loosely
here). It certainly could use more thought. The main thing is, we want
to test real-world use cases and make sure they behave as expected. So
far since rebasing, I've been testing and haven't noticed any real
issues other than lack of frame events sent to minimized clients. The
gh next branches for wayland/weston has this series all applied and
working, in case anyone would like to tinker with it.

 I can provide more thoughts later, but there's my initial thoughts.

Thanks again for your concern.

 --Jason Ekstrand

Now I would like to take this opportunity to relate some new
information I have received from Kristian on IRC. It has come to my
attention that weston is not intended to be used as a real

Re: Auto key repeat in wayland.

[Scott Moreau]

On Sun, Mar 17, 2013 at 7:47 PM, Yichao Yu yyc1...@gmail.com wrote:
 Hi Scott,

 On Sun, Mar 17, 2013 at 8:51 PM, Scott Moreau ore...@gmail.com wrote:
 On Sun, Mar 17, 2013 at 5:36 PM, Yichao Yu yyc1...@gmail.com wrote:
 Hi,

 Seems that weston uses a client side keyboard auto-repeat that is
 HARD-CODED in `window.c` and I haven't seen anywhere in wayland's
 mentioning how this should be done in wayland. There doesn't seem to
 be a place where the client can get a recommended repeat delay and
 frequency from the server either. Does it mean each program/toolkit
 will then have it's own key repeat setting or even hard coded in the
 code that cannot be change without a recompiling (and in either case
 it is not possible to set it globally anymore)???

 Why can't this be done in the server or shouldn't a least a
 recommended value that can also be set from client be added?

 Yichao Yu

 Hi Yichao,

 I have asked about this several months ago and the decision was made

 This one[1]?

 by wayland developers that each toolkit should implement this feature
 if they would like to have it. My position is that the key repeat

 And the decision was all toolkits/programs written without using a
 toolkit ALL need to agree on where to retrieve that (key repeat
 configuration) from??? Shouldn't that where be the compositor??

 events should originate from compositor side. Not only would this give
 this expected behavior of a consistent key repeat timing and always be
 available by default, but it would let us have things such as key
 repeat for key bindings in the compositor. Martin also expressed that
 even the Linux kernel has key repeat functionality. Here is a quote
 from Martin on IRC:

 min2_ there is a key repeat functionality in kernel btw, no need to
 recreate in toytoolkit

 There's no reason this should be a client-side implementation. It is
 hard to get wrong in a single implementation but having a desktop with

 At least clutter and weston both have a hard coded key-repeat setting
 (and seems to be different), which IMHO is get wrong..

 each client supporting it differently or not at all is just
 ridiculous. The sheer code and effort duplication that would be
 required is entirely unacceptable. I don't think this is an option, I
 think this is a requirement of any sane display server for a desktop
 platform.

 So is the patch just disappear in nowhere? IMHO, it will also be very
 useful to make it possible for a client to change that setting
 (instead of a hard coded value in the compositor or a value in a
 configure file that require a restart to take effect).

 OT: That patch seems to have a set of hard coded non-repeat keys.
 Isn't this setting (which key should be repeat) part of xkb? (Anyway,
 since the X server can figure that out from keyboard layout, whatever
 backend wayland use shouldn't have any problem on that.)

 Yichao Yu.


 - Scott

 [1] http://lists.freedesktop.org/archives/wayland-devel/2012-March/002511.html

Hi Yichao,

Thanks so much for digging up this patch, I had forgotten all about
it. I've started work in the next branches on github so I'll apply it
there and get rid of toytoolkit repeat.

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

Re: [PATCH v3] shell: grab the parent popup when a sub popup window is deleted or hidden

[Scott Moreau]

Thanks for rebasing this to next, pushed.

- Scott

On Sat, Mar 16, 2013 at 4:59 AM, Giulio Camuffo giuliocamu...@gmail.com wrote:
 If the client opens a popup menu and submenu, when it closes or hides the
 submenu the pointer grab should return to the parent menu.
 Furthermore, when clicking outside the client area the popup_done event
 is sent to the active popup surface and recursively to its parent.
 ---
  src/shell.c | 73 
 -
  1 file changed, 68 insertions(+), 5 deletions(-)

 diff --git a/src/shell.c b/src/shell.c
 index 3da5321..ca1dfcb 100644
 --- a/src/shell.c
 +++ b/src/shell.c
 @@ -194,6 +194,8 @@ struct shell_surface {
 int32_t initial_up;
 struct wl_seat *seat;
 uint32_t serial;
 +   struct shell_surface *prev;
 +   struct wl_listener prev_listener;
 } popup;

 struct {
 @@ -1894,20 +1896,40 @@ popup_grab_end(struct wl_pointer *pointer)
 struct wl_pointer_grab *grab = pointer-grab;
 struct shell_surface *shsurf =
 container_of(grab, struct shell_surface, popup.grab);
 +   struct shell_surface *tmp;

 if (pointer-grab-interface == popup_grab_interface) {
 -   wl_shell_surface_send_popup_done(shsurf-resource);
 wl_pointer_end_grab(grab-pointer);
 -   shsurf-popup.grab.pointer = NULL;
 +   /* Send the popup_done event to all the popups open, and not 
 just
 +* the one that currently has the grab. */
 +   while (shsurf  shsurf-popup.grab.pointer) {
 +   wl_shell_surface_send_popup_done(shsurf-resource);
 +   shsurf-popup.grab.pointer = NULL;
 +
 +   tmp = shsurf;
 +   shsurf = shsurf-popup.prev;
 +   tmp-popup.prev = NULL;
 +   }
 }
  }

  static void
 +popup_prev_destroyed(struct wl_listener *listener, void *data)
 +{
 +   struct shell_surface *shsurf = container_of(listener,
 +   struct shell_surface,
 +   surface_destroy_listener);
 +
 +   shsurf-popup.prev = NULL;
 +}
 +
 +static void
  shell_map_popup(struct shell_surface *shsurf)
  {
 struct wl_seat *seat = shsurf-popup.seat;
 struct weston_surface *es = shsurf-surface;
 struct weston_surface *parent = shsurf-parent;
 +   struct shell_surface *popup_parent;

 /* Remove the old transform. We don't want to add it twice
  * otherwise Weston will go into an infinite loop when going
 @@ -1941,9 +1963,30 @@ shell_map_popup(struct shell_surface *shsurf)
 weston_surface_set_position(es, shsurf-popup.x, shsurf-popup.y);
 weston_surface_update_transform(es);

 +   if (seat-pointer-grab-interface == popup_grab_interface)
 +   popup_parent = container_of(seat-pointer-grab,
 + struct shell_surface, popup.grab);
 +   else
 +   popup_parent = NULL;
 +
 /* We don't require the grab to still be active, but if another
  * grab has started in the meantime, we end the popup now. */
 -   if (seat-pointer-grab_serial == shsurf-popup.serial) {
 +
 +   /* Need to make sure here that a sub-popup doesn't trigger the
 +* send_popup_done case.  And we need to set the popup.prev
 +* pointer.  We can look at seat-pointer-grab.interface to
 +* see if it's popup_grab_interface and if it is use
 +* container_of on seat-pointer-grab to get back to the
 +* shsurf. */
 +
 +   if (seat-pointer-grab_serial == shsurf-popup.serial ||
 +   (popup_parent  popup_parent-resource.client == 
 shsurf-resource.client)) {
 +   shsurf-popup.prev = popup_parent;
 +   if (popup_parent) {
 +   shsurf-popup.prev_listener.notify = 
 popup_prev_destroyed;
 +   
 wl_signal_add(popup_parent-surface-surface.resource.destroy_signal,
 + 
 shsurf-popup.prev_listener);
 +   }
 wl_pointer_start_grab(seat-pointer, shsurf-popup.grab);
 } else {
 wl_shell_surface_send_popup_done(shsurf-resource);
 @@ -1982,10 +2025,24 @@ static const struct wl_shell_surface_interface 
 shell_surface_implementation = {
  };

  static void
 +grab_parent_popup(struct shell_surface *shsurf)
 +{
 +   wl_pointer_end_grab(shsurf-popup.grab.pointer);
 +   shsurf-popup.grab.pointer = NULL;
 +   struct shell_surface *parent = shsurf-popup.prev;
 +   if (parent) {
 +   wl_pointer_start_grab(parent-popup.seat-pointer, 
 parent-popup.grab);
 +   shsurf-popup.prev = NULL;
 +   }
 +}
 +
 +static void
  destroy_shell_surface(struct shell_surface 

Re: [PATCH gtk+] wayland: Remove unneeded semicolons.

[Scott Moreau]

Pushed to gh next.

On Sun, Mar 10, 2013 at 12:17 PM, Scott Moreau ore...@gmail.com wrote:


 On Wed, Oct 24, 2012 at 9:38 PM, Scott Moreau ore...@gmail.com wrote:

 ---
  gdk/wayland/gdkdevice-wayland.c  | 2 +-
  gdk/wayland/gdkdisplay-wayland.c | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/gdk/wayland/gdkdevice-wayland.c
 b/gdk/wayland/gdkdevice-wayland.c
 index cef1ddf..625946a 100644
 --- a/gdk/wayland/gdkdevice-wayland.c
 +++ b/gdk/wayland/gdkdevice-wayland.c
 @@ -1818,7 +1818,7 @@ data_source_send (void  *data,
const char*mime_type,
int32_tfd)
  {
 -  GdkWaylandSelectionOffer *offer = (GdkWaylandSelectionOffer *)data;;
 +  GdkWaylandSelectionOffer *offer = (GdkWaylandSelectionOffer *)data;
gchar *buf;
gssize len, bytes_written = 0;

 diff --git a/gdk/wayland/gdkdisplay-wayland.c
 b/gdk/wayland/gdkdisplay-wayland.c
 index a2eb8e0..d60d897 100644
 --- a/gdk/wayland/gdkdisplay-wayland.c
 +++ b/gdk/wayland/gdkdisplay-wayland.c
 @@ -357,7 +357,7 @@ gdk_wayland_display_flush (GdkDisplay *display)
g_return_if_fail (GDK_IS_DISPLAY (display));

if (!display-closed)
 -wl_display_flush(GDK_WAYLAND_DISPLAY (display)-wl_display);;
 +wl_display_flush(GDK_WAYLAND_DISPLAY (display)-wl_display);
  }

  static gboolean
 --
 1.7.11.7



 I might as well bump this while I'm here..

 - Scott

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

Re: [PATCH gtk+] wayland: Attach buffer before committing

[Scott Moreau]

Pushed to gh next.

On Sun, Mar 10, 2013 at 10:55 AM, Scott Moreau ore...@gmail.com wrote:
 With recent changes in attach semantics, we always need to attach before
 committing. This fixes the problem with wayland gtk clients not updating
 surface contents correctly since latest changes regarding attach.
 ---
  gdk/wayland/gdkwindow-wayland.c |7 ---
  1 file changed, 7 deletions(-)

 diff --git a/gdk/wayland/gdkwindow-wayland.c b/gdk/wayland/gdkwindow-wayland.c
 index 6f7e744..00b0c54 100644
 --- a/gdk/wayland/gdkwindow-wayland.c
 +++ b/gdk/wayland/gdkwindow-wayland.c
 @@ -324,13 +324,6 @@ gdk_wayland_window_attach_image (GdkWindow *window)
if (GDK_WINDOW_DESTROYED (window))
  return;

 -  /* The drawn to Cairo surface is the same as the Cairo surface from which
 -   * we are driving the buffer for the Wayland surface. Therefore we don't
 -   * need to do anything here
 -   */
 -  if (impl-server_surface == impl-cairo_surface)
 -return;
 -
/* The wayland surface is attached to a buffer that is from the old drawn
 * to surface. Unref the surface and restore the state.
 */
 --
 1.7.10.4

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

Re: [PATCH] Revert weston.ini: Use 'modeline' key for modeline example

[Scott Moreau]

Pushed to gh next.

On Sun, Mar 10, 2013 at 9:30 AM, Scott Moreau ore...@gmail.com wrote:
 This reverts commit 97a56145636316fdb431b91ec64adff217287cd9.

 The current code detects the mode key, not modeline. Reference:
 http://cgit.freedesktop.org/wayland/weston/tree/src/compositor-drm.c#n2464
 ---

 I'm not sure where the confusion is here.

  weston.ini |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/weston.ini b/weston.ini
 index 98092a1..c213460 100644
 --- a/weston.ini
 +++ b/weston.ini
 @@ -46,7 +46,7 @@ path=/usr/libexec/weston-keyboard

  #[output]
  #name=VGA1
 -#modeline=173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
 +#mode=173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
  #transform=flipped

  #[output]
 --
 1.7.10.4

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

Re: [PATCH 2/3 v3] compositor: turn off the idle timer when sleeping

[Scott Moreau]

Hi Philipp,

Thanks for your attention to this. Pushed to gh next.

- Scott

On Sun, Mar 10, 2013 at 9:08 AM, Philipp Brüschweiler ble...@gmail.com wrote:
 Also updates the drm, fbdev and rpi backend to use
 weston_compositor_set_sleeping() and not set the state manually.

 Fixes https://bugs.freedesktop.org/show_bug.cgi?id=61910 (rpi backend
 untested).

 v2: don't set DPMS state when switching VT.
 v3: move unrelated enum change into its own commit.
 ---
  src/compositor-drm.c   |  2 +-
  src/compositor-fbdev.c |  2 +-
  src/compositor-rpi.c   |  2 +-
  src/compositor.c   | 12 +++-
  src/compositor.h   |  2 ++
  5 files changed, 16 insertions(+), 4 deletions(-)

 diff --git a/src/compositor-drm.c b/src/compositor-drm.c
 index d933c92..59d5694 100644
 --- a/src/compositor-drm.c
 +++ b/src/compositor-drm.c
 @@ -2027,7 +2027,7 @@ vt_func(struct weston_compositor *compositor, int event)

 compositor-focus = 0;
 ec-prev_state = compositor-state;
 -   compositor-state = WESTON_COMPOSITOR_SLEEPING;
 +   weston_compositor_set_sleeping(compositor);

 /* If we have a repaint scheduled (either from a
  * pending pageflip or the idle handler), make sure we
 diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
 index 070d187..2a01078 100644
 --- a/src/compositor-fbdev.c
 +++ b/src/compositor-fbdev.c
 @@ -791,7 +791,7 @@ vt_func(struct weston_compositor *base, int event)

 compositor-base.focus = 0;
 compositor-prev_state = compositor-base.state;
 -   compositor-base.state = WESTON_COMPOSITOR_SLEEPING;
 +   weston_compositor_set_sleeping(compositor-base);

 /* If we have a repaint scheduled (from the idle handler), 
 make
  * sure we cancel that so we don't try to pageflip when we're
 diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
 index d3767b9..9571e85 100644
 --- a/src/compositor-rpi.c
 +++ b/src/compositor-rpi.c
 @@ -1381,7 +1381,7 @@ vt_func(struct weston_compositor *base, int event)

 compositor-base.focus = 0;
 compositor-prev_state = compositor-base.state;
 -   compositor-base.state = WESTON_COMPOSITOR_SLEEPING;
 +   weston_compositor_set_sleeping(compositor-base);

 /* If we have a repaint scheduled (either from a
  * pending pageflip or the idle handler), make sure we
 diff --git a/src/compositor.c b/src/compositor.c
 index 7df9658..5041f19 100644
 --- a/src/compositor.c
 +++ b/src/compositor.c
 @@ -1619,12 +1619,22 @@ weston_compositor_wake(struct weston_compositor 
 *compositor)
  }

  WL_EXPORT void
 -weston_compositor_sleep(struct weston_compositor *compositor)
 +weston_compositor_set_sleeping(struct weston_compositor *compositor)
  {
 if (compositor-state == WESTON_COMPOSITOR_SLEEPING)
 return;

 +   wl_event_source_timer_update(compositor-idle_source, 0);
 compositor-state = WESTON_COMPOSITOR_SLEEPING;
 +}
 +
 +WL_EXPORT void
 +weston_compositor_sleep(struct weston_compositor *compositor)
 +{
 +   if (compositor-state == WESTON_COMPOSITOR_SLEEPING)
 +   return;
 +
 +   weston_compositor_set_sleeping(compositor);
 weston_compositor_dpms(compositor, WESTON_DPMS_OFF);
  }

 diff --git a/src/compositor.h b/src/compositor.h
 index 5d939ab..0a9eb81 100644
 --- a/src/compositor.h
 +++ b/src/compositor.h
 @@ -592,6 +592,8 @@ weston_compositor_unlock(struct weston_compositor 
 *compositor);
  void
  weston_compositor_wake(struct weston_compositor *compositor);
  void
 +weston_compositor_set_sleeping(struct weston_compositor *compositor);
 +void
  weston_compositor_sleep(struct weston_compositor *compositor);
  void
  weston_compositor_update_drag_surfaces(struct weston_compositor *compositor);
 --
 1.8.1.5

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

Re: [PATCH weston 1/2] compositor: remove unused field option_idle_time

[Scott Moreau]

Pushed to gh next.

- Scott

On Sun, Mar 10, 2013 at 7:37 AM, Philipp Brüschweiler ble...@gmail.com wrote:
 ---
  src/compositor.c | 1 -
  src/compositor.h | 3 +--
  2 files changed, 1 insertion(+), 3 deletions(-)

 diff --git a/src/compositor.c b/src/compositor.c
 index a2860fd..7df9658 100644
 --- a/src/compositor.c
 +++ b/src/compositor.c
 @@ -3497,7 +3497,6 @@ int main(int argc, char *argv[])
 sigaction(SIGSEGV, segv_action, NULL);
 segv_compositor = ec;

 -   ec-option_idle_time = idle_time;
 ec-idle_time = idle_time;

 setenv(WAYLAND_DISPLAY, socket_name, 1);
 diff --git a/src/compositor.h b/src/compositor.h
 index 4a0c1e3..5d939ab 100644
 --- a/src/compositor.h
 +++ b/src/compositor.h
 @@ -322,8 +322,7 @@ struct weston_compositor {
 uint32_t state;
 struct wl_event_source *idle_source;
 uint32_t idle_inhibit;
 -   int option_idle_time;   /* default timeout, s */
 -   int idle_time;  /* effective timeout, s */
 +   int idle_time;  /* timeout, s */

 /* Repaint state. */
 struct wl_array vertices;
 --
 1.8.1.5

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

Re: Introduce panel window list and surface minimize protocol

[Scott Moreau]

This entire series committed to gh next.

On Thu, Mar 7, 2013 at 9:47 PM, Scott Moreau ore...@gmail.com wrote:
 This series implements a window list for the panel. It introduces protocol for
 minimize/maximize control of shell_surfaces. It also provides a basic
 minimize implementation.

 Admittedly I am a little confused about the interface version system. I am
 wondering if we should have something such as a changlog file kept in the
 protocol folder.

 Aside from this, the window list seems to work pretty well with all the new
 functionality that it offers. Minimized buttons are hooked up by this series
 as well, which means we can start fleshing out the decorations in other 
 clients
 and toolkits. The list operation is dynamic, supporting multiple outputs.

 Changed in v3:

 - Rebased to latest master
 - Addressed everything listed here:
 
 http://lists.freedesktop.org/archives/wayland-devel/2012-November/006485.html
 - Additional bug fixes


 Here is a breif video clip demoing the latest code:

 http://www.youtube.com/watch?v=nv5isdcxBcY

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

Re: [PATCH weston] Fix memory leaks

[Scott Moreau]

Pushed to gh next.

On Thu, Mar 7, 2013 at 10:15 AM, Scott Moreau ore...@gmail.com wrote:
 Fix a couple leaks caught by valgrind.
 ---
  src/gl-renderer.c |2 ++
  src/shell.c   |1 +
  2 files changed, 3 insertions(+)

 diff --git a/src/gl-renderer.c b/src/gl-renderer.c
 index a5dc2f3..3dfcd15 100644
 --- a/src/gl-renderer.c
 +++ b/src/gl-renderer.c
 @@ -1663,6 +1663,8 @@ gl_renderer_destroy(struct weston_compositor *ec)

 eglTerminate(gr-egl_display);
 eglReleaseThread();
 +
 +   free(gr);
  }

  static int
 diff --git a/src/shell.c b/src/shell.c
 index 3da5321..5a09bb6 100644
 --- a/src/shell.c
 +++ b/src/shell.c
 @@ -2002,6 +2002,7 @@ destroy_shell_surface(struct shell_surface *shsurf)
 wl_list_remove(shsurf-surface_destroy_listener.link);
 shsurf-surface-configure = NULL;
 ping_timer_destroy(shsurf);
 +   free(shsurf-title);

 wl_list_remove(shsurf-link);
 free(shsurf);
 --
 1.7.10.4

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

Re: [PATCH wayland] client: Invoke new_id closure arguments as pointers instead of integers

[Scott Moreau]

Committed in gh next.

- Scott

On Fri, Mar 15, 2013 at 8:47 AM, Michael Hasselmann
micha...@openismus.com wrote:
 Could we get this merged please? It fixes an annoying crasher bug for us
 (see FDO#62367).

 Thanks,
 Michael

 On Fri, 2013-03-08 at 18:44 +0100, Jonas Ådahl wrote:
 This commit adds a flags parameter to wl_closure_invoke(). The so far
 added flags are ment to specify if the invokation is client side or
 server side. When on the server side, closure arguments of type 'new_id'
 should be invoked as a integer id while on the client side they should
 be invoked as a pointer to a proxy object.

 This fixes a bug happening when the address of a client side 'new_id'
 proxy object did not fit in a 32 bit integer.

 Signed-off-by: Jonas Ådahl jad...@gmail.com
 ---
  src/connection.c  |   16 +++-
  src/wayland-client.c  |2 +-
  src/wayland-private.h |7 ++-
  src/wayland-server.c  |2 +-
  4 files changed, 19 insertions(+), 8 deletions(-)

 diff --git a/src/connection.c b/src/connection.c
 index e6c2b64..b952da1 100644
 --- a/src/connection.c
 +++ b/src/connection.c
 @@ -801,7 +801,8 @@ wl_closure_lookup_objects(struct wl_closure *closure, 
 struct wl_map *objects)
  }

  static void
 -convert_arguments_to_ffi(const char *signature, union wl_argument *args,
 +convert_arguments_to_ffi(const char *signature, uint32_t flags,
 +  union wl_argument *args,
int count, ffi_type **ffi_types, void** ffi_args)
  {
   int i;
 @@ -834,8 +835,13 @@ convert_arguments_to_ffi(const char *signature, union 
 wl_argument *args,
   ffi_args[i] = args[i].o;
   break;
   case 'n':
 - ffi_types[i] = ffi_type_uint32;
 - ffi_args[i] = args[i].n;
 + if (flags  WL_CLOSURE_INVOKE_CLIENT) {
 + ffi_types[i] = ffi_type_pointer;
 + ffi_args[i] = args[i].o;
 + } else {
 + ffi_types[i] = ffi_type_uint32;
 + ffi_args[i] = args[i].n;
 + }
   break;
   case 'a':
   ffi_types[i] = ffi_type_pointer;
 @@ -855,7 +861,7 @@ convert_arguments_to_ffi(const char *signature, union 
 wl_argument *args,


  void
 -wl_closure_invoke(struct wl_closure *closure,
 +wl_closure_invoke(struct wl_closure *closure, uint32_t flags,
 struct wl_object *target, void (*func)(void), void *data)
  {
   int count;
 @@ -870,7 +876,7 @@ wl_closure_invoke(struct wl_closure *closure,
   ffi_types[1] = ffi_type_pointer;
   ffi_args[1] = target;

 - convert_arguments_to_ffi(closure-message-signature, closure-args,
 + convert_arguments_to_ffi(closure-message-signature, flags, 
 closure-args,
count, ffi_types + 2, ffi_args + 2);

   ffi_prep_cif(cif, FFI_DEFAULT_ABI,
 diff --git a/src/wayland-client.c b/src/wayland-client.c
 index 3ead2ac..c5ad96d 100644
 --- a/src/wayland-client.c
 +++ b/src/wayland-client.c
 @@ -836,7 +836,7 @@ dispatch_event(struct wl_display *display, struct 
 wl_event_queue *queue)
   if (wl_debug)
   wl_closure_print(closure, proxy-object, false);

 - wl_closure_invoke(closure, proxy-object,
 + wl_closure_invoke(closure, WL_CLOSURE_INVOKE_CLIENT, 
 proxy-object,
 proxy-object.implementation[opcode],
 proxy-user_data);
   }
 diff --git a/src/wayland-private.h b/src/wayland-private.h
 index f0c9010..4b757a1 100644
 --- a/src/wayland-private.h
 +++ b/src/wayland-private.h
 @@ -129,8 +129,13 @@ wl_connection_demarshal(struct wl_connection 
 *connection,
  int
  wl_closure_lookup_objects(struct wl_closure *closure, struct wl_map 
 *objects);

 +enum wl_closure_invoke_flag {
 + WL_CLOSURE_INVOKE_CLIENT = (1  0),
 + WL_CLOSURE_INVOKE_SERVER = (1  1)
 +};
 +
  void
 -wl_closure_invoke(struct wl_closure *closure,
 +wl_closure_invoke(struct wl_closure *closure, uint32_t flags,
 struct wl_object *target, void (*func)(void), void *data);
  int
  wl_closure_send(struct wl_closure *closure, struct wl_connection 
 *connection);
 diff --git a/src/wayland-server.c b/src/wayland-server.c
 index 2f3ddc9..aaecf29 100644
 --- a/src/wayland-server.c
 +++ b/src/wayland-server.c
 @@ -277,7 +277,7 @@ wl_client_connection_data(int fd, uint32_t mask, void 
 *data)
   if (wl_debug)
   wl_closure_print(closure, object, false);

 - wl_closure_invoke(closure, object,
 + wl_closure_invoke(closure, WL_CLOSURE_INVOKE_SERVER, object,
 object-implementation[opcode], client);

   wl_closure_destroy(closure);



 ___
 wayland-devel mailing list
 

Re: [PATCH 0/4] improve window maximize handling

[Scott Moreau]

Hi Rafal,

These all look good, merged with gh next. Thanks for the fixes!

- Scott

On Mon, Mar 11, 2013 at 12:26 PM, Rafal Mielniczuk
rafal.mielnicz...@gmail.com wrote:
 Hi

 This series of patches improves a bit handling of maximized windows in desktop
 shell.

 There were some inconsistencies like window could be moved in maximized state
 using mod+left button, window not reseting rotation when going maximized and
 a few other.

 I tried to address those issues, as a good learning exercise :)

 Regards.

 Rafal Mielniczuk (4):
   shell: block move, rotate, resize in maximized state
   shell: reset rotation for maximized surface
   window: save allocation only for toplevel window
   window: restore maximized state from fullscreen mode if necessary

  clients/window.c | 24 ++--
  src/shell.c  | 43 ++-
  2 files changed, 48 insertions(+), 19 deletions(-)

 --
 1.8.1.5

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

Re: [PATCH weston 1/2] weston-launch: move function calls out of assert()

[Scott Moreau]

This looks better, applied to gh next.

- Scott

On Sat, Mar 9, 2013 at 11:38 AM, Philipp Brüschweiler ble...@gmail.com wrote:
 ---
  src/weston-launch.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/src/weston-launch.c b/src/weston-launch.c
 index bc7f8a2..98f0111 100644
 --- a/src/weston-launch.c
 +++ b/src/weston-launch.c
 @@ -209,6 +209,7 @@ setup_launcher_socket(struct weston_launch *wl)
  static int
  setup_signals(struct weston_launch *wl)
  {
 +   int ret;
 sigset_t mask;
 struct sigaction sa;
 struct epoll_event ev;
 @@ -216,13 +217,16 @@ setup_signals(struct weston_launch *wl)
 memset(sa, 0, sizeof sa);
 sa.sa_handler = SIG_DFL;
 sa.sa_flags = SA_NOCLDSTOP | SA_RESTART;
 -   assert(sigaction(SIGCHLD, sa, NULL) == 0);
 +   ret = sigaction(SIGCHLD, sa, NULL);
 +   assert(ret == 0);

 -   assert(sigemptyset(mask) == 0);
 +   ret = sigemptyset(mask);
 +   assert(ret == 0);
 sigaddset(mask, SIGCHLD);
 sigaddset(mask, SIGINT);
 sigaddset(mask, SIGTERM);
 -   assert(sigprocmask(SIG_BLOCK, mask, NULL) == 0);
 +   ret = sigprocmask(SIG_BLOCK, mask, NULL);
 +   assert(ret == 0);

 wl-signalfd = signalfd(-1, mask, SFD_NONBLOCK | SFD_CLOEXEC);
 if (wl-signalfd  0)
 --
 1.8.1.5

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

Re: [PATCH wayland 0/6] Add wl_object based custom dispatchers support

[Scott Moreau]

Hi Jason,

I appreciate your work here. These patches can potentially lower the
entry barrier to writing other language bindings. Unfortunately, I
don't not feel that this is something suitable for gh next. It adds a
dependency on a mesa patch, which makes it more difficult to build the
next stack, without many immediate benefits. I wanted to make it clear
upfront to avoid wasted effort. I am glad that we were able to get
many of the bugs worked out before it is reviewed, it is nice to see
the community working together here.

- Scott

On Sat, Mar 16, 2013 at 1:15 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
 Kristian,
 Working with Scott Moreau to get this applied to his next branch
 demonstrated that this series is a bit tricky to apply.  In order to
 do everything correctly, it needs to be applied in three stages:

 First, apply the following 4 patches (in order):
 http://lists.freedesktop.org/archives/wayland-devel/2013-March/007830.html
 http://lists.freedesktop.org/archives/wayland-devel/2013-March/007964.html
 http://lists.freedesktop.org/archives/wayland-devel/2013-March/007844.html
 http://lists.freedesktop.org/archives/wayland-devel/2013-March/007846.html

 The last of the above patches adds a wl_resource_init function for
 initializing the wl_resource structure.  After this, Weston, Mesa, and
 (possibly) xwayland need to be patched to use wl_resource_init.  The
 following patch for weston applies against git master, but will
 probably need to be re-done due to changes made in weston:
 http://lists.freedesktop.org/archives/wayland-devel/2013-March/007845.html

 Finally, once Weston, xwayland, and Mesa have been patched to use
 wl_resource_init, we can apply the last 4 patches in the series (these
 actually add dispatcher support):

 http://lists.freedesktop.org/archives/wayland-devel/2013-March/007850.html
 http://lists.freedesktop.org/archives/wayland-devel/2013-March/007848.html
 http://lists.freedesktop.org/archives/wayland-devel/2013-March/007849.html
 http://lists.freedesktop.org/archives/wayland-devel/2013-March/007847.html

 Hopefully, this will keep the transition from being too rocky.
 --Jason Ekstrand
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Eat scroll event if a key binding function is executed because of it.

[Scott Moreau]

Hi Rune,

I almost forgot about this one, thanks for reminding me. Pushed to gh next.

- Scott

On Thu, Mar 7, 2013 at 1:50 PM, Rune K. Svendsen runesv...@gmail.com wrote:
 From: Rune K. Svendsen runesv...@gmail.com

 When an axis (scroll) event results in a key binding function
 being executed, eat the scroll event so the underlying window
 doesn't receive it.
 Thanks to Scott Moreau for helping me solve this.
 ---
  src/bindings.c   |5 -
  src/compositor.c |9 +
  src/compositor.h |2 +-
  3 files changed, 10 insertions(+), 6 deletions(-)

 diff --git a/src/bindings.c b/src/bindings.c
 index 6456f79..322736d 100644
 --- a/src/bindings.c
 +++ b/src/bindings.c
 @@ -250,7 +250,7 @@ weston_compositor_run_button_binding(struct 
 weston_compositor *compositor,
 }
  }

 -WL_EXPORT void
 +WL_EXPORT int
  weston_compositor_run_axis_binding(struct weston_compositor *compositor,
struct weston_seat *seat,
uint32_t time, uint32_t axis,
 @@ -262,8 +262,11 @@ weston_compositor_run_axis_binding(struct 
 weston_compositor *compositor,
 if (b-axis == axis  b-modifier == seat-modifier_state) {
 weston_axis_binding_handler_t handler = b-handler;
 handler(seat-seat, time, axis, value, b-data);
 +   return 1;
 }
 }
 +
 +   return 0;
  }

  WL_EXPORT int
 diff --git a/src/compositor.c b/src/compositor.c
 index 248d3b4..18f4649 100644
 --- a/src/compositor.c
 +++ b/src/compositor.c
 @@ -1826,10 +1826,11 @@ notify_axis(struct weston_seat *seat, uint32_t time, 
 uint32_t axis,

 weston_compositor_wake(compositor);

 -   if (value)
 -   weston_compositor_run_axis_binding(compositor, seat,
 -  time, axis, value);
 -   else
 +   if (!value)
 +   return;
 +
 +   if (weston_compositor_run_axis_binding(compositor, seat,
 +  time, axis, value))
 return;

 if (pointer-focus_resource)
 diff --git a/src/compositor.h b/src/compositor.h
 index 4a0c1e3..0f1b20e 100644
 --- a/src/compositor.h
 +++ b/src/compositor.h
 @@ -649,7 +649,7 @@ weston_compositor_run_button_binding(struct 
 weston_compositor *compositor,
  struct weston_seat *seat, uint32_t time,
  uint32_t button,
  enum wl_pointer_button_state value);
 -void
 +int
  weston_compositor_run_axis_binding(struct weston_compositor *compositor,
struct weston_seat *seat, uint32_t time,
uint32_t axis, int32_t value);
 --
 1.7.10.4

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

New wayland patch-staging repositories

[Scott Moreau]

Hi,

I have noticed that there are a flood of patches for wayland and
related projects that reach the wayland mailing list. Unfortunately,
many of these patches become forgotten or incompatible over time. This
can be very frustrating to everyone including contributers, users and
developers. I have noticed that this has been a consistent problem
since I began following the project about one year ago. I have tried
various methods to help solve this problem but nothing has worked.
Kristian expressed some months ago here
http://lists.freedesktop.org/archives/wayland-devel/2012-October/006055.html
that there would be next branches for new commits. This is a great
idea, but it is clear that the time and resources required to maintain
this branch in addition to 1.0 and master is not available. Kristian
has also made efforts with a patch queue but this only seems to add to
the workload in itself. The fact of the matter is, the community is
moving faster than the project can keep up. So in order to keep up and
try to help everyone and the project as a whole, I have decided to
create staging repositories to house important community patches and
other experimental changes.

General Goals:
1) Provide a place for runtime-critical patches
2) Provide a place to test experimental developments
3) Provide a repository for users with new fixes, concepts and ideas


How it works:

The repositories are contained on github at https://github.com/soreau
in the next branches. Stick to the official wayland/weston build
guide, substituting the next branches from the repos available on
github. The main repos of interest are wayland and weston. If anyone
wants or needs a patch committed to these repositories, let me know.
Any clients that want to support new core protocol can be added.
Currently, there are wayland, weston, xserver and gtk+ repositories. I
will try to keep rebased to latest wayland/weston as commits are made
to the official master repositories.

Notes:

This is not a fork of wayland, this is a staging area to test new
protocol and other interesting patches.
Hopefully, we'll be able to catch bugs with patches before they are
committed to the official repositories and become a problem.
The next branches will be rebased on their respective official
repositories master branches periodically


So far, these patches are included:

1) The window list series
2) Jonas Ådahl's [PATCH wayland] client: Invoke new_id closure
arguments as pointers instead of integers
3) Ander Conselvan de Oliveira's [PATCH weston 2/2] compositor-drm:
Fix inconsistency in finish frame timestamps
4) Fixes for new attach semantics in gtk+ and xserver

If you would like to see your patch(es) pushed to this staging
repository, feel free to reply to this post. You can also find me on
irc.freenode.net in #wayland and #wayland-dev or send me a message on
github.


Thanks,

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

Re: [PATCH] xRandr strikes back

[Scott Moreau]

On Mon, Mar 11, 2013 at 3:47 PM, Alex Deucher alexdeuc...@gmail.com wrote:

 On Mon, Mar 11, 2013 at 5:39 PM, Scott Moreau ore...@gmail.com wrote:
 
 
  On Mon, Mar 11, 2013 at 12:59 PM, Pekka Paalanen ppaala...@gmail.com
  wrote:
 
  On Sun, 10 Mar 2013 15:53:30 +0100
  Hardening rdp.eff...@gmail.com wrote:
 
   This patch adds a wlrandr extension. It is useful to test
   mode switching. The patch provides the weston-switch-mode
   utility that can be use quite the same way as xrandr to
   change graphical modes. For now only the DRM backend supports
   mode switching, but other may follow.
   ---
clients/Makefile.am   |   10 ++
clients/switch-mode.c |  300
   +
protocol/Makefile.am  |3 +-
protocol/wlrandr.xml  |   62 ++
src/Makefile.am   |5 +
src/compositor.c  |1 +
src/compositor.h  |3 +
src/wlrandr.c |  105 +
8 files changed, 488 insertions(+), 1 deletion(-)
create mode 100644 clients/switch-mode.c
create mode 100644 protocol/wlrandr.xml
create mode 100644 src/wlrandr.c
  ...
   diff --git a/protocol/wlrandr.xml b/protocol/wlrandr.xml
   new file mode 100644
   index 000..192ba24
   --- /dev/null
   +++ b/protocol/wlrandr.xml
   @@ -0,0 +1,62 @@
   +protocol name=wlrandr
   +  copyright
   +Copyright © 2013 Hardening, rdp.eff...@gmail.com
   +
   +Permission to use, copy, modify, distribute, and sell this
   +software and its documentation for any purpose is hereby granted
   +without fee, provided that the above copyright notice appear in
   +all copies and that both that copyright notice and this
 permission
   +notice appear in supporting documentation, and that the name of
   +the copyright holders not be used in advertising or publicity
   +pertaining to distribution of the software without specific,
   +written prior permission.  The copyright holders make no
   +representations about the suitability of this software for any
   +purpose.  It is provided as is without express or implied
   +warranty.
   +
   +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
   +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
   +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR
 ANY
   +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
   +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER
 IN
   +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
   +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
   +THIS SOFTWARE.
   +  /copyright
   +
   +
   +  interface name=wlrandr version=1
   +description summary=xRandr for weston
   +This is a port of the xRandr extension for weston
   +/description
   +
   +request name=switch_mode
   +  description summary=switch mode
   +Asks weston to switch graphical mode for the given output.
   +  /description
   +
   +  arg name=output type=object interface=wl_output/
   +  arg name=width type=int/
   +  arg name=height type=int/
   +  arg name=refresh type=int/
   +/request
   +
   +enum name=switch_mode_result
   +  description summary=switch mode result
   +The result of a switch_mode request
   +  /description
   +
   + entry name=ok value=0
   + summary=the mode switch completed successfully/
   + entry name=failed value=1
   + summary=something failed during mode switch (internal
   error)/
   + entry name=not_available value=2
   + summary=the requested mode was not available/
   +/enum
   +
   +event name=done
   + arg name='result' type='uint'/
   +/event
   +  /interface
   +
   +/protocol
 
  Let's assume you have 3 outputs, and you change the modes on all of
  them in a bunch. How do you know which 'done' event corresponds to
  which 'switch_mode' request?
 
  I think if you want this kind of a one-shot reply for a request,
  the request should create a new protocol object. That new object
  then would have a single event and no requests defined, and it will
  selfdestruct when the event leaves the server.
 
  wl_display.sync and wl_surface.frame are examples of such requests,
  and I think you could reuse wl_callback as the reply object type,
  as it carries an integer payload.
 
  That way you let the protocol object management take care of which
  reply was for which request.
 
  Mode switching can take time, and it might even be best to be
  performed with all outputs at once, instead of one output at a time
  sequentially. So, maybe you should also think whether the protocol
  itself should also have a concept of atomic mode setting for many
  outputs in one go, so that a server does not have to guess how many
  outputs you might want to change at a time.
 
 
  Indeed, multiple outputs introduces

Re: [PATCH] xRandr strikes back

[Scott Moreau]

On Mon, Mar 11, 2013 at 12:59 PM, Pekka Paalanen ppaala...@gmail.comwrote:

 On Sun, 10 Mar 2013 15:53:30 +0100
 Hardening rdp.eff...@gmail.com wrote:

  This patch adds a wlrandr extension. It is useful to test
  mode switching. The patch provides the weston-switch-mode
  utility that can be use quite the same way as xrandr to
  change graphical modes. For now only the DRM backend supports
  mode switching, but other may follow.
  ---
   clients/Makefile.am   |   10 ++
   clients/switch-mode.c |  300
 +
   protocol/Makefile.am  |3 +-
   protocol/wlrandr.xml  |   62 ++
   src/Makefile.am   |5 +
   src/compositor.c  |1 +
   src/compositor.h  |3 +
   src/wlrandr.c |  105 +
   8 files changed, 488 insertions(+), 1 deletion(-)
   create mode 100644 clients/switch-mode.c
   create mode 100644 protocol/wlrandr.xml
   create mode 100644 src/wlrandr.c
 ...
  diff --git a/protocol/wlrandr.xml b/protocol/wlrandr.xml
  new file mode 100644
  index 000..192ba24
  --- /dev/null
  +++ b/protocol/wlrandr.xml
  @@ -0,0 +1,62 @@
  +protocol name=wlrandr
  +  copyright
  +Copyright © 2013 Hardening, rdp.eff...@gmail.com
  +
  +Permission to use, copy, modify, distribute, and sell this
  +software and its documentation for any purpose is hereby granted
  +without fee, provided that the above copyright notice appear in
  +all copies and that both that copyright notice and this permission
  +notice appear in supporting documentation, and that the name of
  +the copyright holders not be used in advertising or publicity
  +pertaining to distribution of the software without specific,
  +written prior permission.  The copyright holders make no
  +representations about the suitability of this software for any
  +purpose.  It is provided as is without express or implied
  +warranty.
  +
  +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
  +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
  +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
  +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
  +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
  +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
  +THIS SOFTWARE.
  +  /copyright
  +
  +
  +  interface name=wlrandr version=1
  +description summary=xRandr for weston
  +This is a port of the xRandr extension for weston
  +/description
  +
  +request name=switch_mode
  +  description summary=switch mode
  +Asks weston to switch graphical mode for the given output.
  +  /description
  +
  +  arg name=output type=object interface=wl_output/
  +  arg name=width type=int/
  +  arg name=height type=int/
  +  arg name=refresh type=int/
  +/request
  +
  +enum name=switch_mode_result
  +  description summary=switch mode result
  +The result of a switch_mode request
  +  /description
  +
  + entry name=ok value=0
  + summary=the mode switch completed successfully/
  + entry name=failed value=1
  + summary=something failed during mode switch (internal
 error)/
  + entry name=not_available value=2
  + summary=the requested mode was not available/
  +/enum
  +
  +event name=done
  + arg name='result' type='uint'/
  +/event
  +  /interface
  +
  +/protocol

 Let's assume you have 3 outputs, and you change the modes on all of
 them in a bunch. How do you know which 'done' event corresponds to
 which 'switch_mode' request?

 I think if you want this kind of a one-shot reply for a request,
 the request should create a new protocol object. That new object
 then would have a single event and no requests defined, and it will
 selfdestruct when the event leaves the server.

 wl_display.sync and wl_surface.frame are examples of such requests,
 and I think you could reuse wl_callback as the reply object type,
 as it carries an integer payload.

 That way you let the protocol object management take care of which
 reply was for which request.

 Mode switching can take time, and it might even be best to be
 performed with all outputs at once, instead of one output at a time
 sequentially. So, maybe you should also think whether the protocol
 itself should also have a concept of atomic mode setting for many
 outputs in one go, so that a server does not have to guess how many
 outputs you might want to change at a time.


Indeed, multiple outputs introduces complexities. I think we should be able
to follow most of the default xrandr assumptions here. These are a few
random thoughts I have with that idea in mind:

1) A second output should be added to the right (or left) of the primary by
default. (Is there a concept of a primary output in 

[PATCH weston v2] compositor-x11: Consider output position when computing relative motion

[Scott Moreau]

This fixes pointer movement for multiple x11 outputs. This was broken
when switching to relative events.

Fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=61672
---

I do not currently have a multi-output setup to test drm but it's possible that
evdev needs a similar fix.

 src/compositor-x11.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 8e052dd..db51409 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -1012,8 +1012,8 @@ x11_compositor_deliver_motion_event(struct x11_compositor 
*c,
output = x11_compositor_find_output(c, motion_notify-event);
x = wl_fixed_from_int(motion_notify-event_x - c-prev_x);
y = wl_fixed_from_int(motion_notify-event_y - c-prev_y);
-   c-prev_x = motion_notify-event_x;
-   c-prev_y = motion_notify-event_y;
+   c-prev_x = motion_notify-event_x + output-base.x;
+   c-prev_y = motion_notify-event_y + output-base.y;
x11_output_transform_coordinate(output, x, y);
 
notify_motion(c-core_seat, weston_compositor_get_time(), x, y);
@@ -1033,8 +1033,8 @@ x11_compositor_deliver_enter_event(struct x11_compositor 
*c,
if (!c-has_xkb)
update_xkb_state_from_core(c, enter_notify-state);
output = x11_compositor_find_output(c, enter_notify-event);
-   c-prev_x = enter_notify-event_x;
-   c-prev_y = enter_notify-event_y;
+   c-prev_x = enter_notify-event_x + output-base.x;
+   c-prev_y = enter_notify-event_y + output-base.y;
x = wl_fixed_from_int(enter_notify-event_x);
y = wl_fixed_from_int(enter_notify-event_y);
x11_output_transform_coordinate(output, x, y);
-- 
1.7.10.4

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

[PATCH] Revert weston.ini: Use 'modeline' key for modeline example

[Scott Moreau]

This reverts commit 97a56145636316fdb431b91ec64adff217287cd9.

The current code detects the mode key, not modeline. Reference:
http://cgit.freedesktop.org/wayland/weston/tree/src/compositor-drm.c#n2464
---

I'm not sure where the confusion is here.

 weston.ini |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weston.ini b/weston.ini
index 98092a1..c213460 100644
--- a/weston.ini
+++ b/weston.ini
@@ -46,7 +46,7 @@ path=/usr/libexec/weston-keyboard
 
 #[output]
 #name=VGA1
-#modeline=173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
+#mode=173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
 #transform=flipped
 
 #[output]
-- 
1.7.10.4

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

Re: [PATCH] xRandr strikes back

[Scott Moreau]

On Sun, Mar 10, 2013 at 9:17 AM, Jonas Ådahl jad...@gmail.com wrote:

 On Sun, Mar 10, 2013 at 3:53 PM, Hardening rdp.eff...@gmail.com wrote:
  This patch adds a wlrandr extension. It is useful to test
  mode switching. The patch provides the weston-switch-mode
  utility that can be use quite the same way as xrandr to
  change graphical modes. For now only the DRM backend supports
  mode switching, but other may follow.


Hi Jonas,



 Hi,

 I think the consensus has been not to have a protocol like this as
 clients should not dictate what resolution an output should have. A
 client can ask nicely via the fullscreen API a preferred resolution,
 but it should not set it. The point with this is that no client should
 be able to change resolution, crash, and then leave the compositor in
 an invalid state (read wrong resolution). The shell, however, can have
 its own private protocol for doing this, and then whatever user
 interface wants to have to change resolution, but it should not be in
 a client facing protocol.


What you stated is the common consensus but the fact is, we have no way to
change the output resolution in weston while it is running. This is not a
secure protocol and any client can use it, true. However, we need a way to
do this right now so we can shake out the bugs that do not detect mode
switching properly. The outstanding case is desktop-shell components, panel
and background. It would be interesting to find a way to secure a protocol
such as this but aside from handling mode switching directly in the
compositor somehow, there's really not many sane options left. Unless you
have a better way to switch modes while weston is running?

- Scott



 Jonas

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

[PATCH gtk+] wayland: Attach buffer before committing

[Scott Moreau]

With recent changes in attach semantics, we always need to attach before
committing. This fixes the problem with wayland gtk clients not updating
surface contents correctly since latest changes regarding attach.
---
 gdk/wayland/gdkwindow-wayland.c |7 ---
 1 file changed, 7 deletions(-)

diff --git a/gdk/wayland/gdkwindow-wayland.c b/gdk/wayland/gdkwindow-wayland.c
index 6f7e744..00b0c54 100644
--- a/gdk/wayland/gdkwindow-wayland.c
+++ b/gdk/wayland/gdkwindow-wayland.c
@@ -324,13 +324,6 @@ gdk_wayland_window_attach_image (GdkWindow *window)
   if (GDK_WINDOW_DESTROYED (window))
 return;
 
-  /* The drawn to Cairo surface is the same as the Cairo surface from which
-   * we are driving the buffer for the Wayland surface. Therefore we don't
-   * need to do anything here
-   */
-  if (impl-server_surface == impl-cairo_surface)
-return;
-
   /* The wayland surface is attached to a buffer that is from the old drawn
* to surface. Unref the surface and restore the state.
*/
-- 
1.7.10.4

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

[PATCH gtk+] wayland: Remove unused header

[Scott Moreau]

---
 gdk/wayland/gdkwindow-wayland.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/gdk/wayland/gdkwindow-wayland.c b/gdk/wayland/gdkwindow-wayland.c
index 00b0c54..d4e8150 100644
--- a/gdk/wayland/gdkwindow-wayland.c
+++ b/gdk/wayland/gdkwindow-wayland.c
@@ -36,7 +36,6 @@
 #include sys/mman.h
 #include errno.h
 
-#include wayland-egl.h
 
 #define WINDOW_IS_TOPLEVEL_OR_FOREIGN(window) \
   (GDK_WINDOW_TYPE (window) != GDK_WINDOW_CHILD\
-- 
1.7.10.4

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

Re: [PATCH gtk+] wayland: Remove unneeded semicolons.

[Scott Moreau]

On Wed, Oct 24, 2012 at 9:38 PM, Scott Moreau ore...@gmail.com wrote:

 ---
  gdk/wayland/gdkdevice-wayland.c  | 2 +-
  gdk/wayland/gdkdisplay-wayland.c | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/gdk/wayland/gdkdevice-wayland.c
 b/gdk/wayland/gdkdevice-wayland.c
 index cef1ddf..625946a 100644
 --- a/gdk/wayland/gdkdevice-wayland.c
 +++ b/gdk/wayland/gdkdevice-wayland.c
 @@ -1818,7 +1818,7 @@ data_source_send (void  *data,
const char*mime_type,
int32_tfd)
  {
 -  GdkWaylandSelectionOffer *offer = (GdkWaylandSelectionOffer *)data;;
 +  GdkWaylandSelectionOffer *offer = (GdkWaylandSelectionOffer *)data;
gchar *buf;
gssize len, bytes_written = 0;

 diff --git a/gdk/wayland/gdkdisplay-wayland.c
 b/gdk/wayland/gdkdisplay-wayland.c
 index a2eb8e0..d60d897 100644
 --- a/gdk/wayland/gdkdisplay-wayland.c
 +++ b/gdk/wayland/gdkdisplay-wayland.c
 @@ -357,7 +357,7 @@ gdk_wayland_display_flush (GdkDisplay *display)
g_return_if_fail (GDK_IS_DISPLAY (display));

if (!display-closed)
 -wl_display_flush(GDK_WAYLAND_DISPLAY (display)-wl_display);;
 +wl_display_flush(GDK_WAYLAND_DISPLAY (display)-wl_display);
  }

  static gboolean
 --
 1.7.11.7



I might as well bump this while I'm here..

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

[PATCH xserver] xwayland: Attach buffer before committing

[Scott Moreau]

This fixes the wlshm path which was not updating the buffer correctly.
---
 hw/xfree86/xwayland/xwayland.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/xfree86/xwayland/xwayland.c b/hw/xfree86/xwayland/xwayland.c
index d97f4ee..f59bfe4 100644
--- a/hw/xfree86/xwayland/xwayland.c
+++ b/hw/xfree86/xwayland/xwayland.c
@@ -344,6 +344,9 @@ void xwl_screen_post_damage(struct xwl_screen *xwl_screen)
  box-x2 - box-x1 + 1,
  box-y2 - box-y1 + 1);
}
+   wl_surface_attach(xwl_window-surface,
+ xwl_window-buffer,
+ 0, 0);
wl_surface_commit(xwl_window-surface);
DamageEmpty(xwl_window-damage);
 }
-- 
1.7.10.4

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

[PATCH weston] weston.man: Document the way to disable idle timeout

[Scott Moreau]

---
 man/weston.man |1 +
 1 file changed, 1 insertion(+)

diff --git a/man/weston.man b/man/weston.man
index e7692c7..39d854b 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -117,6 +117,7 @@ seconds. The default timeout is 300 seconds. When there has 
not been any
 user input for the idle timeout, Weston enters an inactive mode. The
 screen fades to black, and depending on the shell in use, a screensaver
 may activate, monitors may switch off, and the shell may lock the session.
+A value of 0 effectively disables the timeout.
 .TP
 \fB\-\-log\fR=\fIfile.log\fR
 Append log messages to the file
-- 
1.7.10.4

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

Re: Clipboard and selection in wayland.

[Scott Moreau]

Hi Yichao,

On Sat, Mar 9, 2013 at 9:47 PM, Yichao Yu yyc1...@gmail.com wrote:

 Hi,

 In X11 there are CLIPBOARD and PRIMARY selection each correspond to
 the current clipboard and selected content and applications can
 monitor the change of them using XFixes. In wayland, I have found
 wl_data_device which I suppose should do the similar thing. The
 question is, since there is only one wl_data_device::selection event,
 is it possible to get current selected data as well as clipboard
 content in wayland (or in another word is it possible to have X11's
 handy middle button paste)? I also found the only weston client that
 uses clipboard (weston-terminal) use it in a weird way, should this be
 considered a bug and should the selection signal used in a similar way
 as the XFixes signal in X to monitor clibpoard/selection changes?


It is understood that the client or toolkit should implement this if it
wants to support such a feature.

- Scott



 Thanks.

 Yichao Yu

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

Re: [PATCH] pixman-renderer: don't forget to initialize the debug fields

[Scott Moreau]

On Fri, Mar 8, 2013 at 12:35 PM, Philipp Brüschweiler ble...@gmail.comwrote:

 Fixes https://bugs.freedesktop.org/show_bug.cgi?id=61930
 ---
  src/pixman-renderer.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
 index 9571f6f..9dbe9f0 100644
 --- a/src/pixman-renderer.c
 +++ b/src/pixman-renderer.c
 @@ -485,6 +485,8 @@ pixman_renderer_init(struct weston_compositor *ec)
 if (renderer == NULL)
 return -1;

 +   renderer-repaint_debug = 0;
 +   renderer-debug_color = NULL;


Alternatively you could change malloc to calloc so the entire struct is
initialized.


 renderer-base.read_pixels = pixman_renderer_read_pixels;
 renderer-base.repaint_output = pixman_renderer_repaint_output;
 renderer-base.flush_damage = pixman_renderer_flush_damage;
 --
 1.8.1.5

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

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

Re: [PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

On Fri, Mar 8, 2013 at 12:50 PM, Bill Spitzak spit...@gmail.com wrote:

 Scott Moreau wrote:

  The client doesn't need to be involved
 in a minimize action, unlike (un)maximize, it only needs a way to track
 its
 minimize state and request to be minimized.


 No, please allow the client to decide exactly what surfaces to unmap in
 response to minimize.

 I need the ability to make floating windows that are shared by more than
 one surface. A request to minimize one of those surfaces can only be
 correctly handled by the client, unless you start sending incredibly
 complex DAG information from the clients to the server which I think should
 be avoided at all costs. Any workaround is going to make the floating
 windows blink which is against Wayland design principles.

 In general, the client must ALWAYS have last say over what surfaces are
 visible and what their stacking order is. The compositor NEVER NEVER NEVER
 changes this except in response to a request from the client.


I don't know what you're talking about here but please see the comment in
the last paragraph of the commit message:

Further, the term minimize is relatively subjective and defined by the
implementation. Clients should not expect that minimized means the surface
will be invisable to the user. There are several use cases where displaying
minimized surfaces will be useful.

Minimize can be handled differently by each compositor. The protocol does
not define minimize explicitly. The important part is that the protocol is
in place so that the compositor and clients can communicate minimize state
information, not unlike maximize. The comment you're looking at does not
represent any protocol restriction, it's merely a reminder that suggests a
minimize surface might not be unmapped. We might want to view 'live'
minimized surfaces in a window preview, graphical window switcher or
scaling feature. It seems that you're misinterpreting this specific text
but I'm not really sure what you mean. Just know that the weston
implementation is a reference with working proof-of-concepts, exercising
and demonstrating the protocol. A different wayland compositor can handle
all of these events and requests differently.

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

Re: [PATCH] pixman-renderer: don't forget to initialize the debug fields

[Scott Moreau]

On Fri, Mar 8, 2013 at 1:05 PM, Philipp Brüschweiler ble...@gmail.comwrote:

 Sorry, forgot Reply All.


 On Fri, Mar 8, 2013 at 9:04 PM, Philipp Brüschweiler ble...@gmail.comwrote:

 On Fri, Mar 8, 2013 at 8:44 PM, Scott Moreau ore...@gmail.com wrote:



 On Fri, Mar 8, 2013 at 12:35 PM, Philipp Brüschweiler 
 ble...@gmail.comwrote:

 Fixes https://bugs.freedesktop.org/show_bug.cgi?id=61930
 ---
  src/pixman-renderer.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
 index 9571f6f..9dbe9f0 100644
 --- a/src/pixman-renderer.c
 +++ b/src/pixman-renderer.c
 @@ -485,6 +485,8 @@ pixman_renderer_init(struct weston_compositor *ec)
 if (renderer == NULL)
 return -1;

 +   renderer-repaint_debug = 0;
 +   renderer-debug_color = NULL;


 Alternatively you could change malloc to calloc so the entire struct is
 initialized.


 True. Though this has the downside that valgrind will not be able to tell
 you when you are using uninitialized memory. Which is a pretty small
 downside compared to this bug. What is the general convention in
 wayland/weston regarding malloc vs. calloc?


I think there are enough instances in the code to answer this question.






  renderer-base.read_pixels = pixman_renderer_read_pixels;
 renderer-base.repaint_output = pixman_renderer_repaint_output;
 renderer-base.flush_damage = pixman_renderer_flush_damage;
 --
 1.8.1.5

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





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

[PATCH weston] Fix memory leaks

[Scott Moreau]

Fix a couple leaks caught by valgrind.
---
 src/gl-renderer.c |2 ++
 src/shell.c   |1 +
 2 files changed, 3 insertions(+)

diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index a5dc2f3..3dfcd15 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1663,6 +1663,8 @@ gl_renderer_destroy(struct weston_compositor *ec)
 
eglTerminate(gr-egl_display);
eglReleaseThread();
+
+   free(gr);
 }
 
 static int
diff --git a/src/shell.c b/src/shell.c
index 3da5321..5a09bb6 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2002,6 +2002,7 @@ destroy_shell_surface(struct shell_surface *shsurf)
wl_list_remove(shsurf-surface_destroy_listener.link);
shsurf-surface-configure = NULL;
ping_timer_destroy(shsurf);
+   free(shsurf-title);
 
wl_list_remove(shsurf-link);
free(shsurf);
-- 
1.7.10.4

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

Introduce panel window list and surface minimize protocol

[Scott Moreau]

This series implements a window list for the panel. It introduces protocol for
minimize/maximize control of shell_surfaces. It also provides a basic
minimize implementation.

Admittedly I am a little confused about the interface version system. I am
wondering if we should have something such as a changlog file kept in the
protocol folder.

Aside from this, the window list seems to work pretty well with all the new
functionality that it offers. Minimized buttons are hooked up by this series
as well, which means we can start fleshing out the decorations in other clients
and toolkits. The list operation is dynamic, supporting multiple outputs.

Changed in v3:

- Rebased to latest master
- Addressed everything listed here:

http://lists.freedesktop.org/archives/wayland-devel/2012-November/006485.html
- Additional bug fixes


Here is a breif video clip demoing the latest code:

http://www.youtube.com/watch?v=nv5isdcxBcY

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

[PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

In order for clients to notify the compositor that they wish to be minimized, a
minimize request is needed. This can be used to minimize the surface when a
user clicks a minimize button for example.

The compositor needs a way to tell clients to maximize and unmaximize their
surfaces. The desktop shell client can ask the compositor to send a surface
an (un)maximize event, in response to a panel button for example.

The compositor can minimize and unminimize surfaces but clients can only
request that its surface is minimized. The client doesn't need to be involved
in a minimize action, unlike (un)maximize, it only needs a way to track its
minimize state and request to be minimized. This patch adds minimize and
unminimize protocol events for this purpose.

Further, the term minimize is relatively subjective and defined by the
implementation. Clients should not expect that minimized means the surface
will be invisable to the user. There are several use cases where displaying
minimized surfaces will be useful. Clients might want to change input handling
or pause when minimized but nothing should change with regards to submitting
surface buffer updates.
---
 protocol/wayland.xml |   38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 0ce68ef..8fb5841 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -527,7 +527,7 @@
 /request
   /interface
 
-  interface name=wl_shell_surface version=1
+  interface name=wl_shell_surface version=2
 
 description summary=desktop style meta data interface
   An interface implemented by a wl_surface.  On server side the
@@ -729,6 +729,42 @@
to the client owning the popup surface.
   /description
 /event
+
+!-- Version 2 additions --
+
+request name=set_minimized
+  description summary=request minimize
+   A request from the client to notify the compositor that it wants to be
+   minimized.
+  /description
+/request
+
+event name=maximize
+  description summary=suggest maximize
+   The maximize event is to signal to the client that it should become
+   maximized.
+  /description
+/event
+
+event name=unmaximize
+  description summary=suggest unmaximize
+   The unmaximize event is to signal to the client that it should become
+   unmaximized.
+  /description
+/event
+
+event name=minimize
+  description summary=minimize notification
+   The minimize event is to notify the client that it has been minimized.
+  /description
+/event
+
+event name=unminimize
+  description summary=unminimize notification
+   The unminimize event is to notify the client that it has been
+   unminimized.
+  /description
+/event
   /interface
 
   interface name=wl_surface version=2
-- 
1.7.10.4

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

[PATCH weston 1/9] shell: Install protocol for surface_data objects

[Scott Moreau]

This patch introduces a new surface_data_manager interface that allows the
compositor to send surface data to the shell client, using the accompanying
surface_data object interface. This allows the shell client to receive
information about surfaces to build a window list, for example.
---
 protocol/desktop-shell.xml |   42 ++
 1 file changed, 42 insertions(+)

diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml
index d48c3dd..2fed660 100644
--- a/protocol/desktop-shell.xml
+++ b/protocol/desktop-shell.xml
@@ -82,6 +82,48 @@
 /enum
   /interface
 
+  interface name=surface_data version=1
+description summary=the surface data offer object
+   The shell can use this interface to receive surface information or make
+   requests for this surface.
+/description
+request name=destroy type=destructor
+  description summary=destroy surface request
+   The shell must send this request in response to a gone event so the
+   compositor can destroy the object properly.
+  /description
+/request
+event name=output_mask
+  description summary=send the surface object output_mask to the shell/
+  arg name=output_mask type=uint/
+/event
+event name=title
+  description summary=send the surface object title to the shell/
+  arg name=title type=string/
+/event
+event name=gone
+  description summary=destroy surface notification
+   The compositor should send this event to notify the shell that a
+   surface has been destroyed. The client must respond with a destroy
+   request.
+  /description
+/event
+  /interface
+
+  interface name=surface_data_manager version=1
+description summary=send surface object to shell
+   The compositor can offer surface data to a shell. The client can use
+   this interface as a way to receive special surface_data objects.
+/description
+event name=surface_object
+  description summary=surface object
+   Surface object sent to a shell. This object is intended to allow the
+   shell to initiate a surface_data object interface.
+  /description
+  arg name=id type=new_id interface=surface_data/
+/event
+  /interface
+
   interface name=screensaver version=1
 description summary=interface for implementing screensavers
   Only one client can bind this interface at a time.
-- 
1.7.10.4

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

[PATCH weston 2/9] shell: Implement panel window list

[Scott Moreau]

This patch uses the special surface_data interface to send information about
the surface to the shell. The shell then uses this information to render a
window list in the panel.
---
 clients/desktop-shell.c |  479 +--
 data/Makefile.am|1 +
 data/list_item_icon.png |  Bin 0 - 176 bytes
 src/compositor.c|3 +
 src/compositor.h|1 +
 src/shell.c |  201 
 6 files changed, 671 insertions(+), 14 deletions(-)
 create mode 100644 data/list_item_icon.png

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 41e7daa..2b5f7c8 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -44,6 +44,8 @@
 
 #include desktop-shell-client-protocol.h
 
+#define MIN(x, y) (((x)  (y)) ? (x) : (y))
+
 extern char **environ; /* defined by libc */
 
 struct desktop {
@@ -51,31 +53,55 @@ struct desktop {
struct desktop_shell *shell;
struct unlock_dialog *unlock_dialog;
struct task unlock_task;
+   struct wl_list surfaces;
struct wl_list outputs;
+   uint32_t output_count;
 
struct window *grab_window;
struct widget *grab_widget;
 
enum cursor_type grab_cursor;
+
+   struct surface_data_manager *surface_data_manager;
 };
 
 struct surface {
+   struct surface_data *surface_data;
+   struct desktop *desktop;
+   uint32_t output_mask;
+   char *title;
+
+   /* One window list item per panel of the surface's output_mask */
+   struct wl_list item_list;
+
+   struct wl_list link;
+};
+
+struct resize {
void (*configure)(void *data,
  struct desktop_shell *desktop_shell,
  uint32_t edges, struct window *window,
  int32_t width, int32_t height);
 };
 
+struct rgba {
+   float r, g, b, a;
+};
+
 struct panel {
-   struct surface base;
+   struct resize base;
struct window *window;
struct widget *widget;
struct wl_list launcher_list;
+   struct wl_list window_list;
+   struct rectangle window_list_rect;
+   uint32_t surface_count;
+   struct rgba focused_item;
struct panel_clock *clock;
 };
 
 struct background {
-   struct surface base;
+   struct resize base;
struct window *window;
struct widget *widget;
 };
@@ -83,11 +109,22 @@ struct background {
 struct output {
struct wl_output *output;
struct wl_list link;
+   uint32_t id;
 
struct panel *panel;
struct background *background;
 };
 
+struct list_item {
+   struct surface *surface;
+   struct widget *widget;
+   struct panel *panel;
+   cairo_surface_t *icon;
+   int focused, highlight;
+   struct wl_list link;
+   struct wl_list surface_link;
+};
+
 struct panel_launcher {
struct widget *widget;
struct panel *panel;
@@ -249,6 +286,15 @@ set_hex_color(cairo_t *cr, uint32_t color)
 }
 
 static void
+get_hex_color_rgba(uint32_t color, float *r, float *g, float *b, float *a)
+{
+   *r = ((color  16)  0xff) / 255.0;
+   *g = ((color   8)  0xff) / 255.0;
+   *b = ((color   0)  0xff) / 255.0;
+   *a = ((color  24)  0xff) / 255.0;
+}
+
+static void
 panel_redraw_handler(struct widget *widget, void *data)
 {
cairo_surface_t *surface;
@@ -421,15 +467,46 @@ panel_button_handler(struct widget *widget,
 }
 
 static void
+panel_window_list_schedule_redraw(struct panel *panel)
+{
+   struct list_item *item;
+   int item_width, padding, x, w;
+
+   /* If there are no window list items, redraw the panel to clear it */
+   if (wl_list_empty(panel-window_list)) {
+   widget_schedule_redraw(panel-widget);
+   return;
+   }
+
+   item_width = (panel-window_list_rect.width / panel-surface_count);
+   padding = 2;
+
+   x = panel-window_list_rect.x + padding;
+   w = MIN(item_width - padding, 200);
+
+   wl_list_for_each(item, panel-window_list, link) {
+   widget_set_allocation(item-widget, x, 4, w, 24);
+
+   x += w + padding;
+   widget_schedule_redraw(item-widget);
+   }
+}
+
+static void
 panel_resize_handler(struct widget *widget,
 int32_t width, int32_t height, void *data)
 {
struct panel_launcher *launcher;
+   struct rectangle launcher_rect;
+   struct rectangle clock_rect;
struct panel *panel = data;
int x, y, w, h;
-   
+
x = 10;
y = 16;
+
+   launcher_rect.x = x;
+
wl_list_for_each(launcher, panel-launcher_list, link) {
w = cairo_image_surface_get_width(launcher-icon);
h = cairo_image_surface_get_height(launcher-icon);
@@ -437,12 +514,25 @@ panel_resize_handler(struct widget *widget,
  x, y - h / 2, w + 1, h + 1);
x += w + 10;
}

[PATCH weston 3/9] shell: Install protocol for minimize, focus and close

[Scott Moreau]

---
 protocol/desktop-shell.xml |   20 
 1 file changed, 20 insertions(+)

diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml
index 2fed660..51219d2 100644
--- a/protocol/desktop-shell.xml
+++ b/protocol/desktop-shell.xml
@@ -87,6 +87,18 @@
The shell can use this interface to receive surface information or make
requests for this surface.
 /description
+request name=minimize
+  description summary=ask the compositor to minimize the surface/
+/request
+request name=unminimize
+  description summary=ask the compositor to unminimize the surface/
+/request
+request name=focus
+  description summary=ask the compositor to focus the surface/
+/request
+request name=close
+  description summary=ask the compositor to close the surface/
+/request
 request name=destroy type=destructor
   description summary=destroy surface request
The shell must send this request in response to a gone event so the
@@ -101,6 +113,14 @@
   description summary=send the surface object title to the shell/
   arg name=title type=string/
 /event
+event name=minimized
+  description summary=send the surface object minimize state to the 
shell/
+  arg name=minimized type=int/
+/event
+event name=focused
+  description summary=send the surface object focus state to the shell/
+  arg name=focused type=int/
+/event
 event name=gone
   description summary=destroy surface notification
The compositor should send this event to notify the shell that a
-- 
1.7.10.4

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

[PATCH weston 5/9] shell: Implement simple dnd for window list item reordering

[Scott Moreau]

This allows the user to rearrange the list items by drag-and-drop. There is no
drag icon, only preliminary functionality. Eventually, this could be expanded
to use the wayland dnd protocol.
---
 clients/desktop-shell.c |   85 +++
 1 file changed, 85 insertions(+)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 582a19f..1fa7387 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -122,8 +122,10 @@ struct list_item {
struct panel *panel;
cairo_surface_t *icon;
int focused, highlight;
+   int x, y;
struct wl_list link;
struct wl_list surface_link;
+   struct wl_list reorder_link;
 };
 
 struct panel_launcher {
@@ -1145,6 +1147,9 @@ panel_list_item_motion_handler(struct widget *widget, 
struct input *input,
 {
struct list_item *item = data;
 
+   item-x = x;
+   item-y = y;
+
widget_set_tooltip(widget, basename((char *)item-surface-title), x, 
y);
 
return CURSOR_LEFT_PTR;
@@ -1156,6 +1161,8 @@ panel_list_item_enter_handler(struct widget *widget, 
struct input *input,
 {
struct list_item *item = data;
 
+   item-x = x;
+   item-y = y;
item-highlight = 1;
item-focused = 1;
widget_schedule_redraw(widget);
@@ -1243,6 +1250,79 @@ list_item_show_menu(struct list_item *item, struct input 
*input, uint32_t time)
list_item_menu_func, entries, MENU_ENTRIES);
 }
 
+static int
+rect_contains_point(struct rectangle rect, int x, int y)
+{
+   int x1, y1, x2, y2;
+
+   x1 = rect.x;
+   y1 = rect.y;
+   x2 = rect.x + rect.width;
+   y2 = rect.y + rect.height;
+
+   if (x  x1  x  x2  y  y1  y  y2)
+   return 1;
+
+   return 0;
+}
+
+static int
+item_contains_point(struct list_item *item, int x, int y)
+{
+   struct rectangle item_rect;
+
+   widget_get_allocation(item-widget, item_rect);
+
+   return rect_contains_point(item_rect, x, y);
+}
+
+static int
+list_contains_point(struct list_item *item, int x, int y)
+{
+   struct rectangle list_rect;
+
+   list_rect = item-panel-window_list_rect;
+
+   return rect_contains_point(list_rect, x, y);
+}
+
+static void
+panel_item_list_reorder(struct panel *panel,
+   struct list_item *current, struct list_item *item)
+{
+   struct rectangle current_rect, item_rect;
+
+   if (current == item)
+   return;
+
+   widget_get_allocation(current-widget, current_rect);
+   widget_get_allocation(item-widget, item_rect);
+
+   wl_list_remove(current-link);
+
+   if (item_rect.x  current_rect.x)
+   wl_list_insert(item-link.prev, current-link);
+   else
+   wl_list_insert(item-link, current-link);
+
+   panel_window_list_schedule_redraw(item-panel);
+}
+
+static void
+list_item_move(struct list_item *current, int x, int y)
+{
+   struct list_item *item;
+
+   wl_list_for_each(item, current-panel-window_list, link) {
+   if (item == current)
+   continue;
+   if (item_contains_point(item, x, y)) {
+   panel_item_list_reorder(item-panel, current, item);
+   return;
+   }
+   }
+}
+
 static void
 panel_list_item_button_handler(struct widget *widget,
  struct input *input, uint32_t time,
@@ -1267,6 +1347,11 @@ panel_list_item_button_handler(struct widget *widget,
return;
 
surface = item-surface;
+   if (!item_contains_point(item, item-x, item-y)) {
+   if (list_contains_point(item, item-x, item-y))
+   list_item_move(item, item-x, item-y);
+   return;
+   }
if (!surface-focused  !surface-minimized) {
surface_data_focus(surface-surface_data);
surface-focused = 1;
-- 
1.7.10.4

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

[PATCH weston 6/9] shell: Install listeners to reflect shell surface protocol changes

[Scott Moreau]

---
 clients/simple-egl.c   |   26 +-
 clients/simple-shm.c   |   26 +-
 clients/simple-touch.c |   26 +-
 clients/window.c   |   26 +-
 src/shell.c|9 -
 5 files changed, 108 insertions(+), 5 deletions(-)

diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index 26ebe5c..d90ecf5 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -246,10 +246,34 @@ handle_popup_done(void *data, struct wl_shell_surface 
*shell_surface)
 {
 }
 
+static void
+handle_maximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_minimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
 static const struct wl_shell_surface_listener shell_surface_listener = {
handle_ping,
handle_configure,
-   handle_popup_done
+   handle_popup_done,
+   handle_maximize,
+   handle_unmaximize,
+   handle_minimize,
+   handle_unminimize
 };
 
 static void
diff --git a/clients/simple-shm.c b/clients/simple-shm.c
index f187b10..ded27c5 100644
--- a/clients/simple-shm.c
+++ b/clients/simple-shm.c
@@ -126,10 +126,34 @@ handle_popup_done(void *data, struct wl_shell_surface 
*shell_surface)
 {
 }
 
+static void
+handle_maximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_minimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
 static const struct wl_shell_surface_listener shell_surface_listener = {
handle_ping,
handle_configure,
-   handle_popup_done
+   handle_popup_done,
+   handle_maximize,
+   handle_unmaximize,
+   handle_minimize,
+   handle_unminimize
 };
 
 static struct window *
diff --git a/clients/simple-touch.c b/clients/simple-touch.c
index b8473f1..8ebb29b 100644
--- a/clients/simple-touch.c
+++ b/clients/simple-touch.c
@@ -233,10 +233,34 @@ handle_popup_done(void *data, struct wl_shell_surface 
*shell_surface)
 {
 }
 
+static void
+handle_maximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_minimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
 static const struct wl_shell_surface_listener shell_surface_listener = {
handle_ping,
handle_configure,
-   handle_popup_done
+   handle_popup_done,
+   handle_maximize,
+   handle_unmaximize,
+   handle_minimize,
+   handle_unminimize
 };
 
 static void
diff --git a/clients/window.c b/clients/window.c
index 249ba6f..d13a1ac 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3313,10 +3313,34 @@ handle_popup_done(void *data, struct wl_shell_surface 
*shell_surface)
menu_destroy(menu);
 }
 
+static void
+handle_maximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_minimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
 static const struct wl_shell_surface_listener shell_surface_listener = {
handle_ping,
handle_configure,
-   handle_popup_done
+   handle_popup_done,
+   handle_maximize,
+   handle_unmaximize,
+   handle_minimize,
+   handle_unminimize
 };
 
 void
diff --git a/src/shell.c b/src/shell.c
index 9e19ddb..f3877d2 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1944,6 +1944,12 @@ shell_surface_set_maximized(struct wl_client *client,
 }
 
 static void
+shell_surface_set_minimized(struct wl_client *client,
+   struct wl_resource *resource)
+{
+}
+
+static void
 black_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy, 
int32_t width, int32_t height);
 
 static struct weston_surface *
@@ -2286,7 +2292,8 @@ static const struct wl_shell_surface_interface 
shell_surface_implementation = {
shell_surface_set_popup,
shell_surface_set_maximized,
shell_surface_set_title,
-   shell_surface_set_class
+   shell_surface_set_class,
+   shell_surface_set_minimized
 };
 
 static void
-- 
1.7.10.4

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

[PATCH weston 7/9] toytoolkit: Enable titlebar minimize button functionality

[Scott Moreau]

---
 clients/window.c |   25 -
 clients/window.h |3 +++
 src/shell.c  |9 -
 3 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index d13a1ac..7093a38 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -220,6 +220,7 @@ struct window {
int resize_needed;
int type;
int focus_count;
+   int minimized;
 
int resizing;
int fullscreen_method;
@@ -1925,7 +1926,7 @@ frame_button_button_handler(struct widget *widget,
display_exit(window-display);
break;
case FRAME_BUTTON_MINIMIZE:
-   fprintf(stderr,Minimize stub\n);
+   window_set_minimized(window, !window-minimized);
break;
case FRAME_BUTTON_MAXIMIZE:
window_set_maximized(window, window-type != TYPE_MAXIMIZED);
@@ -3326,11 +3327,17 @@ handle_unmaximize(void *data, struct wl_shell_surface 
*shell_surface)
 static void
 handle_minimize(void *data, struct wl_shell_surface *shell_surface)
 {
+   struct window *window = data;
+
+   window-minimized = 1;
 }
 
 static void
 handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
 {
+   struct window *window = data;
+
+   window-minimized = 0;
 }
 
 static const struct wl_shell_surface_listener shell_surface_listener = {
@@ -3472,6 +3479,22 @@ window_set_maximized(struct window *window, int 
maximized)
 }
 
 void
+window_set_minimized(struct window *window, int minimized)
+{
+   if (!window-display-shell)
+   return;
+
+   if (window-minimized == minimized)
+   return;
+
+   if (minimized) {
+   wl_shell_surface_set_minimized(window-shell_surface);
+   window-minimized = 1;
+   } else
+   window-minimized = 0;
+}
+
+void
 window_set_user_data(struct window *window, void *data)
 {
window-user_data = data;
diff --git a/clients/window.h b/clients/window.h
index c2946d8..331ce23 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -313,6 +313,9 @@ void
 window_set_maximized(struct window *window, int maximized);
 
 void
+window_set_minimized(struct window *window, int maximized);
+
+void
 window_set_user_data(struct window *window, void *data);
 
 void *
diff --git a/src/shell.c b/src/shell.c
index f3877d2..fd1411b 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1470,6 +1470,9 @@ shell_surface_minimize(struct shell_surface *shsurf)
shsurf-saved_type = shsurf-type;
shsurf-minimized = 1;
 
+   send_surface_data_focused_state(surface);
+   wl_shell_surface_send_minimize(shsurf-resource);
+
/* Focus next surface in stack */
wl_list_for_each(seat, compositor-seat_list, link)
if (seat-seat.keyboard 
@@ -1486,7 +1489,6 @@ shell_surface_minimize(struct shell_surface *shsurf)
wl_keyboard_set_focus(seat-seat.keyboard, 
NULL);
}
 
-   send_surface_data_focused_state(surface);
weston_compositor_damage_all(compositor);
 }
 
@@ -1506,6 +1508,7 @@ surface_unminimize(struct shell_surface *shsurf, struct 
workspace *ws)
shell_surface_focus(shsurf);
send_surface_data_focused_state(surface);
shsurf-minimized = false;
+   wl_shell_surface_send_unminimize(shsurf-resource);
weston_compositor_damage_all(compositor);
 }
 
@@ -1947,6 +1950,10 @@ static void
 shell_surface_set_minimized(struct wl_client *client,
struct wl_resource *resource)
 {
+   struct shell_surface *shsurf = resource-data;
+
+   shell_surface_minimize(shsurf);
+   send_surface_data_minimized_state(shsurf-surface);
 }
 
 static void
-- 
1.7.10.4

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

[PATCH weston 8/9] shell: Install protocol for maximize menu button

[Scott Moreau]

---
 protocol/desktop-shell.xml |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml
index 51219d2..20e2eb9 100644
--- a/protocol/desktop-shell.xml
+++ b/protocol/desktop-shell.xml
@@ -87,6 +87,12 @@
The shell can use this interface to receive surface information or make
requests for this surface.
 /description
+request name=maximize
+  description summary=ask the compositor to maximize the surface/
+/request
+request name=unmaximize
+  description summary=ask the compositor to unmaximize the surface/
+/request
 request name=minimize
   description summary=ask the compositor to minimize the surface/
 /request
@@ -113,6 +119,10 @@
   description summary=send the surface object title to the shell/
   arg name=title type=string/
 /event
+event name=maximized
+  description summary=send the surface object maximize state to the 
shell/
+  arg name=maximized type=int/
+/event
 event name=minimized
   description summary=send the surface object minimize state to the 
shell/
   arg name=minimized type=int/
-- 
1.7.10.4

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

[PATCH weston 9/9] shell: Implement maximize menu button functionality

[Scott Moreau]

Add maximize button for list item drop down menu.
---
 clients/desktop-shell.c |   44 +++-
 clients/window.c|6 ++
 src/shell.c |   23 +++
 3 files changed, 68 insertions(+), 5 deletions(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 1fa7387..4b2f805 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -70,7 +70,7 @@ struct surface {
struct desktop *desktop;
uint32_t output_mask;
char *title;
-   int minimized, focused;
+   int maximized, minimized, focused;
 
/* One window list item per panel of the surface's output_mask */
struct wl_list item_list;
@@ -1159,7 +1159,7 @@ static int
 panel_list_item_enter_handler(struct widget *widget, struct input *input,
 float x, float y, void *data)
 {
-   struct list_item *item = data;
+   struct list_item *item = data, *t_item;
 
item-x = x;
item-y = y;
@@ -1167,6 +1167,13 @@ panel_list_item_enter_handler(struct widget *widget, 
struct input *input,
item-focused = 1;
widget_schedule_redraw(widget);
 
+   wl_list_for_each(t_item, item-panel-window_list, link) {
+   if(item == t_item)
+   continue;
+   t_item-highlight = 0;
+   t_item-focused = 0;
+   }
+
return CURSOR_LEFT_PTR;
 }
 
@@ -1201,7 +1208,17 @@ list_item_menu_handle_button(struct list_item *item, int 
index)
surface-minimized = 1;
}
break;
-   case 1: /* Close */
+   case 1: /* (Un)Maximize */
+   if (surface-maximized) {
+   surface_data_unmaximize(surface-surface_data);
+   surface-maximized = 0;
+   }
+   else {
+   surface_data_maximize(surface-surface_data);
+   surface-maximized = 1;
+   }
+   break;
+   case 2: /* Close */
surface_data_close(surface-surface_data);
break;
default:
@@ -1231,7 +1248,7 @@ list_item_menu_func(struct window *window, int index, 
void *data)
}
 }
 
-#define MENU_ENTRIES 2
+#define MENU_ENTRIES 3
 
 static void
 list_item_show_menu(struct list_item *item, struct input *input, uint32_t time)
@@ -1241,7 +1258,8 @@ list_item_show_menu(struct list_item *item, struct input 
*input, uint32_t time)
static const char *entries[MENU_ENTRIES];
 
entries[0] = item-surface-minimized ? Unminimize : Minimize;
-   entries[1] = Close;
+   entries[1] = item-surface-maximized ? Unmaximize : Maximize;
+   entries[2] = Close;
 
panel = item-panel;
input_get_position(input, x, y);
@@ -1503,6 +1521,21 @@ surface_data_set_title(void *data,
 }
 
 static void
+surface_data_set_maximized_state(void *data,
+   struct surface_data *surface_data,
+   int maximized)
+{
+   struct desktop *desktop;
+   struct surface *surface = data;
+
+   desktop = surface-desktop;
+
+   surface-maximized = maximized;
+
+   desktop_update_list_items(desktop, surface);
+}
+
+static void
 surface_data_set_minimized_state(void *data,
struct surface_data *surface_data,
int minimized)
@@ -1568,6 +1601,7 @@ surface_data_destroy_handler(void *data, struct 
surface_data *surface_data)
 static const struct surface_data_listener surface_data_listener = {
surface_data_set_output_mask,
surface_data_set_title,
+   surface_data_set_maximized_state,
surface_data_set_minimized_state,
surface_data_set_focused_state,
surface_data_destroy_handler
diff --git a/clients/window.c b/clients/window.c
index 7093a38..d5a1898 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3317,11 +3317,17 @@ handle_popup_done(void *data, struct wl_shell_surface 
*shell_surface)
 static void
 handle_maximize(void *data, struct wl_shell_surface *shell_surface)
 {
+   struct window *window = data;
+
+   window_set_maximized(window, 1);
 }
 
 static void
 handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
 {
+   struct window *window = data;
+
+   window_set_maximized(window, 0);
 }
 
 static void
diff --git a/src/shell.c b/src/shell.c
index fd1411b..1e2eb52 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1508,6 +1508,7 @@ surface_unminimize(struct shell_surface *shsurf, struct 
workspace *ws)
shell_surface_focus(shsurf);
send_surface_data_focused_state(surface);
shsurf-minimized = false;
+   shsurf-type = shsurf-saved_type;
wl_shell_surface_send_unminimize(shsurf-resource);
weston_compositor_damage_all(compositor);
 }
@@ -1526,6 +1527,24 @@ shell_surface_unminimize(struct shell_surface 

[PATCH weston] compositor-x11: Consider output position when computing relative motion

[Scott Moreau]

This fixes pointer movement for multiple x11 outputs. This was broken
when switching to relative events.
---

I do not currently have a multi-output setup to test drm but it's possible that
evdev needs a similar fix.

 src/compositor-x11.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 8e052dd..db51409 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -1012,8 +1012,8 @@ x11_compositor_deliver_motion_event(struct x11_compositor 
*c,
output = x11_compositor_find_output(c, motion_notify-event);
x = wl_fixed_from_int(motion_notify-event_x - c-prev_x);
y = wl_fixed_from_int(motion_notify-event_y - c-prev_y);
-   c-prev_x = motion_notify-event_x;
-   c-prev_y = motion_notify-event_y;
+   c-prev_x = motion_notify-event_x + output-base.x;
+   c-prev_y = motion_notify-event_y + output-base.y;
x11_output_transform_coordinate(output, x, y);
 
notify_motion(c-core_seat, weston_compositor_get_time(), x, y);
@@ -1033,8 +1033,8 @@ x11_compositor_deliver_enter_event(struct x11_compositor 
*c,
if (!c-has_xkb)
update_xkb_state_from_core(c, enter_notify-state);
output = x11_compositor_find_output(c, enter_notify-event);
-   c-prev_x = enter_notify-event_x;
-   c-prev_y = enter_notify-event_y;
+   c-prev_x = enter_notify-event_x + output-base.x;
+   c-prev_y = enter_notify-event_y + output-base.y;
x = wl_fixed_from_int(enter_notify-event_x);
y = wl_fixed_from_int(enter_notify-event_y);
x11_output_transform_coordinate(output, x, y);
-- 
1.7.10.4

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

Re: More problems building xserver

[Scott Moreau]

On Mon, Mar 4, 2013 at 11:08 AM, Fred Ollinger folli...@gmail.com wrote:

 If you have the binary packages, this is obviously quicker, but I
 found that the easiest thing to do is to google the name plus source
 code and I usually found the source.

 I stuff all the deps into /opt/wayland which wound up (for most
 packages) to be quicker than tracking down the right vers of pre-build
 binaries.

 Fred


I've found the easiest way is to use packages.ubuntu.com and search for the
filename under 'Search the contents of packages'. You can get the name of
the package in ubuntu repos which should also serve as a hint for other
distros.

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

Re: Getting GTK XWayland applications to use the system's GTK theme

[Scott Moreau]

Hi Rune,

On Sat, Mar 2, 2013 at 9:16 PM, Rune Kjær Svendsen runesv...@gmail.comwrote:

 Hello list

 I'm having trouble getting GTK applications running as XWayland client to
 use my system's GTK theme.


In traditional X, the client draws it's content and the window manager or
other process decorates the windows. It's not much different with xwayland.
Xwayland clients draw their contents and the window manager draws the
decorations. In this case, the window manager is a special window manager
integrated with weston. As it stands currently, weston's xwm draws a static
decoration for all xwayland surfaces and does not support theming.


 I run Ubuntu 12.10, and everything just works wrt. GTK themes here (with
 Unity and compiz). But when I run weston (whether it be using the DRM or X
 backend) and launch GTK clients, most of them load a different theme than
 Ubuntu's default one (Ambiance).

 Here's a screenshot showcasing different applications running as XWayland
 clients with the DRM backend: http://i.imgur.com/lvUbYIb.png

 It seems that some pick up the right GTK theme (font viewer looks good,
 and gedit and gnome-control-center also look good, although they don't use
 the grey buttons), but most of them don't.

 What could be the cause of this?


For gtk applications, you should use the native gtk+ wayland backend. You
can optionally build the wip/csd branch of gtk+ master for decorations.
There is no theming support in this branch, as far as I know.



 /Rune


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

Re: Patch queue update

[Scott Moreau]

 * surface_data and surface panel list (Scott Moreau)

   - This one was in good shape at the last resend, but I think there
 was a few more issues we still we discussion.  I forget (sorry).


Hi Kristian, you reviewed the main patch and commented here:
http://lists.freedesktop.org/archives/wayland-devel/2012-November/006485.html
I haven't forgot about it, I plan to fix the issues you mentioned and
continue with
v3.



 * resize from center (Scott Moreau)

   - I think we got stuck discussion how to trigger resize-from-center.
 I think we can just handle it in the compositor, by remembering
 the initial center (pre-resize) and then center the window there
 if shift is pressed during resize, and jump back to normal
 resizing if shift is released.

   - Scott said he got the idea working, but still some issues to work
 out.


Right, so the main problem here is not resize from center but the ability
to toggle
between this mode and normal resizing. See the comment here:
http://lists.freedesktop.org/archives/wayland-devel/2013-February/007359.html

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