[PATCH] Bug fix client apps because of output change

[Quanxian Wang]

1)
Width and height of Panel and Background depend
on output's, therefore they should be bound
with output changes including mode, transform and scale.

2)
Update the min_allocation before resize the panel and
background window. Add window_set_min_allocation function
because it is invisible outside window.c.

Signed-off-by: Quanxian Wang 
---
 clients/desktop-shell.c | 70 +
 clients/window.c|  7 +
 clients/window.h|  2 ++
 3 files changed, 79 insertions(+)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index a0c6b6d..9ccba34 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -96,6 +96,12 @@ struct background {
uint32_t color;
 };
 
+struct mode {
+   int height;
+   int width;
+   uint32_t refresh;
+};
+
 struct output {
struct wl_output *output;
uint32_t server_output_id;
@@ -103,6 +109,9 @@ struct output {
 
struct panel *panel;
struct background *background;
+   struct mode *mode;
+   uint32_t transform;
+   uint32_t scale;
 };
 
 struct panel_launcher {
@@ -1128,6 +1137,10 @@ output_destroy(struct output *output)
 {
background_destroy(output->background);
panel_destroy(output->panel);
+
+   if (output->mode)
+   free(output->mode);
+
wl_output_destroy(output->output);
wl_list_remove(&output->link);
 
@@ -1145,6 +1158,44 @@ desktop_destroy_outputs(struct desktop *desktop)
 }
 
 static void
+update_output(struct output *output)
+{
+   struct panel *panel = output->panel;
+   struct background *background = output->background;
+   int width, height;
+
+   if (!output || !output->mode)
+   return;
+
+   width = output->mode->width;
+   height = output->mode->height;
+
+   switch (output->transform) {
+   case WL_OUTPUT_TRANSFORM_90:
+   case WL_OUTPUT_TRANSFORM_270:
+   case WL_OUTPUT_TRANSFORM_FLIPPED_90:
+   case WL_OUTPUT_TRANSFORM_FLIPPED_270:
+   /* Swap width and height */
+   width = output->mode->height;
+   height = output->mode->width;
+   break;
+   default:
+   break;
+   }
+
+   if (output->scale != 0) {
+   width /= output->scale;
+   height /= output->scale;
+   }
+
+   /* Set min_allocation of panel */
+   window_set_min_allocation(panel->window, width, 32);
+
+   window_schedule_resize(background->window, width, height);
+   window_schedule_resize(panel->window, width, 32);
+}
+
+static void
 output_handle_geometry(void *data,
struct wl_output *wl_output,
int x, int y,
@@ -1157,6 +1208,8 @@ output_handle_geometry(void *data,
 {
struct output *output = data;
 
+   output->transform = transform;
+   update_output(output);
window_set_buffer_transform(output->panel->window, transform);
window_set_buffer_transform(output->background->window, transform);
 }
@@ -1169,6 +1222,17 @@ output_handle_mode(void *data,
   int height,
   int refresh)
 {
+   struct output *output = data;
+
+   if (flags & WL_OUTPUT_MODE_CURRENT) {
+   if (!output && !output->mode)
+   return;
+
+   output->mode->width = width;
+   output->mode->height = height;
+   output->mode->refresh = refresh;
+   update_output(output);
+   }
 }
 
 static void
@@ -1184,6 +1248,8 @@ output_handle_scale(void *data,
 {
struct output *output = data;
 
+   output->scale  = scale;
+   update_output(output);
window_set_buffer_scale(output->panel->window, scale);
window_set_buffer_scale(output->background->window, scale);
 }
@@ -1206,6 +1272,10 @@ output_init(struct output *output, struct desktop 
*desktop)
output->output, surface);
 
output->background = background_create(desktop);
+   output->mode = (struct mode *)xzalloc(sizeof(*output->mode));
+   if (!output->mode)
+   fprintf(stderr, "No memory for mode allocation.\n");
+
surface = window_get_wl_surface(output->background->window);
desktop_shell_set_background(desktop->shell,
 output->output, surface);
diff --git a/clients/window.c b/clients/window.c
index c8287e2..6c01222 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3839,6 +3839,13 @@ undo_resize(struct window *window)
 }
 
 void
+window_set_min_allocation(struct window *window, int width, int height)
+{
+   window->min_allocation.width = width;
+   window->min_allocation.height = height;
+}
+
+void
 window_schedule_resize(struct window *window, int width, int height)
 {
/* We should probably get these numbers from the theme. */
diff --git a/clients/window.h b/clients/window.h
index 54b8

Re: [PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

On Thu, 6 Mar 2014 03:01:11 +
"Wang, Quanxian"  wrote:

> Except the comment below. I mention some points.
> 
> 1) My idea:
> My original idea is from xrandr of xserver. I just want to let xrandr
> could be implemented in wayland. If no protocol is used, that is
> fine. But no way to implement some function for example transform,
> scale, mode set output. I have to create a protocol to communicate
> with compositor and let compositor do that.

Usually such configuration changes should originate within the
compositor itself. In practice, it could be a special shell helper
application (e.g. weston-desktop-shell) using a private protocol to
communicate the intent of the user.

The X server is different, because the X server is the same for every
environment, so it must have standard protocol to do configuration
changes. On Wayland this is not the case.

> This protocol basically live with compositor. It also provides the
> interface for library above to provide the randr function. For
> example efl, gtk, or ... If you think it is to build the standard
> protocol, that is fine. Anyway, my idea is that.

The point is, those toolkit libraries should not have access to
"wayland-randr" at all. It's not something a normal application should
use.

Again in X things are different because the RandR protocol must exist,
but there is no easy way to make it restricted.

> 2) About mode setting requirement:
> Most of case, it is for configuration of output as a whole. Generally
> it should be in setting panel for screen size, rotation, ...option
> setting. The user cases I mentioned are related with that setting. Of
> course you may prefer another way to implement. 

Such use cases would be perfectly served by the special shell
client, which already needs a private, priviledged interface to the
compositor anyway. This private interface is almost always environment
specific.

Wayland is not X; it is not intended that you could simply run a "panel
program" at any time and expect it to add a well-functioning panel to
the desktop. Such programs are special, so in the current design they
are started directly by the compositor.

> 
> 3) Security Issue:
> I found Pq, Jason, Japsper, ... don't want to expose the interface
> because of "at will, arbitrary or disaster or any client". Actually
> it is security issue. That is fine. Yes, it really exists. We must be
> careful for that. Firstly I take it as a module, let owner to
> determine if he really need randr function. Secondly at the same
> time, it will be convenient for us to update randr when new wayland
> security control policy is ready.

Sure, we just need to be clear first on what the intended use cases
are, because they will affect the design a great deal, and even more on
how well the proposal is received.

> 4) Here I can share an security idea for such protocol. I just want
> to show, if wayland provides such kind security checking, it will be
> easily adopted by randr interface. Previous interface could be
> default defined as general, other special could be identified as
> video or root. Please do not focus on the role definition and I just
> take an example. 
> 
> My security idea:
> Add two attributes separately to wl_client, wl_randr interface.
> wl_client has the user id and group id, wl_randr interface has an
> access attribute (general user, video user, root/admin). if you are
> afraid it is hacked, when you wl_closure_send, you can dynamically
> generate user id and group id.
> 
> In client:
> wl_randr_set_mode(wl_wrandr_interface, ...)
> In compositor:
> Uid = get_uid(client)
> Gid = get_gid(client)
> If (It_video_user(uid, gid,..) || !is_root_user(uid,gid..))
> Wl_randr_send_permission("No permission to do that!\n");
> 
> Continue...

Except that checking for the UID and GID are completely useless: the
compositor already runs as the user in most cases, and all clients
will be run as the same user anyway, because no other user should have
access to the compositor, unless they are already root.

So the only thing you could do with this scheme is check for the root
user. I do not think that is appropriate.

Coming up with a workable security design is very hard. So far the only
mechanism we have for granting special powers to a client is that it is
started by the compositor directly from a well-known system path. This
currently applies to the special shell helper programs.

Just don't go there.

First define the use cases clearly, and then if they are acceptable, we
can find a way to expose the interface properly.

> 5) At last I answer the questions raised by Pq for me.
> 
> - Would you be happy with something that works for your specific use
>   case only?
> [Wang Quanxian]not happy, really not happy. I like what I do is
> helpful for everyone.

That's very cool. :-)

> - Do you want to establish a universal standard, i.e. get this into
>   Wayland core? If so, why?
> [Wang Quanxian] No, it lives with compositor. Without compositor,
> randr could do noth

Re: [PATCH] Bug fix client apps because of output change

[Pekka Paalanen]

On Thu,  6 Mar 2014 16:25:42 +0800
Quanxian Wang  wrote:

> 1)
> Width and height of Panel and Background depend
> on output's, therefore they should be bound
> with output changes including mode, transform and scale.
> 
> 2)
> Update the min_allocation before resize the panel and
> background window. Add window_set_min_allocation function
> because it is invisible outside window.c.
> 
> Signed-off-by: Quanxian Wang 
> ---
>  clients/desktop-shell.c | 70
> +
> clients/window.c|  7 + clients/window.h|  2 ++
>  3 files changed, 79 insertions(+)
> 
> diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
> index a0c6b6d..9ccba34 100644
> --- a/clients/desktop-shell.c
> +++ b/clients/desktop-shell.c
> @@ -96,6 +96,12 @@ struct background {
>   uint32_t color;
>  };
>  
> +struct mode {
> + int height;
> + int width;
> + uint32_t refresh;
> +};
> +
>  struct output {
>   struct wl_output *output;
>   uint32_t server_output_id;
> @@ -103,6 +109,9 @@ struct output {
>  
>   struct panel *panel;
>   struct background *background;
> + struct mode *mode;

Hi,

I think you could simplify this code quite a bit by just having the
struct mode embed in struct output, instead of dynamically allocating
it. You will always have exactly one struct mode for each struct
output, right?

> + uint32_t transform;
> + uint32_t scale;
>  };
>  
>  struct panel_launcher {
> @@ -1128,6 +1137,10 @@ output_destroy(struct output *output)
>  {
>   background_destroy(output->background);
>   panel_destroy(output->panel);
> +
> + if (output->mode)
> + free(output->mode);
> +
>   wl_output_destroy(output->output);
>   wl_list_remove(&output->link);
>  
> @@ -1145,6 +1158,44 @@ desktop_destroy_outputs(struct desktop
> *desktop) }
>  
>  static void
> +update_output(struct output *output)
> +{
> + struct panel *panel = output->panel;
> + struct background *background = output->background;
> + int width, height;
> +
> + if (!output || !output->mode)
> + return;
> +
> + width = output->mode->width;
> + height = output->mode->height;
> +
> + switch (output->transform) {
> + case WL_OUTPUT_TRANSFORM_90:
> + case WL_OUTPUT_TRANSFORM_270:
> + case WL_OUTPUT_TRANSFORM_FLIPPED_90:
> + case WL_OUTPUT_TRANSFORM_FLIPPED_270:
> + /* Swap width and height */
> + width = output->mode->height;
> + height = output->mode->width;
> + break;
> + default:
> + break;
> + }
> +
> + if (output->scale != 0) {
> + width /= output->scale;
> + height /= output->scale;
> + }
> +
> + /* Set min_allocation of panel */
> + window_set_min_allocation(panel->window, width, 32);

Is there a reason why the background window does not need the
min_allocation changed?

> +
> + window_schedule_resize(background->window, width, height);
> + window_schedule_resize(panel->window, width, 32);
> +}
> +
> +static void
>  output_handle_geometry(void *data,
> struct wl_output *wl_output,
> int x, int y,
> @@ -1157,6 +1208,8 @@ output_handle_geometry(void *data,
>  {
>   struct output *output = data;
>  
> + output->transform = transform;
> + update_output(output);
>   window_set_buffer_transform(output->panel->window,
> transform); window_set_buffer_transform(output->background->window,
> transform); }
> @@ -1169,6 +1222,17 @@ output_handle_mode(void *data,
>  int height,
>  int refresh)
>  {
> + struct output *output = data;
> +
> + if (flags & WL_OUTPUT_MODE_CURRENT) {
> + if (!output && !output->mode)
> + return;
> +
> + output->mode->width = width;
> + output->mode->height = height;
> + output->mode->refresh = refresh;
> + update_output(output);
> + }
>  }
>  
>  static void
> @@ -1184,6 +1248,8 @@ output_handle_scale(void *data,
>  {
>   struct output *output = data;
>  
> + output->scale  = scale;
> + update_output(output);

I think calling update_output() would be better done from the
wl_output.done event handler, because there you are guaranteed to have
all the relevant events received. Otherwise you race the scheduled
resize against receiving all the related events.

However, the catch is that wl_output.done is in interface version >= 2,
but not in version 1. For version 1 you'd need just call
update_output() directly like you already do.

>   window_set_buffer_scale(output->panel->window, scale);
>   window_set_buffer_scale(output->background->window, scale);
>  }
> @@ -1206,6 +1272,10 @@ output_init(struct output *output, struct
> desktop *desktop) output->output, surface);
>  
>   output->background = background_create(desktop);
> + output->mode = (

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

Thanks Pq's comment. 

By the way, if we make it as a configuration tools or testing protocol. Will it 
be fine or not? 

For example graphics QA testing, 
I just send a patch to bug fix the client apps because of output change. I use 
weston-wrandr to do the testing to make sure what I have done is right. If I 
have not this tool, I don't make sure how to test it. Because you need 
dynamically change rotate, transform, or mode set to make sure desktop shell 
could get the change and really works fine with new change.

Also this tool should be fine for wayland QA testing. 

Anyway, if you guys think it right for configuration or testing wayland 
graphics tools, that is fine. I can continue working on these patches instead 
of original idea to expose this to client to use.

Thanks for everyone's comment and help.

Regards

Quanxian Wang

>-Original Message-
>From: wayland-devel-boun...@lists.freedesktop.org
>[mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Pekka
>Paalanen
>Sent: Thursday, March 06, 2014 4:25 PM
>To: Wang, Quanxian
>Cc: Hardening; Jasper St. Pierre; Matthias Clasen;
>wayland-devel@lists.freedesktop.org; Jason Ekstrand; Zhang, Xiong Y
>Subject: Re: [PATCH 1/6] Add weston randr protocol
>
>On Thu, 6 Mar 2014 03:01:11 +
>"Wang, Quanxian"  wrote:
>
>> Except the comment below. I mention some points.
>>
>> 1) My idea:
>> My original idea is from xrandr of xserver. I just want to let xrandr
>> could be implemented in wayland. If no protocol is used, that is fine.
>> But no way to implement some function for example transform, scale,
>> mode set output. I have to create a protocol to communicate with
>> compositor and let compositor do that.
>
>Usually such configuration changes should originate within the compositor 
>itself. In
>practice, it could be a special shell helper application (e.g. 
>weston-desktop-shell)
>using a private protocol to communicate the intent of the user.
>
>The X server is different, because the X server is the same for every 
>environment,
>so it must have standard protocol to do configuration changes. On Wayland this 
>is
>not the case.
>
>> This protocol basically live with compositor. It also provides the
>> interface for library above to provide the randr function. For example
>> efl, gtk, or ... If you think it is to build the standard protocol,
>> that is fine. Anyway, my idea is that.
>
>The point is, those toolkit libraries should not have access to 
>"wayland-randr" at all.
>It's not something a normal application should use.
>
>Again in X things are different because the RandR protocol must exist, but 
>there is
>no easy way to make it restricted.
>
>> 2) About mode setting requirement:
>> Most of case, it is for configuration of output as a whole. Generally
>> it should be in setting panel for screen size, rotation, ...option
>> setting. The user cases I mentioned are related with that setting. Of
>> course you may prefer another way to implement.
>
>Such use cases would be perfectly served by the special shell client, which 
>already
>needs a private, priviledged interface to the compositor anyway. This private
>interface is almost always environment specific.
>
>Wayland is not X; it is not intended that you could simply run a "panel 
>program" at
>any time and expect it to add a well-functioning panel to the desktop. Such
>programs are special, so in the current design they are started directly by the
>compositor.
>
>>
>> 3) Security Issue:
>> I found Pq, Jason, Japsper, ... don't want to expose the interface
>> because of "at will, arbitrary or disaster or any client". Actually it
>> is security issue. That is fine. Yes, it really exists. We must be
>> careful for that. Firstly I take it as a module, let owner to
>> determine if he really need randr function. Secondly at the same time,
>> it will be convenient for us to update randr when new wayland security
>> control policy is ready.
>
>Sure, we just need to be clear first on what the intended use cases are, 
>because
>they will affect the design a great deal, and even more on how well the 
>proposal is
>received.
>
>> 4) Here I can share an security idea for such protocol. I just want to
>> show, if wayland provides such kind security checking, it will be
>> easily adopted by randr interface. Previous interface could be default
>> defined as general, other special could be identified as video or
>> root. Please do not focus on the role definition and I just take an
>> example.
>>
>> My security idea:
>> Add two attributes separately to wl_client, wl_randr interface.
>> wl_client has the user id and group id, wl_randr interface has an
>> access attribute (general user, video user, root/admin). if you are
>> afraid it is hacked, when you wl_closure_send, you can dynamically
>> generate user id and group id.
>>
>> In client:
>> wl_randr_set_mode(wl_wrandr_interface, ...) In compositor:
>> Uid = get_uid(client)
>> Gid = get_gid(client)
>> If (It_video_user(uid, gid,..) || !is_root

RE: [PATCH] Bug fix client apps because of output change

[Wang, Quanxian]

>-Original Message-
>From: Pekka Paalanen [mailto:ppaala...@gmail.com]
>Sent: Thursday, March 06, 2014 4:42 PM
>To: Wang, Quanxian
>Cc: wayland-devel@lists.freedesktop.org
>Subject: Re: [PATCH] Bug fix client apps because of output change
>
>On Thu,  6 Mar 2014 16:25:42 +0800
>Quanxian Wang  wrote:
>
>> 1)
>> Width and height of Panel and Background depend on output's, therefore
>> they should be bound with output changes including mode, transform and
>> scale.
>>
>> 2)
>> Update the min_allocation before resize the panel and background
>> window. Add window_set_min_allocation function because it is invisible
>> outside window.c.
>>
>> Signed-off-by: Quanxian Wang 
>> ---
>>  clients/desktop-shell.c | 70
>> +
>> clients/window.c|  7 + clients/window.h|  2 ++
>>  3 files changed, 79 insertions(+)
>>
>> diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c index
>> a0c6b6d..9ccba34 100644
>> --- a/clients/desktop-shell.c
>> +++ b/clients/desktop-shell.c
>> @@ -96,6 +96,12 @@ struct background {
>>  uint32_t color;
>>  };
>>
>> +struct mode {
>> +int height;
>> +int width;
>> +uint32_t refresh;
>> +};
>> +
>>  struct output {
>>  struct wl_output *output;
>>  uint32_t server_output_id;
>> @@ -103,6 +109,9 @@ struct output {
>>
>>  struct panel *panel;
>>  struct background *background;
>> +struct mode *mode;
>
>Hi,
>
>I think you could simplify this code quite a bit by just having the struct mode
>embed in struct output, instead of dynamically allocating it. You will always 
>have
>exactly one struct mode for each struct output, right?
[Wang, Quanxian] fine. Got it.
>
>> +uint32_t transform;
>> +uint32_t scale;
>>  };
>>
>>  struct panel_launcher {
>> @@ -1128,6 +1137,10 @@ output_destroy(struct output *output)  {
>>  background_destroy(output->background);
>>  panel_destroy(output->panel);
>> +
>> +if (output->mode)
>> +free(output->mode);
>> +
>>  wl_output_destroy(output->output);
>>  wl_list_remove(&output->link);
>>
>> @@ -1145,6 +1158,44 @@ desktop_destroy_outputs(struct desktop
>> *desktop) }
>>
>>  static void
>> +update_output(struct output *output)
>> +{
>> +struct panel *panel = output->panel;
>> +struct background *background = output->background;
>> +int width, height;
>> +
>> +if (!output || !output->mode)
>> +return;
>> +
>> +width = output->mode->width;
>> +height = output->mode->height;
>> +
>> +switch (output->transform) {
>> +case WL_OUTPUT_TRANSFORM_90:
>> +case WL_OUTPUT_TRANSFORM_270:
>> +case WL_OUTPUT_TRANSFORM_FLIPPED_90:
>> +case WL_OUTPUT_TRANSFORM_FLIPPED_270:
>> +/* Swap width and height */
>> +width = output->mode->height;
>> +height = output->mode->width;
>> +break;
>> +default:
>> +break;
>> +}
>> +
>> +if (output->scale != 0) {
>> +width /= output->scale;
>> +height /= output->scale;
>> +}
>> +
>> +/* Set min_allocation of panel */
>> +window_set_min_allocation(panel->window, width, 32);
>
>Is there a reason why the background window does not need the min_allocation
>changed?
[Wang, Quanxian] With testing, this doesn't make error. Let me double check 
that. 
>
>> +
>> +window_schedule_resize(background->window, width, height);
>> +window_schedule_resize(panel->window, width, 32); }
>> +
>> +static void
>>  output_handle_geometry(void *data,
>> struct wl_output *wl_output,
>> int x, int y,
>> @@ -1157,6 +1208,8 @@ output_handle_geometry(void *data,  {
>>  struct output *output = data;
>>
>> +output->transform = transform;
>> +update_output(output);
>>  window_set_buffer_transform(output->panel->window,
>> transform); window_set_buffer_transform(output->background->window,
>> transform); }
>> @@ -1169,6 +1222,17 @@ output_handle_mode(void *data,
>> int height,
>> int refresh)
>>  {
>> +struct output *output = data;
>> +
>> +if (flags & WL_OUTPUT_MODE_CURRENT) {
>> +if (!output && !output->mode)
>> +return;
>> +
>> +output->mode->width = width;
>> +output->mode->height = height;
>> +output->mode->refresh = refresh;
>> +update_output(output);
>> +}
>>  }
>>
>>  static void
>> @@ -1184,6 +1248,8 @@ output_handle_scale(void *data,  {
>>  struct output *output = data;
>>
>> +output->scale  = scale;
>> +update_output(output);
>
>I think calling update_output() would be better done from the wl_output.done
>event handler, because there you are guaranteed to have all the relevant events
>received. Otherwise you race the scheduled resize against receiving all the 
>related
>events.
>
>However, the catch is that wl_output.done is in interface version >= 2, but 
>no

[PATCH weston-ivi-shell 01/15] This vfunc lets us read out a rectangle of pixels from the currently attached surface buffer.

[Nobuhiko Tanibata]

From: Kristian Høgsberg 

---
 src/compositor.h  |  3 +++
 src/gl-renderer.c | 54 ++
 2 files changed, 57 insertions(+)

diff --git a/src/compositor.h b/src/compositor.h
index 22a485f..ace75da 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -540,6 +540,9 @@ struct weston_renderer {
   pixman_format_code_t format, void *pixels,
   uint32_t x, uint32_t y,
   uint32_t width, uint32_t height);
+   int (*read_surface_pixels)(struct weston_surface *es,
+  pixman_format_code_t format, void *pixels,
+  int x, int y, int width, int height);
void (*repaint_output)(struct weston_output *output,
   pixman_region32_t *output_damage);
void (*flush_damage)(struct weston_surface *surface);
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 0e5afbe..dca2e05 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -106,6 +106,8 @@ struct gl_renderer {
EGLContext egl_context;
EGLConfig egl_config;
 
+   GLuint fbo;
+
struct wl_array vertices;
struct wl_array vtxcnt;
 
@@ -585,6 +587,54 @@ out:
pixman_region32_fini(&repaint);
 }
 
+static int
+gl_renderer_read_surface_pixels(struct weston_surface *es,
+   pixman_format_code_t format, void *pixels,
+   int x, int y, int width, int height)
+{
+   struct weston_buffer *buffer = es->buffer_ref.buffer;
+   struct weston_compositor *ec = es->compositor;
+   struct gl_renderer *gr = get_renderer(ec);
+   struct gl_surface_state *gs = get_surface_state(es);
+   GLenum gl_format;
+   int size;
+   struct wl_shm_buffer *shm_buffer = NULL;
+
+   switch (format) {
+   case PIXMAN_a8r8g8b8:
+   gl_format = GL_BGRA_EXT;
+   break;
+   case PIXMAN_a8b8g8r8:
+   gl_format = GL_RGBA;
+   break;
+   default:
+   return -1;
+   }
+
+if (buffer) {
+   shm_buffer = wl_shm_buffer_get(buffer->resource);
+   }
+   if (shm_buffer) {
+   size = buffer->width * 4 * buffer->height;
+   memcpy(pixels, wl_shm_buffer_get_data(shm_buffer), size);
+   } else {
+   if (gr->fbo == 0)
+   glGenFramebuffers(1, &gr->fbo);
+   glBindFramebuffer(GL_FRAMEBUFFER, gr->fbo);
+   glFramebufferTexture2D(GL_FRAMEBUFFER,
+  GL_COLOR_ATTACHMENT0,
+  GL_TEXTURE_2D,
+  gs->textures[0], 0);
+
+   glReadPixels(x, y, width, height,
+gl_format, GL_UNSIGNED_BYTE, pixels);
+
+   glBindFramebuffer(GL_FRAMEBUFFER, 0);
+   }
+
+   return 0;
+}
+
 static void
 repaint_views(struct weston_output *output, pixman_region32_t *damage)
 {
@@ -1602,6 +1652,9 @@ gl_renderer_destroy(struct weston_compositor *ec)
 
wl_signal_emit(&gr->destroy_signal, gr);
 
+   if (gr->fbo)
+   glDeleteFramebuffers(1, &gr->fbo);
+
if (gr->has_bind_display)
gr->unbind_display(gr->egl_display, ec->wl_display);
 
@@ -1699,6 +1752,7 @@ gl_renderer_create(struct weston_compositor *ec, 
EGLNativeDisplayType display,
return -1;
 
gr->base.read_pixels = gl_renderer_read_pixels;
+   gr->base.read_surface_pixels = gl_renderer_read_surface_pixels;
gr->base.repaint_output = gl_renderer_repaint_output;
gr->base.flush_damage = gl_renderer_flush_damage;
gr->base.attach = gl_renderer_attach;
-- 
1.8.3.1

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

[PATCH weston-ivi-shell 02/15] ivi application protocol:

[Nobuhiko Tanibata]

Add interface ivi_application, which creates ivi_surface objects tied
to a given wl_surface with a given id. The given id can be used in a
shell to identify which application is assigned to a wl_surface and
layout the surface wherever the shell wants. ivi_surface objects can
be used to receive status of wl_surface in the scenegraph of the
compositor.

Signed-off-by: Nobuhiko Tanibata 
---
 protocol/ivi-application.xml | 88 
 1 file changed, 88 insertions(+)
 create mode 100644 protocol/ivi-application.xml

diff --git a/protocol/ivi-application.xml b/protocol/ivi-application.xml
new file mode 100644
index 000..e58ad26
--- /dev/null
+++ b/protocol/ivi-application.xml
@@ -0,0 +1,88 @@
+
+
+
+
+Copyright (C) 2013 DENSO CORPORATION
+Copyright (c) 2013 BMW Car IT GmbH
+
+Permission is hereby granted, free of charge, to any person obtaining a 
copy
+of this software and associated documentation files (the "Software"), to 
deal
+in the Software without restriction, including without limitation the 
rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
+
+
+
+
+
+
+
+
+
+
+
+The new visibility state is provided in argument visibility.
+If visibility is 0, the surface has become invisible.
+If visibility is not 0, the surface has become visible.
+
+
+
+
+
+
+
+
+
+
+
+surface_create will create a new surface with surface_id in 
ivi compositor,
+if it does not yet exists. If the surface with surface_id 
already exists in
+ivi compositor, the application content provided in argument 
surface will
+be used as surface content. If an other ivi application 
already registered
+content for surface with surface_id, an error event will 
indicate the problem.
+
+
+
+
+
+
+
+
+These error codes define all possible error codes returned by 
ivi compositor
+on server-side errors.
+
+
+
+
+
+
+
+The ivi compositor encountered error while processing a 
request by this
+application. The error is defined by argument error_code and 
optional
+error_text.
+If the application requires to associate this error event to a 
request,
+it can
+1. send request
+2. force display roundtrip
+3. check, if error event was received
+ but this restricts the application to have only one open 
request at a time.
+
+
+
+
+
+
+
+
-- 
1.8.3.1

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

[PATCH weston-ivi-shell 03/15] ivi-shell: Modified Makefile.am to build ivi-application protocol

[Nobuhiko Tanibata]

Signed-off-by: Nobuhiko Tanibata 
---
 protocol/Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/protocol/Makefile.am b/protocol/Makefile.am
index 5e331a7..9913f16 100644
--- a/protocol/Makefile.am
+++ b/protocol/Makefile.am
@@ -8,7 +8,8 @@ protocol_sources =  \
text-cursor-position.xml\
wayland-test.xml\
xdg-shell.xml   \
-   scaler.xml
+   scaler.xml  \
+   ivi-application.xml
 
 if HAVE_XMLLINT
 .PHONY: validate
-- 
1.8.3.1

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

[PATCH weston-ivi-shell 04/15] ivi-shell supports a type of shell for In-Vehicle Infotainment system.

[Nobuhiko Tanibata]

In-Vehicle Infotainment system traditionally manages surfaces with global
identification. A protocol, ivi_application, supports such a feature by
implementing a request, ivi_application::surface_creation defined in
ivi_application.xml. Additionally, it initialize a library, weston-layout,
to manage properties of surfaces and group surfaces in layer. In detail,
refer library, weston_layout.

Signed-off-by: Nobuhiko Tanibata 
---
 ivi-shell/ivi-shell.c | 333 ++
 1 file changed, 333 insertions(+)
 create mode 100644 ivi-shell/ivi-shell.c

diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c
new file mode 100644
index 000..f4c4d25
--- /dev/null
+++ b/ivi-shell/ivi-shell.c
@@ -0,0 +1,333 @@
+/*
+ * Copyright (C) 2013 DENSO CORPORATION
+ *
+ * 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.
+ */
+
+
+/**
+ * ivi-shell supports a type of shell for In-Vehicle Infotainment system.
+ * In-Vehicle Infotainment system traditionally manages surfaces with global
+ * identification. A protocol, ivi_application, supports such a feature
+ * by implementing a request, ivi_application::surface_creation defined in
+ * ivi_application.xml.
+ *
+ * Additionally, it initialize a library, weston-layout, to manage properties 
of
+ * surfaces and group surfaces in layer. In detail, refer weston_layout.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "compositor.h"
+#include "ivi-application-server-protocol.h"
+#include "weston-layout.h"
+
+struct ivi_shell;
+
+struct ivi_shell_surface
+{
+struct ivi_shell *shell;
+struct weston_layout_surface *layout_surface;
+
+struct weston_surface *surface;
+uint32_t id_surface;
+
+int32_t width;
+int32_t height;
+
+struct wl_list link;
+};
+
+struct ivi_shell
+{
+struct wl_resource *resource;
+struct wl_listener destroy_listener;
+
+struct weston_compositor *compositor;
+struct weston_seat *seat;
+
+struct wl_list list_surface;
+};
+
+/* - */
+/* common functions  */
+/* - */
+
+static void
+configure(struct weston_view *view, float x, float y)
+{
+if (view != NULL) {
+weston_view_set_position(view, x, y);
+weston_view_update_transform(view);
+}
+}
+
+/**
+ * Implementation of ivi_surface
+ */
+
+static void
+ivi_shell_surface_configure(struct weston_surface *, int32_t, int32_t);
+
+static struct ivi_shell_surface *
+get_ivi_shell_surface(struct weston_surface *surface)
+{
+if (surface->configure == ivi_shell_surface_configure) {
+return surface->configure_private;
+} else {
+return NULL;
+}
+}
+
+static void
+ivi_shell_surface_configure(struct weston_surface *es,
+int32_t sx, int32_t sy)
+{
+struct ivi_shell_surface *ivisurf = get_ivi_shell_surface(es);
+struct weston_view *view = NULL;
+float from_x = 0.0f;
+float from_y = 0.0f;
+float to_x = 0.0f;
+float to_y = 0.0f;
+
+if ((es->width == 0) || (es->height == 0) || (ivisurf == NULL)) {
+return;
+}
+
+view = weston_layout_get_weston_view(ivisurf->layout_surface);
+if (view == NULL) {
+return;
+}
+
+if (ivisurf->width != es->width || ivisurf->height != es->height) {
+
+ivisurf->width  = es->width;
+ivisurf->height = es->height;
+
+weston_view_to_global_float(view, 0, 0, &from_x, &from_y);
+weston_view_to_global_float(view, sx, sy, &to_x, &to_y);
+configure(view,
+  view->geometry.x + to_x - from_x,
+  view->geometry.y + to_y - from_y);
+
+weston_layout_surfaceConfigure(ivisurf->layout_surface, es->width,

[PATCH weston-ivi-shell 06/15] Modified Makefile and configure

[Nobuhiko Tanibata]

building ivi-shell.so and libweston-layout.so.

Signed-off-by: Nobuhiko Tanibata 
---
 Makefile.am   |  1 +
 configure.ac  | 15 ++-
 ivi-shell/Makefile.am | 52 +++
 3 files changed, 67 insertions(+), 1 deletion(-)
 create mode 100644 ivi-shell/Makefile.am

diff --git a/Makefile.am b/Makefile.am
index f22c542..1bc35e2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -11,6 +11,7 @@ SUBDIRS = \
src \
$(xwayland_subdir)  \
desktop-shell   \
+   ivi-shell   \
clients \
data\
protocol\
diff --git a/configure.ac b/configure.ac
index cce1850..4c0a90f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -409,6 +409,16 @@ if test "x$enable_dbus" != "xno"; then
 fi
 AM_CONDITIONAL(ENABLE_DBUS, test "x$enable_dbus" = "xyes")
 
+# ivi-shell support
+AC_ARG_ENABLE(ivi-shell,
+  AS_HELP_STRING([--disable-ivi-shell],
+ [do not build ivi-shell server plugin and 
client]),,
+ enable_ivi_shell=yes)
+AM_CONDITIONAL(ENABLE_IVI_SHELL, test "x$enable_ivi_shell" = "xyes")
+if test x$enable_ivi_shell = xyes; then
+  PKG_CHECK_MODULES(IVI_SHELL, [cairo])
+fi
+
 AC_ARG_ENABLE(wcap-tools, [  --disable-wcap-tools],, enable_wcap_tools=yes)
 AM_CONDITIONAL(BUILD_WCAP_TOOLS, test x$enable_wcap_tools = xyes)
 if test x$enable_wcap_tools = xyes; then
@@ -505,7 +515,8 @@ AC_CONFIG_FILES([Makefile
 data/Makefile
 protocol/Makefile
 man/Makefile
-tests/Makefile])
+tests/Makefile
+ivi-shell/Makefile])
 AC_OUTPUT
 
 AC_MSG_RESULT([
@@ -519,6 +530,8 @@ AC_MSG_RESULT([
XWayland${enable_xwayland}
dbus${enable_dbus}
 
+   ivi-shell   ${enable_ivi_shell}
+
Build wcap utility  ${enable_wcap_tools}
 
weston-launch utility   ${enable_weston_launch}
diff --git a/ivi-shell/Makefile.am b/ivi-shell/Makefile.am
new file mode 100644
index 000..d0c0d62
--- /dev/null
+++ b/ivi-shell/Makefile.am
@@ -0,0 +1,52 @@
+moduledir = $(libdir)/weston
+
+module_LTLIBRARIES =   \
+   $(libweston_layout) \
+   $(ivi_shell)
+
+AM_CPPFLAGS =  \
+   -I$(top_srcdir)/shared  \
+   -I$(top_srcdir)/src \
+   -I$(top_builddir)/src   \
+   -DDATADIR='"$(datadir)"'\
+   -DMODULEDIR='"$(moduledir)"'\
+   -DLIBEXECDIR='"$(libexecdir)"'  \
+   -DIN_WESTON
+
+westonincludedir = $(includedir)/weston
+westoninclude_HEADERS =
+
+if ENABLE_IVI_SHELL
+westoninclude_HEADERS +=   \
+   ivi-application-client-protocol.h   \
+   weston-layout.h
+
+libweston_layout = libweston-layout.la
+libweston_layout_la_LDFLAGS = -avoid-version
+libweston_layout_la_LIBADD = $(IVI_SHELL_LIBS) ../shared/libshared.la
+libweston_layout_la_CFLAGS = $(GCC_CFLAGS) $(IVI_SHELL_CFLAGS)
+libweston_layout_la_SOURCES =  \
+   weston-layout.c \
+   weston-layout.h
+
+ivi_shell = ivi-shell.la
+ivi_shell_la_LDFLAGS = -module -avoid-version
+ivi_shell_la_LIBADD = $(COMPOSITOR_LIBS) $(IVI_SHELL_LIBS) 
./libweston-layout.la
+ivi_shell_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(IVI_SHELL_CFLAGS)
+ivi_shell_la_SOURCES = \
+   ivi-shell.c \
+   weston-layout.h \
+   ivi-application-protocol.c  \
+   ivi-application-server-protocol.h
+
+endif
+
+BUILT_SOURCES =\
+   ivi-application-protocol.c  \
+   ivi-application-server-protocol.h   \
+   ivi-application-client-protocol.h
+
+CLEANFILES = $(BUILT_SOURCES)
+
+wayland_protocoldir = $(top_srcdir)/protocol
+include $(top_srcdir)/wayland-scanner.mk
-- 
1.8.3.1

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

[PATCH weston-ivi-shell 07/15] A reference protocol of ivi hmi controller to set up IVI style UI.

[Nobuhiko Tanibata]

The reference protocol is used between hmi-controller and
hmi-controller-homescreen.

Signed-off-by: Nobuhiko Tanibata 
---
 protocol/ivi-hmi-controller.xml | 105 
 1 file changed, 105 insertions(+)
 create mode 100644 protocol/ivi-hmi-controller.xml

diff --git a/protocol/ivi-hmi-controller.xml b/protocol/ivi-hmi-controller.xml
new file mode 100644
index 000..04e22f4
--- /dev/null
+++ b/protocol/ivi-hmi-controller.xml
@@ -0,0 +1,105 @@
+
+
+
+
+Copyright (C) 2013 DENSO CORPORATION
+
+Permission is hereby granted, free of charge, to any person obtaining a 
copy
+of this software and associated documentation files (the "Software"), to 
deal
+in the Software without restriction, including without limitation the 
rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
+
+
+
+
+Currently it's possible to set up surface for background, panel,
+buttons, and workspace.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Several buttons are regitered on panel by using arg; number.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Per calling this request, a group of launchers are added.
+
+
+
+
+
+
+
+Give seat to the server to be controlled by server side.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-- 
1.8.3.1

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

[PATCH weston-ivi-shell 08/15] ivi-shell: Modified Makefile.am to build ivi-hmi-controller protocol

[Nobuhiko Tanibata]

From: Nobuhiko Tanibata 

---
 protocol/Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/protocol/Makefile.am b/protocol/Makefile.am
index 9913f16..140aef5 100644
--- a/protocol/Makefile.am
+++ b/protocol/Makefile.am
@@ -9,7 +9,8 @@ protocol_sources =  \
wayland-test.xml\
xdg-shell.xml   \
scaler.xml  \
-   ivi-application.xml
+   ivi-application.xml \
+   ivi-hmi-controller.xml
 
 if HAVE_XMLLINT
 .PHONY: validate
-- 
1.8.3.1

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

[PATCH weston-ivi-shell 10/15] A reference implementation of UI client how to use ivi-hmi-controller.

[Nobuhiko Tanibata]

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 
---
 ivi-shell/hmi-controller-homescreen.c | 1370 +
 ivi-shell/hmi-controller-homescreen.h |   36 +
 2 files changed, 1406 insertions(+)
 create mode 100644 ivi-shell/hmi-controller-homescreen.c
 create mode 100644 ivi-shell/hmi-controller-homescreen.h

diff --git a/ivi-shell/hmi-controller-homescreen.c 
b/ivi-shell/hmi-controller-homescreen.c
new file mode 100644
index 000..51f6c75
--- /dev/null
+++ b/ivi-shell/hmi-controller-homescreen.c
@@ -0,0 +1,1370 @@
+/*
+ * Copyright (C) 2013 DENSO CORPORATION
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hmi-controller-homescreen.h"
+#include "../shared/cairo-util.h"
+#include "../shared/config-parser.h"
+#include "ivi-application-client-protocol.h"
+#include "ivi-hmi-controller-client-protocol.h"
+
+/**
+ * A reference implementation how to use ivi-hmi-controller interface to 
interact
+ * with hmi-controller. 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.
+ */
+
+/*
+ *  structure, globals
+ /
+enum cursor_type {
+CURSOR_BOTTOM_LEFT,
+CURSOR_BOTTOM_RIGHT,
+CURSOR_BOTTOM,
+CURSOR_DRAGGING,
+CURSOR_LEFT_PTR,
+CURSOR_LEFT,
+CURSOR_RIGHT,
+CURSOR_TOP_LEFT,
+CURSOR_TOP_RIGHT,
+CURSOR_TOP,
+CURSOR_IBEAM,
+CURSOR_HAND1,
+CURSOR_WATCH,
+
+CURSOR_BLANK
+};
+struct wlContextCommon {
+struct wl_display  *wlDisplay;
+struct wl_registry *wlRegistry;
+struct wl_compositor   *wlCompositor;
+struct wl_shm   

[PATCH weston-ivi-shell 11/15] Modify ivi-shell/Makefile

[Nobuhiko Tanibata]

to build references;ivi-hmi-controller protocol, hmi-controller,
and hmi-controller-homescreen.

Signed-off-by: Nobuhiko Tanibata 
---
 ivi-shell/.gitignore  |  7 +++
 ivi-shell/Makefile.am | 21 +++--
 2 files changed, 26 insertions(+), 2 deletions(-)
 create mode 100644 ivi-shell/.gitignore

diff --git a/ivi-shell/.gitignore b/ivi-shell/.gitignore
new file mode 100644
index 000..9f31bfd
--- /dev/null
+++ b/ivi-shell/.gitignore
@@ -0,0 +1,7 @@
+ivi-application-client-protocol.h
+ivi-application-protocol.c
+ivi-application-server-protocol.h
+ivi-hmi-controller-client-protocol.h
+ivi-hmi-controller-protocol.c
+ivi-hmi-controller-server-protocol.h
+weston.ini
diff --git a/ivi-shell/Makefile.am b/ivi-shell/Makefile.am
index d0c0d62..afaa5e3 100644
--- a/ivi-shell/Makefile.am
+++ b/ivi-shell/Makefile.am
@@ -2,7 +2,8 @@ moduledir = $(libdir)/weston
 
 module_LTLIBRARIES =   \
$(libweston_layout) \
-   $(ivi_shell)
+   $(ivi_shell)\
+   $(hmi_controller)
 
 AM_CPPFLAGS =  \
-I$(top_srcdir)/shared  \
@@ -39,12 +40,28 @@ ivi_shell_la_SOURCES =  \
ivi-application-protocol.c  \
ivi-application-server-protocol.h
 
+hmi_controller = hmi-controller.la
+hmi_controller_la_LDFLAGS = -module -avoid-version
+hmi_controller_la_LIBADD = $(CLIENT_LIBS) $(IVI_SHELL_LIBS) 
./libweston-layout.la ../shared/libshared-cairo.la
+hmi_controller_la_CFLAGS = $(GCC_CFLAGS) $(IVI_SHELL_CFLAGS)
+hmi_controller_la_SOURCES =\
+   hmi-controller.c\
+   hmi-controller-homescreen.h \
+   hmi-controller-homescreen.c \
+   ivi-application-protocol.c  \
+   ivi-application-client-protocol.h   \
+   ivi-hmi-controller-protocol.c   \
+   ivi-hmi-controller-client-protocol.h\
+   ivi-hmi-controller-server-protocol.h
 endif
 
 BUILT_SOURCES =\
ivi-application-protocol.c  \
ivi-application-server-protocol.h   \
-   ivi-application-client-protocol.h
+   ivi-application-client-protocol.h   \
+   ivi-hmi-controller-protocol.c   \
+   ivi-hmi-controller-client-protocol.h\
+   ivi-hmi-controller-server-protocol.h
 
 CLEANFILES = $(BUILT_SOURCES)
 
-- 
1.8.3.1

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

[PATCH weston-ivi-shell 13/15] Update data/Makefile.am to support reference image files for ivi-hmi-conroller.

[Nobuhiko Tanibata]

Signed-off-by: Nobuhiko Tanibata 
---
 data/Makefile.am | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/data/Makefile.am b/data/Makefile.am
index a7cc944..2aa6e5c 100644
--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -9,7 +9,19 @@ dist_westondata_DATA = \
icon_window.png \
sign_close.png  \
sign_maximize.png   \
-   sign_minimize.png
+   sign_minimize.png   \
+   background.png  \
+   tiling.png  \
+   fullscreen.png  \
+   panel.png   \
+   random.png  \
+   sidebyside.png  \
+   home.png\
+   icon_ivi_clickdot.png   \
+   icon_ivi_flower.png \
+   icon_ivi_simple-egl.png \
+   icon_ivi_simple-shm.png \
+   icon_ivi_smoke.png
 
 if HAVE_RSVG_CONVERT
 wayland_icon_png = wayland.png
-- 
1.8.3.1

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

[PATCH weston-ivi-shell 14/15] Add a reference of weston.ini for ivi-shell and ivi-hmi-controller.

[Nobuhiko Tanibata]

Signed-off-by: Nobuhiko Tanibata 
---
 ivi-shell/Makefile.am   | 12 
 ivi-shell/weston.ini.in | 79 +
 2 files changed, 91 insertions(+)
 create mode 100644 ivi-shell/weston.ini.in

diff --git a/ivi-shell/Makefile.am b/ivi-shell/Makefile.am
index afaa5e3..333abb7 100644
--- a/ivi-shell/Makefile.am
+++ b/ivi-shell/Makefile.am
@@ -67,3 +67,15 @@ CLEANFILES = $(BUILT_SOURCES)
 
 wayland_protocoldir = $(top_srcdir)/protocol
 include $(top_srcdir)/wayland-scanner.mk
+
+
+weston.ini : $(srcdir)/weston.ini.in
+   $(AM_V_GEN)$(SED) \
+   -e 's|@bindir[@]|$(bindir)|g' \
+   -e 's|@abs_top_builddir[@]|$(abs_top_builddir)|g' \
+   -e 's|@libexecdir[@]|$(libexecdir)|g' \
+   $< > $@
+
+all-local : weston.ini
+
+CLEANFILES += weston.ini
diff --git a/ivi-shell/weston.ini.in b/ivi-shell/weston.ini.in
new file mode 100644
index 000..c9a6861
--- /dev/null
+++ b/ivi-shell/weston.ini.in
@@ -0,0 +1,79 @@
+[core]
+shell=ivi-shell.so
+modules=hmi-controller.so
+
+[ivi-shell]
+cursor-theme=default
+cursor-size=32
+
+base-layer-id=1000
+workspace-background-layer-id=2000
+workspace-layer-id=3000
+application-layer-id=4000
+
+background-image=@abs_top_builddir@/data/background.png
+background-id=1001
+panel-image=@abs_top_builddir@/data/panel.png
+panel-id=1002
+tiling-image=@abs_top_builddir@/data/tiling.png
+tiling-id=1003
+sidebyside-image=@abs_top_builddir@/data/sidebyside.png
+sidebyside-id=1004
+fullscreen-image=@abs_top_builddir@/data/fullscreen.png
+fullscreen-id=1005
+random-image=@abs_top_builddir@/data/random.png
+random-id=1006
+home-image=@abs_top_builddir@/data/home.png
+home-id=1007
+workspace-background-color=0x9900
+workspace-background-id=2001
+
+[ivi-launcher]
+workspace-id=0
+icon=@abs_top_builddir@/data/icon_ivi_flower.png
+path=@abs_top_builddir@/clients/weston-flower-ivi
+
+[ivi-launcher]
+workspace-id=0
+icon=@abs_top_builddir@/data/icon_ivi_clickdot.png
+path=@abs_top_builddir@/clients/weston-clickdot-ivi
+
+[ivi-launcher]
+workspace-id=1
+icon=@abs_top_builddir@/data/icon_ivi_simple-egl.png
+path=@abs_top_builddir@/clients/weston-simple-egl-ivi
+
+[ivi-launcher]
+workspace-id=1
+icon=@abs_top_builddir@/data/icon_ivi_simple-shm.png
+path=@abs_top_builddir@/clients/weston-simple-shm-ivi
+
+[ivi-launcher]
+workspace-id=2
+icon=@abs_top_builddir@/data/icon_ivi_smoke.png
+path=@abs_top_builddir@/clients/weston-smoke-ivi
+
+[ivi-launcher]
+workspace-id=3
+icon=@abs_top_builddir@/data/icon_ivi_flower.png
+path=@abs_top_builddir@/clients/weston-flower-ivi
+
+[ivi-launcher]
+workspace-id=3
+icon=@abs_top_builddir@/data/icon_ivi_clickdot.png
+path=@abs_top_builddir@/clients/weston-clickdot-ivi
+
+[ivi-launcher]
+workspace-id=3
+icon=@abs_top_builddir@/data/icon_ivi_simple-egl.png
+path=@abs_top_builddir@/clients/weston-simple-egl-ivi
+
+[ivi-launcher]
+workspace-id=3
+icon=@abs_top_builddir@/data/icon_ivi_simple-shm.png
+path=@abs_top_builddir@/clients/weston-simple-shm-ivi
+
+[ivi-launcher]
+workspace-id=3
+icon=@abs_top_builddir@/data/icon_ivi_smoke.png
+path=@abs_top_builddir@/clients/weston-smoke-ivi
-- 
1.8.3.1

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

[PATCH weston-ivi-shell 15/15] Modify example clients to support ivi-application.xml

[Nobuhiko Tanibata]

Signed-off-by: Nobuhiko Tanibata 
---
 clients/.gitignore   |  5 
 clients/Makefile.am  | 65 ++
 clients/simple-egl.c | 67 
 clients/simple-shm.c | 50 ++-
 clients/window.c | 42 ++--
 5 files changed, 211 insertions(+), 18 deletions(-)

diff --git a/clients/.gitignore b/clients/.gitignore
index d23027c..41b3be3 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -20,6 +20,11 @@ weston-stacking
 weston-subsurfaces
 weston-transformed
 weston-view
+weston-clickdot-ivi
+weston-flower-ivi
+weston-simple-egl-ivi
+weston-simple-shm-ivi
+weston-smoke-ivi
 
 desktop-shell-client-protocol.h
 desktop-shell-protocol.c
diff --git a/clients/Makefile.am b/clients/Makefile.am
index 4f8d4a6..4bbacb3 100644
--- a/clients/Makefile.am
+++ b/clients/Makefile.am
@@ -7,6 +7,11 @@ demo_clients = \
$(simple_clients_programs)  \
$(simple_egl_clients_programs)
 
+if ENABLE_IVI_SHELL
+demo_clients += \
+   $(ivi_shell_clients_programs)
+endif
+
 if INSTALL_DEMO_CLIENTS
 bin_PROGRAMS += $(demo_clients)
 else
@@ -246,6 +251,66 @@ endif
 
 endif
 
+if ENABLE_IVI_SHELL
+noinst_LTLIBRARIES = libivitoytoolkit.la
+
+libivitoytoolkit_la_SOURCES =  \
+   window.c\
+   window.h\
+   text-cursor-position-protocol.c \
+   text-cursor-position-client-protocol.h  \
+   scaler-protocol.c   \
+   scaler-client-protocol.h\
+   workspaces-protocol.c   \
+   workspaces-client-protocol.h
+
+libivitoytoolkit_la_CPPFLAGS = $(AM_CPPFLAGS) -DENABLE_IVI_CLIENT
+
+libivitoytoolkit_la_LIBADD =   \
+   $(CLIENT_LIBS)  \
+   $(CAIRO_EGL_LIBS)   \
+   ../shared/libshared-cairo.la -lrt -lm
+
+ivi_shell_clients_programs =   \
+   weston-simple-egl-ivi   \
+   weston-simple-shm-ivi   \
+   weston-flower-ivi   \
+   weston-smoke-ivi\
+   weston-clickdot-ivi
+
+weston_simple_egl_ivi_SOURCES = simple-egl.c \
+   ../ivi-shell/ivi-application-protocol.c \
+   ../ivi-shell/ivi-application-client-protocol.h
+weston_simple_egl_ivi_CPPFLAGS = $(SIMPLE_EGL_CLIENT_CFLAGS) 
-DENABLE_IVI_CLIENT
+weston_simple_egl_ivi_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm
+
+weston_simple_shm_ivi_SOURCES = simple-shm.c   \
+   ../shared/os-compatibility.c\
+   ../shared/os-compatibility.h\
+   ../ivi-shell/ivi-application-protocol.c \
+   ../ivi-shell/ivi-application-client-protocol.h
+weston_simple_shm_ivi_CPPFLAGS = $(SIMPLE_CLIENT_CFLAGS) -DENABLE_IVI_CLIENT
+weston_simple_shm_ivi_LDADD = $(SIMPLE_CLIENT_LIBS)
+
+weston_flower_ivi_SOURCES = flower.c \
+   ../ivi-shell/ivi-application-protocol.c \
+   ../ivi-shell/ivi-application-client-protocol.h
+weston_flower_ivi_CPPFLAGS = $(AM_CPPFLAGS) -DENABLE_IVI_CLIENT
+weston_flower_ivi_LDADD = libivitoytoolkit.la
+
+weston_smoke_ivi_SOURCES = smoke.c \
+   ../ivi-shell/ivi-application-protocol.c \
+   ../ivi-shell/ivi-application-client-protocol.h
+weston_smoke_ivi_CPPFLAGS = $(AM_CPPFLAGS) -DENABLE_IVI_CLIENT
+weston_smoke_ivi_LDADD = libivitoytoolkit.la
+
+weston_clickdot_ivi_SOURCES = clickdot.c \
+   ../ivi-shell/ivi-application-protocol.c \
+   ../ivi-shell/ivi-application-client-protocol.h
+weston_clickdot_ivi_CPPFLAGS = $(AM_CPPFLAGS) -DENABLE_IVI_CLIENT
+weston_clickdot_ivi_LDADD = libivitoytoolkit.la
+endif
+
 wayland_protocoldir = $(top_srcdir)/protocol
 include $(top_srcdir)/wayland-scanner.mk
 
diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index 2c009ee..b06742f 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -38,6 +38,13 @@
 #include 
 #include 
 
+#ifdef ENABLE_IVI_CLIENT
+#include 
+#include 
+#include "../ivi-shell/ivi-application-client-protocol.h"
+#define IVI_SURFACE_ID 9000
+#endif
+
 #ifndef EGL_EXT_swap_buffers_with_damage
 #define EGL_EXT_swap_buffers_with_damage 1
 typedef EGLBoolean (EGLAPIENTRYP 
PFNEGLSWAPBUFFERSWITHDAMAGEEXTPROC)(EGLDisplay dpy, EGLSurface surface, EGLint 
*rects, EGLint n_rects);
@@ -70,6 +77,9 @@ struct display {
EGLConfig conf;
} egl;
struct window *window;
+#ifdef ENABLE_IVI_CLIENT
+struct ivi_application *ivi_application;
+#endif
 
PFNEGLSWAPBUFFERSWITHDAMAGEEXTPROC swap_buffers_with_damage;
 };
@@ -91,6 +101,9 @@ struct window {
struct wl_egl_window *native;
struct wl_surface *surface;
struct wl_shell_surface *shell_surface;
+#ifdef ENABLE_IVI_CLIENT
+struct ivi_surface *ivi_surface;
+#endif

RE: [PATCH] Bug fix client apps because of output change

[Wang, Quanxian]

Hi, Pq


>>
>>Is there a reason why the background window does not need the
>>min_allocation changed?
>[Wang, Quanxian] With testing, this doesn't make error. Let me double check 
>that.

[Wang, Quanxian] According to the logic, we need set the min_allocation because 
of background should overwrite the whole output.
I have done with testing with set and not set. Nothing wrong happens in this 
condition. I add that in next updated patch.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Bug fix client apps because of output change

[Quanxian Wang]

1)
Width and height of Panel and Background depend
on output's, therefore they should be bound
with output changes including mode, transform and scale.

2)
Update the min_allocation before resize the panel and
background window. Add window_set_min_allocation function
because it is invisible outside window.c.

Signed-off-by: Quanxian Wang 
---
 clients/desktop-shell.c | 80 +++--
 clients/window.c|  7 +
 clients/window.h|  2 ++
 3 files changed, 87 insertions(+), 2 deletions(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index a0c6b6d..4373448 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -103,6 +103,15 @@ struct output {
 
struct panel *panel;
struct background *background;
+   struct {
+   int height;
+   int width;
+   uint32_t refresh;
+   } mode;
+
+   uint32_t interface_version;
+   uint32_t transform;
+   uint32_t scale;
 };
 
 struct panel_launcher {
@@ -1145,6 +1154,45 @@ desktop_destroy_outputs(struct desktop *desktop)
 }
 
 static void
+update_output(struct output *output)
+{
+   struct panel *panel = output->panel;
+   struct background *background = output->background;
+   int width, height;
+
+   if (!output)
+   return;
+
+   width = output->mode.width;
+   height = output->mode.height;
+
+   switch (output->transform) {
+   case WL_OUTPUT_TRANSFORM_90:
+   case WL_OUTPUT_TRANSFORM_270:
+   case WL_OUTPUT_TRANSFORM_FLIPPED_90:
+   case WL_OUTPUT_TRANSFORM_FLIPPED_270:
+   /* Swap width and height */
+   width = output->mode.height;
+   height = output->mode.width;
+   break;
+   default:
+   break;
+   }
+
+   if (output->scale != 0) {
+   width /= output->scale;
+   height /= output->scale;
+   }
+
+   /* Set min_allocation of panel */
+   window_set_min_allocation(panel->window, width, 32);
+   window_set_min_allocation(background->window, width, height);
+
+   window_schedule_resize(background->window, width, height);
+   window_schedule_resize(panel->window, width, 32);
+}
+
+static void
 output_handle_geometry(void *data,
struct wl_output *wl_output,
int x, int y,
@@ -1157,6 +1205,11 @@ output_handle_geometry(void *data,
 {
struct output *output = data;
 
+   output->transform = transform;
+
+   if (output->interface_version < 2)
+   update_output(output);
+
window_set_buffer_transform(output->panel->window, transform);
window_set_buffer_transform(output->background->window, transform);
 }
@@ -1169,12 +1222,29 @@ output_handle_mode(void *data,
   int height,
   int refresh)
 {
+   struct output *output = data;
+
+   if (flags & WL_OUTPUT_MODE_CURRENT) {
+   if (!output)
+   return;
+
+   output->mode.width = width;
+   output->mode.height = height;
+   output->mode.refresh = refresh;
+
+   if (output->interface_version < 2)
+   update_output(output);
+   }
 }
 
 static void
 output_handle_done(void *data,
struct wl_output *wl_output)
 {
+   struct output *output = data;
+
+   if (output->interface_version >= 2)
+   update_output(output);
 }
 
 static void
@@ -1184,6 +1254,11 @@ output_handle_scale(void *data,
 {
struct output *output = data;
 
+   output->scale  = scale;
+
+   if (output->interface_version < 2)
+   update_output(output);
+
window_set_buffer_scale(output->panel->window, scale);
window_set_buffer_scale(output->background->window, scale);
 }
@@ -1212,7 +1287,7 @@ output_init(struct output *output, struct desktop 
*desktop)
 }
 
 static void
-create_output(struct desktop *desktop, uint32_t id)
+create_output(struct desktop *desktop, uint32_t id, uint32_t version)
 {
struct output *output;
 
@@ -1223,6 +1298,7 @@ create_output(struct desktop *desktop, uint32_t id)
output->output =
display_bind(desktop->display, id, &wl_output_interface, 2);
output->server_output_id = id;
+   output->interface_version = version;
 
wl_output_add_listener(output->output, &output_listener, output);
 
@@ -1247,7 +1323,7 @@ global_handler(struct display *display, uint32_t id,
  desktop->interface_version);
desktop_shell_add_listener(desktop->shell, &listener, desktop);
} else if (!strcmp(interface, "wl_output")) {
-   create_output(desktop, id);
+   create_output(desktop, id, version);
}
 }
 
diff --git a/clients/window.c b/clients/window.c
index c8287e2..6c01222 100644
--- a/clients/win

[PATCH weston-ivi-shell 12/15] Add refernce image files for ivi-hmi-controller

[Nobuhiko Tanibata]

Hi,

This will add the following reference png files but I don't know whether I can 
send huge size of patch, around 650KB, to mailing list. These pngs file can be 
downloaded from here,

https://review.tizen.org/git/?p=profile/ivi/weston-ivi-shell.git;a=tree;f=data;h=600a549d874d7a54c16c3def09a4dad0853532a3;hb=e0f2e11fd31fd8b1201254a6c638c1e21d505ced

BR,
Nobuhiko



Signed-off-by: Nobuhiko Tanibata 
---
 data/background.png  | Bin 0 -> 245579 bytes
 data/fullscreen.png  | Bin 0 -> 3406 bytes
 data/home.png| Bin 0 -> 4629 bytes
 data/icon_ivi_clickdot.png   | Bin 0 -> 39523 bytes
 data/icon_ivi_flower.png | Bin 0 -> 24475 bytes
 data/icon_ivi_simple-egl.png | Bin 0 -> 29316 bytes
 data/icon_ivi_simple-shm.png | Bin 0 -> 71120 bytes
 data/icon_ivi_smoke.png  | Bin 0 -> 46577 bytes
 data/panel.png   | Bin 0 -> 41955 bytes
 data/random.png  | Bin 0 -> 4891 bytes
 data/sidebyside.png  | Bin 0 -> 3929 bytes
 data/tiling.png  | Bin 0 -> 5620 bytes
 12 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 data/background.png
 create mode 100644 data/fullscreen.png
 create mode 100644 data/home.png
 create mode 100644 data/icon_ivi_clickdot.png
 create mode 100644 data/icon_ivi_flower.png
 create mode 100644 data/icon_ivi_simple-egl.png
 create mode 100644 data/icon_ivi_simple-shm.png
 create mode 100644 data/icon_ivi_smoke.png
 create mode 100644 data/panel.png
 create mode 100644 data/random.png
 create mode 100644 data/sidebyside.png
 create mode 100644 data/tiling.png


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

[PATCH weston] weston-launch: Let the user use her real shell

[Quentin Glidic]

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---

This patch restores the old behaviour if the user wants to. This keeps
/bin/sh around for shells that do not understand -c "weston \"$@\"".

 src/weston-launch.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/weston-launch.c b/src/weston-launch.c
index 56e22b1..fd04552 100644
--- a/src/weston-launch.c
+++ b/src/weston-launch.c
@@ -103,6 +103,7 @@ struct weston_launch {
 
pid_t child;
int verbose;
+   int user_shell;
char *new_user;
 };
 
@@ -644,7 +645,7 @@ launch_compositor(struct weston_launch *wl, int argc, char 
*argv[])
sigaddset(&mask, SIGINT);
sigprocmask(SIG_UNBLOCK, &mask, NULL);
 
-   child_argv[0] = "/bin/sh";
+   child_argv[0] = wl->user_shell ? wl->pw->pw_shell : "/bin/sh";
child_argv[1] = "-l";
child_argv[2] = "-c";
child_argv[3] = BINDIR "/weston \"$@\"";
@@ -663,6 +664,7 @@ help(const char *name)
fprintf(stderr, "Usage: %s [args...] [-- [weston args..]]\n", name);
fprintf(stderr, "  -u, --user  Start session as specified 
username\n");
fprintf(stderr, "  -t, --tty   Start session on alternative tty\n");
+   fprintf(stderr, "  -s, --shell Use the user shell instead of 
/bin/sh to run weston\n");
fprintf(stderr, "  -v, --verbose   Be verbose\n");
fprintf(stderr, "  -h, --help  Display this help message\n");
 }
@@ -676,6 +678,7 @@ main(int argc, char *argv[])
struct option opts[] = {
{ "user",required_argument, NULL, 'u' },
{ "tty", required_argument, NULL, 't' },
+   { "shell",   no_argument,   NULL, 's' },
{ "verbose", no_argument,   NULL, 'v' },
{ "help",no_argument,   NULL, 'h' },
{ 0, 0, NULL,  0  }
@@ -683,7 +686,7 @@ main(int argc, char *argv[])
 
memset(&wl, 0, sizeof wl);
 
-   while ((c = getopt_long(argc, argv, "u:t::vh", opts, &i)) != -1) {
+   while ((c = getopt_long(argc, argv, "u:t::svh", opts, &i)) != -1) {
switch (c) {
case 'u':
wl.new_user = optarg;
@@ -693,6 +696,9 @@ main(int argc, char *argv[])
case 't':
tty = optarg;
break;
+   case 's':
+   wl.user_shell = 1;
+   break;
case 'v':
wl.verbose = 1;
break;
-- 
1.9.0

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

Re: [PATCH 1/6] Add weston randr protocol

[Hardening]

Le 05/03/2014 03:07, Wang, Quanxian a écrit :

Hi, All

With the first version of randr protol, I got many useful idea and comments. 
Thanks.

Before I send the email, I have make it happen in real world but need more deep 
testing.

Here are new changes and idea for that protocol based on the idea and comments, 
welcome your input.

1) Unique operation issue
Given that one client has two more threads to do mode setting on the same 
output at the same time, how to identify what response (done event) is belong 
to one or another request when they want to get response?

This is a design flaw in the first version of randr protocol.

The solution is to use the wayland/weston mechanism, every request will 
generate a resource which be used to send done event to the owner who start it. 
Owner could set the listener on that and keep tuning on the response event.

For example
In client:
randr_transform = 
wl_randr_set_transform(randr.randr,wayland_output,argument.transform);

/* Here will will add listen callback to get the response for this unique 
request */
wl_randr_add_listener(randr_transform, &randr_transform_listener, &randr);

In compositor:
randr_resource = wl_resource_create(client,&wl_randr_interface,1, action);
wl_randr_send_action_done(randr_resource, 1<

I don't think that allowing to set only announced modes is a good idea. 
The RDP compositor is a good example where you can't know the supported 
modes (as nearly all modes can be supported).


IIRC depending on the drivers, drm can also set arbitrary modes.

[...]

Apart from that I think we really have to find a way to offer randr like 
interface, this leads to the security requirements that have been talked 
extensively here.


Haven't you noticed that most recent talks on big subjects always end 
with "but what about security ?"


Regards

--
David FORT
website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] weston-launch: Let the user use her real shell

[Jason Ekstrand]

Where is the shell coming from?  If it's the shell specified in /etc/paswd
and if we can guarantee that it doesn't read ~/.profile or similar than
it's ok.  However, If this is the case, then how is it useful to run with
the user's shell?

If it is the shell from $SHELL or if it reads ~/.profile and friends, then
we have just leaked drm/evdev fd's to the entire system and that's bad.  If
the caller can specify a shell or specify the environment in which the
shell runs, then a malicious program can modify this stuff too, run
weston-launch, and get access to protected stuff.  Please double-check this.
--Jason Ekstrand
On Mar 6, 2014 8:03 AM, "Quentin Glidic" 
wrote:

> From: Quentin Glidic 
>
> Signed-off-by: Quentin Glidic 
> ---
>
> This patch restores the old behaviour if the user wants to. This keeps
> /bin/sh around for shells that do not understand -c "weston \"$@\"".
>
>  src/weston-launch.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/weston-launch.c b/src/weston-launch.c
> index 56e22b1..fd04552 100644
> --- a/src/weston-launch.c
> +++ b/src/weston-launch.c
> @@ -103,6 +103,7 @@ struct weston_launch {
>
> pid_t child;
> int verbose;
> +   int user_shell;
> char *new_user;
>  };
>
> @@ -644,7 +645,7 @@ launch_compositor(struct weston_launch *wl, int argc,
> char *argv[])
> sigaddset(&mask, SIGINT);
> sigprocmask(SIG_UNBLOCK, &mask, NULL);
>
> -   child_argv[0] = "/bin/sh";
> +   child_argv[0] = wl->user_shell ? wl->pw->pw_shell : "/bin/sh";
> child_argv[1] = "-l";
> child_argv[2] = "-c";
> child_argv[3] = BINDIR "/weston \"$@\"";
> @@ -663,6 +664,7 @@ help(const char *name)
> fprintf(stderr, "Usage: %s [args...] [-- [weston args..]]\n",
> name);
> fprintf(stderr, "  -u, --user  Start session as specified
> username\n");
> fprintf(stderr, "  -t, --tty   Start session on alternative
> tty\n");
> +   fprintf(stderr, "  -s, --shell Use the user shell instead of
> /bin/sh to run weston\n");
> fprintf(stderr, "  -v, --verbose   Be verbose\n");
> fprintf(stderr, "  -h, --help  Display this help message\n");
>  }
> @@ -676,6 +678,7 @@ main(int argc, char *argv[])
> struct option opts[] = {
> { "user",required_argument, NULL, 'u' },
> { "tty", required_argument, NULL, 't' },
> +   { "shell",   no_argument,   NULL, 's' },
> { "verbose", no_argument,   NULL, 'v' },
> { "help",no_argument,   NULL, 'h' },
> { 0, 0, NULL,  0  }
> @@ -683,7 +686,7 @@ main(int argc, char *argv[])
>
> memset(&wl, 0, sizeof wl);
>
> -   while ((c = getopt_long(argc, argv, "u:t::vh", opts, &i)) != -1) {
> +   while ((c = getopt_long(argc, argv, "u:t::svh", opts, &i)) != -1) {
> switch (c) {
> case 'u':
> wl.new_user = optarg;
> @@ -693,6 +696,9 @@ main(int argc, char *argv[])
> case 't':
> tty = optarg;
> break;
> +   case 's':
> +   wl.user_shell = 1;
> +   break;
> case 'v':
> wl.verbose = 1;
> break;
> --
> 1.9.0
>
> ___
> 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-ivi-shell 02/15] ivi application protocol:

[Jason Ekstrand]

On Mar 6, 2014 3:53 AM, "Nobuhiko Tanibata" <
nobuhiko_tanib...@xddp.denso.co.jp> wrote:
>
> Add interface ivi_application, which creates ivi_surface objects tied
> to a given wl_surface with a given id. The given id can be used in a
> shell to identify which application is assigned to a wl_surface and
> layout the surface wherever the shell wants. ivi_surface objects can
> be used to receive status of wl_surface in the scenegraph of the
> compositor.

In general, I think this looks pretty good.  It's nice and simple and only
adds what's needed for clients.  I do have a couple comments below.
--Jason Ekstrand

>
> Signed-off-by: Nobuhiko Tanibata 
> ---
>  protocol/ivi-application.xml | 88

>  1 file changed, 88 insertions(+)
>  create mode 100644 protocol/ivi-application.xml
>
> diff --git a/protocol/ivi-application.xml b/protocol/ivi-application.xml
> new file mode 100644
> index 000..e58ad26
> --- /dev/null
> +++ b/protocol/ivi-application.xml
> @@ -0,0 +1,88 @@
> +
> +
> +
> +
> +Copyright (C) 2013 DENSO CORPORATION
> +Copyright (c) 2013 BMW Car IT GmbH
> +
> +Permission is hereby granted, free of charge, to any person
obtaining a copy
> +of this software and associated documentation files (the
"Software"), to deal
> +in the Software without restriction, including without limitation
the rights
> +to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell
> +copies of the Software, and to permit persons to whom the Software is
> +furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice shall be
included in
> +all copies or substantial portions of the Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
> +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
> +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN
> +THE SOFTWARE.
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +The new visibility state is provided in argument
visibility.
> +If visibility is 0, the surface has become invisible.
> +If visibility is not 0, the surface has become visible.
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +surface_create will create a new surface with surface_id
in ivi compositor,
> +if it does not yet exists. If the surface with
surface_id already exists in
> +ivi compositor, the application content provided in
argument surface will
> +be used as surface content. If an other ivi application
already registered
> +content for surface with surface_id, an error event will
indicate the problem.
> +
> +
> +
> +
> +
> +
> +
> +
> +These error codes define all possible error codes
returned by ivi compositor
> +on server-side errors.
> +
> +

What kinds of things do you use "unknown error" for?  I'm not sure how
that's useful to the client.

> +

What kind of resource does this refer to?  It looks like you use it if
someone tries to call surface_create twice on the same surface, but you
don't specify.

> +
> +
> +
> +
> +The ivi compositor encountered error while processing a
request by this
> +application. The error is defined by argument error_code
and optional
> +error_text.
> +If the application requires to associate this error
event to a request,
> +it can
> +1. send request
> +2. force display roundtrip
> +3. check, if error event was received
> + but this restricts the application to have only one
open request at a time.
> +
> +
> +
> +

Why are you using this rather than the built-in wl_display.error?  The
built-in wl_display.error also terminates the client when an error is
sent.  Under what error conditions would you want the client to continue?

> +
> +
> +
> +
> --
> 1.8.3.1
>
> ___
> 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.o

[PATCH weston] weston-launch: Do not run weston in a shell

[Quentin Glidic]

From: Quentin Glidic 

Since 636156d5f693ac5b01cec6a2937d2b6cd4237ea9 it is not needed any more
to allow the user to pass environment to weston. Actually, the login
shell is wiping parts of the environment.

Signed-off-by: Quentin Glidic 
---

Then we should remove the shell invocation alltogether.

I still need a way to run things at weston’s start and stop,
but that can wait for another patch.

 src/weston-launch.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/src/weston-launch.c b/src/weston-launch.c
index 56e22b1..1f67557 100644
--- a/src/weston-launch.c
+++ b/src/weston-launch.c
@@ -644,16 +644,12 @@ launch_compositor(struct weston_launch *wl, int argc, 
char *argv[])
sigaddset(&mask, SIGINT);
sigprocmask(SIG_UNBLOCK, &mask, NULL);
 
-   child_argv[0] = "/bin/sh";
-   child_argv[1] = "-l";
-   child_argv[2] = "-c";
-   child_argv[3] = BINDIR "/weston \"$@\"";
-   child_argv[4] = "weston";
+   child_argv[0] = BINDIR "/weston";
for (i = 0; i < argc; ++i)
-   child_argv[5 + i] = argv[i];
-   child_argv[5 + i] = NULL;
+   child_argv[1 + i] = argv[i];
+   child_argv[1 + i] = NULL;
 
-   execv(child_argv[0], child_argv);
+   execv("weston", child_argv);
error(1, errno, "exec failed");
 }
 
-- 
1.9.0

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

Wayland and multiseat

[Daniel J Blueman]

Is it possible to run Weston on a tri-output Intel GPU, with three
fullscreen XWayland sessions with a touchscreen bound to each
XWayland?

Of course, this would be an excellent alternative to Xephyr and it's
limitations.

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

Re: [PATCH 1/6] Add weston randr protocol

[Hardening]

Le 05/03/2014 11:04, Pekka Paalanen a écrit :

On Wed, 5 Mar 2014 09:40:32 +
"Wang, Quanxian"  wrote:


Just mention one thing

Pq:
But RandR is a disaster if random applications use it! Windows and
icons squashed into top-left corner, dialogs too large to fit on the
screen after the random application fails to restore the video mode,
or the picture just looking horrible and an average user not even
knowing why everything suddenly went ugly. [Wang, Quanxian] For this,
if you think it is disaster because of mode setting. It is a pity. If
the apps designer is careful, layout should be consistent with width
or height of output. In my testing for randr protocol, I found window
is designed to use width and height of output. Because it uses width
and height of output, but it doesn't care the change of
output(wl_output provides the mechanism to listen mode, scale
change). You can read my patch 6/6 for bug fix. It is just one fix.
It is the apps design flaw instead of wayland issue. Also you also
find 200 or 600 some hard code number is set.


Yeah, it looks like the patch 6/6 would be a nice fix, but I think you
should resend that alone, so it won't have to wait until the protocol
design is concluded. It's a stand-alone patch, right?



+1 for this one which is a very old bug.


--
David FORT
website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston-ivi-shell 02/15] ivi application protocol:

[Nobuhiko Tanibata]

2014-03-07 00:21 に Jason Ekstrand さんは書きました:

On Mar 6, 2014 3:53 AM, "Nobuhiko Tanibata"
 wrote:
 >
 > Add interface ivi_application, which creates ivi_surface objects
tied
 > to a given wl_surface with a given id. The given id can be used in
a
 > shell to identify which application is assigned to a wl_surface and
 > layout the surface wherever the shell wants. ivi_surface objects
can
 > be used to receive status of wl_surface in the scenegraph of the
 > compositor.

In general, I think this looks pretty good.  It's nice and simple and
only adds what's needed for clients.  I do have a couple comments
below.
 --Jason Ekstrand




 > Signed-off-by: Nobuhiko Tanibata

 > ---
 >  protocol/ivi-application.xml | 88

 >  1 file changed, 88 insertions(+)
 >  create mode 100644 protocol/ivi-application.xml
 >
 > diff --git a/protocol/ivi-application.xml
b/protocol/ivi-application.xml
 > new file mode 100644
 > index 000..e58ad26
 > --- /dev/null
 > +++ b/protocol/ivi-application.xml
 > @@ -0,0 +1,88 @@
 > +
 > +
 > +
 > +    
 > +    Copyright (C) 2013 DENSO CORPORATION
 > +    Copyright (c) 2013 BMW Car IT GmbH
 > +
 > +    Permission is hereby granted, free of charge, to any person
obtaining a copy
 > +    of this software and associated documentation files (the
"Software"), to deal
 > +    in the Software without restriction, including without
limitation the rights
 > +    to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell
 > +    copies of the Software, and to permit persons to whom the
Software is
 > +    furnished to do so, subject to the following conditions:
 > +
 > +    The above copyright notice and this permission notice shall
be included in
 > +    all copies or substantial portions of the Software.
 > +
 > +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR
 > +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
 > +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
EVENT SHALL THE
 > +    AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER
 > +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM,
 > +    OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN
 > +    THE SOFTWARE.
 > +    
 > +
 > +    
 > +        
 > +
 > +        
 > +            
 > +        
 > +
 > +        
 > +            
 > +                The new visibility state is provided in
argument visibility.
 > +                If visibility is 0, the surface has become
invisible.
 > +                If visibility is not 0, the surface has
become visible.
 > +            
 > +            
 > +        
 > +
 > +    
 > +
 > +    
 > +        
 > +
 > +        
 > +            
 > +                surface_create will create a new surface
with surface_id in ivi compositor,
 > +                if it does not yet exists. If the surface
with surface_id already exists in
 > +                ivi compositor, the application content
provided in argument surface will
 > +                be used as surface content. If an other
ivi application already registered
 > +                content for surface with surface_id, an
error event will indicate the problem.
 > +            
 > +            
 > +            
 > +            
 > +        
 > +
 > +        
 > +            
 > +                These error codes define all possible
error codes returned by ivi compositor
 > +                on server-side errors.
 > +            
 > +            

What kinds of things do you use "unknown error" for?  I'm not sure
how that's useful to the client.



Hi Jason,

Thank you for reviewing.

I see. From this review point, it shall not return no useful value to 
the client.

I break down more here.
- id in use: specified ID for ivi_surface is already used by itself or 
other client.
- resource in use: specified ID of wl_surface is already tie to another 
ID of ivi_surface.

- invalid resource: specified ID of wl_surface is not valid in server.

I think these three is sufficient for client.


+            
summary="resource is in use and can not be shared"/>

What kind of resource does this refer to?  It looks like you use it
if someone tries to call surface_create twice on the same surface, but
you don't specify.


+        

 > +
 > +        
 > +            
 > +                The ivi compositor encountered error while
processing a request by this
 > +                application. The error is defined by
argument error_code and optional
 > +                error_text.
 > +                If the application requires to associate
this error event to a request,
 > +                it can
 > +                    1. send request
 > +                    2. force display roundtrip
 > +                    3. check, if error event was
received
 > +                 but this restricts the application to
have only one open request at a time.
 > +            
 > +    

Re: [PATCH weston-ivi-shell 02/15] ivi application protocol:

[Jason Ekstrand]

On Mar 6, 2014 7:08 PM, "Nobuhiko Tanibata" <
nobuhiko_tanib...@xddp.denso.co.jp> wrote:
>
> 2014-03-07 00:21 に Jason Ekstrand さんは書きました:
>
>> On Mar 6, 2014 3:53 AM, "Nobuhiko Tanibata"
>>  wrote:
>>  >
>>  > Add interface ivi_application, which creates ivi_surface objects
>> tied
>>  > to a given wl_surface with a given id. The given id can be used in
>> a
>>  > shell to identify which application is assigned to a wl_surface and
>>  > layout the surface wherever the shell wants. ivi_surface objects
>> can
>>  > be used to receive status of wl_surface in the scenegraph of the
>>  > compositor.
>>
>> In general, I think this looks pretty good.  It's nice and simple and
>> only adds what's needed for clients.  I do have a couple comments
>> below.
>>  --Jason Ekstrand
>>
>>>
>>  > Signed-off-by: Nobuhiko Tanibata
>> 
>>  > ---
>>  >  protocol/ivi-application.xml | 88
>> 
>>  >  1 file changed, 88 insertions(+)
>>  >  create mode 100644 protocol/ivi-application.xml
>>  >
>>  > diff --git a/protocol/ivi-application.xml
>> b/protocol/ivi-application.xml
>>  > new file mode 100644
>>  > index 000..e58ad26
>>  > --- /dev/null
>>  > +++ b/protocol/ivi-application.xml
>>  > @@ -0,0 +1,88 @@
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +Copyright (C) 2013 DENSO CORPORATION
>>  > +Copyright (c) 2013 BMW Car IT GmbH
>>  > +
>>  > +Permission is hereby granted, free of charge, to any person
>> obtaining a copy
>>  > +of this software and associated documentation files (the
>> "Software"), to deal
>>  > +in the Software without restriction, including without
>> limitation the rights
>>  > +to use, copy, modify, merge, publish, distribute,
>> sublicense, and/or sell
>>  > +copies of the Software, and to permit persons to whom the
>> Software is
>>  > +furnished to do so, subject to the following conditions:
>>  > +
>>  > +The above copyright notice and this permission notice shall
>> be included in
>>  > +all copies or substantial portions of the Software.
>>  > +
>>  > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
>> KIND, EXPRESS OR
>>  > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>>  > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>> EVENT SHALL THE
>>  > +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
>> DAMAGES OR OTHER
>>  > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>> OTHERWISE, ARISING FROM,
>>  > +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> OTHER DEALINGS IN
>>  > +THE SOFTWARE.
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +The new visibility state is provided in
>> argument visibility.
>>  > +If visibility is 0, the surface has become
>> invisible.
>>  > +If visibility is not 0, the surface has
>> become visible.
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +surface_create will create a new surface
>> with surface_id in ivi compositor,
>>  > +if it does not yet exists. If the surface
>> with surface_id already exists in
>>  > +ivi compositor, the application content
>> provided in argument surface will
>>  > +be used as surface content. If an other
>> ivi application already registered
>>  > +content for surface with surface_id, an
>> error event will indicate the problem.
>>  > +
>>  > +
>>  > +> interface="wl_surface"/>
>>  > +> interface="ivi_surface"/>
>>  > +
>>  > +
>>  > +
>>  > +
>>  > +These error codes define all possible
>> error codes returned by ivi compositor
>>  > +on server-side errors.
>>  > +
>>  > +> summary="unknown error encountered"/>
>>
>> What kinds of things do you use "unknown error" for?  I'm not sure
>> how that's useful to the client.
>>
>
> Hi Jason,
>
> Thank you for reviewing.
>
> I see. From this review point, it shall not return no useful value to the
client.
> I break down more here.
> - id in use: specified ID for ivi_surface is already used by itself or
other client.
> - resource in use: specified ID of wl_surface is already tie to another
ID of ivi_surface.
> - invalid resource: specified ID of wl_surface is not valid in server.
>
> I think these three is sufficient for client.
>
>
>>> +>
>> summary="resource is in use and can not be shared"/>
>>
>> What kind of resource does this refer to?  It looks like you use it
>> if someone tries to call surface_create twice on the same surface, but
>> you don't specify.
>>
>>> +
>>
>>  > +
>>  > +
>>  > +
>> 

RE: [PATCH] Bug fix client apps because of output change

[Wang, Quanxian]

Ignore this, I have found a bug. After bug fixing, I will resend the patch. 
Sorry about that.

I have two monitors. 
VGA1(left) + HDMI3(right)

The bug is shown when you set the mode of HDMI3 to 800x600, and then move 
layout as HDMI3(left) + VGA1(right), and then change to mode 1920x1200.
It will have some issue.

Sorry about that.

Regards

Quanxian Wang

>-Original Message-
>From: Wang, Quanxian
>Sent: Thursday, March 06, 2014 6:31 PM
>To: wayland-devel@lists.freedesktop.org
>Cc: ppaala...@gmail.com; Wang, Quanxian
>Subject: [PATCH] Bug fix client apps because of output change
>
>1)
>Width and height of Panel and Background depend on output's, therefore they
>should be bound with output changes including mode, transform and scale.
>
>2)
>Update the min_allocation before resize the panel and background window. Add
>window_set_min_allocation function because it is invisible outside window.c.
>
>Signed-off-by: Quanxian Wang 
>---
> clients/desktop-shell.c | 80
>+++--
> clients/window.c|  7 +
> clients/window.h|  2 ++
> 3 files changed, 87 insertions(+), 2 deletions(-)
>
>diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c index
>a0c6b6d..4373448 100644
>--- a/clients/desktop-shell.c
>+++ b/clients/desktop-shell.c
>@@ -103,6 +103,15 @@ struct output {
>
>   struct panel *panel;
>   struct background *background;
>+  struct {
>+  int height;
>+  int width;
>+  uint32_t refresh;
>+  } mode;
>+
>+  uint32_t interface_version;
>+  uint32_t transform;
>+  uint32_t scale;
> };
>
> struct panel_launcher {
>@@ -1145,6 +1154,45 @@ desktop_destroy_outputs(struct desktop *desktop)  }
>
> static void
>+update_output(struct output *output)
>+{
>+  struct panel *panel = output->panel;
>+  struct background *background = output->background;
>+  int width, height;
>+
>+  if (!output)
>+  return;
>+
>+  width = output->mode.width;
>+  height = output->mode.height;
>+
>+  switch (output->transform) {
>+  case WL_OUTPUT_TRANSFORM_90:
>+  case WL_OUTPUT_TRANSFORM_270:
>+  case WL_OUTPUT_TRANSFORM_FLIPPED_90:
>+  case WL_OUTPUT_TRANSFORM_FLIPPED_270:
>+  /* Swap width and height */
>+  width = output->mode.height;
>+  height = output->mode.width;
>+  break;
>+  default:
>+  break;
>+  }
>+
>+  if (output->scale != 0) {
>+  width /= output->scale;
>+  height /= output->scale;
>+  }
>+
>+  /* Set min_allocation of panel */
>+  window_set_min_allocation(panel->window, width, 32);
>+  window_set_min_allocation(background->window, width, height);
>+
>+  window_schedule_resize(background->window, width, height);
>+  window_schedule_resize(panel->window, width, 32); }
>+
>+static void
> output_handle_geometry(void *data,
>struct wl_output *wl_output,
>int x, int y,
>@@ -1157,6 +1205,11 @@ output_handle_geometry(void *data,  {
>   struct output *output = data;
>
>+  output->transform = transform;
>+
>+  if (output->interface_version < 2)
>+  update_output(output);
>+
>   window_set_buffer_transform(output->panel->window, transform);
>   window_set_buffer_transform(output->background->window,
>transform);  } @@ -1169,12 +1222,29 @@ output_handle_mode(void *data,
>  int height,
>  int refresh)
> {
>+  struct output *output = data;
>+
>+  if (flags & WL_OUTPUT_MODE_CURRENT) {
>+  if (!output)
>+  return;
>+
>+  output->mode.width = width;
>+  output->mode.height = height;
>+  output->mode.refresh = refresh;
>+
>+  if (output->interface_version < 2)
>+  update_output(output);
>+  }
> }
>
> static void
> output_handle_done(void *data,
>struct wl_output *wl_output)  {
>+  struct output *output = data;
>+
>+  if (output->interface_version >= 2)
>+  update_output(output);
> }
>
> static void
>@@ -1184,6 +1254,11 @@ output_handle_scale(void *data,  {
>   struct output *output = data;
>
>+  output->scale  = scale;
>+
>+  if (output->interface_version < 2)
>+  update_output(output);
>+
>   window_set_buffer_scale(output->panel->window, scale);
>   window_set_buffer_scale(output->background->window, scale);  } @@
>-1212,7 +1287,7 @@ output_init(struct output *output, struct desktop
>*desktop)  }
>
> static void
>-create_output(struct desktop *desktop, uint32_t id)
>+create_output(struct desktop *desktop, uint32_t id, uint32_t version)
> {
>   struct output *output;
>
>@@ -1223,6 +1298,7 @@ create_output(struct desktop *desktop, uint32_t id)
>   output->output =
>   display_bind(desktop->display, id, &wl_output_interface

RE: [PATCH 1/6] Add weston randr protocol

[Jason Ekstrand]

On Mar 6, 2014 3:05 AM, "Wang, Quanxian"  wrote:
>
> Thanks Pq's comment.
>
> By the way, if we make it as a configuration tools or testing protocol.
Will it be fine or not?
>
> For example graphics QA testing,
> I just send a patch to bug fix the client apps because of output change.
I use weston-wrandr to do the testing to make sure what I have done is
right. If I have not this tool, I don't make sure how to test it. Because
you need dynamically change rotate, transform, or mode set to make sure
desktop shell could get the change and really works fine with new change.
>
> Also this tool should be fine for wayland QA testing.
>
> Anyway, if you guys think it right for configuration or testing wayland
graphics tools, that is fine. I can continue working on these patches
instead of original idea to expose this to client to use.

Quanxian,
I think that for testing and configuration, this is fine.  In fact, when
testing my fullscreen shell I really wish I had a utility like that.  Right
now, with recent changes to toytoolkit, there's no good way to trigger a
dynamic mode-switch for testing.  If you go ahead and add this, I have a
couple suggestions:

1) Rename it weston_randr and make it weston-specific.

2) Make it a module and possibly require a command-line option to allow the
command-line utility to connect.  It's great for testing, but we want the
user to explicitly state that they want the command-line utility

3) It would be nice if we had a little GUI that gets launched priveledged
to change the mode.  This can be launched from weston directly, so we can
give it access to the private interface similar to the way the
screenshooter or desktop-shell is launched.  This wouldn't need the
security of a command-line option because it requires direct user
interaction and can't be executed from a script.

All that being said, I don't think you should expect GNOME, KDE, or the
others to be interested in this as a standard.  They have their own
mechanisms and GUI's for output configuration and I don't thin an output
configuration standard would be of any real use.

Hope that helps,
--Jason Ekstrand

>
> Thanks for everyone's comment and help.
>
> Regards
>
> Quanxian Wang
>
> >-Original Message-
> >From: wayland-devel-boun...@lists.freedesktop.org
> >[mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Pekka
> >Paalanen
> >Sent: Thursday, March 06, 2014 4:25 PM
> >To: Wang, Quanxian
> >Cc: Hardening; Jasper St. Pierre; Matthias Clasen;
> >wayland-devel@lists.freedesktop.org; Jason Ekstrand; Zhang, Xiong Y
> >Subject: Re: [PATCH 1/6] Add weston randr protocol
> >
> >On Thu, 6 Mar 2014 03:01:11 +
> >"Wang, Quanxian"  wrote:
> >
> >> Except the comment below. I mention some points.
> >>
> >> 1) My idea:
> >> My original idea is from xrandr of xserver. I just want to let xrandr
> >> could be implemented in wayland. If no protocol is used, that is fine.
> >> But no way to implement some function for example transform, scale,
> >> mode set output. I have to create a protocol to communicate with
> >> compositor and let compositor do that.
> >
> >Usually such configuration changes should originate within the
compositor itself. In
> >practice, it could be a special shell helper application (e.g.
weston-desktop-shell)
> >using a private protocol to communicate the intent of the user.
> >
> >The X server is different, because the X server is the same for every
environment,
> >so it must have standard protocol to do configuration changes. On
Wayland this is
> >not the case.
> >
> >> This protocol basically live with compositor. It also provides the
> >> interface for library above to provide the randr function. For example
> >> efl, gtk, or ... If you think it is to build the standard protocol,
> >> that is fine. Anyway, my idea is that.
> >
> >The point is, those toolkit libraries should not have access to
"wayland-randr" at all.
> >It's not something a normal application should use.
> >
> >Again in X things are different because the RandR protocol must exist,
but there is
> >no easy way to make it restricted.
> >
> >> 2) About mode setting requirement:
> >> Most of case, it is for configuration of output as a whole. Generally
> >> it should be in setting panel for screen size, rotation, ...option
> >> setting. The user cases I mentioned are related with that setting. Of
> >> course you may prefer another way to implement.
> >
> >Such use cases would be perfectly served by the special shell client,
which already
> >needs a private, priviledged interface to the compositor anyway. This
private
> >interface is almost always environment specific.
> >
> >Wayland is not X; it is not intended that you could simply run a "panel
program" at
> >any time and expect it to add a well-functioning panel to the desktop.
Such
> >programs are special, so in the current design they are started directly
by the
> >compositor.
> >
> >>
> >> 3) Security Issue:
> >> I found Pq, Jason, Japsper, ... don't want to expose the

Re: [PATCH weston v4 01/15] Add a fullscreen shell protocol

[Bryce W. Harrington]

On Tue, Feb 25, 2014 at 07:26:33PM -0600, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand 
> ---
>  protocol/fullscreen-shell.xml | 158 
> ++
>  1 file changed, 158 insertions(+)
>  create mode 100644 protocol/fullscreen-shell.xml
> 
> diff --git a/protocol/fullscreen-shell.xml b/protocol/fullscreen-shell.xml
> new file mode 100644
> index 000..13bdfcf
> --- /dev/null
> +++ b/protocol/fullscreen-shell.xml
> @@ -0,0 +1,158 @@
> +
> +  
> +
> +  Displays a single surface per output.
> +
> +  This interface provides a mechanism for a single client to display
> +  simple full-screen surfaces.  While there technically may be multiple
> +  clients bound to this interface, only one of those clients should be
> +  shown at a time.
> +
> +  To present a surface, the client uses either the present_surface or
> +  present_surface_for_mode requests.  Presenting a surface takes effect
> +  on the next wl_surface.commit.  See the individual requests for
> +  details about scaling and mode switches.
> +  
> +  The client can have at most one surface per output at any time.
> +  Requesting a surface be presented on an output that already has a
> +  surface replaces the previously presented surface.  Presenting a null
> +  surface removes its content and effectively disables the output.
> +  Exactly what happens when an output is "disabled" is
> +  compositor-specific.  The same surface may be presented multiple

presented to multiple

> +  outputs simultaneously.
> +
> +  Once a surface is presented on an output, it stays on that output
> +  until either the client removes it or the compositor destroys the
> +  output.  This way, the client can update the output's contents by
> +  simply attaching a new buffer.
> +
> +
> +
> +  
> + Release the binding from the wl_fullscreen_shell interface
> +
> + This destroys the server-side object and frees this binding.  If
> + the client binds to wl_fullscreen_shell multiple times, it may wish
> + to free some of those bindings.
> +  
> +
> +
> +
> +  
> + Hints to indicate to the compositor how to deal with a conflict
> + between the dimensions of the surface and the dimensions of the
> + output. The compositor is free to ignore this parameter.
> +  
> +  
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> + Present a surface on the given output.
> +
> + If the output is null, the compositor will present the surface on
> + whatever display (or displays) it thinks best.  In particular, this
> + may replace any or all surfaces currently presented so it should
> + not be used in combination with placing surfaces on specific
> + outputs.
> +
> + The method parameter is a hint to the compositor for how the surface
> + is to be presented.  In particular, it tells the compostior how to
> + handle a size mismatch between the presented surface and the
> + output.  The compositor is free to ignore this parameter.
> +
> + The "zoom", "zoom_crop", and "stretch" methods imply a scaling
> + operation on the surface.  This will override any kind of output
> + scaling, so the buffer_scale property of the surface is effectively
> + ignored.
> +  
> +   allow-null="true"/>
> +  
> +   allow-null="true"/>
> +
> +
> +
> +  
> + Presents a surface on the given output for a particular mode.
> +
> + If the current size of the output differs from that of the surface,
> + the compositor will attempt to change the size of the output to
> + match the surface.  The result of the mode-swith operation will be

mode-switch

> + returned via the provided wl_fullscreen_shell_mode_feedback object.
> +
> + If the current output mode matches the one requested or if the
> + compositor successfully switches the mode to match the surface,
> + then the mode_successfull event will be sent and the output will

mode_successful event

> + contain the contents of the given surface.  If the compositor
> + cannot match the output size to the surface size, the mode_failed
> + will be sent and the output will contain the contents of the
> + previously presented surface (if any).  If another surface is
> + presented on the given output before either of these has a chance
> + to happen, the present_canceled event will be sent.

present_cancelled

Grepping weston for 'canceled' vs. 'cancelled' seems to indicate the
latter spelling is preferred.

> + If the size of the presented surface changes, the resulting output
> + is undefined.  The compositor may attempt to change the output mode
> + to compensate.  However, there is no guarantee that a suitable mode
> + will be found and the client has no way to be notified of success
> + or failure.

Probabl

RE: [PATCH] Bug fix client apps because of output change

[Wang, Quanxian]

I have double checked the patch and retesting it.

The bug is caused by not setting background window size after output change.

This fix has been included in previous patch. Pq's comment is right. We should 
set background min allocation before resize. 

Why did I get this? Because I just use another patch which only comment 
min_allocation of background for testing. This caused the bug I mentioned.

Just use previous patch is fine.

Thanks

Regards

Quanxian Wang


>-Original Message-
>From: Wang, Quanxian
>Sent: Friday, March 07, 2014 10:44 AM
>To: wayland-devel@lists.freedesktop.org
>Cc: ppaala...@gmail.com
>Subject: RE: [PATCH] Bug fix client apps because of output change
>
>Ignore this, I have found a bug. After bug fixing, I will resend the patch. 
>Sorry
>about that.
>
>I have two monitors.
>VGA1(left) + HDMI3(right)
>
>The bug is shown when you set the mode of HDMI3 to 800x600, and then move
>layout as HDMI3(left) + VGA1(right), and then change to mode 1920x1200.
>It will have some issue.
>
>Sorry about that.
>
>Regards
>
>Quanxian Wang
>
>>-Original Message-
>>From: Wang, Quanxian
>>Sent: Thursday, March 06, 2014 6:31 PM
>>To: wayland-devel@lists.freedesktop.org
>>Cc: ppaala...@gmail.com; Wang, Quanxian
>>Subject: [PATCH] Bug fix client apps because of output change
>>
>>1)
>>Width and height of Panel and Background depend on output's, therefore
>>they should be bound with output changes including mode, transform and scale.
>>
>>2)
>>Update the min_allocation before resize the panel and background
>>window. Add window_set_min_allocation function because it is invisible outside
>window.c.
>>
>>Signed-off-by: Quanxian Wang 
>>---
>> clients/desktop-shell.c | 80
>>+++--
>> clients/window.c|  7 +
>> clients/window.h|  2 ++
>> 3 files changed, 87 insertions(+), 2 deletions(-)
>>
>>diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c index
>>a0c6b6d..4373448 100644
>>--- a/clients/desktop-shell.c
>>+++ b/clients/desktop-shell.c
>>@@ -103,6 +103,15 @@ struct output {
>>
>>  struct panel *panel;
>>  struct background *background;
>>+ struct {
>>+ int height;
>>+ int width;
>>+ uint32_t refresh;
>>+ } mode;
>>+
>>+ uint32_t interface_version;
>>+ uint32_t transform;
>>+ uint32_t scale;
>> };
>>
>> struct panel_launcher {
>>@@ -1145,6 +1154,45 @@ desktop_destroy_outputs(struct desktop *desktop)
>>}
>>
>> static void
>>+update_output(struct output *output)
>>+{
>>+ struct panel *panel = output->panel;
>>+ struct background *background = output->background;
>>+ int width, height;
>>+
>>+ if (!output)
>>+ return;
>>+
>>+ width = output->mode.width;
>>+ height = output->mode.height;
>>+
>>+ switch (output->transform) {
>>+ case WL_OUTPUT_TRANSFORM_90:
>>+ case WL_OUTPUT_TRANSFORM_270:
>>+ case WL_OUTPUT_TRANSFORM_FLIPPED_90:
>>+ case WL_OUTPUT_TRANSFORM_FLIPPED_270:
>>+ /* Swap width and height */
>>+ width = output->mode.height;
>>+ height = output->mode.width;
>>+ break;
>>+ default:
>>+ break;
>>+ }
>>+
>>+ if (output->scale != 0) {
>>+ width /= output->scale;
>>+ height /= output->scale;
>>+ }
>>+
>>+ /* Set min_allocation of panel */
>>+ window_set_min_allocation(panel->window, width, 32);
>>+ window_set_min_allocation(background->window, width, height);
>>+
>>+ window_schedule_resize(background->window, width, height);
>>+ window_schedule_resize(panel->window, width, 32); }
>>+
>>+static void
>> output_handle_geometry(void *data,
>>struct wl_output *wl_output,
>>int x, int y,
>>@@ -1157,6 +1205,11 @@ output_handle_geometry(void *data,  {
>>  struct output *output = data;
>>
>>+ output->transform = transform;
>>+
>>+ if (output->interface_version < 2)
>>+ update_output(output);
>>+
>>  window_set_buffer_transform(output->panel->window, transform);
>>  window_set_buffer_transform(output->background->window,
>>transform);  } @@ -1169,12 +1222,29 @@ output_handle_mode(void *data,
>> int height,
>> int refresh)
>> {
>>+ struct output *output = data;
>>+
>>+ if (flags & WL_OUTPUT_MODE_CURRENT) {
>>+ if (!output)
>>+ return;
>>+
>>+ output->mode.width = width;
>>+ output->mode.height = height;
>>+ output->mode.refresh = refresh;
>>+
>>+ if (output->interface_version < 2)
>>+ update_output(output);
>>+ }
>> }
>>
>> static void
>> output_handle_done(void *data,
>>struct wl_output *wl_output)  {
>>+ struct output *output = data;
>>+
>>+ if (output->interface_version >= 2)
>>+ update_output(output);
>> }
>>
>> static void
>>@@ -1184

RE: [PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Friday, March 07, 2014 11:21 AM
To: Wang, Quanxian
Cc: Hardening; Matthias Clasen; wayland-devel@lists.freedesktop.org; Jasper St. 
Pierre; Pekka Paalanen
Subject: RE: [PATCH 1/6] Add weston randr protocol


On Mar 6, 2014 3:05 AM, "Wang, Quanxian" 
mailto:quanxian.w...@intel.com>> wrote:
>
> Thanks Pq's comment.
>
> By the way, if we make it as a configuration tools or testing protocol. Will 
> it be fine or not?
>
> For example graphics QA testing,
> I just send a patch to bug fix the client apps because of output change. I 
> use weston-wrandr to do the testing to make sure what I have done is right. 
> If I have not this tool, I don't make sure how to test it. Because you need 
> dynamically change rotate, transform, or mode set to make sure desktop shell 
> could get the change and really works fine with new change.
>
> Also this tool should be fine for wayland QA testing.
>
> Anyway, if you guys think it right for configuration or testing wayland 
> graphics tools, that is fine. I can continue working on these patches instead 
> of original idea to expose this to client to use.

Quanxian,
I think that for testing and configuration, this is fine.  In fact, when 
testing my fullscreen shell I really wish I had a utility like that.  Right 
now, with recent changes to toytoolkit, there's no good way to trigger a 
dynamic mode-switch for testing.  If you go ahead and add this, I have a couple 
suggestions:

1) Rename it weston_randr and make it weston-specific.

2) Make it a module and possibly require a command-line option to allow the 
command-line utility to connect.  It's great for testing, but we want the user 
to explicitly state that they want the command-line utility

3) It would be nice if we had a little GUI that gets launched priveledged to 
change the mode.  This can be launched from weston directly, so we can give it 
access to the private interface similar to the way the screenshooter or 
desktop-shell is launched.  This wouldn't need the security of a command-line 
option because it requires direct user interaction and can't be executed from a 
script.

[Wang, Quanxian] That is a good news. Thanks. I will continue working on that 
and provide the patches. Thanks for your response.

All that being said, I don't think you should expect GNOME, KDE, or the others 
to be interested in this as a standard.  They have their own mechanisms and 
GUI's for output configuration and I don't thin an output configuration 
standard would be of any real use.

Hope that helps,
--Jason Ekstrand

>
> Thanks for everyone's comment and help.
>
> Regards
>
> Quanxian Wang
>
> >-Original Message-
> >From: 
> >wayland-devel-boun...@lists.freedesktop.org
> >[mailto:wayland-devel-boun...@lists.freedesktop.org]
> > On Behalf Of Pekka
> >Paalanen
> >Sent: Thursday, March 06, 2014 4:25 PM
> >To: Wang, Quanxian
> >Cc: Hardening; Jasper St. Pierre; Matthias Clasen;
> >wayland-devel@lists.freedesktop.org;
> > Jason Ekstrand; Zhang, Xiong Y
> >Subject: Re: [PATCH 1/6] Add weston randr protocol
> >
> >On Thu, 6 Mar 2014 03:01:11 +
> >"Wang, Quanxian" mailto:quanxian.w...@intel.com>> 
> >wrote:
> >
> >> Except the comment below. I mention some points.
> >>
> >> 1) My idea:
> >> My original idea is from xrandr of xserver. I just want to let xrandr
> >> could be implemented in wayland. If no protocol is used, that is fine.
> >> But no way to implement some function for example transform, scale,
> >> mode set output. I have to create a protocol to communicate with
> >> compositor and let compositor do that.
> >
> >Usually such configuration changes should originate within the compositor 
> >itself. In
> >practice, it could be a special shell helper application (e.g. 
> >weston-desktop-shell)
> >using a private protocol to communicate the intent of the user.
> >
> >The X server is different, because the X server is the same for every 
> >environment,
> >so it must have standard protocol to do configuration changes. On Wayland 
> >this is
> >not the case.
> >
> >> This protocol basically live with compositor. It also provides the
> >> interface for library above to provide the randr function. For example
> >> efl, gtk, or ... If you think it is to build the standard protocol,
> >> that is fine. Anyway, my idea is that.
> >
> >The point is, those toolkit libraries should not have access to 
> >"wayland-randr" at all.
> >It's not something a normal application should use.
> >
> >Again in X things are different because the RandR protocol must exist, but 
> >there is
> >no easy way to make it restricted.
> >
> >> 2) About mode setting requirement:
> >> Most of case, it is for configuration of output as a whole. Generally
> >> it should be in setting panel for screen size, rotation, ...option
> >> setting. The user cases

Re: [PATCH weston-ivi-shell 02/15] ivi application protocol:

[Nobuhiko Tanibata]

2014-03-07 11:37 に Jason Ekstrand さんは書きました:

On Mar 6, 2014 7:08 PM, "Nobuhiko Tanibata"
 wrote:
 >
 > 2014-03-07 00:21 に Jason Ekstrand さんは書きました:
 >
 >> On Mar 6, 2014 3:53 AM, "Nobuhiko Tanibata"
 >>  wrote:
 >> >
 >> > Add interface ivi_application, which creates ivi_surface objects
 >> tied
 >> > to a given wl_surface with a given id. The given id can be used
in
 >> a
 >> > shell to identify which application is assigned to a wl_surface
and
 >> > layout the surface wherever the shell wants. ivi_surface objects
 >> can
 >> > be used to receive status of wl_surface in the scenegraph of the
 >> > compositor.
 >>
 >> In general, I think this looks pretty good. It's nice and simple
and
 >> only adds what's needed for clients. I do have a couple comments
 >> below.
 >> --Jason Ekstrand
 >>
 >>>
 >> > Signed-off-by: Nobuhiko Tanibata
 >> 
 >> > ---
 >> > protocol/ivi-application.xml | 88
 >> 
 >> > 1 file changed, 88 insertions(+)
 >> > create mode 100644 protocol/ivi-application.xml
 >> >
 >> > diff --git a/protocol/ivi-application.xml
 >> b/protocol/ivi-application.xml
 >> > new file mode 100644
 >> > index 000..e58ad26
 >> > --- /dev/null
 >> > +++ b/protocol/ivi-application.xml
 >> > @@ -0,0 +1,88 @@
 >> > +
 >> > +
 >> > +
 >> > + 
 >> > + Copyright (C) 2013 DENSO CORPORATION
 >> > + Copyright (c) 2013 BMW Car IT GmbH
 >> > +
 >> > + Permission is hereby granted, free of charge, to any person
 >> obtaining a copy
 >> > + of this software and associated documentation files (the
 >> "Software"), to deal
 >> > + in the Software without restriction, including without
 >> limitation the rights
 >> > + to use, copy, modify, merge, publish, distribute,
 >> sublicense, and/or sell
 >> > + copies of the Software, and to permit persons to whom the
 >> Software is
 >> > + furnished to do so, subject to the following conditions:
 >> > +
 >> > + The above copyright notice and this permission notice shall
 >> be included in
 >> > + all copies or substantial portions of the Software.
 >> > +
 >> > + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
 >> KIND, EXPRESS OR
 >> > + IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 >> MERCHANTABILITY,
 >> > + FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
 >> EVENT SHALL THE
 >> > + AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
 >> DAMAGES OR OTHER
 >> > + LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
 >> OTHERWISE, ARISING FROM,
 >> > + OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 >> OTHER DEALINGS IN
 >> > + THE SOFTWARE.
 >> > + 
 >> > +
 >> > + 
 >> > + 
 >> > +
 >> > + 
 >> > + 
 >> > + 
 >> > +
 >> > + 
 >> > + 
 >> > + The new visibility state is provided in
 >> argument visibility.
 >> > + If visibility is 0, the surface has become
 >> invisible.
 >> > + If visibility is not 0, the surface has
 >> become visible.
 >> > + 
 >> > + 
 >> > + 
 >> > +
 >> > + 
 >> > +
 >> > + 
 >> > + 
 >> > +
 >> > + 
 >> > + 
 >> > + surface_create will create a new surface
 >> with surface_id in ivi compositor,
 >> > + if it does not yet exists. If the surface
 >> with surface_id already exists in
 >> > + ivi compositor, the application content
 >> provided in argument surface will
 >> > + be used as surface content. If an other
 >> ivi application already registered
 >> > + content for surface with surface_id, an
 >> error event will indicate the problem.
 >> > + 
 >> > + 
 >> > + > interface="wl_surface"/>
 >> > + > interface="ivi_surface"/>
 >> > + 
 >> > +
 >> > + 
 >> > + 
 >> > + These error codes define all possible
 >> error codes returned by ivi compositor
 >> > + on server-side errors.
 >> > + 
 >> > + > summary="unknown error encountered"/>
 >>
 >> What kinds of things do you use "unknown error" for? I'm not sure
 >> how that's useful to the client.
 >>
 >
 > Hi Jason,
 >
 > Thank you for reviewing.
 >
 > I see. From this review point, it shall not return no useful value
to the client.
 > I break down more here.
 > - id in use: specified ID for ivi_surface is already used by itself
or other client.
 > - resource in use: specified ID of wl_surface is already tie to
another ID of ivi_surface.
 > - invalid resource: specified ID of wl_surface is not valid in
server.
 >
 > I think these three is sufficient for client.
 >
 >
 >>> + >
 >> summary="resource is in use and can not be shared"/>
 >>
 >> What kind of resource does this refer to? It looks like you use it
 >> if someone tries to call surface_create twice on the same surface,
but
 >> you don't specify.
 >>
 >>> + 
 >>
 >> > +
 >> > + 
 >> > + 
 >> > + The ivi compositor encountered error while
 >> processing a request by this
 >> > + application. The error is defined by
 >> argument error_code and optional
 >> > + error_text.
 >> > + If the application requires to associate
 >> this error event to a request,
 >> > + it can
 >> > + 1. send request
 >> > + 2. force display roundtrip
 >> > + 3. check, if error event was
 >