Re: [Weston] More discussion about weston output relative motion algorithm

[Pekka Paalanen]

On Wed, 16 Apr 2014 04:21:46 +
Wang, Quanxian quanxian.w...@intel.com wrote:

 Clear some definition for easy understanding.
 Supposed B is beside A. B maybe leftof, rightof, above, or below A.
 If leftof,  output(B) is the horizontal parent of A.
 If above, output(B) is the vertical parent of A.
 If rightof, output(B) is the horizontal child of A.
 If below, output(B) is the vertical child of A.
 
 With definition, you will be easy to set up a binary tree. But you
 may think some node may have two parent. The answer is no, you can
 have a try to move and will find it is right. Just let you know my
 mistakes I ever made. When you move output to be leftof or above of
 another, the output will take the place of another instead of really
 above or left of the position of another. :) After that, you will be
 know why one node has  one parent at most.
 
 Of course, the original layout will be one horizontal line for
 extended mode.
 
 If clone mode is supported, that is fine. Keep clone link for that in
 output structure. The algorithm will be updated with minimal. But it
 will be easy and based on clone mode design.

Hi,

I have nothing against an algorithm for placing outputs in Weston, and
it would fit Weston core. I think we would like to support all kinds of
layouts based on weston.ini alone, even without any dynamic
configuration like your proposed protocol extension.

However, from your algorithm description, I am not sure how it'll work
for hotplug or hot-unplug.

Let's imagine a physical setting of four monitors, arranged like this:

┌───┬───┐
│ A │ B │
├───┼───┤
│ C │ D │
└───┴───┘

That is a 2x2 grid.

There are two ways to represent this in your tree structure, I believe:

A.hlink - B
A.vlink - C
C.hlink - D

or

A.hlink - B
A.vlink - C
B.vlink - D

What happens, if C is not present originally and gets hotplugged?
What happens, if C gets hot-unplugged? And then plugged back?
What happens, if a user adds a new output and defines it to be left-of
C? Will C end up below B or will it stay below A?
What if A is wider than C; will there be a gap between C and D?

Is there a behavioral difference between the two tree structures?

Can you realize the following arrangement?
┌───┬───┐
│ A │ B │
┌───┼───┼───┤
│ E │ C │ D │
└───┴───┴───┘


Then an even better question is, what would the user expect?
Which outputs should move, and which should stay in place with respect
to the desktop coordinate system (global coordinates)?

I don't have the correct answers here. I only agree that it would be
nice if Weston supported more than just a horizontal line of monitors.
Personally I have a vertical line setup.

I don't even think the problem is well-defined.

Maybe we need completely different algorithms for vertical/horizontal
line vs. a grid pattern?

In the end, the algorithm will only compute positions for each output
in the global coordinate system. Quite likely no algorithm will be able
to realize all possible arrangements and alignments (for differing
output sizes) without becoming practically unusable, so we would still
need the option of just defining the output position as coordinates in
the global space.


Thanks,
pq


 Thanks
 
 Regards
 
 Quanxian Wang
 
 
 From: Wang, Quanxian
 Sent: Wednesday, April 16, 2014 11:26 AM
 To: wayland-devel@lists.freedesktop.org
 Cc: Wang, Quanxian; Pekka Paalanen (ppaala...@gmail.com); Jason
 Ekstrand (ja...@jlekstrand.net); Bryce W. Harrington
 (b.harring...@samsung.com); Fu, Michael; Hardening
 (rdp.eff...@gmail.com); Kang, Jeong Seok Subject: [Weston] More
 discussion about weston output relative motion algorithm
 
 Hi, All
 
 Relative motion of output is needed in Weston compositor or others.
 For example, plugin a monitor, you want move it above or leftof or
 rightof or below others.
 
 More details about this motion algorithm will be shown in the email.
 Before that, I mention one point, I don't refer any code from others
 including xserver. My idea is based on the current Weston compositor
 design and statistics. It is original for Weston compositor. At the
 same time, when I implemented it, I try to make parameters to be
 general. If possible, make it common instead of only in randr
 protocol.
 
 Weston movement algorithm
 
 If only support one line layout. For example, all vertical or all
 horizontal, it is very easy to implement. But if we want support both
 at the same time, it will be more complex instead of 1+1=2. Currently
 in Weston compositor, only horizontal is supported. Compositor uses
 output_list to make it happen.
 
 Here are the summary of motion properties.
 
 
 1)  It is similar with binary tree.  Here are some related
 features.  Every node is one output.
 
 a.   Every node have one parent at most, also the parent maybe
 from vertical, maybe from horizontal(it is different with binary
 tree). But never has two parents. I will not explain why, you can use
 4 outputs to do more movement, and you can find this.
 
 b.  Every node 

Re: Thoughts on getting surfaces to appear on the right output

[Pekka Paalanen]

On Fri, 02 May 2014 19:22:39 +0100
Neil Roberts n...@linux.intel.com wrote:

 Hi,
 
 Currently Weston has a problem that it always puts new surfaces on the
 same output as the one the first pointer is in. I guess the idea is
 that most of the time surfaces are created as a result of mouse
 events and there is usually only one pointer so it works most of the
 time. However of course this doesn't work if a surface is created by
 a touch event, a keyboard event or an event from a second pointer.
 The problem is mentioned in the following bug report:
 
 https://bugs.freedesktop.org/show_bug.cgi?id=73715
 
 I guess ideally you want the client to explicitly say what output new
 surfaces should appear on because only the client knows which input
 event caused the new surface to be created. We already have
 xdg_shell.set_output which the client could use for this purpose. It
 doesn't look like Weston takes that chosen output into account if the
 surface is not fullscreen or maximised, but perhaps we could change it
 so that it does?
 
 This isn't a complete solution however because when the client first
 connects it doesn't know what event caused its process to be executed
 so it doesn't know which output to put itself on. This is the case
 when panel buttons are used to launch an application from
 desktop-shell. I was thinking that maybe we need a request that
 desktop-shell can make to specify a default output for new surfaces
 from the clients that it launches. To do this I was thinking that
 maybe desktop-shell could make a connection to the compositor on
 behalf of the client, call a request to set the default output and
 then pass the socket down to client using the existing WAYLAND_SOCKET
 mechanism.
 
 That would be an unusual use of WAYLAND_SOCKET because in the other
 cases the socket that is passed down is created with socketpair and is
 not first used for any communication. This would have the effect that
 wl_display_connect_to_fd is called twice on a connected socket.
 However, it doesn't look like any data is sent or any negotiation is
 done when that is called so it might not be a problem.
 
 Doing requests on the connection before passing it down might cause
 the resource ID numbers to get out of sync. However I was thinking
 that if the parent process is careful to destroy any resources that
 it creates before forking the child and if the Wayland protocol
 aggressively reuses IDs then it might reset back to zero anyway and
 it would just work.
 
 I was going to experiment with adding this request as a
 Weston-specific extension unless someone points out why it won't
 work. However, I think this probably shouldn't be Weston-specific
 because normal clients may also want to launch child clients in
 response to an input event and they too will want to do something
 similar.

Hi,

I think creating the socket pair in the client that launches another
client and passes it on in WAYLAND_SOCKET could be the key here. This
is the lowest-level standard mechanism, as it is implemented in
libwayland-client.

However, I don't agree with using the new connection to pre-set the
stage as you imagined. Doing stuff on a connection and then pretending
it is a fresh connection for the new client is tedious like you said.

Instead, we could have an app launcher protocol extension. The
lancher client, e.g. weston-desktop-shell with the panel buttons,
creates a socket pair, and passes the server end to the compositor by
using this new protocol. But it does not have to stop there. The
protocol could also allow things like setting the default output,
designating how the new app will be launched, which wl_seat did it,
etc. Anything the compositor might see as useful. Also, on which
workspace the new app should appear by default.

This app launcher extension could be a public interface. After all,
clients will be able to connect to the socket file, too, so no need to
restrict this I guess. As a side-effect, it would also allow launching
a client as a different user by using a suitable launcher tool.

If the client using the app launcher extension is already privileged,
there might be a mechanism to pass the authorization on to the new
client. (Jumping to another topic here. :-)

The hard part will be designing the app launcher extension. If it is
a public, generic extension to be in the core, it cannot reference
xdg_shell or desktop concepts. What things should it have?

 This approach wouldn't help for something like launching clients from
 a terminal window because obviously bash isn't going to do this trick
 before forking. As a fallback perhaps the positioning mechanism should
 be that the surface will appear on the last output that received *any*
 input event instead of where one of the pointers is. It's probably
 relatively safe to assume that a new surface is related to last input
 event.

Right.

Though another option comes to mind, but I'm not sure how good it is.

The terminal could ask the compositor to create a 

RE: [Weston] More discussion about weston output relative motion algorithm

[Wang, Quanxian]

 -Original Message-
 From: Pekka Paalanen [mailto:ppaala...@gmail.com]
 Sent: Tuesday, May 6, 2014 2:36 PM
 To: Wang, Quanxian
 Cc: wayland-devel@lists.freedesktop.org; Jason Ekstrand
 (ja...@jlekstrand.net); Bryce W. Harrington (b.harring...@samsung.com);
 Fu, Michael; Hardening (rdp.eff...@gmail.com); Kang, Jeong Seok
 Subject: Re: [Weston] More discussion about weston output relative motion
 algorithm
 
 On Wed, 16 Apr 2014 04:21:46 +
 Wang, Quanxian quanxian.w...@intel.com wrote:
 
  Clear some definition for easy understanding.
  Supposed B is beside A. B maybe leftof, rightof, above, or below A.
  If leftof,  output(B) is the horizontal parent of A.
  If above, output(B) is the vertical parent of A.
  If rightof, output(B) is the horizontal child of A.
  If below, output(B) is the vertical child of A.
 
  With definition, you will be easy to set up a binary tree. But you may
  think some node may have two parent. The answer is no, you can have a
  try to move and will find it is right. Just let you know my mistakes I
  ever made. When you move output to be leftof or above of another, the
  output will take the place of another instead of really above or left
  of the position of another. :) After that, you will be know why one
  node has  one parent at most.
 
  Of course, the original layout will be one horizontal line for
  extended mode.
 
  If clone mode is supported, that is fine. Keep clone link for that in
  output structure. The algorithm will be updated with minimal. But it
  will be easy and based on clone mode design.
 
 Hi,
 
 I have nothing against an algorithm for placing outputs in Weston, and it
 would fit Weston core. I think we would like to support all kinds of layouts
 based on weston.ini alone, even without any dynamic configuration like your
 proposed protocol extension.
 
 However, from your algorithm description, I am not sure how it'll work for
 hotplug or hot-unplug.
[Wang, Quanxian] The algorithm will process all dynamic layout change. If you 
hotplug, just add one output into the tree, just call enable_node(A), supposed 
you hot-plug A. The initial design is inserted it into tail of master's hlink. 
(master is at (0,0)). 
When you hot-unplug, that means you delete this output from the tree. Following 
the algorithm, just call delete_node(A), supposed you hot-unplug A. the detail 
algorithm, you can refer to the disable_node algorithm in V4.  The order to 
take its place is clone link, horizontal link and vertical link. (If no clink, 
then hlink, still no, vlink)
In file module/wrandr/randr_layout_algorithm.h
115  * Disable Node Rules:
116  * 1) The node is deleted and the place is replaced by others.
117  * 2) The order to take the place of parent:
118  *clink, hlink and then vlink.
119  * Others are the same as clean_node.
 
 Let's imagine a physical setting of four monitors, arranged like this:
 
 ┌───┬───┐
 │ A │ B │
 ├───┼───┤
 │ C │ D │
 └───┴───┘
 
 That is a 2x2 grid.
 
 There are two ways to represent this in your tree structure, I believe:
 
 A.hlink - B
 A.vlink - C
 C.hlink - D
 
 or
 
 A.hlink - B
 A.vlink - C
 B.vlink - D
 
[Wang, Quanxian] Firstly, you imagine the grid. But from the very beginning,  C 
is not present. You can do like this.
a) Initial status
 ┌───┬───┐
 │ A │ B │
 ├───┼───┤
 │ │ D │
 └───┴───┘
 b) hot-plugged C and move C below of A
 ┌───┬───┐
 │ A │ B │
 ├───┼───┤
 │ C  │ D │
 └───┴───┘
Remember, since D is below of B, there will not any relation between C and D. 
Otherwise D will have two parents (horizontal C and vertical B).

 What happens, if C is not present originally and gets hotplugged?
[Wang, Quanxian] 
Original status: C is not present
 ┌───┬───┐
 │ A │ B │
 ├───┼───┤
 │ │ D │
 └───┴───┘
 A.hlink - B
 B.vlink - D

C is hot-plugged, it will go to tail of Master(A)'s hlink.
┌───┬───┐
 │ A │ B │C |
 ├───┼───┤
 │   │ D │
 └───┴───┘
A.hlink - B
B.hlink - C
B.vlink - D
 What happens, if C gets hot-unplugged? And then plugged back?
[Wang, Quanxian] 
C is hot-unplugged based on previous. In previous status, C has no any child 
link (clink, hlink, vlink)
┌───┬───┐
 │ A │ B │|
 ├───┼───┤
 │   │ D │
 └───┴───┘
C is hot-plugged, it will be as before.
┌───┬───┐
 │ A │ B │C |
 ├───┼───┤
 │   │ D │
 └───┴───┘
 What happens, if a user adds a new output and defines it to be left-of C? Will
 C end up below B or will it stay below A?
[Wang, Quanxian] 
If a new output called E is added and define it as left-of C. It will do two 
actions. One is add, another is move.
Adding:
┌───┬───┐
 │ A │ B │C | E
 ├───┼───┤
 │   │ D │
 └───┴───┘
Move: move E left of C (it will have the actions: remove E, and then E replace 
C'place, C is moving to right of E)
 ┌───┬───┐
 │ A │ B │E  | C
 ├───┼───┤
 │   │ D │
 └───┴───┘
 What if A is wider than C; will there be a gap between C and D?
[Wang, Quanxian] 
You imagine
 ┌───┬───┐
 │ A │ B   |
 ├───┼───┤
 │ C  │ D │
 └───┴───┘

A's hlink == B
A's vlink = C
B's vlink = D

It is 

[PATCH weston 3/4] data-device: fix crash on systems with no pointer device

[Stanislav Vorobiov]

---
 src/data-device.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/data-device.c b/src/data-device.c
index 6a81bc8..a80f271 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -650,11 +650,13 @@ data_device_start_drag(struct wl_client *client, struct 
wl_resource *resource,
struct weston_surface *icon = NULL;
int32_t ret = 0;
 
-   if ((seat-pointer-button_count == 0 ||
+   if ((!seat-pointer ||
+   seat-pointer-button_count == 0 ||
seat-pointer-grab_serial != serial ||
!seat-pointer-focus ||
seat-pointer-focus-surface != 
wl_resource_get_user_data(origin_resource)) 
-   (seat-touch-grab_serial != serial ||
+   (!seat-touch ||
+   seat-touch-grab_serial != serial ||
!seat-touch-focus ||
seat-touch-focus-surface != 
wl_resource_get_user_data(origin_resource)))
return;
@@ -672,14 +674,16 @@ data_device_start_drag(struct wl_client *client, struct 
wl_resource *resource,
return;
}
 
-   if (seat-pointer-button_count == 1 
+   if (seat-pointer 
+   seat-pointer-button_count == 1 
seat-pointer-grab_serial == serial 
seat-pointer-focus 
seat-pointer-focus-surface == 
wl_resource_get_user_data(origin_resource))
ret = weston_pointer_start_drag(seat-pointer, source, icon, 
client);
-   else if (seat-touch-grab_serial != serial ||
-   seat-touch-focus ||
-   seat-touch-focus-surface != 
wl_resource_get_user_data(origin_resource))
+   else if (seat-touch 
+   (seat-touch-grab_serial != serial ||
+   seat-touch-focus ||
+   seat-touch-focus-surface != 
wl_resource_get_user_data(origin_resource)))
ret = weston_touch_start_drag(seat-touch, source, icon, 
client);
 
if (ret  0)
-- 
1.7.9.5

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

[PATCH weston 0/4] improving support for systems without a pointer device

[Stanislav Vorobiov]

I've grouped these patches:

http://lists.freedesktop.org/archives/wayland-devel/2014-May/014576.html
http://lists.freedesktop.org/archives/wayland-devel/2014-May/014580.html

into a patchset, I've also added 2 more: one that fixes dnd crash and
one that adds touchscreen support to exposay

Stanislav Vorobiov (4):
  shell: support window resizing using touchscreen
  shell: support zooming without a pointer device
  data-device: fix crash on systems with no pointer device
  exposay: support systems without a pointer device

 clients/window.c|5 +-
 desktop-shell/exposay.c |   95 +++--
 desktop-shell/shell.c   |  175 ---
 desktop-shell/shell.h   |1 +
 shared/cairo-util.h |2 +-
 shared/frame.c  |   20 +++---
 src/compositor.h|1 +
 src/data-device.c   |   16 +++--
 src/input.c |3 +
 src/zoom.c  |   40 ---
 10 files changed, 315 insertions(+), 43 deletions(-)

-- 
1.7.9.5

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

[PATCH weston 1/4] shell: support window resizing using touchscreen

[Stanislav Vorobiov]

if the system doesn't have a pointer device
common_surface_resize will crash on
accessing seat-pointer-button_count. if the system
does have a pointer device, but attempts to resize
a window using touchscreen - nothing happens. here
we implement separate window resizing path for
seat-touch as it is done in common_surface_move
---
 clients/window.c  |5 +-
 desktop-shell/shell.c |  153 ++---
 shared/cairo-util.h   |2 +-
 shared/frame.c|   20 ---
 4 files changed, 159 insertions(+), 21 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index f12ce39..be2c0e0 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2409,9 +2409,10 @@ frame_touch_down_handler(struct widget *widget, struct 
input *input,
 float x, float y, void *data)
 {
struct window_frame *frame = data;
+   enum theme_location location;
 
-   frame_touch_down(frame-frame, input, id, x, y);
-   frame_handle_status(frame, input, time, THEME_LOCATION_CLIENT_AREA);
+   location = frame_touch_down(frame-frame, input, id, x, y);
+   frame_handle_status(frame, input, time, location);
 }
 
 static void
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index a631c62..2aab283 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -395,6 +395,7 @@ shell_touch_grab_end(struct shell_touch_grab *grab)
if (grab-shsurf) {
wl_list_remove(grab-shsurf_destroy_listener.link);
grab-shsurf-grabbed = 0;
+   grab-shsurf-resize_edges = 0;
}
 
weston_touch_end_grab(grab-touch);
@@ -1615,6 +1616,14 @@ struct weston_resize_grab {
int32_t width, height;
 };
 
+struct weston_touch_resize_grab {
+   struct shell_touch_grab base;
+   int active;
+   uint32_t edges;
+   int32_t width, height;
+   wl_fixed_t dx, dy;
+};
+
 static void
 resize_grab_motion(struct weston_pointer_grab *grab, uint32_t time,
   wl_fixed_t x, wl_fixed_t y)
@@ -1702,6 +1711,83 @@ static const struct weston_pointer_grab_interface 
resize_grab_interface = {
resize_grab_cancel,
 };
 
+static void
+touch_resize_grab_down(struct weston_touch_grab *grab, uint32_t time,
+int touch_id, wl_fixed_t sx, wl_fixed_t sy)
+{
+}
+
+static void
+touch_resize_grab_up(struct weston_touch_grab *grab, uint32_t time, int 
touch_id)
+{
+   struct weston_touch_resize_grab *resize =
+   (struct weston_touch_resize_grab *) container_of(
+   grab, struct shell_touch_grab, grab);
+
+   if (touch_id == 0)
+   resize-active = 0;
+
+   if (grab-touch-num_tp == 0) {
+   shell_touch_grab_end(resize-base);
+   free(resize);
+   }
+}
+
+static void
+touch_resize_grab_motion(struct weston_touch_grab *grab, uint32_t time,
+  int touch_id, wl_fixed_t sx, wl_fixed_t sy)
+{
+   struct weston_touch_resize_grab *resize = (struct 
weston_touch_resize_grab *) grab;
+   struct weston_touch *touch = grab-touch;
+   struct shell_surface *shsurf = resize-base.shsurf;
+   int32_t width, height;
+   wl_fixed_t from_x, from_y;
+   wl_fixed_t to_x, to_y;
+
+   if (!shsurf || !resize-active)
+   return;
+
+   weston_view_from_global_fixed(shsurf-view,
+ resize-dx, resize-dy,
+ from_x, from_y);
+   weston_view_from_global_fixed(shsurf-view,
+ touch-grab_x, touch-grab_y, to_x, 
to_y);
+
+   width = resize-width;
+   if (resize-edges  WL_SHELL_SURFACE_RESIZE_LEFT) {
+   width += wl_fixed_to_int(from_x - to_x);
+   } else if (resize-edges  WL_SHELL_SURFACE_RESIZE_RIGHT) {
+   width += wl_fixed_to_int(to_x - from_x);
+   }
+
+   height = resize-height;
+   if (resize-edges  WL_SHELL_SURFACE_RESIZE_TOP) {
+   height += wl_fixed_to_int(from_y - to_y);
+   } else if (resize-edges  WL_SHELL_SURFACE_RESIZE_BOTTOM) {
+   height += wl_fixed_to_int(to_y - from_y);
+   }
+
+   shsurf-client-send_configure(shsurf-surface, width, height);
+}
+
+static void
+touch_resize_grab_cancel(struct weston_touch_grab *grab)
+{
+   struct weston_touch_resize_grab *resize =
+   (struct weston_touch_resize_grab *) container_of(
+   grab, struct shell_touch_grab, grab);
+
+   shell_touch_grab_end(resize-base);
+   free(resize);
+}
+
+static const struct weston_touch_grab_interface touch_resize_grab_interface = {
+   touch_resize_grab_down,
+   touch_resize_grab_up,
+   touch_resize_grab_motion,
+   touch_resize_grab_cancel,
+};
+
 /*
  * Returns the bounding box of a surface and all its sub-surfaces,
  * in the surface coordinates system. */
@@ -1766,6 +1852,37 @@ surface_resize(struct shell_surface 

[PATCH weston 2/4] shell: support zooming without a pointer device

[Stanislav Vorobiov]

if the system doesn't have a pointer device
do_zoom will crash on accessing seat-pointer-x.
here we implement zoom support on systems with
a touchscreen, touchscreen's last touch point is
simply used instead of pointer's current position
---
 desktop-shell/shell.c |   22 --
 src/compositor.h  |1 +
 src/input.c   |3 +++
 src/zoom.c|   40 
 4 files changed, 56 insertions(+), 10 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 2aab283..c7760f7 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1375,6 +1375,7 @@ static void
 touch_move_grab_down(struct weston_touch_grab *grab, uint32_t time,
 int touch_id, wl_fixed_t sx, wl_fixed_t sy)
 {
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
 }
 
 static void
@@ -1403,6 +1404,8 @@ touch_move_grab_motion(struct weston_touch_grab *grab, 
uint32_t time,
int dx = wl_fixed_to_int(grab-touch-grab_x + move-dx);
int dy = wl_fixed_to_int(grab-touch-grab_y + move-dy);
 
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
+
if (!shsurf || !move-active)
return;
 
@@ -1715,6 +1718,7 @@ static void
 touch_resize_grab_down(struct weston_touch_grab *grab, uint32_t time,
 int touch_id, wl_fixed_t sx, wl_fixed_t sy)
 {
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
 }
 
 static void
@@ -1744,6 +1748,8 @@ touch_resize_grab_motion(struct weston_touch_grab *grab, 
uint32_t time,
wl_fixed_t from_x, from_y;
wl_fixed_t to_x, to_y;
 
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
+
if (!shsurf || !resize-active)
return;
 
@@ -4376,11 +4382,23 @@ do_zoom(struct weston_seat *seat, uint32_t time, 
uint32_t key, uint32_t axis,
struct weston_compositor *compositor = ws-compositor;
struct weston_output *output;
float increment;
+   double x, y;
+
+   if (seat-pointer) {
+   x = wl_fixed_to_double(seat-pointer-x);
+   y = wl_fixed_to_double(seat-pointer-y);
+   } else if (seat-touch) {
+   x = wl_fixed_to_double(seat-touch-grab_x);
+   y = wl_fixed_to_double(seat-touch-grab_y);
+   } else {
+   x = wl_fixed_to_double(0);
+   y = wl_fixed_to_double(0);
+   }
 
wl_list_for_each(output, compositor-output_list, link) {
if (pixman_region32_contains_point(output-region,
-  
wl_fixed_to_double(seat-pointer-x),
-  
wl_fixed_to_double(seat-pointer-y),
+  x,
+  y,
   NULL)) {
if (key == KEY_PAGEUP)
increment = output-zoom.increment;
diff --git a/src/compositor.h b/src/compositor.h
index 057f8be..f2f1bf4 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -347,6 +347,7 @@ struct weston_touch {
struct wl_listener focus_resource_listener;
uint32_t focus_serial;
struct wl_signal focus_signal;
+   struct wl_signal motion_signal;
 
uint32_t num_tp;
 
diff --git a/src/input.c b/src/input.c
index 2c799f4..616b6e6 100644
--- a/src/input.c
+++ b/src/input.c
@@ -278,6 +278,8 @@ default_grab_touch_motion(struct weston_touch_grab *grab, 
uint32_t time,
struct wl_resource *resource;
struct wl_list *resource_list;
 
+   wl_signal_emit(touch-motion_signal, touch);
+
resource_list = touch-focus_resource_list;
 
wl_resource_for_each(resource, resource_list) {
@@ -583,6 +585,7 @@ weston_touch_create(void)
touch-default_grab.touch = touch;
touch-grab = touch-default_grab;
wl_signal_init(touch-focus_signal);
+   wl_signal_init(touch-motion_signal);
 
return touch;
 }
diff --git a/src/zoom.c b/src/zoom.c
index 622c0d7..8c8b18a 100644
--- a/src/zoom.c
+++ b/src/zoom.c
@@ -86,8 +86,16 @@ weston_zoom_frame_xy(struct weston_animation *animation,
 
if (weston_spring_done(output-zoom.spring_xy)) {
output-zoom.spring_xy.current = output-zoom.spring_xy.target;
-   output-zoom.current.x = seat-pointer-x;
-   output-zoom.current.y = seat-pointer-y;
+   if (seat-pointer) {
+   output-zoom.current.x = seat-pointer-x;
+   output-zoom.current.y = seat-pointer-y;
+   } else if (seat-touch) {
+   output-zoom.current.x = seat-touch-grab_x;
+   output-zoom.current.y = seat-touch-grab_y;
+   } else {
+   output-zoom.current.x = 0;
+   output-zoom.current.y = 0;
+   }

[PATCH weston 4/4] exposay: support systems without a pointer device

[Stanislav Vorobiov]

if the system doesn't have a pointer device
exposay_transition_active will crash
in weston_pointer_start_grab(seat-pointer, ...).
here we fix that and also implement exposay support
on systems with a touchscreen
---
 desktop-shell/exposay.c |   95 ---
 desktop-shell/shell.h   |1 +
 2 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index 1d8b40e..91932ce 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -391,6 +391,77 @@ static const struct weston_pointer_grab_interface 
exposay_ptr_grab = {
exposay_pointer_grab_cancel,
 };
 
+static void
+exposay_touch_down(struct weston_touch_grab *grab, uint32_t time,
+  int touch_id, wl_fixed_t sx, wl_fixed_t sy)
+{
+   struct desktop_shell *shell =
+   container_of(grab, struct desktop_shell, exposay.grab_touch);
+
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
+
+   exposay_pick(shell,
+wl_fixed_to_int(grab-touch-grab_x),
+wl_fixed_to_int(grab-touch-grab_y));
+
+   /* Store the surface we clicked on, and don't do anything if we end up
+* releasing on a different surface. */
+   if (grab-touch-num_tp == 1) {
+   shell-exposay.clicked = shell-exposay.focus_current;
+   }
+}
+
+static void
+exposay_touch_up(struct weston_touch_grab *grab, uint32_t time, int touch_id)
+{
+   struct desktop_shell *shell =
+   container_of(grab, struct desktop_shell, exposay.grab_touch);
+   struct weston_seat *seat = grab-touch-seat;
+
+   if (grab-touch-num_tp == 0) {
+   if (shell-exposay.focus_current == shell-exposay.clicked)
+   exposay_set_state(shell, EXPOSAY_TARGET_SWITCH, seat);
+   else
+   shell-exposay.clicked = NULL;
+   }
+}
+
+static void
+exposay_touch_motion(struct weston_touch_grab *grab, uint32_t time,
+  int touch_id, wl_fixed_t sx, wl_fixed_t sy)
+{
+   struct desktop_shell *shell =
+   container_of(grab, struct desktop_shell, exposay.grab_touch);
+
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
+
+   exposay_pick(shell,
+wl_fixed_to_int(grab-touch-grab_x),
+wl_fixed_to_int(grab-touch-grab_y));
+}
+
+static void
+exposay_touch_frame(struct weston_touch_grab *grab)
+{
+}
+
+static void
+exposay_touch_grab_cancel(struct weston_touch_grab *grab)
+{
+   struct desktop_shell *shell =
+   container_of(grab, struct desktop_shell, exposay.grab_touch);
+
+   exposay_set_state(shell, EXPOSAY_TARGET_CANCEL, shell-exposay.seat);
+}
+
+static const struct weston_touch_grab_interface exposay_touch_grab = {
+   exposay_touch_down,
+   exposay_touch_up,
+   exposay_touch_motion,
+   exposay_touch_frame,
+   exposay_touch_grab_cancel,
+};
+
 static int
 exposay_maybe_move(struct desktop_shell *shell, int row, int column)
 {
@@ -517,7 +588,10 @@ exposay_set_inactive(struct desktop_shell *shell)
struct weston_seat *seat = shell-exposay.seat;
 
weston_keyboard_end_grab(seat-keyboard);
-   weston_pointer_end_grab(seat-pointer);
+   if (seat-pointer)
+   weston_pointer_end_grab(seat-pointer);
+   if (seat-touch)
+   weston_touch_end_grab(seat-touch);
if (seat-keyboard-input_method_resource)
seat-keyboard-grab = seat-keyboard-input_method_grab;
 
@@ -567,11 +641,20 @@ exposay_transition_active(struct desktop_shell *shell)
   shell-exposay.grab_kbd);
weston_keyboard_set_focus(seat-keyboard, NULL);
 
-   shell-exposay.grab_ptr.interface = exposay_ptr_grab;
-   weston_pointer_start_grab(seat-pointer,
- shell-exposay.grab_ptr);
-   weston_pointer_set_focus(seat-pointer, NULL,
-seat-pointer-x, seat-pointer-y);
+   if (seat-pointer) {
+   shell-exposay.grab_ptr.interface = exposay_ptr_grab;
+   weston_pointer_start_grab(seat-pointer,
+ shell-exposay.grab_ptr);
+   weston_pointer_set_focus(seat-pointer, NULL,
+seat-pointer-x, seat-pointer-y);
+   }
+
+   if (seat-touch) {
+   shell-exposay.grab_touch.interface = exposay_touch_grab;
+   weston_touch_start_grab(seat-touch,
+   shell-exposay.grab_touch);
+   weston_touch_set_focus(seat, NULL);
+   }
 
wl_list_for_each(shell_output, shell-output_list, link) {
enum exposay_layout_state state;
diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
index 6e63785..ba7951a 100644
--- a/desktop-shell/shell.h
+++ b/desktop-shell/shell.h
@@ -74,6 +74,7 @@ struct 

[PATCH] wcap: Check for mmap and malloc return value in wcap decode module

[vivek]

Checking for return value in main.c for wcap_decoder_create function
and mmap, malloc return value in wcap_decoder_create function to avoid
crashes

Signed-off-by: vivek vivek.el...@samsung.com
---
 wcap/main.c|4 
 wcap/wcap-decode.c |9 +
 2 files changed, 13 insertions(+)

diff --git a/wcap/main.c b/wcap/main.c
index 29bb9c3..16d37f0 100644
--- a/wcap/main.c
+++ b/wcap/main.c
@@ -251,6 +251,10 @@ int main(int argc, char *argv[])
}
 
decoder = wcap_decoder_create(argv[1]);
+   if (decoder == NULL) {
+   fprintf(stderr, Creating wcap decoder failed\n);
+   exit(EXIT_FAILURE);
+   }
 
if (yuv4mpeg2  isatty(1)) {
fprintf(stderr, Not dumping yuv4mpeg2 data to terminal.  Pipe 
output to a file or a process.\n);
diff --git a/wcap/wcap-decode.c b/wcap/wcap-decode.c
index 87d9337..76ecc2f 100644
--- a/wcap/wcap-decode.c
+++ b/wcap/wcap-decode.c
@@ -126,6 +126,11 @@ wcap_decoder_create(const char *filename)
decoder-size = buf.st_size;
decoder-map = mmap(NULL, decoder-size,
PROT_READ, MAP_PRIVATE, decoder-fd, 0);
+   if (decoder-map == MAP_FAILED) {
+   fprintf(stderr, mmap failed\n);
+   free(decoder);
+   return NULL;
+   }

header = decoder-map;
decoder-format = header-format;
@@ -137,6 +142,10 @@ wcap_decoder_create(const char *filename)
 
frame_size = header-width * header-height * 4;
decoder-frame = malloc(frame_size);
+   if (decoder-frame == NULL) {
+   free(decoder);
+   return NULL;
+   }
memset(decoder-frame, 0, frame_size);
 
return decoder;
-- 
1.7.9.5

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

[PATCH] doc: Added API documentation for wl_display_create function.

[Srivardhan Hebbar]

Signed-off-by: Srivardhan Hebbar sri.heb...@samsung.com
---
 src/wayland-server.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index f2b1b42..7b32848 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -788,6 +788,15 @@ bind_display(struct wl_client *client,
   destroy_client_display_resource);
 }
 
+/** Create Wayland display object.
+ *
+ * \param None
+ * \return The Wayland display object. Null if failed to create
+ *
+ * This creates the wl_display object for the client.
+ *
+ * \memberof wl_display
+ */
 WL_EXPORT struct wl_display *
 wl_display_create(void)
 {
-- 
1.7.9.5

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

RE: New to Wayland, Need suggestion on a starting point

[Srivardhan]

 -Original Message-
 From: wayland-devel [mailto:wayland-devel-
 boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen
 Sent: Monday, May 05, 2014 5:36 PM
 To: Srivardhan
 Cc: 'Jason Ekstrand'; wayland-devel@lists.freedesktop.org
 Subject: Re: New to Wayland, Need suggestion on a starting point
 
 On Mon, 05 May 2014 13:53:05 +0530
 Srivardhan sri.heb...@samsung.com wrote:
 
  The Wayland protocol dumper is interesting. Pardon me if am asking
  stupid questions. I was wondering how I could implement it. I compiled
  Weston on my Ubuntu 21.04 and executed it. Below are my understanding,
  correct me if am wrong.
 
 
 
  1.   Weston uses the functions in the libwayland-server and
  libwayland-client and creates a compositor and client.
 
  2.   All the Wayland library functions which are used to create
  compositor is in src/wayland-server.c and all the Wayland library
  functions which are used to create client is in src/wayland-client.c
 
  3.   In both wayland-server.c and wayland-client.c
  wl_clorsure_print() is used to print logs to stderr. The functions
  call wl_closure_print to print logs and then call socket functions to
  send the message.
 
 
 
  By this understanding, what I was thinking was, in the
  src/connection.c, if we create a debug socket and then write the
  messages to it too. The wayland-trace program can listen to that
  socket and then print the logs. What do you think?
 
 Hi,
 
 I guess that might work, but it also seems a bit messy to manage, and it
does
 not separate the clients much when the server is sending. You would have
to
 create a server dump socket for each client. Then have a way to find the
right
 sockets and connect to them. Enforcing security there would be a big
issue.
 
 At starting time, there would be a race between your dumper app
 connecting to the dump sockets, and the client starting to use the
protocol.
 You might miss the first messages, which would then mean you cannot
 interpret the rest of the stream either. Though I guess that could be
worked
 around by making the client wait for a connection in the dump socket.
 
 My idea is to not use libwayland at all. Instead, you would duplicate all
the
 needed parts in a stand-alone program. The starting point would be to
relay
 Wayland messages in both directions without parsing them at all beyond the
 message size field. You just need to make sure to handle file descriptors,
 otherwise it would be just a byte for byte copy.
 
 Once that works, you can already dump the header of each message,
 allowing the tool to dump at least something on unknown protocol
 extensions. The next step would be to read in the protocol XML files so
that
 you can actually parse and print the messages. You start with wl_display
as
 that is needed to maintain object references, and then do the rest of the
 core protocol. Once you handle the core protocol, you also handle all
 extensions that can ever be, as long as you have their XML description.
 
 You could use a custom generator to convert the XML into C data
structures,
 but I would prefer if the tool read in the XML files directly. That way
the built
 tool is not dependent on any particular protocol version it was built with
but
 you can use it on everything.
 This would be very useful when developing protocols as one would not need
 to recompile the dumping tool all the time. The XML files are installed by
 each project maintaining them (or should be), so they would be always
 available in distribution -devel packages I assume.
 
 That would make the dumping tool an independent project. In the future, it
 could then be a basis for more sophisticated tools, like an object state
 recorder/viewer and graphical visualization, or maybe co-operate with
 existing protocol visualization tools.
 
 This project would introduce you to Wayland starting from the lowest level
of
 the protocol. If you wish to learn how Wayland works on a higher level,
with
 semantics, this would be a slow path, however.
 

Hi,

I guess I need more knowledge on how Wayland protocol is working and how
Weston is working to implement this. I would do more reading and code study
of Weston and then would come back to this.  

Thank-you,
Hebbar
 
 Thanks,
 pq
 ___
 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: New to Wayland, Need suggestion on a starting point

[Pekka Paalanen]

On Tue, 06 May 2014 15:59:58 +0530
Srivardhan sri.heb...@samsung.com wrote:

 
  -Original Message-
  From: wayland-devel [mailto:wayland-devel-
  boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen
  Sent: Monday, May 05, 2014 5:36 PM
  To: Srivardhan
  Cc: 'Jason Ekstrand'; wayland-devel@lists.freedesktop.org
  Subject: Re: New to Wayland, Need suggestion on a starting point
  
  My idea is to not use libwayland at all. Instead, you would
  duplicate all
 the
  needed parts in a stand-alone program. The starting point would be
  to
 relay
  Wayland messages in both directions without parsing them at all
  beyond the message size field. You just need to make sure to handle
  file descriptors, otherwise it would be just a byte for byte copy.
  
  Once that works, you can already dump the header of each message,
  allowing the tool to dump at least something on unknown protocol
  extensions. The next step would be to read in the protocol XML
  files so
 that
  you can actually parse and print the messages. You start with
  wl_display
 as
  that is needed to maintain object references, and then do the rest
  of the core protocol. Once you handle the core protocol, you also
  handle all extensions that can ever be, as long as you have their
  XML description.
  
  You could use a custom generator to convert the XML into C data
 structures,
  but I would prefer if the tool read in the XML files directly. That
  way
 the built
  tool is not dependent on any particular protocol version it was
  built with
 but
  you can use it on everything.
  This would be very useful when developing protocols as one would
  not need to recompile the dumping tool all the time. The XML files
  are installed by each project maintaining them (or should be), so
  they would be always available in distribution -devel packages I
  assume.
  
  That would make the dumping tool an independent project. In the
  future, it could then be a basis for more sophisticated tools, like
  an object state recorder/viewer and graphical visualization, or
  maybe co-operate with existing protocol visualization tools.
  
  This project would introduce you to Wayland starting from the
  lowest level
 of
  the protocol. If you wish to learn how Wayland works on a higher
  level,
 with
  semantics, this would be a slow path, however.
  
 
 Hi,
 
 I guess I need more knowledge on how Wayland protocol is working and
 how Weston is working to implement this. I would do more reading and
 code study of Weston and then would come back to this.  

Hi,

actually no. This stuff is more Unix system programming than anything
specific to Weston or even Wayland, at least at first: how to handle
unix sockets and pass file descriptors as ancillary data. See 'man 7
unix' and SCM_RIGHTS.

I perfectly understand if you would like something that dives
more directly into Wayland things first, rather than the boring(?)
low-level socket stuff. Anyway, the protocol dumper is just one idea.


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

Re: [PATCH] doc: Added API documentation for wl_display_create function.

[Pekka Paalanen]

On Tue, 06 May 2014 15:52:12 +0530
Srivardhan Hebbar sri.heb...@samsung.com wrote:

 Signed-off-by: Srivardhan Hebbar sri.heb...@samsung.com
 ---
  src/wayland-server.c |9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/src/wayland-server.c b/src/wayland-server.c
 index f2b1b42..7b32848 100644
 --- a/src/wayland-server.c
 +++ b/src/wayland-server.c
 @@ -788,6 +788,15 @@ bind_display(struct wl_client *client,
  destroy_client_display_resource);
  }
  
 +/** Create Wayland display object.
 + *
 + * \param None
 + * \return The Wayland display object. Null if failed to create
 + *
 + * This creates the wl_display object for the client.

Hi,

this is a server function, not a client function.

FYI, struct wl_display is a different thing in server vs. client, and I
think there might even be a third definition in clients that is a
wl_proxy.

 + *
 + * \memberof wl_display
 + */
  WL_EXPORT struct wl_display *
  wl_display_create(void)
  {


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

RE: New to Wayland, Need suggestion on a starting point

[Srivardhan]

 -Original Message-
 From: wayland-devel [mailto:wayland-devel-
 boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen
 Sent: Tuesday, May 06, 2014 4:21 PM
 To: Srivardhan
 Cc: 'Jason Ekstrand'; wayland-devel@lists.freedesktop.org
 Subject: Re: New to Wayland, Need suggestion on a starting point
 
 On Tue, 06 May 2014 15:59:58 +0530
 Srivardhan sri.heb...@samsung.com wrote:
 
 
   -Original Message-
   From: wayland-devel [mailto:wayland-devel-
   boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen
   Sent: Monday, May 05, 2014 5:36 PM
   To: Srivardhan
   Cc: 'Jason Ekstrand'; wayland-devel@lists.freedesktop.org
   Subject: Re: New to Wayland, Need suggestion on a starting point
  
   My idea is to not use libwayland at all. Instead, you would
   duplicate all
  the
   needed parts in a stand-alone program. The starting point would be
   to
  relay
   Wayland messages in both directions without parsing them at all
   beyond the message size field. You just need to make sure to handle
   file descriptors, otherwise it would be just a byte for byte copy.
  
   Once that works, you can already dump the header of each message,
   allowing the tool to dump at least something on unknown protocol
   extensions. The next step would be to read in the protocol XML files
   so
  that
   you can actually parse and print the messages. You start with
   wl_display
  as
   that is needed to maintain object references, and then do the rest
   of the core protocol. Once you handle the core protocol, you also
   handle all extensions that can ever be, as long as you have their
   XML description.
  
   You could use a custom generator to convert the XML into C data
  structures,
   but I would prefer if the tool read in the XML files directly. That
   way
  the built
   tool is not dependent on any particular protocol version it was
   built with
  but
   you can use it on everything.
   This would be very useful when developing protocols as one would not
   need to recompile the dumping tool all the time. The XML files are
   installed by each project maintaining them (or should be), so they
   would be always available in distribution -devel packages I assume.
  
   That would make the dumping tool an independent project. In the
   future, it could then be a basis for more sophisticated tools, like
   an object state recorder/viewer and graphical visualization, or
   maybe co-operate with existing protocol visualization tools.
  
   This project would introduce you to Wayland starting from the lowest
   level
  of
   the protocol. If you wish to learn how Wayland works on a higher
   level,
  with
   semantics, this would be a slow path, however.
  
 
  Hi,
 
  I guess I need more knowledge on how Wayland protocol is working and
  how Weston is working to implement this. I would do more reading and
  code study of Weston and then would come back to this.
 
 Hi,
 
 actually no. This stuff is more Unix system programming than anything
 specific to Weston or even Wayland, at least at first: how to handle unix
 sockets and pass file descriptors as ancillary data. See 'man 7 unix' and
 SCM_RIGHTS.
 
 I perfectly understand if you would like something that dives more
directly
 into Wayland things first, rather than the boring(?) low-level socket
stuff.
 Anyway, the protocol dumper is just one idea.
 

Hi,

Sorry, I did not understand it properly. It's not that it is boring. :) Is
the program like a snooper which captures all the packets of Wayland server
and Wayland client? 

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

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

[PATCH weston v2 1/5] shell: support window resizing using touchscreen

[Stanislav Vorobiov]

if the system doesn't have a pointer device
common_surface_resize will crash on
accessing seat-pointer-button_count. if the system
does have a pointer device, but attempts to resize
a window using touchscreen - nothing happens. here
we implement separate window resizing path for
seat-touch as it is done in common_surface_move
---
 clients/window.c  |5 +-
 desktop-shell/shell.c |  153 ++---
 shared/cairo-util.h   |2 +-
 shared/frame.c|   20 ---
 4 files changed, 159 insertions(+), 21 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index f12ce39..be2c0e0 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2409,9 +2409,10 @@ frame_touch_down_handler(struct widget *widget, struct 
input *input,
 float x, float y, void *data)
 {
struct window_frame *frame = data;
+   enum theme_location location;
 
-   frame_touch_down(frame-frame, input, id, x, y);
-   frame_handle_status(frame, input, time, THEME_LOCATION_CLIENT_AREA);
+   location = frame_touch_down(frame-frame, input, id, x, y);
+   frame_handle_status(frame, input, time, location);
 }
 
 static void
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index a631c62..2aab283 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -395,6 +395,7 @@ shell_touch_grab_end(struct shell_touch_grab *grab)
if (grab-shsurf) {
wl_list_remove(grab-shsurf_destroy_listener.link);
grab-shsurf-grabbed = 0;
+   grab-shsurf-resize_edges = 0;
}
 
weston_touch_end_grab(grab-touch);
@@ -1615,6 +1616,14 @@ struct weston_resize_grab {
int32_t width, height;
 };
 
+struct weston_touch_resize_grab {
+   struct shell_touch_grab base;
+   int active;
+   uint32_t edges;
+   int32_t width, height;
+   wl_fixed_t dx, dy;
+};
+
 static void
 resize_grab_motion(struct weston_pointer_grab *grab, uint32_t time,
   wl_fixed_t x, wl_fixed_t y)
@@ -1702,6 +1711,83 @@ static const struct weston_pointer_grab_interface 
resize_grab_interface = {
resize_grab_cancel,
 };
 
+static void
+touch_resize_grab_down(struct weston_touch_grab *grab, uint32_t time,
+int touch_id, wl_fixed_t sx, wl_fixed_t sy)
+{
+}
+
+static void
+touch_resize_grab_up(struct weston_touch_grab *grab, uint32_t time, int 
touch_id)
+{
+   struct weston_touch_resize_grab *resize =
+   (struct weston_touch_resize_grab *) container_of(
+   grab, struct shell_touch_grab, grab);
+
+   if (touch_id == 0)
+   resize-active = 0;
+
+   if (grab-touch-num_tp == 0) {
+   shell_touch_grab_end(resize-base);
+   free(resize);
+   }
+}
+
+static void
+touch_resize_grab_motion(struct weston_touch_grab *grab, uint32_t time,
+  int touch_id, wl_fixed_t sx, wl_fixed_t sy)
+{
+   struct weston_touch_resize_grab *resize = (struct 
weston_touch_resize_grab *) grab;
+   struct weston_touch *touch = grab-touch;
+   struct shell_surface *shsurf = resize-base.shsurf;
+   int32_t width, height;
+   wl_fixed_t from_x, from_y;
+   wl_fixed_t to_x, to_y;
+
+   if (!shsurf || !resize-active)
+   return;
+
+   weston_view_from_global_fixed(shsurf-view,
+ resize-dx, resize-dy,
+ from_x, from_y);
+   weston_view_from_global_fixed(shsurf-view,
+ touch-grab_x, touch-grab_y, to_x, 
to_y);
+
+   width = resize-width;
+   if (resize-edges  WL_SHELL_SURFACE_RESIZE_LEFT) {
+   width += wl_fixed_to_int(from_x - to_x);
+   } else if (resize-edges  WL_SHELL_SURFACE_RESIZE_RIGHT) {
+   width += wl_fixed_to_int(to_x - from_x);
+   }
+
+   height = resize-height;
+   if (resize-edges  WL_SHELL_SURFACE_RESIZE_TOP) {
+   height += wl_fixed_to_int(from_y - to_y);
+   } else if (resize-edges  WL_SHELL_SURFACE_RESIZE_BOTTOM) {
+   height += wl_fixed_to_int(to_y - from_y);
+   }
+
+   shsurf-client-send_configure(shsurf-surface, width, height);
+}
+
+static void
+touch_resize_grab_cancel(struct weston_touch_grab *grab)
+{
+   struct weston_touch_resize_grab *resize =
+   (struct weston_touch_resize_grab *) container_of(
+   grab, struct shell_touch_grab, grab);
+
+   shell_touch_grab_end(resize-base);
+   free(resize);
+}
+
+static const struct weston_touch_grab_interface touch_resize_grab_interface = {
+   touch_resize_grab_down,
+   touch_resize_grab_up,
+   touch_resize_grab_motion,
+   touch_resize_grab_cancel,
+};
+
 /*
  * Returns the bounding box of a surface and all its sub-surfaces,
  * in the surface coordinates system. */
@@ -1766,6 +1852,37 @@ surface_resize(struct shell_surface 

[PATCH weston v2 2/5] shell: support zooming without a pointer device

[Stanislav Vorobiov]

if the system doesn't have a pointer device
do_zoom will crash on accessing seat-pointer-x.
here we implement zoom support on systems with
a touchscreen, touchscreen's last touch point is
simply used instead of pointer's current position
---
 desktop-shell/shell.c |   22 --
 src/compositor.h  |1 +
 src/input.c   |3 +++
 src/zoom.c|   40 
 4 files changed, 56 insertions(+), 10 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 2aab283..c7760f7 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1375,6 +1375,7 @@ static void
 touch_move_grab_down(struct weston_touch_grab *grab, uint32_t time,
 int touch_id, wl_fixed_t sx, wl_fixed_t sy)
 {
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
 }
 
 static void
@@ -1403,6 +1404,8 @@ touch_move_grab_motion(struct weston_touch_grab *grab, 
uint32_t time,
int dx = wl_fixed_to_int(grab-touch-grab_x + move-dx);
int dy = wl_fixed_to_int(grab-touch-grab_y + move-dy);
 
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
+
if (!shsurf || !move-active)
return;
 
@@ -1715,6 +1718,7 @@ static void
 touch_resize_grab_down(struct weston_touch_grab *grab, uint32_t time,
 int touch_id, wl_fixed_t sx, wl_fixed_t sy)
 {
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
 }
 
 static void
@@ -1744,6 +1748,8 @@ touch_resize_grab_motion(struct weston_touch_grab *grab, 
uint32_t time,
wl_fixed_t from_x, from_y;
wl_fixed_t to_x, to_y;
 
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
+
if (!shsurf || !resize-active)
return;
 
@@ -4376,11 +4382,23 @@ do_zoom(struct weston_seat *seat, uint32_t time, 
uint32_t key, uint32_t axis,
struct weston_compositor *compositor = ws-compositor;
struct weston_output *output;
float increment;
+   double x, y;
+
+   if (seat-pointer) {
+   x = wl_fixed_to_double(seat-pointer-x);
+   y = wl_fixed_to_double(seat-pointer-y);
+   } else if (seat-touch) {
+   x = wl_fixed_to_double(seat-touch-grab_x);
+   y = wl_fixed_to_double(seat-touch-grab_y);
+   } else {
+   x = wl_fixed_to_double(0);
+   y = wl_fixed_to_double(0);
+   }
 
wl_list_for_each(output, compositor-output_list, link) {
if (pixman_region32_contains_point(output-region,
-  
wl_fixed_to_double(seat-pointer-x),
-  
wl_fixed_to_double(seat-pointer-y),
+  x,
+  y,
   NULL)) {
if (key == KEY_PAGEUP)
increment = output-zoom.increment;
diff --git a/src/compositor.h b/src/compositor.h
index 057f8be..f2f1bf4 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -347,6 +347,7 @@ struct weston_touch {
struct wl_listener focus_resource_listener;
uint32_t focus_serial;
struct wl_signal focus_signal;
+   struct wl_signal motion_signal;
 
uint32_t num_tp;
 
diff --git a/src/input.c b/src/input.c
index 2c799f4..616b6e6 100644
--- a/src/input.c
+++ b/src/input.c
@@ -278,6 +278,8 @@ default_grab_touch_motion(struct weston_touch_grab *grab, 
uint32_t time,
struct wl_resource *resource;
struct wl_list *resource_list;
 
+   wl_signal_emit(touch-motion_signal, touch);
+
resource_list = touch-focus_resource_list;
 
wl_resource_for_each(resource, resource_list) {
@@ -583,6 +585,7 @@ weston_touch_create(void)
touch-default_grab.touch = touch;
touch-grab = touch-default_grab;
wl_signal_init(touch-focus_signal);
+   wl_signal_init(touch-motion_signal);
 
return touch;
 }
diff --git a/src/zoom.c b/src/zoom.c
index 622c0d7..8c8b18a 100644
--- a/src/zoom.c
+++ b/src/zoom.c
@@ -86,8 +86,16 @@ weston_zoom_frame_xy(struct weston_animation *animation,
 
if (weston_spring_done(output-zoom.spring_xy)) {
output-zoom.spring_xy.current = output-zoom.spring_xy.target;
-   output-zoom.current.x = seat-pointer-x;
-   output-zoom.current.y = seat-pointer-y;
+   if (seat-pointer) {
+   output-zoom.current.x = seat-pointer-x;
+   output-zoom.current.y = seat-pointer-y;
+   } else if (seat-touch) {
+   output-zoom.current.x = seat-touch-grab_x;
+   output-zoom.current.y = seat-touch-grab_y;
+   } else {
+   output-zoom.current.x = 0;
+   output-zoom.current.y = 0;
+   }

[PATCH weston v2 0/5] improving support for systems without a pointer device

[Stanislav Vorobiov]

upd: one more patch that fixes frame buttons
reaction for touchscreens

Stanislav Vorobiov (5):
  shell: support window resizing using touchscreen
  shell: support zooming without a pointer device
  data-device: fix crash on systems with no pointer device
  exposay: support systems without a pointer device
  shared/frame: fix frame buttons for touchscreen

 clients/window.c|   19 -
 desktop-shell/exposay.c |   95 +++--
 desktop-shell/shell.c   |  175 ---
 desktop-shell/shell.h   |1 +
 shared/cairo-util.h |5 +-
 shared/frame.c  |   60 
 src/compositor.h|1 +
 src/data-device.c   |   19 +++--
 src/input.c |3 +
 src/zoom.c  |   40 ---
 10 files changed, 371 insertions(+), 47 deletions(-)

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

[PATCH weston v2 4/5] exposay: support systems without a pointer device

[Stanislav Vorobiov]

if the system doesn't have a pointer device
exposay_transition_active will crash
in weston_pointer_start_grab(seat-pointer, ...).
here we fix that and also implement exposay support
on systems with a touchscreen
---
 desktop-shell/exposay.c |   95 ---
 desktop-shell/shell.h   |1 +
 2 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index 1d8b40e..91932ce 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -391,6 +391,77 @@ static const struct weston_pointer_grab_interface 
exposay_ptr_grab = {
exposay_pointer_grab_cancel,
 };
 
+static void
+exposay_touch_down(struct weston_touch_grab *grab, uint32_t time,
+  int touch_id, wl_fixed_t sx, wl_fixed_t sy)
+{
+   struct desktop_shell *shell =
+   container_of(grab, struct desktop_shell, exposay.grab_touch);
+
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
+
+   exposay_pick(shell,
+wl_fixed_to_int(grab-touch-grab_x),
+wl_fixed_to_int(grab-touch-grab_y));
+
+   /* Store the surface we clicked on, and don't do anything if we end up
+* releasing on a different surface. */
+   if (grab-touch-num_tp == 1) {
+   shell-exposay.clicked = shell-exposay.focus_current;
+   }
+}
+
+static void
+exposay_touch_up(struct weston_touch_grab *grab, uint32_t time, int touch_id)
+{
+   struct desktop_shell *shell =
+   container_of(grab, struct desktop_shell, exposay.grab_touch);
+   struct weston_seat *seat = grab-touch-seat;
+
+   if (grab-touch-num_tp == 0) {
+   if (shell-exposay.focus_current == shell-exposay.clicked)
+   exposay_set_state(shell, EXPOSAY_TARGET_SWITCH, seat);
+   else
+   shell-exposay.clicked = NULL;
+   }
+}
+
+static void
+exposay_touch_motion(struct weston_touch_grab *grab, uint32_t time,
+  int touch_id, wl_fixed_t sx, wl_fixed_t sy)
+{
+   struct desktop_shell *shell =
+   container_of(grab, struct desktop_shell, exposay.grab_touch);
+
+   wl_signal_emit(grab-touch-motion_signal, grab-touch);
+
+   exposay_pick(shell,
+wl_fixed_to_int(grab-touch-grab_x),
+wl_fixed_to_int(grab-touch-grab_y));
+}
+
+static void
+exposay_touch_frame(struct weston_touch_grab *grab)
+{
+}
+
+static void
+exposay_touch_grab_cancel(struct weston_touch_grab *grab)
+{
+   struct desktop_shell *shell =
+   container_of(grab, struct desktop_shell, exposay.grab_touch);
+
+   exposay_set_state(shell, EXPOSAY_TARGET_CANCEL, shell-exposay.seat);
+}
+
+static const struct weston_touch_grab_interface exposay_touch_grab = {
+   exposay_touch_down,
+   exposay_touch_up,
+   exposay_touch_motion,
+   exposay_touch_frame,
+   exposay_touch_grab_cancel,
+};
+
 static int
 exposay_maybe_move(struct desktop_shell *shell, int row, int column)
 {
@@ -517,7 +588,10 @@ exposay_set_inactive(struct desktop_shell *shell)
struct weston_seat *seat = shell-exposay.seat;
 
weston_keyboard_end_grab(seat-keyboard);
-   weston_pointer_end_grab(seat-pointer);
+   if (seat-pointer)
+   weston_pointer_end_grab(seat-pointer);
+   if (seat-touch)
+   weston_touch_end_grab(seat-touch);
if (seat-keyboard-input_method_resource)
seat-keyboard-grab = seat-keyboard-input_method_grab;
 
@@ -567,11 +641,20 @@ exposay_transition_active(struct desktop_shell *shell)
   shell-exposay.grab_kbd);
weston_keyboard_set_focus(seat-keyboard, NULL);
 
-   shell-exposay.grab_ptr.interface = exposay_ptr_grab;
-   weston_pointer_start_grab(seat-pointer,
- shell-exposay.grab_ptr);
-   weston_pointer_set_focus(seat-pointer, NULL,
-seat-pointer-x, seat-pointer-y);
+   if (seat-pointer) {
+   shell-exposay.grab_ptr.interface = exposay_ptr_grab;
+   weston_pointer_start_grab(seat-pointer,
+ shell-exposay.grab_ptr);
+   weston_pointer_set_focus(seat-pointer, NULL,
+seat-pointer-x, seat-pointer-y);
+   }
+
+   if (seat-touch) {
+   shell-exposay.grab_touch.interface = exposay_touch_grab;
+   weston_touch_start_grab(seat-touch,
+   shell-exposay.grab_touch);
+   weston_touch_set_focus(seat, NULL);
+   }
 
wl_list_for_each(shell_output, shell-output_list, link) {
enum exposay_layout_state state;
diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
index 6e63785..ba7951a 100644
--- a/desktop-shell/shell.h
+++ b/desktop-shell/shell.h
@@ -74,6 +74,7 @@ struct 

[PATCH weston v2 5/5] shared/frame: fix frame buttons for touchscreen

[Stanislav Vorobiov]

support frame buttons hovering with touchscreen and
cancel button press if a touch was not released over
the button that was pressed
---
 clients/window.c|   14 ++
 shared/cairo-util.h |3 +++
 shared/frame.c  |   44 ++--
 3 files changed, 55 insertions(+), 6 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index be2c0e0..ecb90c0 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2426,6 +2426,19 @@ frame_touch_up_handler(struct widget *widget,
frame_handle_status(frame, input, time, THEME_LOCATION_CLIENT_AREA);
 }
 
+static void
+frame_touch_motion_handler(struct widget *widget,
+  struct input *input,
+  uint32_t time, int32_t id, float x, float y,
+  void *data)
+{
+   struct window_frame *frame = data;
+
+   frame_touch_motion(frame-frame, input, x, y);
+   if (frame_status(frame-frame)  FRAME_STATUS_REPAINT)
+   widget_schedule_redraw(frame-widget);
+}
+
 struct widget *
 window_frame_create(struct window *window, void *data)
 {
@@ -2453,6 +2466,7 @@ window_frame_create(struct window *window, void *data)
widget_set_button_handler(frame-widget, frame_button_handler);
widget_set_touch_down_handler(frame-widget, frame_touch_down_handler);
widget_set_touch_up_handler(frame-widget, frame_touch_up_handler);
+   widget_set_touch_motion_handler(frame-widget, 
frame_touch_motion_handler);
 
window-frame = frame;
 
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 9643023..70f62a6 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -211,6 +211,9 @@ void
 frame_touch_up(struct frame *frame, void *data, int32_t id);
 
 void
+frame_touch_motion(struct frame *frame, void *data, int x, int y);
+
+void
 frame_repaint(struct frame *frame, cairo_t *cr);
 
 #endif
diff --git a/shared/frame.c b/shared/frame.c
index 833117c..d0430a7 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -77,6 +77,7 @@ struct frame_touch {
 
int x, y;
 
+   struct frame_button *hover_button;
struct frame_button *button;
 };
 
@@ -789,7 +790,7 @@ frame_touch_down(struct frame *frame, void *data, int32_t 
id, int x, int y)
struct frame_button *button = frame_find_button(frame, x, y);
enum theme_location location = THEME_LOCATION_EXTERIOR;
 
-   if (id  0)
+   if (!touch || (id  0))
return location;
 
location = theme_get_location(frame-theme, x, y,
@@ -797,8 +798,9 @@ frame_touch_down(struct frame *frame, void *data, int32_t 
id, int x, int y)
  frame-flags  FRAME_FLAG_MAXIMIZED ?
  THEME_FRAME_MAXIMIZED : 0);
 
-   if (touch  button) {
-   touch-button = button;
+   if (button) {
+   touch-hover_button = touch-button = button;
+   frame_button_enter(touch-button);
frame_button_press(touch-button);
return location;
}
@@ -829,16 +831,46 @@ frame_touch_up(struct frame *frame, void *data, int32_t 
id)
 {
struct frame_touch *touch = frame_touch_get(frame, data);
 
-   if (id  0)
+   if (!touch || (id  0))
return;
 
-   if (touch  touch-button) {
-   frame_button_release(touch-button);
+   if (touch-hover_button)
+   frame_button_leave(touch-hover_button, NULL);
+
+   if (touch-button) {
+   if (touch-button == touch-hover_button)
+   frame_button_release(touch-button);
+   else
+   frame_button_cancel(touch-button);
frame_touch_destroy(touch);
}
 }
 
 void
+frame_touch_motion(struct frame *frame, void *data, int x, int y)
+{
+   struct frame_touch *touch = frame_touch_get(frame, data);
+   struct frame_button *button = frame_find_button(frame, x, y);
+
+   if (!touch)
+   return;
+
+   touch-x = x;
+   touch-y = y;
+
+   if (touch-hover_button == button)
+   return;
+
+   if (touch-hover_button)
+   frame_button_leave(touch-hover_button, NULL);
+
+   touch-hover_button = button;
+
+   if (touch-hover_button)
+   frame_button_enter(touch-hover_button);
+}
+
+void
 frame_repaint(struct frame *frame, cairo_t *cr)
 {
struct frame_button *button;
-- 
1.7.9.5

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

RE: [PATCH] doc: Added API documentation for wl_display_create function.

[Srivardhan]

 -Original Message-
 From: wayland-devel [mailto:wayland-devel-
 boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen
 Sent: Tuesday, May 06, 2014 5:03 PM
 To: Srivardhan Hebbar
 Cc: wayland-devel@lists.freedesktop.org
 Subject: Re: [PATCH] doc: Added API documentation for wl_display_create
 function.
 
 On Tue, 06 May 2014 15:52:12 +0530
 Srivardhan Hebbar sri.heb...@samsung.com wrote:
 
  Signed-off-by: Srivardhan Hebbar sri.heb...@samsung.com
  ---
   src/wayland-server.c |9 +
   1 file changed, 9 insertions(+)
 
  diff --git a/src/wayland-server.c b/src/wayland-server.c index
  f2b1b42..7b32848 100644
  --- a/src/wayland-server.c
  +++ b/src/wayland-server.c
  @@ -788,6 +788,15 @@ bind_display(struct wl_client *client,
 destroy_client_display_resource);  }
 
  +/** Create Wayland display object.
  + *
  + * \param None
  + * \return The Wayland display object. Null if failed to create
  + *
  + * This creates the wl_display object for the client.
 
 Hi,
 
 this is a server function, not a client function.
 
 FYI, struct wl_display is a different thing in server vs. client, and I
think there
 might even be a third definition in clients that is a wl_proxy.

Oops... My bad. Sorry. This function creates the wl_display singleton object
for the server. Right? Would correct it update the patch.

Thank-you,
Sri
 
  + *
  + * \memberof wl_display
  + */
   WL_EXPORT struct wl_display *
   wl_display_create(void)
   {
 
 
 Thanks,
 pq
 ___
 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: New to Wayland, Need suggestion on a starting point

[Pekka Paalanen]

On Tue, 06 May 2014 17:09:56 +0530
Srivardhan sri.heb...@samsung.com wrote:

 Sorry, I did not understand it properly. It's not that it is
 boring. :) Is the program like a snooper which captures all the
 packets of Wayland server and Wayland client? 

A man-in-the-middle, to be more precise, but yes.


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

[PATCH weston] window: Ignore input events from subsurfaces

[Ander Conselvan de Oliveira]

From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com

Toytoolkit was not designed to handle input from subsurfaces and
instead it expects subsurfaces to have an empty input region. That way
input events for subsurfaces are generated on the main surface and
there is no need to convert coordinates before reporting the event to
the user.

However it is possible that a subsurface has a non-empty input region,
but in that case those events aren't properly processed. The function
window_find_widget() assumes the coordinates are in the main surface
coordinate space, and ends up chosing the wrong widget.

This patch changes the input code to completely ignore input events from
subsurfaces. This option was chosen instead of ensuring that the input
region on those surfaces is always empty since there's no enforcement
that a subsurface should completely overlap with the main surface. If
an event happens in the area of the surface that doesn't overlap, the
event could cause a completely unrelated surface to be picked.

https://bugs.freedesktop.org/show_bug.cgi?id=78207
---
 clients/window.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index b7febed..3b57264 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2605,10 +2605,15 @@ pointer_handle_enter(void *data, struct wl_pointer 
*pointer,
return;
}
 
+   window = wl_surface_get_user_data(surface);
+   if (surface != window-main_surface-surface) {
+   DBG(Ignoring input event from subsurface %p\n, surface);
+   return;
+   }
+
input-display-serial = serial;
input-pointer_enter_serial = serial;
-   input-pointer_focus = wl_surface_get_user_data(surface);
-   window = input-pointer_focus;
+   input-pointer_focus = window;
 
if (window-resizing) {
window-resizing = 0;
@@ -2644,12 +2649,12 @@ pointer_handle_motion(void *data, struct wl_pointer 
*pointer,
float sx = wl_fixed_to_double(sx_w);
float sy = wl_fixed_to_double(sy_w);
 
-   input-sx = sx;
-   input-sy = sy;
-
if (!window)
return;
 
+   input-sx = sx;
+   input-sy = sy;
+
/* when making the window smaller - e.g. after a unmaximise we might
 * still have a pending motion event that the compositor has picked
 * based on the old surface dimensions
@@ -2979,6 +2984,12 @@ touch_handle_down(void *data, struct wl_touch *wl_touch,
return;
}
 
+   if (surface != input-touch_focus-main_surface-surface) {
+   DBG(Ignoring input event from subsurface %p\n, surface);
+   input-touch_focus = NULL;
+   return;
+   }
+
if (input-grab)
widget = input-grab;
else
-- 
1.8.3.2

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

Re: [PATCH weston] window: Ignore input events from subsurfaces

[Pekka Paalanen]

On Tue,  6 May 2014 15:25:40 +0300
Ander Conselvan de Oliveira conselv...@gmail.com wrote:

 From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
 
 Toytoolkit was not designed to handle input from subsurfaces and
 instead it expects subsurfaces to have an empty input region. That way
 input events for subsurfaces are generated on the main surface and
 there is no need to convert coordinates before reporting the event to
 the user.
 
 However it is possible that a subsurface has a non-empty input region,
 but in that case those events aren't properly processed. The function
 window_find_widget() assumes the coordinates are in the main surface
 coordinate space, and ends up chosing the wrong widget.
 
 This patch changes the input code to completely ignore input events from
 subsurfaces. This option was chosen instead of ensuring that the input
 region on those surfaces is always empty since there's no enforcement
 that a subsurface should completely overlap with the main surface. If
 an event happens in the area of the surface that doesn't overlap, the
 event could cause a completely unrelated surface to be picked.
 
 https://bugs.freedesktop.org/show_bug.cgi?id=78207
 ---
  clients/window.c | 21 -
  1 file changed, 16 insertions(+), 5 deletions(-)
 
 diff --git a/clients/window.c b/clients/window.c
 index b7febed..3b57264 100644
 --- a/clients/window.c
 +++ b/clients/window.c
 @@ -2605,10 +2605,15 @@ pointer_handle_enter(void *data, struct wl_pointer 
 *pointer,
   return;
   }
  
 + window = wl_surface_get_user_data(surface);
 + if (surface != window-main_surface-surface) {
 + DBG(Ignoring input event from subsurface %p\n, surface);
 + return;

Ignoring enter on a sub-surface, actually. I assume the explanation is
that, that the leave on the main surface already sets pointer_focus to
NULL, and here we just avoid setting it, so all following input events
get ignored.

Ok.

 + }
 +
   input-display-serial = serial;
   input-pointer_enter_serial = serial;
 - input-pointer_focus = wl_surface_get_user_data(surface);
 - window = input-pointer_focus;
 + input-pointer_focus = window;
  
   if (window-resizing) {
   window-resizing = 0;
 @@ -2644,12 +2649,12 @@ pointer_handle_motion(void *data, struct wl_pointer 
 *pointer,
   float sx = wl_fixed_to_double(sx_w);
   float sy = wl_fixed_to_double(sy_w);
  
 - input-sx = sx;
 - input-sy = sy;
 -
   if (!window)
   return;
  
 + input-sx = sx;
 + input-sy = sy;
 +
   /* when making the window smaller - e.g. after a unmaximise we might
* still have a pending motion event that the compositor has picked
* based on the old surface dimensions
 @@ -2979,6 +2984,12 @@ touch_handle_down(void *data, struct wl_touch 
 *wl_touch,
   return;
   }
  
 + if (surface != input-touch_focus-main_surface-surface) {

Could touch_focus somehow already be NULL?
Like putting two fingers one after the other to the sub-surface?

 + DBG(Ignoring input event from subsurface %p\n, surface);
 + input-touch_focus = NULL;

If I have a finger down on the main surface somewhere, and put another
finger on the tooltip, won't I lose the main surface then?

Sorry, I've no idea how multitouch works here.

 + return;
 + }
 +
   if (input-grab)
   widget = input-grab;
   else

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

Re: [PATCH weston] window: Ignore input events from subsurfaces

[Ander Conselvan de Oliveira]

On 05/06/2014 03:40 PM, Pekka Paalanen wrote:

On Tue,  6 May 2014 15:25:40 +0300
Ander Conselvan de Oliveira conselv...@gmail.com wrote:


From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com

Toytoolkit was not designed to handle input from subsurfaces and
instead it expects subsurfaces to have an empty input region. That way
input events for subsurfaces are generated on the main surface and
there is no need to convert coordinates before reporting the event to
the user.

However it is possible that a subsurface has a non-empty input region,
but in that case those events aren't properly processed. The function
window_find_widget() assumes the coordinates are in the main surface
coordinate space, and ends up chosing the wrong widget.

This patch changes the input code to completely ignore input events from
subsurfaces. This option was chosen instead of ensuring that the input
region on those surfaces is always empty since there's no enforcement
that a subsurface should completely overlap with the main surface. If
an event happens in the area of the surface that doesn't overlap, the
event could cause a completely unrelated surface to be picked.

https://bugs.freedesktop.org/show_bug.cgi?id=78207
---
  clients/window.c | 21 -
  1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index b7febed..3b57264 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2605,10 +2605,15 @@ pointer_handle_enter(void *data, struct wl_pointer 
*pointer,
return;
}

+   window = wl_surface_get_user_data(surface);
+   if (surface != window-main_surface-surface) {
+   DBG(Ignoring input event from subsurface %p\n, surface);
+   return;


Ignoring enter on a sub-surface, actually. I assume the explanation is
that, that the leave on the main surface already sets pointer_focus to
NULL, and here we just avoid setting it, so all following input events
get ignored.

Ok.


+   }
+
input-display-serial = serial;
input-pointer_enter_serial = serial;
-   input-pointer_focus = wl_surface_get_user_data(surface);
-   window = input-pointer_focus;
+   input-pointer_focus = window;

if (window-resizing) {
window-resizing = 0;
@@ -2644,12 +2649,12 @@ pointer_handle_motion(void *data, struct wl_pointer 
*pointer,
float sx = wl_fixed_to_double(sx_w);
float sy = wl_fixed_to_double(sy_w);

-   input-sx = sx;
-   input-sy = sy;
-
if (!window)
return;

+   input-sx = sx;
+   input-sy = sy;
+
/* when making the window smaller - e.g. after a unmaximise we might
 * still have a pending motion event that the compositor has picked
 * based on the old surface dimensions
@@ -2979,6 +2984,12 @@ touch_handle_down(void *data, struct wl_touch *wl_touch,
return;
}

+   if (surface != input-touch_focus-main_surface-surface) {


Could touch_focus somehow already be NULL?


Yeah, it's possible. If I understand correctly, in that case all touch 
events are ignored.



Like putting two fingers one after the other to the sub-surface?


+   DBG(Ignoring input event from subsurface %p\n, surface);
+   input-touch_focus = NULL;


If I have a finger down on the main surface somewhere, and put another
finger on the tooltip, won't I lose the main surface then?

Sorry, I've no idea how multitouch works here.


Yeah, the main surface would lose touch focus. The behavior is to change 
the focus to the last touched surface. So if they were two separate 
windows, only the second window would get the touch events. At least 
that's how I understood it.


Cheers,
Ander




+   return;
+   }
+
if (input-grab)
widget = input-grab;
else


Thanks,
pq



-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 


This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: [PATCH] doc: Added API documentation for wl_display_create function.

[Ander Conselvan de Oliveira]

On 05/06/2014 01:22 PM, Srivardhan Hebbar wrote:

Signed-off-by: Srivardhan Hebbar sri.heb...@samsung.com
---
  src/wayland-server.c |9 +
  1 file changed, 9 insertions(+)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index f2b1b42..7b32848 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -788,6 +788,15 @@ bind_display(struct wl_client *client,
   destroy_client_display_resource);
  }

+/** Create Wayland display object.
+ *
+ * \param None
+ * \return The Wayland display object. Null if failed to create
+ *
+ * This creates the wl_display object for the client.
+ *
+ * \memberof wl_display


We have two objects named wl_display, and the one that is documented as 
\class wl_display is the client side one. I'm not sure how to tell 
doxygen that these are two separate things. A quick Google search 
suggested \addtogroup might help, but I haven't really checked if that 
is what we want.


Cheers,
Ander


+ */
  WL_EXPORT struct wl_display *
  wl_display_create(void)
  {



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

[PATCH wayland-web 4/6] xwayland: libepoxy needed

[Pekka Paalanen]

From: Pekka Paalanen pekka.paala...@collabora.co.uk

---
 xserver.html | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/xserver.html b/xserver.html
index 75fb970..fc8cecb 100644
--- a/xserver.html
+++ b/xserver.html
@@ -42,6 +42,20 @@
   xserver on 32-bit systems.
 /p
 
+h2libepoxy/h2
+p
+The Xwayland server depends on
+a href=https://github.com/anholt/libepoxy;libepoxy/a.
+/p
+pregit clone https://github.com/anholt/libepoxy.git
+cd libepoxy
+./autogen.sh --prefix=$WLD
+make
+make install
+cd ..
+/pre
+
+
 h2X Server/h2
 
 pXWayland support has been merged in the master branch on April 4th, 2014,
-- 
1.8.5.5

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

[PATCH wayland-web 2/6] xwayland: merged to master

[Pekka Paalanen]

From: Pekka Paalanen pekka.paala...@collabora.co.uk

Drop the branch that does not exist anymore.
Drop DDX build instructions as not needed anymore.
Ditto xorg.conf changes for the special DDXes.
---
 xserver.html | 65 +---
 1 file changed, 5 insertions(+), 60 deletions(-)

diff --git a/xserver.html b/xserver.html
index db99dd0..eb1f146 100644
--- a/xserver.html
+++ b/xserver.html
@@ -42,60 +42,18 @@
   xserver on 32-bit systems.
 /p
 
-h2X.org/h2
+h2X Server/h2
 
-pregit clone git://anongit.freedesktop.org/xorg/xserver -b xwayland
+pXWayland support has been merged in the master branch on April 4th, 2014,
+and is first released with xserver 1.16. The separate X.org video DDXes
+are not needed anymore./p
+pregit clone git://anongit.freedesktop.org/xorg/xserver
 cd xserver
 ./autogen.sh --prefix=$WLD
 make
 make install
 cd ..
 /pre
-pThis gets you the latest Wayland enabled X server, until the Wayland 
enablement
-gets merged into the master branch./p
-
-h2DDX/h2
-
-p
-  The Device Dependent part of X.  Only one of these is necessary.
-  xf86-video-intel works with Intel open source video drivers.
-  xf86-video-ati works with AMD Radeon open source drivers.
-  xf86-video-wayland is implemented in software, so it works on all
-  hardware, but is somewhat less complete.  xf86-video-nouveau works
-  with Nvidia / Nouveau.
-/p
-
-pregit clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel 
-b xwayland
-cd xf86-video-intel
-./autogen.sh --prefix=$WLD
-make
-make install
-cd ..
-/pre
-
-pregit clone https://github.com/RAOF/xf86-video-ati -b xwayland
-cd xf86-video-ati
-./autogen.sh --prefix=$WLD
-make
-make install
-cd ..
-/pre
-
-pregit clone git://anongit.freedesktop.org/xorg/driver/xf86-video-wayland
-cd xf86-video-wayland
-./autogen.sh --prefix=$WLD
-make
-make install
-cd ..
-/pre
-
-pregit clone https://github.com/RAOF/xf86-video-nouveau -b xwayland
-cd xf86-video-nouveau
-./autogen.sh --prefix=$WLD
-make
-make install
-cd ..
-/pre
 
 h2Paths/h2
 
@@ -108,19 +66,6 @@ gets merged into the master branch./p
 ln -s /usr/bin/xkbcomp $WLD/bin/
 /pre
 
-h2xorg.conf/h2
-
-p
-  Intel, ATI / AMD, and Nouveau DDXes probably do not require
-  any xorg.conf modifications.  If you use WLSHM, it requires a
-  $WLD/etc/X11/xorg.conf containing:
-/p
-preSection Device
-Identifier Device
-Driver wlshm
-EndSection
-/pre
-
 h2weston.ini/h2
 
 p
-- 
1.8.5.5

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

[PATCH wayland-web 1/6] testing: how to check with a particular backend

[Pekka Paalanen]

From: Pekka Paalanen pekka.paala...@collabora.co.uk

---
 testing.html | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/testing.html b/testing.html
index 21c0b7b..b199d82 100644
--- a/testing.html
+++ b/testing.html
@@ -63,10 +63,16 @@ The Weston maintainer(s) have the right to refuse any 
patches that are not accom
 by a unit test or if the patches break existing unit tests.
 /p
 h3Compiling and Running/h3
+pTo run with the default headless backend:/p
 pre
 $ make check
 /pre
 
+pTo run with a different backend, e.g. the X11 backend:/p
+pre
+$ make check BACKEND=x11-backend.so
+/pre
+
 h3Writing Tests/h3
 
 pbCompositor Tests/b/p
-- 
1.8.5.5

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

[PATCH wayland-web 5/6] xwayland: add $ to shell commands

[Pekka Paalanen]

From: Pekka Paalanen pekka.paala...@collabora.co.uk

Make the syntax look like in the main building page.
---
 xserver.html | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/xserver.html b/xserver.html
index fc8cecb..bd4abb7 100644
--- a/xserver.html
+++ b/xserver.html
@@ -47,12 +47,12 @@
 The Xwayland server depends on
 a href=https://github.com/anholt/libepoxy;libepoxy/a.
 /p
-pregit clone https://github.com/anholt/libepoxy.git
-cd libepoxy
-./autogen.sh --prefix=$WLD
-make
-make install
-cd ..
+pre$ git clone https://github.com/anholt/libepoxy.git
+$ cd libepoxy
+$ ./autogen.sh --prefix=$WLD
+$ make
+$ make install
+$ cd ..
 /pre
 
 
@@ -61,12 +61,12 @@ The Xwayland server depends on
 pXWayland support has been merged in the master branch on April 4th, 2014,
 and is first released with xserver 1.16. The separate X.org video DDXes
 are not needed anymore./p
-pregit clone git://anongit.freedesktop.org/xorg/xserver
-cd xserver
-./autogen.sh --prefix=$WLD
-make
-make install
-cd ..
+pre$ git clone git://anongit.freedesktop.org/xorg/xserver
+$ cd xserver
+$ ./autogen.sh --prefix=$WLD
+$ make
+$ make install
+$ cd ..
 /pre
 
 h2Paths/h2
@@ -75,9 +75,9 @@ are not needed anymore./p
   Without this you will get the error XKB: Failed to compile keymap.
 /p
 
-premkdir -p $WLD/share/X11/xkb/rules
-ln -s /usr/share/X11/xkb/rules/evdev $WLD/share/X11/xkb/rules/
-ln -s /usr/bin/xkbcomp $WLD/bin/
+pre$ mkdir -p $WLD/share/X11/xkb/rules
+$ ln -s /usr/share/X11/xkb/rules/evdev $WLD/share/X11/xkb/rules/
+$ ln -s /usr/bin/xkbcomp $WLD/bin/
 /pre
 
 h2weston.ini/h2
-- 
1.8.5.5

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

[PATCH wayland-web 6/6] xwayland: add xserver build options

[Pekka Paalanen]

From: Pekka Paalanen pekka.paala...@collabora.co.uk

With these, it will only install the Xwayland binary. No Xorg, no
modules, no cruft. Just 4 files in total here.
---
 xserver.html | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xserver.html b/xserver.html
index bd4abb7..dd8ff30 100644
--- a/xserver.html
+++ b/xserver.html
@@ -63,7 +63,9 @@ and is first released with xserver 1.16. The separate X.org 
video DDXes
 are not needed anymore./p
 pre$ git clone git://anongit.freedesktop.org/xorg/xserver
 $ cd xserver
-$ ./autogen.sh --prefix=$WLD
+$ ./autogen.sh --prefix=$WLD --disable-docs --disable-devel-docs \
+  --enable-xwayland --disable-xorg --disable-xvfb --disable-xnest \
+  --disable-xquartz --disable-xwin
 $ make
 $ make install
 $ cd ..
-- 
1.8.5.5

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

Re: [PATCH] doc: Added API documentation for wl_display_create function.

[Ander Conselvan de Oliveira]

On 05/06/2014 04:17 PM, Ander Conselvan de Oliveira wrote:

On 05/06/2014 01:22 PM, Srivardhan Hebbar wrote:

Signed-off-by: Srivardhan Hebbar sri.heb...@samsung.com
---
  src/wayland-server.c |9 +
  1 file changed, 9 insertions(+)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index f2b1b42..7b32848 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -788,6 +788,15 @@ bind_display(struct wl_client *client,
 destroy_client_display_resource);
  }

+/** Create Wayland display object.
+ *
+ * \param None
+ * \return The Wayland display object. Null if failed to create
+ *
+ * This creates the wl_display object for the client.
+ *
+ * \memberof wl_display


We have two objects named wl_display, and the one that is documented as
\class wl_display is the client side one. I'm not sure how to tell
doxygen that these are two separate things. A quick Google search
suggested \addtogroup might help, but I haven't really checked if that
is what we want.


Never mind. We actually do two separate doxygen passes, one for the 
server source files and one for the client source files, so this is 
already separate.





Cheers,
Ander


+ */
  WL_EXPORT struct wl_display *
  wl_display_create(void)
  {





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

Re: [PATCH 1/3] protocol: Add an event to specify the name of an output

[Neil Roberts]

Pekka Paalanen ppaala...@gmail.com writes:

 were you aware of […] perhaps? :-)

Ah, no, I hadn't noticed those patches. Oops!

 Your series is almost identical to Quanxian's, except:
 - wording differences, of course
 - patch 2 checks if output-name is set before sending (can it ever be
   NULL?)
 - patch 2 missed setting the actual protocol object version
 - you add support to weston-info in patch 3
 - Quanxian adds empty handlers to window.c and desktop-shell.c which
   isn't really necessary

Ok, it sounds like it would make the most sense to use Quanxian's
patches without the empty handlers and then land my weston-info patch on
top.

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

[PATCH weston] compositor-drm: Don't use vaapi recorder with unsupported formats

[Ander Conselvan de Oliveira]

From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com

We only support recording with GBM_FORMAT_XRGB888 format, so don't try
to record if the output has a differnt format.

https://bugs.freedesktop.org/show_bug.cgi?id=78199
---
 src/compositor-drm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 4441308..5f59789 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -2611,6 +2611,12 @@ recorder_binding(struct weston_seat *seat, uint32_t 
time, uint32_t key,
  struct drm_output, base.link);
 
if (!output-recorder) {
+   if (output-format != GBM_FORMAT_XRGB) {
+   weston_log(failed to start vaapi recorder: 
+  output format not supported\n);
+   return;
+   }
+
width = output-base.current_mode-width;
height = output-base.current_mode-height;
 
-- 
1.8.3.2

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

Re: Thoughts on getting surfaces to appear on the right output

[Jasper St. Pierre]

We solved this under X11 with the startup-notification protocol. Ryan
Lortie has been looking at making a DBus-only startup-notification for
other platforms like Wayland.

Since there's an intersection here, I'm going to CC Ryan and have him
provide his thoughts on this, so we don't have duplicate effort and
multiple protocols to support across DEs.


On Tue, May 6, 2014 at 3:11 AM, Pekka Paalanen ppaala...@gmail.com wrote:

 On Fri, 02 May 2014 19:22:39 +0100
 Neil Roberts n...@linux.intel.com wrote:

  Hi,
 
  Currently Weston has a problem that it always puts new surfaces on the
  same output as the one the first pointer is in. I guess the idea is
  that most of the time surfaces are created as a result of mouse
  events and there is usually only one pointer so it works most of the
  time. However of course this doesn't work if a surface is created by
  a touch event, a keyboard event or an event from a second pointer.
  The problem is mentioned in the following bug report:
 
  https://bugs.freedesktop.org/show_bug.cgi?id=73715
 
  I guess ideally you want the client to explicitly say what output new
  surfaces should appear on because only the client knows which input
  event caused the new surface to be created. We already have
  xdg_shell.set_output which the client could use for this purpose. It
  doesn't look like Weston takes that chosen output into account if the
  surface is not fullscreen or maximised, but perhaps we could change it
  so that it does?
 
  This isn't a complete solution however because when the client first
  connects it doesn't know what event caused its process to be executed
  so it doesn't know which output to put itself on. This is the case
  when panel buttons are used to launch an application from
  desktop-shell. I was thinking that maybe we need a request that
  desktop-shell can make to specify a default output for new surfaces
  from the clients that it launches. To do this I was thinking that
  maybe desktop-shell could make a connection to the compositor on
  behalf of the client, call a request to set the default output and
  then pass the socket down to client using the existing WAYLAND_SOCKET
  mechanism.
 
  That would be an unusual use of WAYLAND_SOCKET because in the other
  cases the socket that is passed down is created with socketpair and is
  not first used for any communication. This would have the effect that
  wl_display_connect_to_fd is called twice on a connected socket.
  However, it doesn't look like any data is sent or any negotiation is
  done when that is called so it might not be a problem.
 
  Doing requests on the connection before passing it down might cause
  the resource ID numbers to get out of sync. However I was thinking
  that if the parent process is careful to destroy any resources that
  it creates before forking the child and if the Wayland protocol
  aggressively reuses IDs then it might reset back to zero anyway and
  it would just work.
 
  I was going to experiment with adding this request as a
  Weston-specific extension unless someone points out why it won't
  work. However, I think this probably shouldn't be Weston-specific
  because normal clients may also want to launch child clients in
  response to an input event and they too will want to do something
  similar.

 Hi,

 I think creating the socket pair in the client that launches another
 client and passes it on in WAYLAND_SOCKET could be the key here. This
 is the lowest-level standard mechanism, as it is implemented in
 libwayland-client.

 However, I don't agree with using the new connection to pre-set the
 stage as you imagined. Doing stuff on a connection and then pretending
 it is a fresh connection for the new client is tedious like you said.

 Instead, we could have an app launcher protocol extension. The
 lancher client, e.g. weston-desktop-shell with the panel buttons,
 creates a socket pair, and passes the server end to the compositor by
 using this new protocol. But it does not have to stop there. The
 protocol could also allow things like setting the default output,
 designating how the new app will be launched, which wl_seat did it,
 etc. Anything the compositor might see as useful. Also, on which
 workspace the new app should appear by default.

 This app launcher extension could be a public interface. After all,
 clients will be able to connect to the socket file, too, so no need to
 restrict this I guess. As a side-effect, it would also allow launching
 a client as a different user by using a suitable launcher tool.

 If the client using the app launcher extension is already privileged,
 there might be a mechanism to pass the authorization on to the new
 client. (Jumping to another topic here. :-)

 The hard part will be designing the app launcher extension. If it is
 a public, generic extension to be in the core, it cannot reference
 xdg_shell or desktop concepts. What things should it have?

  This approach wouldn't help for something like launching 

[PATCH weston] Apply the zoom transformation before the output transformation

[Neil Roberts]

The zoom translation is just a scale and a translate. The translation
is calculated based on the coordinates of the pointer which are in
global space. Previously the calculated translation was transformed by
the output transformation so that when the zoom transform is applied
after the output transform then it will be correct. However if we just
apply the zoom transformation first then we get the same result
without the zoom code having to be aware of the output transformation.

This also fixes weston_output_transform_coordinate which was applying
the output and zoom transforms in the wrong order.

https://bugs.freedesktop.org/show_bug.cgi?id=78211
---
 src/compositor.c |  4 ++--
 src/zoom.c   | 47 ---
 2 files changed, 2 insertions(+), 49 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index 3d65e4c..cd1ca9a 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3198,8 +3198,6 @@ weston_output_update_matrix(struct weston_output *output)
2.0 / output-width,
-2.0 / output-height, 1);
 
-   weston_output_compute_transform(output);
-
if (output-zoom.active) {
magnification = 1 / (1 - output-zoom.spring_z.current);
weston_output_update_zoom(output);
@@ -3209,6 +3207,8 @@ weston_output_update_matrix(struct weston_output *output)
magnification, 1.0);
}
 
+   weston_output_compute_transform(output);
+
output-dirty = 0;
 }
 
diff --git a/src/zoom.c b/src/zoom.c
index 622c0d7..7553849 100644
--- a/src/zoom.c
+++ b/src/zoom.c
@@ -111,50 +111,6 @@ zoom_area_center_from_pointer(struct weston_output *output,
 }
 
 static void
-weston_zoom_apply_output_transform(struct weston_output *output,
-   float *x, float *y)
-{
-   float tx, ty;
-
-   switch(output-transform) {
-   case WL_OUTPUT_TRANSFORM_NORMAL:
-   default:
-   return;
-   case WL_OUTPUT_TRANSFORM_90:
-   tx = -*y;
-   ty = *x;
-   break;
-   case WL_OUTPUT_TRANSFORM_180:
-   tx = -*x;
-   ty = -*y;
-   break;
-   case WL_OUTPUT_TRANSFORM_270:
-   tx = *y;
-   ty = -*x;
-   break;
-   case WL_OUTPUT_TRANSFORM_FLIPPED:
-   tx = -*x;
-   ty = *y;
-   break;
-   case WL_OUTPUT_TRANSFORM_FLIPPED_90:
-   tx = -*y;
-   ty = -*x;
-   break;
-   case WL_OUTPUT_TRANSFORM_FLIPPED_180:
-   tx = *x;
-   ty = -*y;
-   break;
-   case WL_OUTPUT_TRANSFORM_FLIPPED_270:
-   tx = *y;
-   ty = *x;
-   break;
-   }
-
-   *x = tx;
-   *y = ty;
-}
-
-static void
 weston_output_update_zoom_transform(struct weston_output *output)
 {
float global_x, global_y;
@@ -183,9 +139,6 @@ weston_output_update_zoom_transform(struct weston_output 
*output)
global_y - output-y) / output-height) *
(level * 2)) - level) * ratio;
 
-   weston_zoom_apply_output_transform(output, output-zoom.trans_x,
-  output-zoom.trans_y);
-
trans_max = level * 2 - level;
trans_min = -trans_max;
 
-- 
1.9.0

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

[PATCH weston 3/3] compositor-wayland: avoid possible NULL deref in handle_keymap

[U. Artie Eoff]

If data is NULL, then we jumped to error which attempts to
dereference data.  Instead, just close(fd) and return when
data is NULL.

Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com
---
 src/compositor-wayland.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 3cd308f..a08b71a 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1424,8 +1424,10 @@ input_handle_keymap(void *data, struct wl_keyboard 
*keyboard, uint32_t format,
struct xkb_keymap *keymap;
char *map_str;
 
-   if (!data)
-   goto error;
+   if (!data) {
+   close(fd);
+   return;
+   }
 
if (format == WL_KEYBOARD_KEYMAP_FORMAT_XKB_V1) {
map_str = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
-- 
1.9.0

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

[PATCH weston 2/3] compositor-wayland: assign the correct mode

[U. Artie Eoff]

Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com
---
 src/compositor-wayland.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 35e99a6..3cd308f 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1149,7 +1149,7 @@ wayland_output_create_for_parent_output(struct 
wayland_compositor *c,
if (poutput-current_mode) {
mode = poutput-current_mode;
} else if (poutput-preferred_mode) {
-   mode = poutput-current_mode;
+   mode = poutput-preferred_mode;
} else if (!wl_list_empty(poutput-mode_list)) {
mode = container_of(poutput-mode_list.next,
struct weston_mode, link);
-- 
1.9.0

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

[PATCH weston 1/3] compositor-wayland: free output before returning

[U. Artie Eoff]

Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com
---
 src/compositor-wayland.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 67f15be..35e99a6 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1723,8 +1723,11 @@ wayland_compositor_register_output(struct 
wayland_compositor *c, uint32_t id)
output-id = id;
output-global = wl_registry_bind(c-parent.registry, id,
  wl_output_interface, 1);
-   if (!output-global)
+   if (!output-global) {
+   free(output);
return;
+   }
+
wl_output_add_listener(output-global, output_listener, output);
 
output-scale = 0;
-- 
1.9.0

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

Re: [PATCH wayland 2/2] connection-test: check malloc result

[Kristian Høgsberg]

On Mon, May 05, 2014 at 02:45:20PM -0700, U. Artie Eoff wrote:
 Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com

Applied, thanks.

 ---
  tests/connection-test.c | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/tests/connection-test.c b/tests/connection-test.c
 index 1213875..659bf68 100644
 --- a/tests/connection-test.c
 +++ b/tests/connection-test.c
 @@ -516,6 +516,8 @@ TEST(connection_marshal_too_big)
   struct marshal_data data;
   char *big_string = malloc(5000);
  
 + assert(big_string);
 +
   memset(big_string, ' ', 4999);
   big_string[4999] = '\0';
  
 -- 
 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 wayland] server: fix potential memleak and NULL deref

[Kristian Høgsberg]

On Mon, May 05, 2014 at 04:28:26PM -0700, U. Artie Eoff wrote:
 If for some reason that errno is neither value (ENOMEM or
 EINVAL), then prior to this patch, there would be a NULL
 deref in wl_closure_lookup(...) at the else if conditional
 when closure == NULL. Also, closure might not be NULL but still
 fall into the block due to the wl_closure_lookup  0 condition...
 in that case, we need to destroy the closure to avoid a memory
 leak.
 
 Currently, wl_connection_demarshal only sets errno to ENOMEM
 or EINVAL... we've already checked for ENOMEM so remove check
 for EINVAL (just assume it).  Also, call wl_closure_destroy(...)
 unconditionally in the else if block (assume it can handle
 NULL closure, too, which it does right now).

Yup, that looks good, thanks.

Kristian

 
 Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com
 ---
  src/wayland-server.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/src/wayland-server.c b/src/wayland-server.c
 index f2b1b42..e850d48 100644
 --- a/src/wayland-server.c
 +++ b/src/wayland-server.c
 @@ -313,7 +313,7 @@ wl_client_connection_data(int fd, uint32_t mask, void 
 *data)
   if (closure == NULL  errno == ENOMEM) {
   wl_resource_post_no_memory(resource);
   break;
 - } else if ((closure == NULL  errno == EINVAL) ||
 + } else if (closure == NULL ||
  wl_closure_lookup_objects(closure, client-objects) 
  0) {
   wl_resource_post_error(client-display_resource,
  WL_DISPLAY_ERROR_INVALID_METHOD,
 @@ -321,6 +321,7 @@ wl_client_connection_data(int fd, uint32_t mask, void 
 *data)
  object-interface-name,
  object-id,
  message-name);
 + wl_closure_destroy(closure);
   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] doc: Added API documentation for wl_display_create function.

[Kristian Høgsberg]

On Tue, May 06, 2014 at 03:52:12PM +0530, Srivardhan Hebbar wrote:
 Signed-off-by: Srivardhan Hebbar sri.heb...@samsung.com
 ---
  src/wayland-server.c |9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/src/wayland-server.c b/src/wayland-server.c
 index f2b1b42..7b32848 100644
 --- a/src/wayland-server.c
 +++ b/src/wayland-server.c
 @@ -788,6 +788,15 @@ bind_display(struct wl_client *client,
  destroy_client_display_resource);
  }
  
 +/** Create Wayland display object.
 + *
 + * \param None
 + * \return The Wayland display object. Null if failed to create
 + *
 + * This creates the wl_display object for the client.

Thanks for adding documentation for this function.  The display object isn't
specific to any client though, so I wouldn't write for the client.

Kristian

 + *
 + * \memberof wl_display
 + */
  WL_EXPORT struct wl_display *
  wl_display_create(void)
  {
 -- 
 1.7.9.5
 
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] wcap: Check for mmap and malloc return value in wcap decode module

[Kristian Høgsberg]

On Tue, May 06, 2014 at 03:54:49PM +0530, vivek wrote:
 Checking for return value in main.c for wcap_decoder_create function
 and mmap, malloc return value in wcap_decoder_create function to avoid
 crashes

Thanks, that looks better.

Kristian

 Signed-off-by: vivek vivek.el...@samsung.com
 ---
  wcap/main.c|4 
  wcap/wcap-decode.c |9 +
  2 files changed, 13 insertions(+)
 
 diff --git a/wcap/main.c b/wcap/main.c
 index 29bb9c3..16d37f0 100644
 --- a/wcap/main.c
 +++ b/wcap/main.c
 @@ -251,6 +251,10 @@ int main(int argc, char *argv[])
   }
  
   decoder = wcap_decoder_create(argv[1]);
 + if (decoder == NULL) {
 + fprintf(stderr, Creating wcap decoder failed\n);
 + exit(EXIT_FAILURE);
 + }
  
   if (yuv4mpeg2  isatty(1)) {
   fprintf(stderr, Not dumping yuv4mpeg2 data to terminal.  Pipe 
 output to a file or a process.\n);
 diff --git a/wcap/wcap-decode.c b/wcap/wcap-decode.c
 index 87d9337..76ecc2f 100644
 --- a/wcap/wcap-decode.c
 +++ b/wcap/wcap-decode.c
 @@ -126,6 +126,11 @@ wcap_decoder_create(const char *filename)
   decoder-size = buf.st_size;
   decoder-map = mmap(NULL, decoder-size,
   PROT_READ, MAP_PRIVATE, decoder-fd, 0);
 + if (decoder-map == MAP_FAILED) {
 + fprintf(stderr, mmap failed\n);
 + free(decoder);
 + return NULL;
 + }
   
   header = decoder-map;
   decoder-format = header-format;
 @@ -137,6 +142,10 @@ wcap_decoder_create(const char *filename)
  
   frame_size = header-width * header-height * 4;
   decoder-frame = malloc(frame_size);
 + if (decoder-frame == NULL) {
 + free(decoder);
 + return NULL;
 + }
   memset(decoder-frame, 0, frame_size);
  
   return decoder;
 -- 
 1.7.9.5
 
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-web 6/6] xwayland: add xserver build options

[Kristian Høgsberg]

On Tue, May 06, 2014 at 04:25:40PM +0300, Pekka Paalanen wrote:
 From: Pekka Paalanen pekka.paala...@collabora.co.uk
 
 With these, it will only install the Xwayland binary. No Xorg, no
 modules, no cruft. Just 4 files in total here.

Thanks for updating that, all applied.

Kristian

 ---
  xserver.html | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/xserver.html b/xserver.html
 index bd4abb7..dd8ff30 100644
 --- a/xserver.html
 +++ b/xserver.html
 @@ -63,7 +63,9 @@ and is first released with xserver 1.16. The separate X.org 
 video DDXes
  are not needed anymore./p
  pre$ git clone git://anongit.freedesktop.org/xorg/xserver
  $ cd xserver
 -$ ./autogen.sh --prefix=$WLD
 +$ ./autogen.sh --prefix=$WLD --disable-docs --disable-devel-docs \
 +  --enable-xwayland --disable-xorg --disable-xvfb --disable-xnest \
 +  --disable-xquartz --disable-xwin
  $ make
  $ make install
  $ cd ..
 -- 
 1.8.5.5
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] compositor-drm: Don't use vaapi recorder with unsupported formats

[Kristian Høgsberg]

On Tue, May 06, 2014 at 04:49:06PM +0300, Ander Conselvan de Oliveira wrote:
 From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
 
 We only support recording with GBM_FORMAT_XRGB888 format, so don't try
 to record if the output has a differnt format.

That looks good, applied.

Kristian

 
 https://bugs.freedesktop.org/show_bug.cgi?id=78199
 ---
  src/compositor-drm.c | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/src/compositor-drm.c b/src/compositor-drm.c
 index 4441308..5f59789 100644
 --- a/src/compositor-drm.c
 +++ b/src/compositor-drm.c
 @@ -2611,6 +2611,12 @@ recorder_binding(struct weston_seat *seat, uint32_t 
 time, uint32_t key,
 struct drm_output, base.link);
  
   if (!output-recorder) {
 + if (output-format != GBM_FORMAT_XRGB) {
 + weston_log(failed to start vaapi recorder: 
 +output format not supported\n);
 + return;
 + }
 +
   width = output-base.current_mode-width;
   height = output-base.current_mode-height;
  
 -- 
 1.8.3.2
 
 ___
 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] Apply the zoom transformation before the output transformation

[Kristian Høgsberg]

On Tue, May 06, 2014 at 07:04:15PM +0100, Neil Roberts wrote:
 The zoom translation is just a scale and a translate. The translation
 is calculated based on the coordinates of the pointer which are in
 global space. Previously the calculated translation was transformed by
 the output transformation so that when the zoom transform is applied
 after the output transform then it will be correct. However if we just
 apply the zoom transformation first then we get the same result
 without the zoom code having to be aware of the output transformation.
 
 This also fixes weston_output_transform_coordinate which was applying
 the output and zoom transforms in the wrong order.
 
 https://bugs.freedesktop.org/show_bug.cgi?id=78211
 ---
  src/compositor.c |  4 ++--
  src/zoom.c   | 47 ---

I love it:

  2 files changed, 2 insertions(+), 49 deletions(-)

Best bug fix ever.  Thanks, applied.

Kristian
 
 diff --git a/src/compositor.c b/src/compositor.c
 index 3d65e4c..cd1ca9a 100644
 --- a/src/compositor.c
 +++ b/src/compositor.c
 @@ -3198,8 +3198,6 @@ weston_output_update_matrix(struct weston_output 
 *output)
   2.0 / output-width,
   -2.0 / output-height, 1);
  
 - weston_output_compute_transform(output);
 -
   if (output-zoom.active) {
   magnification = 1 / (1 - output-zoom.spring_z.current);
   weston_output_update_zoom(output);
 @@ -3209,6 +3207,8 @@ weston_output_update_matrix(struct weston_output 
 *output)
   magnification, 1.0);
   }
  
 + weston_output_compute_transform(output);
 +
   output-dirty = 0;
  }
  
 diff --git a/src/zoom.c b/src/zoom.c
 index 622c0d7..7553849 100644
 --- a/src/zoom.c
 +++ b/src/zoom.c
 @@ -111,50 +111,6 @@ zoom_area_center_from_pointer(struct weston_output 
 *output,
  }
  
  static void
 -weston_zoom_apply_output_transform(struct weston_output *output,
 - float *x, float *y)
 -{
 - float tx, ty;
 -
 - switch(output-transform) {
 - case WL_OUTPUT_TRANSFORM_NORMAL:
 - default:
 - return;
 - case WL_OUTPUT_TRANSFORM_90:
 - tx = -*y;
 - ty = *x;
 - break;
 - case WL_OUTPUT_TRANSFORM_180:
 - tx = -*x;
 - ty = -*y;
 - break;
 - case WL_OUTPUT_TRANSFORM_270:
 - tx = *y;
 - ty = -*x;
 - break;
 - case WL_OUTPUT_TRANSFORM_FLIPPED:
 - tx = -*x;
 - ty = *y;
 - break;
 - case WL_OUTPUT_TRANSFORM_FLIPPED_90:
 - tx = -*y;
 - ty = -*x;
 - break;
 - case WL_OUTPUT_TRANSFORM_FLIPPED_180:
 - tx = *x;
 - ty = -*y;
 - break;
 - case WL_OUTPUT_TRANSFORM_FLIPPED_270:
 - tx = *y;
 - ty = *x;
 - break;
 - }
 -
 - *x = tx;
 - *y = ty;
 -}
 -
 -static void
  weston_output_update_zoom_transform(struct weston_output *output)
  {
   float global_x, global_y;
 @@ -183,9 +139,6 @@ weston_output_update_zoom_transform(struct weston_output 
 *output)
   global_y - output-y) / output-height) *
   (level * 2)) - level) * ratio;
  
 - weston_zoom_apply_output_transform(output, output-zoom.trans_x,
 -output-zoom.trans_y);
 -
   trans_max = level * 2 - level;
   trans_min = -trans_max;
  
 -- 
 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 3/3] compositor-wayland: avoid possible NULL deref in handle_keymap

[Kristian Høgsberg]

On Tue, May 06, 2014 at 02:50:03PM -0700, U. Artie Eoff wrote:
 If data is NULL, then we jumped to error which attempts to
 dereference data.  Instead, just close(fd) and return when
 data is NULL.
 
 Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com

All three look good, applied.

Kristian

 ---
  src/compositor-wayland.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
 index 3cd308f..a08b71a 100644
 --- a/src/compositor-wayland.c
 +++ b/src/compositor-wayland.c
 @@ -1424,8 +1424,10 @@ input_handle_keymap(void *data, struct wl_keyboard 
 *keyboard, uint32_t format,
   struct xkb_keymap *keymap;
   char *map_str;
  
 - if (!data)
 - goto error;
 + if (!data) {
 + close(fd);
 + return;
 + }
  
   if (format == WL_KEYBOARD_KEYMAP_FORMAT_XKB_V1) {
   map_str = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
 -- 
 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

[PATCH] clients: Initialize label in keyboard handling code

[Bryce W. Harrington]

Quells warning:
  clients/keyboard.c: In function ‘keyboard_handle_key.isra.5’:
  clients/keyboard.c:556:11: warning: ‘label’ may be used uninitialized in
  this function [-Wuninitialized]

Signed-off-by: Bryce Harrington b.harring...@samsung.com
---
 clients/keyboard.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/keyboard.c b/clients/keyboard.c
index cd1ad58..7c11cec 100644
--- a/clients/keyboard.c
+++ b/clients/keyboard.c
@@ -530,7 +530,7 @@ append(char *s1, const char *s2)
 static void
 keyboard_handle_key(struct keyboard *keyboard, uint32_t time, const struct key 
*key, struct input *input, enum wl_pointer_button_state state)
 {
-   const char *label;
+   const char *label = NULL;
 
switch(keyboard-state) {
case KEYBOARD_STATE_DEFAULT :
-- 
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 3/5] clients: Use calloc instead of malloc/memset=0

[Bryce W. Harrington]

Signed-off-by: Bryce Harrington b.harring...@samsung.com
---
 clients/editor.c  |4 +---
 clients/subsurfaces.c |8 ++--
 clients/window.c  |   13 ++---
 3 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/clients/editor.c b/clients/editor.c
index 6ed76d4..b439d9e 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -559,9 +559,7 @@ text_entry_create(struct editor *editor, const char *text)
 {
struct text_entry *entry;
 
-   entry = xmalloc(sizeof *entry);
-   memset(entry, 0, sizeof *entry);
-
+   entry = xcalloc(1, sizeof *entry);
entry-widget = widget_add_widget(editor-widget, entry);
entry-window = editor-window;
entry-text = strdup(text);
diff --git a/clients/subsurfaces.c b/clients/subsurfaces.c
index 15af9aa..a683787 100644
--- a/clients/subsurfaces.c
+++ b/clients/subsurfaces.c
@@ -492,9 +492,7 @@ triangle_create(struct window *window, struct egl_state 
*egl)
 {
struct triangle *tri;
 
-   tri = xmalloc(sizeof *tri);
-   memset(tri, 0, sizeof *tri);
-
+   tri = xcalloc(1, sizeof *tri);
tri-egl = egl;
tri-widget = window_add_subsurface(window, tri,
int_to_mode(option_triangle_mode));
@@ -714,9 +712,7 @@ demoapp_create(struct display *display)
 {
struct demoapp *app;
 
-   app = xmalloc(sizeof *app);
-   memset(app, 0, sizeof *app);
-
+   app = xcalloc(1, sizeof *app);
app-egl = egl_state_create(display_get_display(display));
 
app-display = display;
diff --git a/clients/window.c b/clients/window.c
index cfc1260..2212351 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -1139,12 +1139,7 @@ shm_surface_create(struct display *display, struct 
wl_surface *wl_surface,
struct shm_surface *surface;
DBG_OBJ(wl_surface, \n);
 
-   surface = xmalloc(sizeof *surface);
-   memset(surface, 0, sizeof *surface);
-
-   if (!surface)
-   return NULL;
-
+   surface = xcalloc(1, sizeof *surface);
surface-base.prepare = shm_surface_prepare;
surface-base.swap = shm_surface_swap;
surface-base.acquire = shm_surface_acquire;
@@ -4336,11 +4331,7 @@ surface_create(struct window *window)
struct display *display = window-display;
struct surface *surface;
 
-   surface = xmalloc(sizeof *surface);
-   memset(surface, 0, sizeof *surface);
-   if (!surface)
-   return NULL;
-
+   surface = xcalloc(1, sizeof *surface);
surface-window = window;
surface-surface = wl_compositor_create_surface(display-compositor);
surface-buffer_scale = 1;
-- 
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 0/5] clients: Use the x*alloc routines

[Bryce W. Harrington]

As per our discussion last week, here's patches to convert client code
to using xmalloc, xzalloc, xcalloc, and xstrdup where appropriate.

I opted not to change nested.c, because it looked like errors were being
propagated to a higher level for handling, and bombing out on OOM might
not be desired?

Other files like glmatrix.c, screenshot.c, simple-*.c weston-info.c,
etc. did not include window.h, so I left them unchanged.  If you think
these should also be changed over, I could move the x*alloc() functions
to xalloc.[ch] to allow sharing.

Bryce Harrington (5):
  clients: Add xcalloc
  clients: Use x*alloc routines for memory allocation
  clients: Use calloc instead of malloc/memset=0
  clients: Use xzalloc instead of xcalloc when allocating single
element
  clients:  Use xstrdup instead of strdup

 clients/calibrator.c|5 +
 clients/desktop-shell.c |5 +
 clients/dnd.c   |8 ++--
 clients/editor.c|   20 +---
 clients/eventdemo.c |5 +
 clients/fullscreen.c|2 +-
 clients/gears.c |2 +-
 clients/image.c |8 +++-
 clients/keyboard.c  |   12 ++--
 clients/smoke.c |   12 ++--
 clients/subsurfaces.c   |   12 +++-
 clients/terminal.c  |2 +-
 clients/window.c|   21 ++---
 clients/window.h|2 ++
 clients/wscreensaver-glue.c |8 ++--
 clients/wscreensaver.c  |   14 +++---
 16 files changed, 52 insertions(+), 86 deletions(-)

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

[PATCH 2/5] clients: Use x*alloc routines for memory allocation

[Bryce W. Harrington]

Since these are all demo client programs, program termination is an
appropriate response to an out-of-memory situation.  Using these
routines keeps the client code more concise.

Signed-off-by: Bryce Harrington b.harring...@samsung.com
---
 clients/calibrator.c|5 +
 clients/desktop-shell.c |5 +
 clients/dnd.c   |8 ++--
 clients/editor.c|4 ++--
 clients/eventdemo.c |5 +
 clients/fullscreen.c|2 +-
 clients/gears.c |2 +-
 clients/image.c |4 +---
 clients/smoke.c |   12 ++--
 clients/subsurfaces.c   |4 +---
 clients/wscreensaver-glue.c |8 ++--
 clients/wscreensaver.c  |   14 +++---
 12 files changed, 22 insertions(+), 51 deletions(-)

diff --git a/clients/calibrator.c b/clients/calibrator.c
index 1eb117f..67ee70e 100644
--- a/clients/calibrator.c
+++ b/clients/calibrator.c
@@ -222,10 +222,7 @@ calibrator_create(struct display *display)
 {
struct calibrator *calibrator;
 
-   calibrator = malloc(sizeof *calibrator);
-   if (calibrator == NULL)
-   return NULL;
-
+   calibrator = xmalloc(sizeof *calibrator);
calibrator-window = window_create(display);
calibrator-widget = window_add_widget(calibrator-window, calibrator);
window_set_title(calibrator-window, Wayland calibrator);
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 4880888..a3b2534 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -1217,10 +1217,7 @@ create_output(struct desktop *desktop, uint32_t id)
 {
struct output *output;
 
-   output = calloc(1, sizeof *output);
-   if (!output)
-   return;
-
+   output = xcalloc(1, sizeof *output);
output-output =
display_bind(desktop-display, id, wl_output_interface, 2);
output-server_output_id = id;
diff --git a/clients/dnd.c b/clients/dnd.c
index a463d6f..989e5ab 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -92,15 +92,11 @@ item_create(struct display *display, int x, int y, int seed)
struct item *item;
struct timeval tv;
 
-   item = malloc(sizeof *item);
-   if (item == NULL)
-   return NULL;
-   
-   
+   item = xmalloc(sizeof *item);
gettimeofday(tv, NULL);
item-seed = seed ? seed : tv.tv_usec;
srandom(item-seed);
-   
+
const int petal_count = 3 + random() % 5;
const double r1 = 20 + random() % 10;
const double r2 = 5 + random() % 12;
diff --git a/clients/editor.c b/clients/editor.c
index 3b00833..6ed76d4 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -682,7 +682,7 @@ text_entry_update_layout(struct text_entry *entry)
   (entry-preedit.text ? strlen(entry-preedit.text) : 0)));
 
if (entry-preedit.text) {
-   text = malloc(strlen(entry-text) + strlen(entry-preedit.text) 
+ 1);
+   text = xmalloc(strlen(entry-text) + 
strlen(entry-preedit.text) + 1);
strncpy(text, entry-text, entry-cursor);
strcpy(text + entry-cursor, entry-preedit.text);
strcpy(text + entry-cursor + strlen(entry-preedit.text),
@@ -764,7 +764,7 @@ static void
 text_entry_insert_at_cursor(struct text_entry *entry, const char *text,
int32_t cursor, int32_t anchor)
 {
-   char *new_text = malloc(strlen(entry-text) + strlen(text) + 1);
+   char *new_text = xmalloc(strlen(entry-text) + strlen(text) + 1);
 
strncpy(new_text, entry-text, entry-cursor);
strcpy(new_text + entry-cursor, text);
diff --git a/clients/eventdemo.c b/clients/eventdemo.c
index 5ec6829..d12ec4b 100644
--- a/clients/eventdemo.c
+++ b/clients/eventdemo.c
@@ -297,10 +297,7 @@ eventdemo_create(struct display *d)
 {
struct eventdemo *e;
 
-   e = malloc(sizeof (struct eventdemo));
-   if(e == NULL)
-   return NULL;
-
+   e = xmalloc(sizeof (struct eventdemo));
e-window = window_create(d);
 
if (noborder) {
diff --git a/clients/fullscreen.c b/clients/fullscreen.c
index fa8028a..ad7c703 100644
--- a/clients/fullscreen.c
+++ b/clients/fullscreen.c
@@ -480,7 +480,7 @@ output_handler(struct output *output, void *data)
if (fsout-output == output)
return;
 
-   fsout = calloc(1, sizeof *fsout);
+   fsout = xcalloc(1, sizeof *fsout);
fsout-output = output;
wl_list_insert(fullscreen-output_list, fsout-link);
 }
diff --git a/clients/gears.c b/clients/gears.c
index 93a86b4..cfba30a 100644
--- a/clients/gears.c
+++ b/clients/gears.c
@@ -401,7 +401,7 @@ gears_create(struct display *display)
struct timeval tv;
int i;
 
-   gears = zalloc(sizeof *gears);
+   gears = xzalloc(sizeof *gears);
gears-d = display;
gears-window = window_create(display);
gears-widget 

[PATCH 4/5] clients: Use xzalloc instead of xcalloc when allocating single element

[Bryce W. Harrington]

Signed-off-by: Bryce Harrington b.harring...@samsung.com
---
 clients/desktop-shell.c |2 +-
 clients/editor.c|2 +-
 clients/fullscreen.c|2 +-
 clients/subsurfaces.c   |6 +++---
 clients/window.c|4 ++--
 clients/wscreensaver.c  |2 +-
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index a3b2534..0b8d08b 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -1217,7 +1217,7 @@ create_output(struct desktop *desktop, uint32_t id)
 {
struct output *output;
 
-   output = xcalloc(1, sizeof *output);
+   output = xzalloc(sizeof *output);
output-output =
display_bind(desktop-display, id, wl_output_interface, 2);
output-server_output_id = id;
diff --git a/clients/editor.c b/clients/editor.c
index b439d9e..bda3e91 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -559,7 +559,7 @@ text_entry_create(struct editor *editor, const char *text)
 {
struct text_entry *entry;
 
-   entry = xcalloc(1, sizeof *entry);
+   entry = xzalloc(sizeof *entry);
entry-widget = widget_add_widget(editor-widget, entry);
entry-window = editor-window;
entry-text = strdup(text);
diff --git a/clients/fullscreen.c b/clients/fullscreen.c
index ad7c703..8f41455 100644
--- a/clients/fullscreen.c
+++ b/clients/fullscreen.c
@@ -480,7 +480,7 @@ output_handler(struct output *output, void *data)
if (fsout-output == output)
return;
 
-   fsout = xcalloc(1, sizeof *fsout);
+   fsout = xzalloc(sizeof *fsout);
fsout-output = output;
wl_list_insert(fullscreen-output_list, fsout-link);
 }
diff --git a/clients/subsurfaces.c b/clients/subsurfaces.c
index a683787..1ed698b 100644
--- a/clients/subsurfaces.c
+++ b/clients/subsurfaces.c
@@ -212,7 +212,7 @@ egl_state_create(struct wl_display *display)
EGLint major, minor, n;
EGLBoolean ret;
 
-   egl = xcalloc(1, sizeof *egl);
+   egl = xzalloc(sizeof *egl);
egl-dpy = eglGetDisplay(display);
assert(egl-dpy);
 
@@ -492,7 +492,7 @@ triangle_create(struct window *window, struct egl_state 
*egl)
 {
struct triangle *tri;
 
-   tri = xcalloc(1, sizeof *tri);
+   tri = xzalloc(sizeof *tri);
tri-egl = egl;
tri-widget = window_add_subsurface(window, tri,
int_to_mode(option_triangle_mode));
@@ -712,7 +712,7 @@ demoapp_create(struct display *display)
 {
struct demoapp *app;
 
-   app = xcalloc(1, sizeof *app);
+   app = xzalloc(sizeof *app);
app-egl = egl_state_create(display_get_display(display));
 
app-display = display;
diff --git a/clients/window.c b/clients/window.c
index 2212351..a103530 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -1139,7 +1139,7 @@ shm_surface_create(struct display *display, struct 
wl_surface *wl_surface,
struct shm_surface *surface;
DBG_OBJ(wl_surface, \n);
 
-   surface = xcalloc(1, sizeof *surface);
+   surface = xzalloc(sizeof *surface);
surface-base.prepare = shm_surface_prepare;
surface-base.swap = shm_surface_swap;
surface-base.acquire = shm_surface_acquire;
@@ -4331,7 +4331,7 @@ surface_create(struct window *window)
struct display *display = window-display;
struct surface *surface;
 
-   surface = xcalloc(1, sizeof *surface);
+   surface = xzalloc(sizeof *surface);
surface-window = window;
surface-surface = wl_compositor_create_surface(display-compositor);
surface-buffer_scale = 1;
diff --git a/clients/wscreensaver.c b/clients/wscreensaver.c
index 1070c07..d87d040 100644
--- a/clients/wscreensaver.c
+++ b/clients/wscreensaver.c
@@ -175,7 +175,7 @@ create_wscreensaver_instance(struct wscreensaver 
*screensaver,
struct ModeInfo *mi;
struct rectangle drawarea;
 
-   mi = xcalloc(1, sizeof *mi);
+   mi = xzalloc(sizeof *mi);
 
if (demo_mode)
mi-window = window_create(screensaver-display);
-- 
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 5/5] clients: Use xstrdup instead of strdup

[Bryce W. Harrington]

Signed-off-by: Bryce Harrington b.harring...@samsung.com
---
 clients/editor.c   |   12 ++--
 clients/image.c|4 ++--
 clients/keyboard.c |   12 ++--
 clients/terminal.c |2 +-
 4 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/clients/editor.c b/clients/editor.c
index bda3e91..ece8b1d 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -258,7 +258,7 @@ text_input_preedit_string(void *data,
}
 
text_entry_set_preedit(entry, text, entry-preedit_info.cursor);
-   entry-preedit.commit = strdup(commit);
+   entry-preedit.commit = xstrdup(commit);
entry-preedit.attr_list = 
pango_attr_list_ref(entry-preedit_info.attr_list);
 
clear_pending_preedit(entry);
@@ -562,7 +562,7 @@ text_entry_create(struct editor *editor, const char *text)
entry = xzalloc(sizeof *entry);
entry-widget = widget_add_widget(editor-widget, entry);
entry-window = editor-window;
-   entry-text = strdup(text);
+   entry-text = xstrdup(text);
entry-active = 0;
entry-cursor = strlen(text);
entry-anchor = entry-cursor;
@@ -686,7 +686,7 @@ text_entry_update_layout(struct text_entry *entry)
strcpy(text + entry-cursor + strlen(entry-preedit.text),
   entry-text + entry-cursor);
} else {
-   text = strdup(entry-text);
+   text = xstrdup(entry-text);
}
 
if (entry-cursor != entry-anchor) {
@@ -809,7 +809,7 @@ text_entry_commit_and_reset(struct text_entry *entry)
char *commit = NULL;
 
if (entry-preedit.commit)
-   commit = strdup(entry-preedit.commit);
+   commit = xstrdup(entry-preedit.commit);
 
text_entry_reset_preedit(entry);
if (commit) {
@@ -832,7 +832,7 @@ text_entry_set_preedit(struct text_entry *entry,
if (!preedit_text)
return;
 
-   entry-preedit.text = strdup(preedit_text);
+   entry-preedit.text = xstrdup(preedit_text);
entry-preedit.cursor = preedit_cursor;
 
text_entry_update_layout(entry);
@@ -1345,7 +1345,7 @@ main(int argc, char *argv[])
editor.entry = text_entry_create(editor, Entry);
editor.entry-click_to_show = click_to_show;
if (preferred_language)
-   editor.entry-preferred_language = strdup(preferred_language);
+   editor.entry-preferred_language = xstrdup(preferred_language);
editor.editor = text_entry_create(editor, Numeric);
editor.editor-content_purpose = WL_TEXT_INPUT_CONTENT_PURPOSE_NUMBER;
editor.editor-click_to_show = click_to_show;
diff --git a/clients/image.c b/clients/image.c
index cba68c5..b4a7bb8 100644
--- a/clients/image.c
+++ b/clients/image.c
@@ -362,12 +362,12 @@ image_create(struct display *display, const char 
*filename,
 
image = xzalloc(sizeof *image);
 
-   copy = strdup(filename);
+   copy = xstrdup(filename);
b = basename(copy);
snprintf(title, sizeof title, Wayland Image - %s, b);
free(copy);
 
-   image-filename = strdup(filename);
+   image-filename = xstrdup(filename);
image-image = load_cairo_surface(filename);
 
if (!image-image) {
diff --git a/clients/keyboard.c b/clients/keyboard.c
index cd1ad58..6b1e7a0 100644
--- a/clients/keyboard.c
+++ b/clients/keyboard.c
@@ -440,12 +440,12 @@ virtual_keyboard_commit_preedit(struct virtual_keyboard 
*keyboard)
keyboard-surrounding_text = surrounding_text;
keyboard-surrounding_cursor += 
strlen(keyboard-preedit_string);
} else {
-   keyboard-surrounding_text = strdup(keyboard-preedit_string);
+   keyboard-surrounding_text = xstrdup(keyboard-preedit_string);
keyboard-surrounding_cursor = strlen(keyboard-preedit_string);
}
 
free(keyboard-preedit_string);
-   keyboard-preedit_string = strdup();
+   keyboard-preedit_string = xstrdup();
 }
 
 static void
@@ -757,7 +757,7 @@ handle_surrounding_text(void *data,
struct virtual_keyboard *keyboard = data;
 
free(keyboard-surrounding_text);
-   keyboard-surrounding_text = strdup(text);
+   keyboard-surrounding_text = xstrdup(text);
 
keyboard-surrounding_cursor = cursor;
 }
@@ -772,7 +772,7 @@ handle_reset(void *data,
 
if (strlen(keyboard-preedit_string)) {
free(keyboard-preedit_string);
-   keyboard-preedit_string = strdup();
+   keyboard-preedit_string = xstrdup();
}
 }
 
@@ -840,7 +840,7 @@ handle_preferred_language(void *data,
keyboard-preferred_language = NULL;
 
if (language)
-   keyboard-preferred_language = strdup(language);
+   keyboard-preferred_language = xstrdup(language);
 }
 
 static const struct wl_input_method_context_listener 
input_method_context_listener = {
@@ -869,7 +869,7 @@ input_method_activate(void *data,
 

[PATCH 1/5] clients: Add xcalloc

[Bryce W. Harrington]

Signed-off-by: Bryce Harrington b.harring...@samsung.com
---
 clients/window.c |8 
 clients/window.h |2 ++
 2 files changed, 10 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index f12ce39..cfc1260 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -5647,3 +5647,11 @@ xrealloc(char *p, size_t s)
 {
return fail_on_null(realloc(p, s));
 }
+
+void *
+xcalloc(size_t n, size_t s)
+{
+   if (n == 0 || s == 0)
+   return NULL;
+   return fail_on_null(calloc(n, s));
+}
diff --git a/clients/window.h b/clients/window.h
index 4e4ccc1..40989ba 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -65,6 +65,8 @@ char *
 xstrdup(const char *s);
 void *
 xrealloc(char *p, size_t s);
+void *
+xcalloc(size_t n, size_t s);
 
 struct display *
 display_create(int *argc, char *argv[]);
-- 
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

More build problems: dri2proto

[Bill Spitzak]

Okay, I am trying to build wayland again, from instructions, on a new 
machine.


I am stuck trying to compile mesa:

./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl 
--with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi 
  --with-gallium-drivers=r300,r600,swrast,nouveau

...
checking for DRI2PROTO... no
configure: error: Package requirements (dri2proto = 2.6) were not met:

No package 'dri2proto' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables DRI2PROTO_CFLAGS
and DRI2PROTO_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.


I have downloaded dri2proto from git and did configure + make install. 
The pkgconfig file is there:


$ more $WLD/lib/pkgconfig/dri2proto.pc
prefix=/home/wspitzak/install
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: DRI2Proto
Description: DRI2 extension headers
Version: 2.8
Cflags: -I${includedir}

Also very similar instructions made glproto work.

I tried setting DRI2PROTO_CFLAGS and it did not help any.

Anybody know what is going on?

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

[PATCH 0/2] weston: Add touch support to nested wayland backend

[Boyan Ding]

The following two patches add touch support to weston's nested wayland
backend to facilitate testing. The first one adds motion support to
cairo-util and the second actually add the touch listeners in the
compositor.

I'm new to wayland and weston and this is my first work. So any advice
is welcomed.

Boyan Ding (2):
  cairo-util: Add frame_touch_motion support
  compositor-wayland: Add touch support

 shared/cairo-util.h  |  3 ++
 shared/frame.c   | 24 
 src/compositor-wayland.c | 95 
 3 files changed, 122 insertions(+)

-- 
1.9.2


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

[PATCH 1/2] cairo-util: Add frame_touch_motion support

[Boyan Ding]

---
 shared/cairo-util.h |  3 +++
 shared/frame.c  | 24 
 2 files changed, 27 insertions(+)

diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 4493b0d..7aebb65 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -211,6 +211,9 @@ void
 frame_touch_up(struct frame *frame, void *data, int32_t id);
 
 void
+frame_touch_motion(struct frame *frame, void *data, int32_t id, int x, int y);
+
+void
 frame_repaint(struct frame *frame, cairo_t *cr);
 
 #endif
diff --git a/shared/frame.c b/shared/frame.c
index 35e6b65..df51eca 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -837,6 +837,30 @@ frame_touch_up(struct frame *frame, void *data, int32_t id)
 }
 
 void
+frame_touch_motion(struct frame *frame, void *data, int32_t id, int x, int y)
+{
+   struct frame_touch *touch = frame_touch_get(frame, data);
+   struct frame_button *button = frame_find_button(frame, x, y);
+
+   if (id  0 || !touch)
+   return;
+
+   touch-x = x;
+   touch-y = y;
+
+   if (touch-button == button)
+   return ;
+
+   if (touch-button)
+   frame_button_release(touch-button);
+
+   touch-button = button;
+
+   if (touch-button)
+   frame_button_press(touch-button);
+}
+
+void
 frame_repaint(struct frame *frame, cairo_t *cr)
 {
struct frame_button *button;
-- 
1.9.2


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

[PATCH 2/2] compositor-wayland: Add touch support

[Boyan Ding]

Adding touch support to weston's nested wayland backend to make testing
easier.

https://bugs.freedesktop.org/show_bug.cgi?id=77769
---
 src/compositor-wayland.c | 95 
 1 file changed, 95 insertions(+)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index a08b71a..45040d4 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1582,6 +1582,91 @@ static const struct wl_keyboard_listener 
keyboard_listener = {
 };
 
 static void
+input_handle_touch_down(void *data, struct wl_touch *touch, uint32_t serial,
+   uint32_t time, struct wl_surface *surface, int32_t id,
+   wl_fixed_t x, wl_fixed_t y)
+{
+   struct wayland_input *input = data;
+   int32_t fx, fy;
+
+   if (input-output-frame) {
+   frame_touch_down(input-output-frame, input, id,
+wl_fixed_to_int(x), wl_fixed_to_int(y));
+   frame_interior(input-output-frame, fx, fy, NULL, NULL);
+   x -= wl_fixed_from_int(fx);
+   y -= wl_fixed_from_int(fy);
+
+   if (frame_status(input-output-frame)  FRAME_STATUS_REPAINT)
+   weston_output_schedule_repaint(input-output-base);
+   }
+
+   weston_output_transform_coordinate(input-output-base, x, y, x, y);
+
+   notify_touch(input-base, time, id, x, y, WL_TOUCH_DOWN);
+}
+
+static void
+input_handle_touch_up(void *data, struct wl_touch *touch, uint32_t serial,
+ uint32_t time, int32_t id)
+{
+   struct wayland_input *input = data;
+
+   if (input-output-frame) {
+   frame_touch_up(input-output-frame, input, id);
+
+   if (frame_status(input-output-frame)  FRAME_STATUS_REPAINT)
+   weston_output_schedule_repaint(input-output-base);
+   }
+
+   notify_touch(input-base, time, id, 0, 0, WL_TOUCH_UP);
+}
+
+static void
+input_handle_touch_motion(void *data, struct wl_touch *touch, uint32_t time,
+ int32_t id, wl_fixed_t x, wl_fixed_t y)
+{
+   struct wayland_input *input = data;
+   int32_t fx, fy;
+
+   if (input-output-frame) {
+   frame_touch_motion(input-output-frame, input, id,
+wl_fixed_to_int(x), wl_fixed_to_int(y));
+
+   frame_interior(input-output-frame, fx, fy, NULL, NULL);
+   x -= wl_fixed_from_int(fx);
+   y -= wl_fixed_from_int(fy);
+
+   if (frame_status(input-output-frame)  FRAME_STATUS_REPAINT)
+   weston_output_schedule_repaint(input-output-base);
+   }
+
+   weston_output_transform_coordinate(input-output-base, x, y, x, y);
+
+   notify_touch(input-base, time, id, x, y, WL_TOUCH_MOTION);
+}
+
+static void
+input_handle_touch_frame(void *data, struct wl_touch *touch)
+{
+   struct wayland_input *input = data;
+
+   notify_touch_frame(input-base);
+}
+
+static void
+input_handle_touch_cancel(void *data, struct wl_touch *touch)
+{
+}
+
+static const struct wl_touch_listener touch_listener = {
+   input_handle_touch_down,
+   input_handle_touch_up,
+   input_handle_touch_motion,
+   input_handle_touch_frame,
+   input_handle_touch_cancel
+};
+
+static void
 input_handle_capabilities(void *data, struct wl_seat *seat,
  enum wl_seat_capability caps)
 {
@@ -1607,6 +1692,16 @@ input_handle_capabilities(void *data, struct wl_seat 
*seat,
wl_keyboard_destroy(input-parent.keyboard);
input-parent.keyboard = NULL;
}
+
+   if ((caps  WL_SEAT_CAPABILITY_TOUCH)  !input-parent.touch) {
+   input-parent.touch = wl_seat_get_touch(seat);
+   wl_touch_set_user_data(input-parent.touch, input);
+   wl_touch_add_listener(input-parent.touch,
+touch_listener, input);
+   } else if (!(caps  WL_SEAT_CAPABILITY_TOUCH)  input-parent.touch) {
+   wl_touch_destroy(input-parent.touch);
+   input-parent.touch = NULL;
+   }
 }
 
 static const struct wl_seat_listener seat_listener = {
-- 
1.9.2


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

RE: [Weston] More discussion about weston output relative motion algorithm

[Wang, Quanxian]

Thanks Pq's comment. Before you continue my comment, I mentioned one point.
This is output movement algorithm and it is completely different with 
pre-configuration of output in weston.ini.
For output, no alive, no movement.
If you want to keep pre-configuration in weston.ini when output change, just 
keep it in some place and follow it when pre-defined output is plugged or 
unplugged. But anyway, it is a static configuration.  It is conflict with 
dynamic output movement.

Currently in my weston randr's patches has provided an interface to put your 
configure requests into one file. 

 -Original Message-
 From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org]
 On Behalf Of Pekka Paalanen
 Sent: Tuesday, May 6, 2014 5:16 PM
 To: Wang, Quanxian
 Cc: Hardening (rdp.eff...@gmail.com); Bryce W. Harrington
 (b.harring...@samsung.com); wayland-devel@lists.freedesktop.org; Jason
 Ekstrand (ja...@jlekstrand.net); Kang, Jeong Seok; Fu, Michael
 Subject: Re: [Weston] More discussion about weston output relative motion
 algorithm
 
 On Tue, 6 May 2014 07:26:32 +
 Wang, Quanxian quanxian.w...@intel.com wrote:
 
 
 
   -Original Message-
   From: Pekka Paalanen [mailto:ppaala...@gmail.com]
   Sent: Tuesday, May 6, 2014 2:36 PM
   To: Wang, Quanxian
   Cc: wayland-devel@lists.freedesktop.org; Jason Ekstrand
   (ja...@jlekstrand.net); Bryce W. Harrington
   (b.harring...@samsung.com); Fu, Michael; Hardening
   (rdp.eff...@gmail.com); Kang, Jeong Seok Subject: Re: [Weston] More
   discussion about weston output relative motion algorithm
  
   On Wed, 16 Apr 2014 04:21:46 +
   Wang, Quanxian quanxian.w...@intel.com wrote:
  
Clear some definition for easy understanding.
Supposed B is beside A. B maybe leftof, rightof, above, or below
A. If leftof,  output(B) is the horizontal parent of A.
If above, output(B) is the vertical parent of A.
If rightof, output(B) is the horizontal child of A.
If below, output(B) is the vertical child of A.
   
With definition, you will be easy to set up a binary tree. But you
may think some node may have two parent. The answer is no, you can
have a try to move and will find it is right. Just let you know my
mistakes I ever made. When you move output to be leftof or above
of another, the output will take the place of another instead of
really above or left of the position of another. :) After that,
you will be know why one node has  one parent at most.
   
Of course, the original layout will be one horizontal line for
extended mode.
   
If clone mode is supported, that is fine. Keep clone link for that
in output structure. The algorithm will be updated with minimal.
But it will be easy and based on clone mode design.
  
   Hi,
  
   I have nothing against an algorithm for placing outputs in Weston,
   and it would fit Weston core. I think we would like to support all
   kinds of layouts based on weston.ini alone, even without any dynamic
   configuration like your proposed protocol extension.
  
   However, from your algorithm description, I am not sure how it'll
   work for hotplug or hot-unplug.
  [Wang, Quanxian] The algorithm will process all dynamic layout change.
  If you hotplug, just add one output into the tree, just call
  enable_node(A), supposed you hot-plug A. The initial design is
  inserted it into tail of master's hlink. (master is at (0,0)). When
  you hot-unplug, that means you delete this output from the tree.
  Following the algorithm, just call delete_node(A), supposed you
  hot-unplug A. the detail algorithm, you can refer to the disable_node
  algorithm in V4.  The order to take its place is clone link,
  horizontal link and vertical link. (If no clink, then hlink, still no,
  vlink) In file module/wrandr/randr_layout_algorithm.h 115  *
  Disable Node Rules: 116  * 1) The node is deleted and the place
  is replaced by others. 117  * 2) The order to take the place of
  parent: 118  *clink, hlink and then vlink. 119  * Others
  are the same as clean_node.
  
   Let's imagine a physical setting of four monitors, arranged like
   this:
  
   ┌───┬───┐
   │ A │ B │
   ├───┼───┤
   │ C │ D │
   └───┴───┘
  
   That is a 2x2 grid.
 
 Hi,
 
 each question I made was independent, and supposed to start from this
 particulat setup. Not as a sequence of operations, but always starting with
 this.
[Wang, Quanxian] you expected it in pre-configuration. The algorithm is 
designed for output alive. For output, no alive, no movement.
 
  
   There are two ways to represent this in your tree structure, I
   believe:
  
   A.hlink - B
   A.vlink - C
   C.hlink - D
  
   or
  
   A.hlink - B
   A.vlink - C
   B.vlink - D
  
  [Wang, Quanxian] Firstly, you imagine the grid. But from the very
  beginning,  C is not present. You can do like this. a) Initial status
  ┌───┬───┐  │ A │ B │  ├───┼───┤
   │ │ D │
   └───┴───┘
   b) hot-plugged C and move C below 

[PATCH v2] doc: Added API documentation for wl_display_create function.

[Srivardhan Hebbar]

Signed-off-by: Srivardhan Hebbar sri.heb...@samsung.com
---
 src/wayland-server.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index f2b1b42..57b65ce 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -788,6 +788,15 @@ bind_display(struct wl_client *client,
   destroy_client_display_resource);
 }
 
+/** Create Wayland display object.
+ *
+ * \param None
+ * \return The Wayland display object. Null if failed to create
+ *
+ * This creates the wl_display object.
+ *
+ * \memberof wl_display
+ */
 WL_EXPORT struct wl_display *
 wl_display_create(void)
 {
-- 
1.7.9.5

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

RE: New to Wayland, Need suggestion on a starting point

[Srivardhan]

 -Original Message-
 From: wayland-devel [mailto:wayland-devel-
 boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen
 Sent: Tuesday, May 06, 2014 5:22 PM
 To: Srivardhan
 Cc: 'Jason Ekstrand'; wayland-devel@lists.freedesktop.org
 Subject: Re: New to Wayland, Need suggestion on a starting point
 
 On Tue, 06 May 2014 17:09:56 +0530
 Srivardhan sri.heb...@samsung.com wrote:
 
  Sorry, I did not understand it properly. It's not that it is boring.
  :) Is the program like a snooper which captures all the packets of
  Wayland server and Wayland client?
 
 A man-in-the-middle, to be more precise, but yes.
 

Got it... will start my Wayland journey with Protocol dumper... :)

Thank-you,
Hebbar
 
 Thanks,
 pq
 ___
 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