date:20140709

Re: [PATCH libinput] tablet: Rename TILT_VERTICAL and TILT_HORIZONTAL to TILT_X and TILT_Y

2014-07-09 Thread Peter Hutterer

On Wed, Jul 09, 2014 at 01:14:48AM -0400, Stephen Chandler Paul wrote:
> Since the orientation of the tablet can potentially change, this naming scheme
> makes a lot more sense then VERTICAL and HORIZONTAL does since they don't
> reflect the actual physical movement.
> 
> Signed-off-by: Stephen Chandler Paul 

merged, thanks

Cheers,
   Peter

> ---
>  src/evdev-tablet.c  |  4 ++--
>  src/evdev-tablet.h  |  8 
>  src/libinput.h  | 13 ++---
>  test/tablet.c   | 16 
>  tools/event-debug.c |  8 
>  5 files changed, 24 insertions(+), 25 deletions(-)
> 
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index 051c3b4..d1ad4bb 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -149,8 +149,8 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
>   case LIBINPUT_TABLET_AXIS_PRESSURE:
>   tablet->axes[a] = normalize_pressure_or_dist(absinfo);
>   break;
> - case LIBINPUT_TABLET_AXIS_TILT_VERTICAL:
> - case LIBINPUT_TABLET_AXIS_TILT_HORIZONTAL:
> + case LIBINPUT_TABLET_AXIS_TILT_X:
> + case LIBINPUT_TABLET_AXIS_TILT_Y:
>   tablet->axes[a] = normalize_tilt(absinfo);
>   break;
>   default:
> diff --git a/src/evdev-tablet.h b/src/evdev-tablet.h
> index 4de4cec..74447bd 100644
> --- a/src/evdev-tablet.h
> +++ b/src/evdev-tablet.h
> @@ -75,10 +75,10 @@ evcode_to_axis(const uint32_t evcode)
>   axis = LIBINPUT_TABLET_AXIS_PRESSURE;
>   break;
>   case ABS_TILT_X:
> - axis = LIBINPUT_TABLET_AXIS_TILT_HORIZONTAL;
> + axis = LIBINPUT_TABLET_AXIS_TILT_Y;
>   break;
>   case ABS_TILT_Y:
> - axis = LIBINPUT_TABLET_AXIS_TILT_VERTICAL;
> + axis = LIBINPUT_TABLET_AXIS_TILT_X;
>   break;
>   default:
>   axis = LIBINPUT_TABLET_AXIS_NONE;
> @@ -106,10 +106,10 @@ axis_to_evcode(const enum libinput_tablet_axis axis)
>   case LIBINPUT_TABLET_AXIS_PRESSURE:
>   evcode = ABS_PRESSURE;
>   break;
> - case LIBINPUT_TABLET_AXIS_TILT_VERTICAL:
> + case LIBINPUT_TABLET_AXIS_TILT_X:
>   evcode = ABS_TILT_X;
>   break;
> - case LIBINPUT_TABLET_AXIS_TILT_HORIZONTAL:
> + case LIBINPUT_TABLET_AXIS_TILT_Y:
>   evcode = ABS_TILT_Y;
>   break;
>   default:
> diff --git a/src/libinput.h b/src/libinput.h
> index fa87094..14e533e 100644
> --- a/src/libinput.h
> +++ b/src/libinput.h
> @@ -182,9 +182,9 @@ enum libinput_tablet_axis {
>   LIBINPUT_TABLET_AXIS_Y = 1,
>   LIBINPUT_TABLET_AXIS_DISTANCE = 2,
>   LIBINPUT_TABLET_AXIS_PRESSURE = 3,
> - LIBINPUT_TABLET_AXIS_TILT_VERTICAL = 4,
> - LIBINPUT_TABLET_AXIS_TILT_HORIZONTAL = 5,
> - LIBINPUT_TABLET_AXIS_CNT = LIBINPUT_TABLET_AXIS_TILT_HORIZONTAL + 1
> + LIBINPUT_TABLET_AXIS_TILT_X = 4,
> + LIBINPUT_TABLET_AXIS_TILT_Y = 5,
> + LIBINPUT_TABLET_AXIS_CNT = LIBINPUT_TABLET_AXIS_TILT_Y + 1
>  };
>  
>  /**
> @@ -871,10 +871,9 @@ libinput_event_tablet_axis_has_changed(struct 
> libinput_event_tablet *event,
>   *   sensor, normalized from 0 to 1
>   * - @ref LIBINPUT_TABLET_AXIS_PRESSURE - The current pressure being applied 
> on
>   *   the tool in use, normalized from 0 to 1
> - * - @ref LIBINPUT_TABLET_AXIS_TILT_VERTICAL and @ref
> - *   LIBINPUT_TABLET_AXIS_TILT_HORIZONTAL - normalized value between -1 and 1
> - *   that indicates the tilt vertical or horizontal tilt of the tool
> - *   respectively
> + * - @ref LIBINPUT_TABLET_AXIS_TILT_X and @ref LIBINPUT_TABLET_AXIS_TILT_Y -
> + *   normalized value between -1 and 1 that indicates the X or Y tilt of the
> + *   tool
>   *
>   * @param event The libinput tablet event
>   * @param axis The axis to retrieve the value of
> diff --git a/test/tablet.c b/test/tablet.c
> index 7069074..0cd6357 100644
> --- a/test/tablet.c
> +++ b/test/tablet.c
> @@ -403,22 +403,22 @@ START_TEST(normalization)
>  
>   if (libinput_event_tablet_axis_has_changed(
>   tablet_event,
> - LIBINPUT_TABLET_AXIS_TILT_VERTICAL)) {
> + LIBINPUT_TABLET_AXIS_TILT_X)) {
>   tilt_vertical =
>   libinput_event_tablet_get_axis_value(
>   tablet_event,
> - LIBINPUT_TABLET_AXIS_TILT_VERTICAL);
> + LIBINPUT_TABLET_AXIS_TILT_X);
>  
>   litest_assert_double_eq(tilt_vertical, -1);
>   }
>  
>   if (libinput_event_tablet_axis_has_changed(
>   tablet_event,
> - LIBINPUT_TABLET_AXIS_TILT_HORIZONTAL)) {
> +

Re: [PATCH 10/11] weston-image --help works. Also help if no filename is given

2014-07-09 Thread Jason Ekstrand

On Jul 9, 2014 6:17 PM, "Jason Ekstrand"  wrote:
>
>
> On Jul 8, 2014 9:18 PM, "Bill Spitzak"  wrote:
> >
> > ---
> >  clients/image.c |5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/clients/image.c b/clients/image.c
> > index 112b93d..573117c 100644
> > --- a/clients/image.c
> > +++ b/clients/image.c
> > @@ -412,6 +412,11 @@ main(int argc, char *argv[])
> > int i;
> > int image_counter = 0;
> >
> > +   if (argc <= 1 || argv[1][0]=='-') {
> > +   printf("Usage: %s image...\n", argv[0]);
> > +   return 1;
> > +   }
> > +
>
> One little nitpick: Should we really be returning 1 if --help is given?
That's not an error.

On second thought, I ran a bunch of little utilities and things and some of
them always given an error with the usage and others don't.  However, if
we're going to claim to have a --help or -h option, we shouldn't error on
it.  Considering it to be malformed input and printing an error message is
fine.

Perhaps the thing to do in this client is to simply have failing to open
the file dump the usage.

>
> > d = display_create(&argc, argv);
> > if (d == NULL) {
> > fprintf(stderr, "failed to create display: %m\n");
> > --
> > 1.7.9.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 10/11] weston-image --help works. Also help if no filename is given

2014-07-09 Thread Jason Ekstrand

On Jul 8, 2014 9:18 PM, "Bill Spitzak"  wrote:
>
> ---
>  clients/image.c |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/clients/image.c b/clients/image.c
> index 112b93d..573117c 100644
> --- a/clients/image.c
> +++ b/clients/image.c
> @@ -412,6 +412,11 @@ main(int argc, char *argv[])
> int i;
> int image_counter = 0;
>
> +   if (argc <= 1 || argv[1][0]=='-') {
> +   printf("Usage: %s image...\n", argv[0]);
> +   return 1;
> +   }
> +

One little nitpick: Should we really be returning 1 if --help is given?
That's not an error.

> d = display_create(&argc, argv);
> if (d == NULL) {
> fprintf(stderr, "failed to create display: %m\n");
> --
> 1.7.9.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 0/2] Implement layer clipping

2014-07-09 Thread Giulio Camuffo

This is a resend of my layer clipping patch, rebased on top of current master.
I *really* hope it doesn't die of age on the list again.

--

Giulio Camuffo (2):
  compositor: keep track of the weston_layer a weston_view is in
  compositor: add a masking mechanism to weston_layer

 desktop-shell/exposay.c |   4 +-
 desktop-shell/input-panel.c |   7 ++-
 desktop-shell/shell.c   | 145 +++-
 src/compositor.c|  94 
 src/compositor.h|  24 +++-
 src/data-device.c   |   6 +-
 src/gl-renderer.c   |   2 +-
 src/input.c |   4 +-
 src/pixman-renderer.c   |   2 +-
 tests/weston-test.c |   6 +-
 10 files changed, 197 insertions(+), 97 deletions(-)

-- 
2.0.0

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

[PATCH weston 2/2] compositor: add a masking mechanism to weston_layer

2014-07-09 Thread Giulio Camuffo

this adds a mechanism to mask the views belonging to a layer
to an arbitrary rect, in the global space. The parts that don't fit
in that rect will be clipped away.
Supported by the gl and pixman renderer only for now.
---
 src/compositor.c  | 61 ---
 src/compositor.h  | 10 +
 src/gl-renderer.c |  2 +-
 src/pixman-renderer.c |  2 +-
 4 files changed, 70 insertions(+), 5 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index 1d8d00e..2b52b4f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -349,8 +349,11 @@ weston_view_create(struct weston_surface *surface)
 
view->plane = NULL;
view->layer_link.layer = NULL;
+   view->parent_view = NULL;
 
pixman_region32_init(&view->clip);
+   pixman_region32_init(&view->transform.masked_boundingbox);
+   pixman_region32_init(&view->transform.masked_opaque);
 
view->alpha = 1.0;
pixman_region32_init(&view->transform.opaque);
@@ -783,7 +786,7 @@ weston_view_damage_below(struct weston_view *view)
pixman_region32_t damage;
 
pixman_region32_init(&damage);
-   pixman_region32_subtract(&damage, &view->transform.boundingbox,
+   pixman_region32_subtract(&damage, &view->transform.masked_boundingbox,
 &view->clip);
if (view->plane)
pixman_region32_union(&view->plane->damage,
@@ -1009,10 +1012,20 @@ weston_view_update_transform_enable(struct weston_view 
*view)
return 0;
 }
 
+static struct weston_layer *
+get_view_layer(struct weston_view *view)
+{
+   if (view->parent_view)
+   return get_view_layer(view->parent_view);
+   return view->layer_link.layer;
+}
+
 WL_EXPORT void
 weston_view_update_transform(struct weston_view *view)
 {
struct weston_view *parent = view->geometry.parent;
+   struct weston_layer *layer;
+   pixman_region32_t mask;
 
if (!view->transform.dirty)
return;
@@ -1040,6 +1053,16 @@ weston_view_update_transform(struct weston_view *view)
weston_view_update_transform_disable(view);
}
 
+   layer = get_view_layer(view);
+   if (layer) {
+   pixman_region32_init_with_extents(&mask, &layer->mask);
+   pixman_region32_intersect(&view->transform.masked_boundingbox,
+   &view->transform.boundingbox, &mask);
+   pixman_region32_intersect(&view->transform.masked_opaque,
+   &view->transform.opaque, &mask);
+   pixman_region32_fini(&mask);
+   }
+
weston_view_damage_below(view);
 
weston_view_assign_output(view);
@@ -1331,10 +1354,15 @@ weston_compositor_pick_view(struct weston_compositor 
*compositor,
wl_fixed_t *vx, wl_fixed_t *vy)
 {
struct weston_view *view;
+int ix = wl_fixed_to_int(x);
+int iy = wl_fixed_to_int(y);
 
wl_list_for_each(view, &compositor->view_list, link) {
weston_view_from_global_fixed(view, x, y, vx, vy);
-   if (pixman_region32_contains_point(&view->surface->input,
+   if (pixman_region32_contains_point(
+   &view->transform.masked_boundingbox,
+  ix, iy, NULL) &&
+   pixman_region32_contains_point(&view->surface->input,
   wl_fixed_to_int(*vx),
   wl_fixed_to_int(*vy),
   NULL))
@@ -1426,6 +1454,8 @@ weston_view_destroy(struct weston_view *view)
 
pixman_region32_fini(&view->clip);
pixman_region32_fini(&view->transform.boundingbox);
+   pixman_region32_fini(&view->transform.masked_boundingbox);
+   pixman_region32_fini(&view->transform.masked_opaque);
 
weston_view_set_transform_parent(view, NULL);
 
@@ -1625,7 +1655,7 @@ view_accumulate_damage(struct weston_view *view,
  &view->plane->damage, &damage);
pixman_region32_fini(&damage);
pixman_region32_copy(&view->clip, opaque);
-   pixman_region32_union(opaque, opaque, &view->transform.opaque);
+   pixman_region32_union(opaque, opaque, &view->transform.masked_opaque);
 }
 
 static void
@@ -1740,6 +1770,7 @@ view_list_add_subsurface_view(struct weston_compositor 
*compositor,
weston_view_set_transform_parent(view, parent);
}
 
+   view->parent_view = parent;
weston_view_update_transform(view);
 
if (wl_list_empty(&sub->surface->subsurface_list)) {
@@ -1933,11 +1964,35 @@ weston_layer_init(struct weston_layer *layer, struct 
wl_list *below)
 {
wl_list_init(&layer->view_list.link);
layer->view_list.layer = layer;
+   weston_layer_set_mask_infinite(layer);
if (below !=

[PATCH weston 1/2] compositor: keep track of the weston_layer a weston_view is in

2014-07-09 Thread Giulio Camuffo

This introduces a new struct, weston_layer_entry, which is now used
in place of wl_list to keep the link for the layer list in weston_view
and the head of the list in weston_layer.
weston_layer_entry also has a weston_layer*, which points to the layer
the view is in or, in the case the entry it's the head of the list, to
the layer itself.
---
 desktop-shell/exposay.c |   4 +-
 desktop-shell/input-panel.c |   7 ++-
 desktop-shell/shell.c   | 145 +++-
 src/compositor.c|  33 +++---
 src/compositor.h|  14 -
 src/data-device.c   |   6 +-
 src/input.c |   4 +-
 tests/weston-test.c |   6 +-
 8 files changed, 127 insertions(+), 92 deletions(-)

diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index 104b9d9..4b65cbd 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -219,7 +219,7 @@ exposay_layout(struct desktop_shell *shell, struct 
shell_output *shell_output)
int last_row_removed = 0;
 
eoutput->num_surfaces = 0;
-   wl_list_for_each(view, &workspace->layer.view_list, layer_link) {
+   wl_list_for_each(view, &workspace->layer.view_list.link, 
layer_link.link) {
if (!get_shell_surface(view->surface))
continue;
if (view->output != output)
@@ -272,7 +272,7 @@ exposay_layout(struct desktop_shell *shell, struct 
shell_output *shell_output)
eoutput->surface_size = output->height / 2;
 
i = 0;
-   wl_list_for_each(view, &workspace->layer.view_list, layer_link) {
+   wl_list_for_each(view, &workspace->layer.view_list.link, 
layer_link.link) {
int pad;
 
pad = eoutput->surface_size + eoutput->padding_inner;
diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
index 7623f6c..47bd73c 100644
--- a/desktop-shell/input-panel.c
+++ b/desktop-shell/input-panel.c
@@ -75,8 +75,8 @@ show_input_panel_surface(struct input_panel_surface *ipsurf)
weston_view_set_position(ipsurf->view, x, y);
}
 
-   wl_list_insert(&shell->input_panel_layer.view_list,
-  &ipsurf->view->layer_link);
+   weston_layer_entry_insert(&shell->input_panel_layer.view_list,
+ &ipsurf->view->layer_link);
weston_view_geometry_dirty(ipsurf->view);
weston_view_update_transform(ipsurf->view);
weston_surface_damage(ipsurf->surface);
@@ -135,7 +135,8 @@ hide_input_panels(struct wl_listener *listener, void *data)
wl_list_remove(&shell->input_panel_layer.link);
 
wl_list_for_each_safe(view, next,
- &shell->input_panel_layer.view_list, layer_link)
+ &shell->input_panel_layer.view_list.link,
+ layer_link.link)
weston_view_unmap(view);
 }
 
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f22cef8..6f6e25c 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -279,12 +279,12 @@ shell_surface_is_top_fullscreen(struct shell_surface 
*shsurf)
 
shell = shell_surface_get_shell(shsurf);
 
-   if (wl_list_empty(&shell->fullscreen_layer.view_list))
+   if (wl_list_empty(&shell->fullscreen_layer.view_list.link))
return false;
 
-   top_fs_ev = container_of(shell->fullscreen_layer.view_list.next,
+   top_fs_ev = container_of(shell->fullscreen_layer.view_list.link.next,
 struct weston_view,
-layer_link);
+layer_link.link);
return (shsurf == get_shell_surface(top_fs_ev->surface));
 }
 
@@ -361,7 +361,7 @@ get_output_panel_height(struct desktop_shell *shell,
if (!output)
return 0;
 
-   wl_list_for_each(view, &shell->panel_layer.view_list, layer_link) {
+   wl_list_for_each(view, &shell->panel_layer.view_list.link, 
layer_link.link) {
if (view->surface->output == output) {
panel_height = view->surface->height;
break;
@@ -675,7 +675,8 @@ focus_state_surface_destroy(struct wl_listener *listener, 
void *data)
main_surface = weston_surface_get_main_surface(state->keyboard_focus);
 
next = NULL;
-   wl_list_for_each(view, &state->ws->layer.view_list, layer_link) {
+   wl_list_for_each(view,
+&state->ws->layer.view_list.link, layer_link.link) {
if (view->surface == main_surface)
continue;
if (is_focus_view(view))
@@ -854,8 +855,8 @@ animate_focus_change(struct desktop_shell *shell, struct 
workspace *ws,
 
focus_surface_created = true;
} else {
-   wl_list_remove(&ws->fsurf_front->view->layer_link);
-   wl_list_remove(&ws->fsurf_back->view->layer_link);

RealVNC Wayland developer preview

2014-07-09 Thread Andrew Wedgbury

Hi,

As some of you may know, I've been working on VNC remote access for Wayland, on 
behalf of my employer, RealVNC.

Since this has now reached a point where it is quite usable, we'd like to make 
a preview version freely available for Wayland developers. I should stress that 
this is commercial software - although the basic version is always free to use, 
and we have included a license which unlocks all of the "Enterprise" features 
that are supported on Wayland for the purposes of development and testing. The 
release is in the form of binaries for 32bit and 64bit Linux, which should be 
installed alongside our existing VNC Server software.

This release is compiled against Wayland and Weston master branches as of 
2014-07-01 (Wayland commit 113aac5 and Weston commit 32abdbb), and we will be 
making periodic releases to keep these up to date. We specifically use the 
_wl_fullscreen_shell and xdg_shell interfaces from Weston.

For more information, and to download the software, please go to:
http://www.realvnc.com/products/vnc/wayland/

Please note that this is intended as a preview release aimed at Wayland 
developers, and you will require knowledge of how to build the latest versions 
of Wayland and Weston in order to use it.

The reason we are doing this is simple - our software supports a wide range of 
platforms and technologies, and we see Wayland as an important emerging 
technology. We rely on the screen-share module in Weston to support remote 
access to existing Weston desktops, and we want to encourage the developers of 
other Wayland compositors and desktop environments to implement compatible 
mechanisms to allow remote access (not just to support VNC, but any remote 
access system).

Please direct any feedback or questions regarding this to 
waylandsupp...@realvnc.com, since it's probably not appropriate to discuss here 
(unless it relates to a generic Wayland/Weston issue).

Regards,

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

Re: Weston IVI-Shell GitHub repo

2014-07-09 Thread Manuel Bachmann

You are very welcome, Nabuhiko !

So, regarding the GitHub repo, looks like I managed to do it as promised.

Here is what has just been done :

- the homepage (https://github.com/Tarnyko/weston-ivi-shell/) now displays
an introduction, screenshot, and quick installation procedure ;

- the latest "IVI-Shell v6" patches have been merged in a new branch
("weston150_ivi-shell_v6") which is now the default ;

- the v6 patches have been rebased for latest master in a new branch
("master_ivi-shell_v6"). Beware, I needed to adapt the last 9/9 slightly
(look at "
https://github.com/Tarnyko/weston-ivi-shell/commit/b7fc0e251129a245da7a176aebdb106ef65c5940#diff-f75861e3924903672183c98007852192R370";,
the "fullscreen" part). Plus, it doesn't build, but vanilla master does not
build either, so I guess we are not guilty.

Regards,


2014-07-09 11:41 GMT+02:00 Tanibata, Nobuhiko (ADITJ/SWG) <
ntanib...@jp.adit-jv.com>:

> Hi Manuel,
>
>
>
> Thank you very much for supporting!
>
>
>
> >(3) : http://www.tarnyko.net/repo/weston-ivi-shell.png
>
>
> http://lists.freedesktop.org/archives/wayland-devel/attachments/20140625/abbfc064/attachment-0001.png
>
>
>
> The above png might be helpful for what it looks like currently.
>
>
>
> BR,
>
> ntanibata
>
>
>
> *From:* wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org]
> *On Behalf Of *Manuel Bachmann
> *Sent:* Wednesday, July 09, 2014 4:47 PM
> *To:* wayland-devel@lists.freedesktop.org
> *Subject:* Weston IVI-Shell GitHub repo
>
>
>
> Hi folks,
>
> This is about the IVI-Shell patches, which are provided and frequently
> updated by TANIBATA Nabuhiko, the main developer and maintainer of the
> IVI-Shell project.
>
> Just to act as a reminder, IVI-Shell is providing a Weston shell
> interface, linked to the GENIVI API which targets In-Vehicle Infotainment
> systems  (1)..
>
>
> And as a reminder too, here is a previous patch set (2).
> --
>
> I have setup a GitHub repo, which is basically a copy of the weston repo,
> but with the IVI patches applied :
> https://github.com/Tarnyko/weston-ivi-shell .
>
> There is only one branch currently ("weston150_ivi-shell", which is 1.5.0
> release) but I will create a "master_ivi-shell" which will follow master
> with the latest updates.
>
> So with this repo, testing the latest IVI-Shell code will only be a matter
> of fetching and rebuilding.
>
>
>
> (here is what it looks like currently : (3))
>
> Hope it helps !
>
>
> (1) : http://www.genivi.org/
> (2) :
> http://lists.freedesktop.org/archives/wayland-devel/2014-June/015617.html
> (3) : http://www.tarnyko.net/repo/weston-ivi-shell.png
> --
>
> Regards,
>
> *Manuel BACHMANN*
>
> *Tizen ProjectVANNES-FR*
>



-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/3] tests: remove assert from frame_callback_wait()

2014-07-09 Thread Marek Chalupa

On 7 July 2014 17:22, Pekka Paalanen  wrote:

> On Mon, 26 May 2014 16:58:06 +0200
> Marek Chalupa  wrote:
>
> > This function did dispatching wrapped in assert so when an error came,
> > the test was aborted. Now, with expect_protocol_error, we need
> > this function to abort only when we are not calling expect_protocol_error
> > afterwards. So instead of calling the assert inside of this function,
> > wrap this function into assert in appropriate places.
> > ---
> >  tests/event-test.c| 6 +++---
> >  tests/weston-test-client-helper.c | 7 +--
> >  tests/weston-test-client-helper.h | 2 +-
> >  3 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/tests/event-test.c b/tests/event-test.c
> > index 980dfaa..facce49 100644
> > --- a/tests/event-test.c
> > +++ b/tests/event-test.c
> > @@ -395,7 +395,7 @@ TEST(buffer_release)
> >   wl_surface_attach(surface, buf2, 0, 0);
> >   frame_callback_set(surface, &frame);
> >   wl_surface_commit(surface);
> > - frame_callback_wait(client, &frame);
> > + assert(frame_callback_wait(client, &frame));
> >   assert(buf1_released == 0);
> >   /* buf2 may or may not be released */
> >   assert(buf3_released == 0);
> > @@ -403,7 +403,7 @@ TEST(buffer_release)
> >   wl_surface_attach(surface, buf3, 0, 0);
> >   frame_callback_set(surface, &frame);
> >   wl_surface_commit(surface);
> > - frame_callback_wait(client, &frame);
> > + assert(frame_callback_wait(client, &frame));
> >   assert(buf1_released == 0);
> >   assert(buf2_released == 1);
> >   /* buf3 may or may not be released */
> > @@ -411,7 +411,7 @@ TEST(buffer_release)
> >   wl_surface_attach(surface, client->surface->wl_buffer, 0, 0);
> >   frame_callback_set(surface, &frame);
> >   wl_surface_commit(surface);
> > - frame_callback_wait(client, &frame);
> > + assert(frame_callback_wait(client, &frame));
> >   assert(buf1_released == 0);
> >   assert(buf2_released == 1);
> >   assert(buf3_released == 1);
> > diff --git a/tests/weston-test-client-helper.c
> b/tests/weston-test-client-helper.c
> > index fb2e477..f0b1b06 100644
> > --- a/tests/weston-test-client-helper.c
> > +++ b/tests/weston-test-client-helper.c
> > @@ -80,12 +80,15 @@ frame_callback_set(struct wl_surface *surface, int
> *done)
> >   return callback;
> >  }
> >
> > -void
> > +int
> >  frame_callback_wait(struct client *client, int *done)
> >  {
> >   while (!*done) {
> > - assert(wl_display_dispatch(client->wl_display) >= 0);
> > + if (wl_display_dispatch(client->wl_display) < 0)
> > + return 0;
> >   }
> > +
> > + return 1;
> >  }
> >
> >  void
> > diff --git a/tests/weston-test-client-helper.h
> b/tests/weston-test-client-helper.h
> > index f154661..18c9e39 100644
> > --- a/tests/weston-test-client-helper.h
> > +++ b/tests/weston-test-client-helper.h
> > @@ -120,7 +120,7 @@ move_client(struct client *client, int x, int y);
> >  struct wl_callback *
> >  frame_callback_set(struct wl_surface *surface, int *done);
> >
> > -void
> > +int
> >  frame_callback_wait(struct client *client, int *done);
> >
>
> Hi,
>
> I think you may have missed the frame_callback_wait() in
> move_client().
>

Yes


>
> If a test is calling frame_callback_wait() without assert() and
> without expect_protocol_error(), and simply returns from the test
> function, do we still get a test failure if there was any error?
>
>
No. There's no way how to fail the test without manually checking for
errors, because the wl_display object is not accessible to the test-runner
and if
the test is not aborted from inside, the test_run function returns
EXIT_SUCCESS.
So if programmer doesn't check for errors at the end of the test, the test
won't fail if there's an error.
Here in libwayland:
http://lists.freedesktop.org/archives/wayland-devel/2014-May/015096.html
I solved it by checking for errors in destroying client (in
client_disconnect function).

Another solution is to return EXIT_FAILURE (or another non-zero value) from
the test_run (
http://cgit.freedesktop.org/wayland/weston/tree/tests/weston-test-runner.c#n55
)
which would force the programmers to call exit(0) upon successful end of
test. This would require to rewrite (add exit(0) at the end of) all the
tests, though.


> Maybe it would be better to leave frame_callback_wait() as is, and
> add a new function frame_callback_wait_nofail() or something that
> would not cause the test to fail if it hits an error from
> wl_display. The change would be smaller to the test code, and
> uncaught uses of the old function would not be silent false-passes.
>
>
Yea, maybe it's better.


>
> Thanks,
> pq
>

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

RE: Weston IVI-Shell GitHub repo

2014-07-09 Thread Tanibata, Nobuhiko (ADITJ/SWG)

Hi Manuel,

 

Thank you very much for supporting!

 

>(3) : http://www.tarnyko.net/repo/weston-ivi-shell.png 
> 

http://lists.freedesktop.org/archives/wayland-devel/attachments/20140625/abbfc064/attachment-0001.png

 

The above png might be helpful for what it looks like currently. 

 

BR,

ntanibata

 

From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Manuel Bachmann
Sent: Wednesday, July 09, 2014 4:47 PM
To: wayland-devel@lists.freedesktop.org
Subject: Weston IVI-Shell GitHub repo

 

Hi folks,

This is about the IVI-Shell patches, which are provided and frequently updated 
by TANIBATA Nabuhiko, the main developer and maintainer of the IVI-Shell 
project.

Just to act as a reminder, IVI-Shell is providing a Weston shell interface, 
linked to the GENIVI API which targets In-Vehicle Infotainment systems  (1)..


And as a reminder too, here is a previous patch set (2).
--

I have setup a GitHub repo, which is basically a copy of the weston repo, but 
with the IVI patches applied : https://github.com/Tarnyko/weston-ivi-shell .

There is only one branch currently ("weston150_ivi-shell", which is 1.5.0 
release) but I will create a "master_ivi-shell" which will follow master with 
the latest updates.

So with this repo, testing the latest IVI-Shell code will only be a matter of 
fetching and rebuilding.

 

(here is what it looks like currently : (3))

Hope it helps !


(1) : http://www.genivi.org/
(2) : http://lists.freedesktop.org/archives/wayland-devel/2014-June/015617.html
(3) : http://www.tarnyko.net/repo/weston-ivi-shell.png 
 
-- 

Regards,

Manuel BACHMANN
Tizen Project
VANNES-FR

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

Weston IVI-Shell GitHub repo

2014-07-09 Thread Manuel Bachmann

Hi folks,

This is about the IVI-Shell patches, which are provided and frequently
updated by TANIBATA Nabuhiko, the main developer and maintainer of the
IVI-Shell project.

Just to act as a reminder, IVI-Shell is providing a Weston shell interface,
linked to the GENIVI API which targets In-Vehicle Infotainment systems
(1)..

And as a reminder too, here is a previous patch set (2).
--
I have setup a GitHub repo, which is basically a copy of the weston repo,
but with the IVI patches applied :
https://github.com/Tarnyko/weston-ivi-shell .

There is only one branch currently ("weston150_ivi-shell", which is 1.5.0
release) but I will create a "master_ivi-shell" which will follow master
with the latest updates.

So with this repo, testing the latest IVI-Shell code will only be a matter
of fetching and rebuilding.

(here is what it looks like currently : (3))

Hope it helps !

(1) : http://www.genivi.org/
(2) :
http://lists.freedesktop.org/archives/wayland-devel/2014-June/015617.html
(3) : http://www.tarnyko.net/repo/weston-ivi-shell.png
-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Global shortkeys and keyboard focus

2014-07-09 Thread Pekka Paalanen

On Tue, 8 Jul 2014 22:26:07 +
"Dodier-Lazaro, Steve"  wrote:

> A couple of notes on the previous emails,
> 
> Fabrice, so long as your app ensures that no third-party code can 
> programmatically grab a shortcut without user agreement, it would make sense 
> to let it have a privilege.
> 
> Quite obviously a compo should have the last word and be able to refuse a 
> request to grab a certain shortcut. If this happens, compo developers please 
> do provide the requesting app a displayable/translatable explanation that 
> your end-users would understand ;)
> 
> I don't quite like the idea of a permission prompt from the compo for setting 
> up keyboard shortcuts. In the vast majority of cases the user is already 
> using a specific GUI for that and possibly setting up more than one shortcut 
> (e.g. shortcuts to newly installed media app), so it'd be awkward for them to 
> receive a permission prompt. I think privileges work much better here (or 
> User-Driven Access Control with a button that when clicked displays a 
> compositor-owned dialog inviting the user to select a global shortcut).
> 

A wild thought in passing, which likely borrows from things
I've heard from others before...

What if applications would install config file snippets, a la
configdir design, which specify a semantic action by identifier
string, and the default suggested hotkey, gesture, or whatever. Or
maybe they would be in the app's .desktop file, whatever

The compositor would watch this directory, and when files there
change, it would read them and notice that e.g. now there is a new
hotkey action available. However, all that would do is light up a
marker somewhere in the desktop UI saying "you have new hotkey
actions available, click here to set up all your hotkeys".

So the new hotkey would *not* work simply by the app's actions or
by installing the app.

The user can go into the hotkey config dialog in his DE UI, there
see as highlighted the new things, and have the option to accept the
default key binding, choose another key, or just leave the action
unbound. The idea being that they are all under the DE (compositor)
control, that is under the user's control, and all in one place.

When the app is actually started, it will register for the semantic
action by its identifier string, and then it may or may not get it
triggered.

No privileges needed so far as I can see. Also nothing above says
it must be Wayland protocol. It could as well be dbus. And it could
as well apply to X11-based DEs!

Or maybe existing DEs already have a hotkey registration system,
and we have to do nothing more on Wayland standardization
specifically?...

So it might not even be a Wayland thing at all.

If a hotkey action needs to do something that is most of the time
not allowed, like raise a window to the top (using a hypothetical
protocol I'm not sure exists yet), I suppose the simplest thing
would be for the hotkey action event to carry a "serial" like input
events do, so the app can use that as a ticket to allow the
"raise the window" request to be accepted. This would need
integration in the Wayland protocol.

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

[PATCH weston] xwm: set surface_id of a window to 0 if paired immediately

2014-07-09 Thread Boyan Ding

The surface_id of a wm_window is set to non-zero when shell surface
of the window exists but not mapped, and that wm_window will be inserted
into an unpaired_window_list. If window is mapped immediately in
weston_wm_handle_surface_id, it will not go into the list. However, we
forgot to set surface_id back to zero in this case, causing crash when
trying to remove the window from unpaired list which it is not in.

This bug affects version 1.5 and master with the new Xwayland DDX.

Signed-off-by: Boyan Ding 
---
 xwayland/window-manager.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 2fb65b1..3444141 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1377,10 +1377,11 @@ weston_wm_window_handle_surface_id(struct 
weston_wm_window *window,
window->surface_id = client_message->data.data32[0];
resource = wl_client_get_object(wm->server->client,
window->surface_id);
-   if (resource)
+   if (resource) {
xserver_map_shell_surface(window,
  wl_resource_get_user_data(resource));
-   else
+   window->surface_id = 0;
+   } else
wl_list_insert(&wm->unpaired_window_list, &window->link);
 }
 
-- 
2.0.1


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

Re: [PATCH weston-ivi-shell v5 6/9] A reference implementation of UI client how to use ivi-hmi-controller.

2014-07-09 Thread Pekka Paalanen

On Wed, 09 Jul 2014 15:43:27 +0900
Nobuhiko Tanibata  wrote:

> 2014-07-07 17:04 に Pekka Paalanen さんは書きました:
> > On Tue, 20 May 2014 19:02:56 +0900
> > Nobuhiko Tanibata  wrote:
> > 
> >> 2014-04-25 20:55 に Pekka Paalanen さんは書きました:
> >> > On Thu, 20 Mar 2014 16:00:57 +0900
> >> > Nobuhiko Tanibata  wrote:
> >> >
> >> >> This is launched from hmi-controller by using hmi_client_start and
> >> >> create a
> >> >> pthread.
> >> >>
> >> >> The basic flow is as followed,
> >> >> 1/ create pthread
> >> >> 2/ read configuration from weston.ini.
> >> >> 3/ draw png file to surface according to configuration of weston.ini
> >> >> 4/ set up UI by using ivi-hmi-controller protocol
> >> >> 5/ Enter event loop
> >> >> 6/ If a surface receives touch/pointer event, followings are invoked
> >> >> according
> >> >>to type of event and surface
> >> >> 6-1/ If a surface to launch ivi_application receive touch up, it execs
> >> >>  ivi-application configured in weston.ini.
> >> >> 6-2/ If a surface to switch layout mode receive touch up, it sends a
> >> >> request,
> >> >>  ivi_hmi_controller_switch_mode, to hmi-controller.
> >> >> 6-3/ If a surface to show workspace having launchers, it sends a
> >> >> request,
> >> >>  ivi_hmi_controller_home, to hmi-controller.
> >> >> 6-4/ If touch down events happens in workspace,
> >> >>  ivi_hmi_controller_workspace_control is sent to slide workspace.
> >> >>  When control finished, event:
> >> >> ivi_hmi_controller_workspace_end_control
> >> >>  is received.
> >> >>
> >> >> Signed-off-by: Nobuhiko Tanibata 
> >> >> ---
> >> >>
> >> >> Changes for v2:
> >> >>  - squash Makefile to this patch
> >> >>
> >> >> Changes for v3 and v4:
> >> >>  - nothing. Version number aligned to the first patch
> >> >>
> >> >> Changes for v5:
> >> >>  - usleep with roundtrip uses CPU. replace them with
> >> >> wl_display_dispatch
> >> >>
> >> >>  ivi-shell/Makefile.am |2 +
> >> >>  ivi-shell/hmi-controller-homescreen.c | 1369
> >> >> +
> >> >>  ivi-shell/hmi-controller-homescreen.h |   36 +
> >> >>  ivi-shell/hmi-controller.c|3 +-
> >> >>  4 files changed, 1409 insertions(+), 1 deletion(-)
> >> >>  create mode 100644 ivi-shell/hmi-controller-homescreen.c
> >> >>  create mode 100644 ivi-shell/hmi-controller-homescreen.h
> >> >
> >> > Would it not be simpler and more robust to make this an independent
> >> > program like e.g. clients/desktop-shell.c is, rather than running it in
> >> > a thread in the compositor?
> >> >
> >> > I would certainly prefer it to be. We would avoid threads in the
> >> > compositor, and pulling in client side stuff. Now there is a huge risk
> >> > you might be calling compositor functions from client code, and a crash
> >> > in the client code would bring the whole compositor down.
> >> >
> >> > If we look at weston-desktop-shell, if it crashes, Weston will respawn
> >> > it so fast that a user often does not even notice anything happened.
> >> > ;-)
> >> 
> >> I agree. I apply your comments in v5. it is now process.
> >> Before, I implemented it as a thread to reduce overhead of process
> >> dispatch.
> >> I experienced such a overhead before. However at first, I shall follow
> >> wayland current sample like desktop-shell, invoke it as process.
> >> If ivi vendor want to it as a thread with the same concerning, it can
> >> easily do it by itself.
> > 
> > Hmm, would be interesting to hear a bit more about that overhead
> > thing.
> > 
> > In your code:
> > - it is a thread, so it will be subject to scheduling anyway
> > - it still uses a normal Wayland connections (wl_display_connect),
> >   so it will not skip any of the communication overheads
> > 
> > I'm just curious about what overheads you intended to avoid here.
> > Was it library loading at start-up? I can't think of anything else
> > right now.
> > 
> 
> Thanks for comment, pq!
> 
> My concerning was that process dispatch vs thread dispatch. Threads 
> share their memory space and the dispatch cost might be smaller than 
> process ones. If I can implement IVI clinet in the same process, it can 
> reduce dispatch code compare to process dispatching.

Hmm, that's a thing I do not know anything about, really. I would
not assume there is a difference unless you can show that by
measurements. IIRC all threads in Linux (as via pthread library)
are kernel threads, and not purely user space things in a single
kernel thread per process, which means the kernel does the
scheduling and switching.

Even if there was a difference, you may still hit the heavier
switch if you get a run sequence process-A-thread-1, process-B,
process-A-thread-2. And then CPUs today are almost all multi-core,
so reasoning about performance gets only harder.

Furthermore, as you are still using unix sockets for communication,
there will be at least a couple of syscalls per IO-batch anyway, so
you are not saving even in the number of syscalls.

I would just not spec

Re: [PATCH libinput] tablet: Rename TILT_VERTICAL and TILT_HORIZONTAL to TILT_X and TILT_Y

Re: [PATCH 10/11] weston-image --help works. Also help if no filename is given

Re: [PATCH 10/11] weston-image --help works. Also help if no filename is given

[PATCH weston 0/2] Implement layer clipping

[PATCH weston 2/2] compositor: add a masking mechanism to weston_layer

[PATCH weston 1/2] compositor: keep track of the weston_layer a weston_view is in

RealVNC Wayland developer preview

Re: Weston IVI-Shell GitHub repo

Re: [PATCH 2/3] tests: remove assert from frame_callback_wait()

RE: Weston IVI-Shell GitHub repo

Weston IVI-Shell GitHub repo

Re: Global shortkeys and keyboard focus

[PATCH weston] xwm: set surface_id of a window to 0 if paired immediately

Re: [PATCH weston-ivi-shell v5 6/9] A reference implementation of UI client how to use ivi-hmi-controller.

14 matches

Site Navigation

Mail list logo

Footer information