Re: [Weston] More discussion about weston output relative motion algorithm
On Wed, 7 May 2014 03:26:56 + Wang, Quanxian quanxian.w...@intel.com wrote: 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. Of course it is, but users expect both to work at the same time, not have an option to choose between dynamic and static configuration. They want to configure what the dynamic code will do on hotplug, hence these two cases are inseparable. The weston-randr protocol could be seen as a way to modify the static configuration in-memory and then trigger a re-layout. Btw. there is no reason to avoid negative global coordinates. If you have output A at 0,0 and add output B to the left of it, it is perfectly valid to put B at -widthB,0. You *can* add to the left or above without moving all the existing outputs. Also nothing says that you have to have an output with origin at 0,0. (There may be bugs, but that is all.) If you haven't, and I certainly have not, you really should study how existing monitor layout algorithms work. Do not set out to replicate them as is, but find out how they solve the problems and whether those solutions would be applicable here. For getting this work forward and upstream, I think it is much less controversial to first expand weston.ini to allow setting other than just horizontal line of outputs. That would be interesting to a lot more people than the dynamic configuration protocol, and you would still need to deal with hotplug. Btw. I don't understand the comment no alive, no movement. Thanks, pq ___ 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
-Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Wednesday, May 7, 2014 2:17 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 Wed, 7 May 2014 03:26:56 + Wang, Quanxian quanxian.w...@intel.com wrote: 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. Of course it is, but users expect both to work at the same time, not have an option to choose between dynamic and static configuration. They want to configure what the dynamic code will do on hotplug, hence these two cases are inseparable. The weston-randr protocol could be seen as a way to modify the static configuration in-memory and then trigger a re-layout. Btw. there is no reason to avoid negative global coordinates. If you have output A at 0,0 and add output B to the left of it, it is perfectly valid to put B at -widthB,0. You *can* add to the left or above without moving all the existing outputs. Also nothing says that you have to have an output with origin at 0,0. (There may be bugs, but that is all.) [Wang, Quanxian] no negative coordinate happens. Top left most is the (0,0), it is the primary output. When you move output left of or above primary output(0,0), other outputs will be moved consistently based on the change. Once you primary output is changed, for example in this case, primary output will be changed to another output. All others outputs' coordinate will be calculated again. But the relative position between outputs will not be changed. Top left most output is the root of tree. All other outputs must be descendants of it.(including clone link, hlink, vlink). Output movement algorithm have implemented that. Negative coordinate is invalid. If you haven't, and I certainly have not, you really should study how existing monitor layout algorithms work. Do not set out to replicate them as is, but find out how they solve the problems and whether those solutions would be applicable here. [Wang, Quanxian] You are right. Refer to others could get more valuable idea and be helpful to make algorithm stronger. My goal is to provide a reasonable algorithm for weston output movement. For getting this work forward and upstream, I think it is much less controversial to first expand weston.ini to allow setting other than just horizontal line of outputs. That would be interesting to a lot more people than the dynamic configuration protocol, and you would still need to deal with hotplug. Btw. I don't understand the comment no alive, no movement. [Wang, Quanxian] if output is not active, no movement should happens on this output. Any movement on such kind of output will be invalid. The inactive status include two status. a)unplugged-hardware disable b) plugged but disabled - software disable Thanks, pq ___ 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
On Wed, 7 May 2014 07:03:32 + Wang, Quanxian quanxian.w...@intel.com wrote: -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Wednesday, May 7, 2014 2:17 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 Wed, 7 May 2014 03:26:56 + Wang, Quanxian quanxian.w...@intel.com wrote: 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. Of course it is, but users expect both to work at the same time, not have an option to choose between dynamic and static configuration. They want to configure what the dynamic code will do on hotplug, hence these two cases are inseparable. The weston-randr protocol could be seen as a way to modify the static configuration in-memory and then trigger a re-layout. Btw. there is no reason to avoid negative global coordinates. If you have output A at 0,0 and add output B to the left of it, it is perfectly valid to put B at -widthB,0. You *can* add to the left or above without moving all the existing outputs. Also nothing says that you have to have an output with origin at 0,0. (There may be bugs, but that is all.) [Wang, Quanxian] no negative coordinate happens. Top left most is the (0,0), it is the primary output. You misunderstood. I mean that sometimes it is *good* to use negative coordinates, exactly to avoid moving the world, and that is *perfectly ok*. Moving the world (all existing outputs) is usually not what a user might expect when adding a new output. The top-left most output does not need to be at 0,0. When you move output left of or above primary output(0,0), other outputs will be moved consistently based on the change. Once you primary output is changed, for example in this case, primary output will be changed to another output. All others outputs' coordinate will be calculated again. But the relative position between outputs will not be changed. Top left most output is the root of tree. All other outputs must be descendants of it.(including clone link, hlink, vlink). Output movement algorithm have implemented that. Negative coordinate is invalid. I'm not talking about your specific algorithm anymore. I am talking in general. Existing outputs are usually expected to stay put, when adding outputs to the extremes. Literally that means that the position of the existing outputs must not change, but only the position of the new output is computed appropriately, even if it results in negative coordinates. If I have one output active, and I add another output to the left of it, I certainly do not expect all windows to jump from the existing output to the new output. IOW, the position of the existing output must not change, and the new output will get a negative position. This is about the absolute global coordinates, not the relative positioning between outputs. Btw. I don't understand the comment no alive, no movement. [Wang, Quanxian] if output is not active, no movement should happens on this output. Any movement on such kind of output will be invalid. The inactive status include two status. a)unplugged-hardware disable b) plugged but disabled - software disable What does movement happening on an output mean? What could be moving on that inactive output? Are you perhaps instead trying to say, that using an inactive output as the reference point for placing another output is not allowed? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
On Tue, 6 May 2014 14:40:53 -0700 Kristian Høgsberg hoegsb...@gmail.com wrote: On Mon, May 05, 2014 at 05:02:15PM +0300, Ander Conselvan de Oliveira wrote: From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com Otherwise it might receive touch events. I think a better approach is to just hide the tooltip if it (or the panel) gets touch events. I don't think I agree with Pekka that we can't use subsurfaces for this, but I guess I'm not sure what the problem he sees there is. The panel is not a window, so sub-surfaces can be made to work there well enough. It is for normal windows like registered with xdg_shell where sub-surfaces are not suitable for tooltips. A sub-surface is a part of the window, not another window. A tooltip is not expected to change the window geometry, but a sub-surface does count into the window geometry. Extruding sub-surfaces therefore affect the (parent) window geometry. It is in the protocol spec. Thanks, pq ___ 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
-Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Wednesday, May 7, 2014 3:41 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 Wed, 7 May 2014 07:03:32 + Wang, Quanxian quanxian.w...@intel.com wrote: -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Wednesday, May 7, 2014 2:17 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 Wed, 7 May 2014 03:26:56 + Wang, Quanxian quanxian.w...@intel.com wrote: 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. Of course it is, but users expect both to work at the same time, not have an option to choose between dynamic and static configuration. They want to configure what the dynamic code will do on hotplug, hence these two cases are inseparable. The weston-randr protocol could be seen as a way to modify the static configuration in-memory and then trigger a re-layout. Btw. there is no reason to avoid negative global coordinates. If you have output A at 0,0 and add output B to the left of it, it is perfectly valid to put B at -widthB,0. You *can* add to the left or above without moving all the existing outputs. Also nothing says that you have to have an output with origin at 0,0. (There may be bugs, but that is all.) [Wang, Quanxian] no negative coordinate happens. Top left most is the (0,0), it is the primary output. You misunderstood. I mean that sometimes it is *good* to use negative coordinates, exactly to avoid moving the world, and that is *perfectly ok*. Moving the world (all existing outputs) is usually not what a user might expect when adding a new output. The top-left most output does not need to be at 0,0. When you move output left of or above primary output(0,0), other outputs will be moved consistently based on the change. Once you primary output is changed, for example in this case, primary output will be changed to another output. All others outputs' coordinate will be calculated again. But the relative position between outputs will not be changed. Top left most output is the root of tree. All other outputs must be descendants of it.(including clone link, hlink, vlink). Output movement algorithm have implemented that. Negative coordinate is invalid. I'm not talking about your specific algorithm anymore. I am talking in general. Existing outputs are usually expected to stay put, when adding outputs to the extremes. Literally that means that the position of the existing outputs must not change, but only the position of the new output is computed appropriately, even if it results in negative coordinates. If I have one output active, and I add another output to the left of it, I certainly do not expect all windows to jump from the existing output to the new output. IOW, the position of the existing output must not change, and the new output will get a negative position. This is about the absolute global coordinates, not the relative positioning between outputs. [Wang, Quanxian] Hi, Pq After getting your opinion, I called back my initial thought for this algorithm. I ever thought it like you, but after draw them one by one, I found I was wrong. The following information will tell you how to get the principle of algorithm. How to get that principle? Take a very simple example, it is a horizontal link. Current output layout: A-B-C-D Next action: Move new E output into left of C A-B-E-C-D Question: Can you keep un-changed on all output's coordinate? Absolutely not. C and D will be changed(right extension) or A and B are changed (left extension). Take common case to allow right extension. E will take place of C, C and D's coordinate will be changed at the same time. It is the minor change. The same thing for moving E leftof A. They are the same principle. Therefore in this case no negative happens. We implicitly support right extension. Now you get the principle
[PATCH weston 1/3] shell: Fix artifacts caused by workspace change animation
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Views that extend past the bottom of the output are still visible after
the workspace animation ends but before its layer is hidden. When the
layer was hidden, nothing would cause those regions to be repainted,
leading to artifacts.
https://bugs.freedesktop.org/show_bug.cgi?id=78363
---
desktop-shell/shell.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index a631c62..fac3120 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1027,8 +1027,17 @@ finish_workspace_change_animation(struct desktop_shell
*shell,
struct workspace *from,
struct workspace *to)
{
+ struct weston_view *view;
+
weston_compositor_schedule_repaint(shell-compositor);
+ /* Views that extend past the bottom of the output are still
+* visible after the workspace animation ends but before its layer
+* is hidden. In that case, we need to damage below those views so
+* that the screen is properly repainted. */
+ wl_list_for_each(view, from-layer.view_list, layer_link)
+ weston_view_damage_below(view);
+
wl_list_remove(shell-workspaces.animation.link);
workspace_deactivate_transforms(from);
workspace_deactivate_transforms(to);
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 3/3] shell: Fix crash when restoring focus state during workspace change
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
The check to avoid calling weston_keyboard_set_focus() for a seat that
didn't have a keyboard in restore_focus_state() was cheking the wrong
seat (the one from the previous loop). That caused a crash when
switching workspaces if there was an extra seat that didn't have a
keyboard.
https://bugs.freedesktop.org/show_bug.cgi?id=78349
---
desktop-shell/shell.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index fac3120..ea7b3cd 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -731,7 +731,7 @@ restore_focus_state(struct desktop_shell *shell, struct
workspace *ws)
wl_list_for_each_safe(seat, next_seat, pending_seat_list, link) {
wl_list_insert(shell-compositor-seat_list, seat-link);
- if (state-seat-keyboard == NULL)
+ if (seat-keyboard == NULL)
continue;
weston_keyboard_set_focus(seat-keyboard, NULL);
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/3] simple-touch: Handle multiple seats properly
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
If simple-touch ran on a compositor with multiple seats, and the first
one happened to have the touch capability while the second one didn't,
the handler for seat capabilities would destroy the wl_touch device it
created on the first call for the first seat when it was called a again
for the second seat that has not touch capabilities.
Fix this problem by creating a separate struct for each seat.
https://bugs.freedesktop.org/show_bug.cgi?id=78365
---
clients/simple-touch.c | 48 +---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/clients/simple-touch.c b/clients/simple-touch.c
index b5a84d7..d8439ac 100644
--- a/clients/simple-touch.c
+++ b/clients/simple-touch.c
@@ -36,14 +36,18 @@
#define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
+struct seat {
+ struct touch *touch;
+ struct wl_seat *seat;
+ struct wl_touch *wl_touch;
+};
+
struct touch {
struct wl_display *display;
struct wl_registry *registry;
struct wl_compositor *compositor;
struct wl_shell *shell;
struct wl_shm *shm;
- struct wl_seat *seat;
- struct wl_touch *wl_touch;
struct wl_pointer *pointer;
struct wl_keyboard *keyboard;
struct wl_surface *surface;
@@ -199,18 +203,19 @@ static const struct wl_touch_listener touch_listener = {
};
static void
-seat_handle_capabilities(void *data, struct wl_seat *seat,
+seat_handle_capabilities(void *data, struct wl_seat *wl_seat,
enum wl_seat_capability caps)
{
- struct touch *touch = data;
-
- if ((caps WL_SEAT_CAPABILITY_TOUCH) !touch-wl_touch) {
- touch-wl_touch = wl_seat_get_touch(seat);
- wl_touch_set_user_data(touch-wl_touch, touch);
- wl_touch_add_listener(touch-wl_touch, touch_listener, touch);
- } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) touch-wl_touch) {
- wl_touch_destroy(touch-wl_touch);
- touch-wl_touch = NULL;
+ struct seat *seat = data;
+ struct touch *touch = seat-touch;
+
+ if ((caps WL_SEAT_CAPABILITY_TOUCH) !seat-wl_touch) {
+ seat-wl_touch = wl_seat_get_touch(wl_seat);
+ wl_touch_set_user_data(seat-wl_touch, touch);
+ wl_touch_add_listener(seat-wl_touch, touch_listener, touch);
+ } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) seat-wl_touch) {
+ wl_touch_destroy(seat-wl_touch);
+ seat-wl_touch = NULL;
}
}
@@ -219,6 +224,21 @@ static const struct wl_seat_listener seat_listener = {
};
static void
+add_seat(struct touch *touch, uint32_t name, uint32_t version)
+{
+ struct seat *seat;
+
+ seat = malloc(sizeof *seat);
+ assert(seat);
+
+ seat-touch = touch;
+ seat-wl_touch = NULL;
+ seat-seat = wl_registry_bind(touch-registry, name,
+ wl_seat_interface, 1);
+ wl_seat_add_listener(seat-seat, seat_listener, seat);
+}
+
+static void
handle_ping(void *data, struct wl_shell_surface *shell_surface,
uint32_t serial)
{
@@ -261,9 +281,7 @@ handle_global(void *data, struct wl_registry *registry,
wl_shm_interface, 1);
wl_shm_add_listener(touch-shm, shm_listener, touch);
} else if (strcmp(interface, wl_seat) == 0) {
- touch-seat = wl_registry_bind(registry, name,
- wl_seat_interface, 1);
- wl_seat_add_listener(touch-seat, seat_listener, touch);
+ add_seat(touch, name, version);
}
}
--
1.8.3.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
On Wed, 7 May 2014 08:49:47 + Wang, Quanxian quanxian.w...@intel.com wrote: -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Wednesday, May 7, 2014 3:41 PM To: Wang, Quanxian Subject: Re: [Weston] More discussion about weston output relative motion algorithm On Wed, 7 May 2014 07:03:32 + Wang, Quanxian quanxian.w...@intel.com wrote: -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Wednesday, May 7, 2014 2:17 PM To: Wang, Quanxian Michael Subject: Re: [Weston] More discussion about weston output relative motion algorithm On Wed, 7 May 2014 03:26:56 + Wang, Quanxian quanxian.w...@intel.com wrote: 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. Of course it is, but users expect both to work at the same time, not have an option to choose between dynamic and static configuration. They want to configure what the dynamic code will do on hotplug, hence these two cases are inseparable. The weston-randr protocol could be seen as a way to modify the static configuration in-memory and then trigger a re-layout. Btw. there is no reason to avoid negative global coordinates. If you have output A at 0,0 and add output B to the left of it, it is perfectly valid to put B at -widthB,0. You *can* add to the left or above without moving all the existing outputs. Also nothing says that you have to have an output with origin at 0,0. (There may be bugs, but that is all.) [Wang, Quanxian] no negative coordinate happens. Top left most is the (0,0), it is the primary output. You misunderstood. I mean that sometimes it is *good* to use negative coordinates, exactly to avoid moving the world, and that is *perfectly ok*. Moving the world (all existing outputs) is usually not what a user might expect when adding a new output. The top-left most output does not need to be at 0,0. When you move output left of or above primary output(0,0), other outputs will be moved consistently based on the change. Once you primary output is changed, for example in this case, primary output will be changed to another output. All others outputs' coordinate will be calculated again. But the relative position between outputs will not be changed. Top left most output is the root of tree. All other outputs must be descendants of it.(including clone link, hlink, vlink). Output movement algorithm have implemented that. Negative coordinate is invalid. I'm not talking about your specific algorithm anymore. I am talking in general. Existing outputs are usually expected to stay put, when adding outputs to the extremes. Literally that means that the position of the existing outputs must not change, but only the position of the new output is computed appropriately, even if it results in negative coordinates. If I have one output active, and I add another output to the left of it, I certainly do not expect all windows to jump from the existing output to the new output. IOW, the position of the existing output must not change, and the new output will get a negative position. This is about the absolute global coordinates, not the relative positioning between outputs. [Wang, Quanxian] Hi, Pq After getting your opinion, I called back my initial thought for this algorithm. I ever thought it like you, but after draw them one by one, I found I was wrong. The following information will tell you how to get the principle of algorithm. How to get that principle? Take a very simple example, it is a horizontal link. Current output layout: A-B-C-D Next action: Move new E output into left of C A-B-E-C-D Question: Can you keep un-changed on all output's coordinate? Absolutely not. C and D will be changed(right extension) or A and B are changed (left extension). Take common case to allow right extension. E will take place of C, C and D's coordinate will be changed at the same time. It is the minor change. The same thing for moving E leftof A. They are the same principle. Therefore in this case no negative happens. We implicitly support right extension. That is obvious, and not the case I was talking about. I meant this very simple example: There is only one output A. A Then I add output B to the left of A. B-A The position of A must not change. This means that B must get
Bug 78372 - create multiple windows with offset
Please go through this NOTABUG bug. https://bugs.freedesktop.org/show_bug.cgi?id=78372 Rohit Nandan ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] clients: Initialize label in keyboard handling code
On Wed, 07 May 2014 01:11:07 +
Bryce W. Harrington b.harring...@samsung.com wrote:
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 :
Yeah, I've seen this warning, it's almost a false positive, but nice to
shut it up, anyway.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/5] clients: Use the x*alloc routines
On Wed, 07 May 2014 02:13:10 + Bryce W. Harrington b.harring...@samsung.com wrote: 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(-) Hi, all patches look good to me. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: More build problems: dri2proto
On Tue, 06 May 2014 19:36:59 -0700
Bill Spitzak spit...@gmail.com wrote:
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?
Maybe you forgot to set some of the environment variables from here:
http://wayland.freedesktop.org/building.html
Don't play with the foofoo_CFLAGS and foofoo_LIBS variables, it is much
better to fix pkg-config to find the right .pc files.
- pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] doc: Added API documentation for wl_display_create function.
On Wed, 07 May 2014 09:37:45 +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..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)
{
Looks good to me. Didn't check how it comes out in Doxygen, though.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] gitignore log files, now in root directory
On Tue, 11 Mar 2014 18:11:43 + Bryce W. Harrington b.harring...@samsung.com wrote: Signed-off-by: Bryce Harrington b.harring...@samsung.com --- .gitignore |2 ++ 1 file changed, 2 insertions(+) diff --git a/.gitignore b/.gitignore index e0a73c0..d3044a2 100644 --- a/.gitignore +++ b/.gitignore @@ -2,6 +2,7 @@ *.jpg *.la *.lo +*.log *.o *.pc *.so @@ -21,6 +22,7 @@ cscope.out /config.status /configure /libtool +/logs /stamp-h1 /test-driver /weston.ini Hi, this patch is still needed for Weston, and could use adding *.trs to ignore, too. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] shell: Don't allow maximized surfaces to be moved with touch
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com Moving a maximized surface with the pointer is already not possible, so make the behavior with touch consistent. https://bugs.freedesktop.org/show_bug.cgi?id=78208 --- desktop-shell/shell.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index ea7b3cd..db55ea9 100644 --- a/desktop-shell/shell.c +++ b/desktop-shell/shell.c @@ -1453,7 +1453,7 @@ surface_touch_move(struct shell_surface *shsurf, struct weston_seat *seat) if (!shsurf) return -1; - if (shsurf-state.fullscreen) + if (shsurf-state.fullscreen || shsurf-state.maximized) return 0; move = malloc(sizeof *move); -- 1.8.3.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
Hi, Pq I meant this very simple example: There is only one output A. A Then I add output B to the left of A. B-A The position of A must not change. This means that B must get negative coordinates, and A's position stays at 0,0. In Weston, window positions are stored in global coordinates, and to keep windows that were on output A, still on output A, the position of A must not change. [Wang, Quanxian] This case is a special case, from it, you could not find the principle. Because in this case, you have the choice 'A must not change' or 'A must change'. But for C-B-A, it will be very clear why we follow the principle. We must think about how to make the principle to be accepted anywhere instead of special case. If we randomly define the rule, will make everything complex. It is not what we want. By the way, when moving output, the move event will be sent to windows in this output. The window will be moved at the same time. Note, that you cannot infer this from the syntax B-A, but you can from put B left-of A: B is being set and A is the reference point. Another case: First we have A-B Then add C right-of A. Now you could get the chain A-C-B, or C could end up cloning B. I do not care too much on what happens there, since it is sort of ill-defined. But I do care about the first case where we are not adding in the middle. Now you get the principle from simple link. And then vlink is the same thing. And then combine vlink and hlink together. At last I got this algorithm. I know principle will exist in both complex and simple layout. The algorithm can be summarized from them. Therefore my first step is to study simple case and find what the rule is. And then turn to complex and enhance the algorithm. Make the algorithm to be complete. Here I list several questions for you. 1) Why use tree to link all outputs together? If just use coordinate to calculated the x, y, you will be lost. Because when you moving output, you can't avoid affecting the position of other outputs. You have to review all coordinates of outputs and make decision who is left, right, above, below. It will be much more complex. But if you use tree to link all, everything is very clear. Who is left, right, above, below. It is very clear. Coordinate and relative motion could be easily figured out. It will be very easy to control the position and movement of outputs. My alternate proposition was to keep the ordered list of configuration directives instead of a tree structure. Not just x,y for each live output. Instead of going through the tree to assing new positions, you would execute the list of directives. You would also need some additional rule on where to add outputs that are not placed by any directive. Most likely this rule would just create directives for the outputs. Whether that would work or not, I am not sure. 2) Why one root One root will tell you, this is the top left most. No other outputs will be left or above it. From this, you can calculate and review all outputs. No one is lost. Your definition of top-left most causes you to have problems in realizing an arrangement where the top-left output does not exist, e.g.: - C B A OTOH with directives, there is no need to define a root output. Directives could also refer to inactive outputs. Inactive outputs would simply have zero size, and the directive would be executed as always. [Wang, Quanxian] Let me think about that case. In current algorithm, this case will not happen. The algorithm design will avoid such condition. But in practice, this layout really exists. The solution could be: Root output should exist because it will link all outputs. We really need that. But I like you suggestion to make root virtual (just as you said, zero size). At the same time we can define gap for every output. In this case, C'x coordinate will have this gap. So the link could be Root-hlink = C (x's gap is x) Root-vlink = B (y's gap is y) C-vlink = A or B-hlink = A. Is it reasonable? :) If so, pos(x,y) will take into consideration. But you definitely can not define such case B-hlink = A C-vlink = A If you has such case, it will crash all. A can't have two parent because it will cause conflict of A's coordinate. 3) Why only one parent? If two parents, you will find more links will cross each other. It is absolutely a disaster. (This could cause conflict of coordinates, from this path, it will A, for that path, it will B. A and B is not same.) I am not sure if you understand my idea. Sorry for my poor language. No, I do understand the tree structure well. It is just the rationale behind that is unclear, it clearly has some reasonable cases it cannot represent, and some IMO surprising behaviour. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org
[PATCH] Do not distribute generated headers
From: Thierry Reding tred...@nvidia.com
The wayland-server-protocol.h and wayland-client-protocol.h headers are
currently being shipped in tarballs created using make dist. This causes
out-of-tree builds to fail since make will detect that the headers exist
by looking at the source directory (via VPATH) and not regenerate them.
But as opposed to ${top_builddir}/protocol, ${top_srcdir}/protocol is
not part of the include path and therefore the shipped files can't be
found during compilation.
Two solutions exist to this problem: 1) add ${top_srcdir}/protocol to
the include path to allow shipped files to be used if available or 2)
don't ship these generated files in release tarballs. The latter seems
the most appropriate. wayland-scanner is already a prerequisite in order
to generate wayland-protocol.c, so it is either built as part of the
package or provided externally. Generating all files from the protocol
definition at build time also ensures that they don't get out of sync.
Both of the generated headers are already listed in Makefile.am as
nodist_*_SOURCES, but at the same time they appear in include_HEADERS,
which will cause them to be added to the list of distributable files
after all. To prevent that, split them off into nodist_include_HEADERS.
Note that this problem will be hidden if a previous version of wayland
has been installed, since these files will exist in /usr/include and be
included from there. So this build error will only show for out-of-tree
builds on systems that don't have wayland installed yet.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Makefile.am | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index f1584d5bfc12..0ec6f47ab2c7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -20,13 +20,15 @@ noinst_LTLIBRARIES = libwayland-util.la
include_HEADERS = \
src/wayland-util.h \
- protocol/wayland-server-protocol.h \
src/wayland-server.h\
- protocol/wayland-client-protocol.h \
src/wayland-client.h\
src/wayland-egl.h \
src/wayland-version.h
+nodist_include_HEADERS = \
+ protocol/wayland-server-protocol.h \
+ protocol/wayland-client-protocol.h
+
libwayland_util_la_SOURCES = \
src/connection.c\
src/wayland-util.c \
--
1.9.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 0/3] Automatically find a good WAYLAND_SOCKET for compositors
This patch series implements a better fallback than a hardcoded wayland-0 when a server socket has already been taken. This way, the code for searching for an appropriate socket is shared between all compositors. The option to open an explicit socket still exists, if the client specifies it. Jasper St. Pierre (3): server: Create the socket FD after taking the lock server: Split out code to open sockets for a specific name server: Find an open wayland-* socket by default src/wayland-server.c | 77 1 file changed, 54 insertions(+), 23 deletions(-) -- 1.9.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 3/3] server: Find an open wayland-* socket by default
Rather than just trying wayland-0 and bailing out if it's in use.
---
src/wayland-server.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 3390171..ba13168 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1078,11 +1078,31 @@ open_socket_for_name(struct wl_socket *s, const char
*name)
return 0;
}
+static int
+open_default_socket(struct wl_socket *s)
+{
+ char socket_name[16] = ;
+ int sockno = 0;
+
+ /* A reasonable number of maximum default sockets. If
+* you need more than this, set WAYLAND_DISPLAY explicitly. */
+ const int MAX_SOCKNO = 32;
+
+ do {
+ snprintf(socket_name, sizeof socket_name, wayland-%d, sockno);
+ if (open_socket_for_name(s, socket_name) = 0)
+ return 0;
+ } while (sockno++ MAX_SOCKNO);
+
+ return -1;
+}
+
WL_EXPORT int
wl_display_add_socket(struct wl_display *display, const char *name)
{
struct wl_socket *s;
socklen_t size;
+ int ret;
s = malloc(sizeof *s);
if (s == NULL)
@@ -1090,10 +1110,13 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
if (name == NULL)
name = getenv(WAYLAND_DISPLAY);
- if (name == NULL)
- name = wayland-0;
- if (open_socket_for_name(s, name) 0) {
+ if (name)
+ ret = open_socket_for_name(s, name);
+ else
+ ret = open_default_socket(s);
+
+ if (ret 0) {
free(s);
return -1;
}
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 1/3] server: Create the socket FD after taking the lock
This removes a small cleanup path.
---
src/wayland-server.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index e850d48..d299000 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1061,12 +1061,6 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
if (s == NULL)
return -1;
- s-fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
- if (s-fd 0) {
- free(s);
- return -1;
- }
-
if (name == NULL)
name = getenv(WAYLAND_DISPLAY);
if (name == NULL)
@@ -1081,7 +1075,6 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
if (name_size (int)sizeof s-addr.sun_path) {
wl_log(error: socket path \%s/%s\ plus null terminator
exceeds 108 bytes\n, runtime_dir, name);
- close(s-fd);
free(s);
/* to prevent programs reporting
* failed to add socket: Success */
@@ -1091,7 +1084,12 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
s-fd_lock = get_socket_lock(s);
if (s-fd_lock 0) {
- close(s-fd);
+ free(s);
+ return -1;
+ }
+
+ s-fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
+ if (s-fd 0) {
free(s);
return -1;
}
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 2/3] server: Split out code to open sockets for a specific name
We'll use this to autodetect a good socket to open on.
---
src/wayland-server.c | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index d299000..3390171 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1039,11 +1039,9 @@ get_socket_lock(struct wl_socket *socket)
return fd_lock;
}
-WL_EXPORT int
-wl_display_add_socket(struct wl_display *display, const char *name)
+static int
+open_socket_for_name(struct wl_socket *s, const char *name)
{
- struct wl_socket *s;
- socklen_t size;
int name_size;
const char *runtime_dir;
@@ -1057,15 +1055,6 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
return -1;
}
- s = malloc(sizeof *s);
- if (s == NULL)
- return -1;
-
- if (name == NULL)
- name = getenv(WAYLAND_DISPLAY);
- if (name == NULL)
- name = wayland-0;
-
memset(s-addr, 0, sizeof s-addr);
s-addr.sun_family = AF_LOCAL;
name_size = snprintf(s-addr.sun_path, sizeof s-addr.sun_path,
@@ -1075,7 +1064,6 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
if (name_size (int)sizeof s-addr.sun_path) {
wl_log(error: socket path \%s/%s\ plus null terminator
exceeds 108 bytes\n, runtime_dir, name);
- free(s);
/* to prevent programs reporting
* failed to add socket: Success */
errno = ENAMETOOLONG;
@@ -1084,6 +1072,28 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
s-fd_lock = get_socket_lock(s);
if (s-fd_lock 0) {
+ return -1;
+ }
+
+ return 0;
+}
+
+WL_EXPORT int
+wl_display_add_socket(struct wl_display *display, const char *name)
+{
+ struct wl_socket *s;
+ socklen_t size;
+
+ s = malloc(sizeof *s);
+ if (s == NULL)
+ return -1;
+
+ if (name == NULL)
+ name = getenv(WAYLAND_DISPLAY);
+ if (name == NULL)
+ name = wayland-0;
+
+ if (open_socket_for_name(s, name) 0) {
free(s);
return -1;
}
@@ -1094,7 +1104,7 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
return -1;
}
- size = offsetof (struct sockaddr_un, sun_path) + name_size;
+ size = offsetof (struct sockaddr_un, sun_path) +
strlen(s-addr.sun_path);
if (bind(s-fd, (struct sockaddr *) s-addr, size) 0) {
wl_log(bind() failed with error: %m\n);
close(s-fd);
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] compositor: Add a comment around the WAYLAND_DISPLAY envvar setting
This took me a few minutes to figure out, so document it for the
next person who stumbles in here.
---
src/compositor.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index 3d65e4c..120818f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4245,7 +4245,13 @@ int main(int argc, char *argv[])
ec-idle_time = idle_time;
ec-default_pointer_grab = NULL;
- setenv(WAYLAND_DISPLAY, socket_name, 1);
+ if (socket_name) {
+ setenv(WAYLAND_DISPLAY, socket_name, 1);
+ } else {
+ /* Overwrite WAYLAND_DISPLAY so that nested Weston
+* instances don't try to open the parent's socket. */
+ setenv(WAYLAND_DISPLAY, NULL, 1);
+ }
if (option_shell)
shell = strdup(option_shell);
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 0/3] Automatically find a good WAYLAND_SOCKET for compositors
Of course I mean WAYLAND_DISPLAY, not WAYLAND_SOCKET. Whoops. On Wed, May 7, 2014 at 9:05 AM, Jasper St. Pierre jstpie...@mecheye.netwrote: This patch series implements a better fallback than a hardcoded wayland-0 when a server socket has already been taken. This way, the code for searching for an appropriate socket is shared between all compositors. The option to open an explicit socket still exists, if the client specifies it. Jasper St. Pierre (3): server: Create the socket FD after taking the lock server: Split out code to open sockets for a specific name server: Find an open wayland-* socket by default src/wayland-server.c | 77 1 file changed, 54 insertions(+), 23 deletions(-) -- 1.9.0 -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 1/3] shell: Fix artifacts caused by workspace change animation
Hm, it seems to me that hiding a layer should cause all the regions it
occupied to be marked as needing repaint. Fixing the scene graph is better
than a one-off at the end of an animation.
On Wed, May 7, 2014 at 4:57 AM, Ander Conselvan de Oliveira
conselv...@gmail.com wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Views that extend past the bottom of the output are still visible after
the workspace animation ends but before its layer is hidden. When the
layer was hidden, nothing would cause those regions to be repainted,
leading to artifacts.
https://bugs.freedesktop.org/show_bug.cgi?id=78363
---
desktop-shell/shell.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index a631c62..fac3120 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1027,8 +1027,17 @@ finish_workspace_change_animation(struct
desktop_shell *shell,
struct workspace *from,
struct workspace *to)
{
+ struct weston_view *view;
+
weston_compositor_schedule_repaint(shell-compositor);
+ /* Views that extend past the bottom of the output are still
+* visible after the workspace animation ends but before its layer
+* is hidden. In that case, we need to damage below those views so
+* that the screen is properly repainted. */
+ wl_list_for_each(view, from-layer.view_list, layer_link)
+ weston_view_damage_below(view);
+
wl_list_remove(shell-workspaces.animation.link);
workspace_deactivate_transforms(from);
workspace_deactivate_transforms(to);
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 3/3] shell: Fix crash when restoring focus state during workspace change
Yep, looks good.
On Wed, May 7, 2014 at 4:57 AM, Ander Conselvan de Oliveira
conselv...@gmail.com wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
The check to avoid calling weston_keyboard_set_focus() for a seat that
didn't have a keyboard in restore_focus_state() was cheking the wrong
seat (the one from the previous loop). That caused a crash when
switching workspaces if there was an extra seat that didn't have a
keyboard.
https://bugs.freedesktop.org/show_bug.cgi?id=78349
---
desktop-shell/shell.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index fac3120..ea7b3cd 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -731,7 +731,7 @@ restore_focus_state(struct desktop_shell *shell,
struct workspace *ws)
wl_list_for_each_safe(seat, next_seat, pending_seat_list, link) {
wl_list_insert(shell-compositor-seat_list, seat-link);
- if (state-seat-keyboard == NULL)
+ if (seat-keyboard == NULL)
continue;
weston_keyboard_set_focus(seat-keyboard, NULL);
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/3] simple-touch: Handle multiple seats properly
I was wondering why you didn't move the pointer / keyboard fields to the
seat, before noticing that they were unused. It might make sense to have a
prereq patch that removes those unused fields.
This patch looks good, though.
On Wed, May 7, 2014 at 4:57 AM, Ander Conselvan de Oliveira
conselv...@gmail.com wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
If simple-touch ran on a compositor with multiple seats, and the first
one happened to have the touch capability while the second one didn't,
the handler for seat capabilities would destroy the wl_touch device it
created on the first call for the first seat when it was called a again
for the second seat that has not touch capabilities.
Fix this problem by creating a separate struct for each seat.
https://bugs.freedesktop.org/show_bug.cgi?id=78365
---
clients/simple-touch.c | 48
+---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/clients/simple-touch.c b/clients/simple-touch.c
index b5a84d7..d8439ac 100644
--- a/clients/simple-touch.c
+++ b/clients/simple-touch.c
@@ -36,14 +36,18 @@
#define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
+struct seat {
+ struct touch *touch;
+ struct wl_seat *seat;
+ struct wl_touch *wl_touch;
+};
+
struct touch {
struct wl_display *display;
struct wl_registry *registry;
struct wl_compositor *compositor;
struct wl_shell *shell;
struct wl_shm *shm;
- struct wl_seat *seat;
- struct wl_touch *wl_touch;
struct wl_pointer *pointer;
struct wl_keyboard *keyboard;
struct wl_surface *surface;
@@ -199,18 +203,19 @@ static const struct wl_touch_listener touch_listener
= {
};
static void
-seat_handle_capabilities(void *data, struct wl_seat *seat,
+seat_handle_capabilities(void *data, struct wl_seat *wl_seat,
enum wl_seat_capability caps)
{
- struct touch *touch = data;
-
- if ((caps WL_SEAT_CAPABILITY_TOUCH) !touch-wl_touch) {
- touch-wl_touch = wl_seat_get_touch(seat);
- wl_touch_set_user_data(touch-wl_touch, touch);
- wl_touch_add_listener(touch-wl_touch, touch_listener,
touch);
- } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) touch-wl_touch) {
- wl_touch_destroy(touch-wl_touch);
- touch-wl_touch = NULL;
+ struct seat *seat = data;
+ struct touch *touch = seat-touch;
+
+ if ((caps WL_SEAT_CAPABILITY_TOUCH) !seat-wl_touch) {
+ seat-wl_touch = wl_seat_get_touch(wl_seat);
+ wl_touch_set_user_data(seat-wl_touch, touch);
+ wl_touch_add_listener(seat-wl_touch, touch_listener,
touch);
+ } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) seat-wl_touch) {
+ wl_touch_destroy(seat-wl_touch);
+ seat-wl_touch = NULL;
}
}
@@ -219,6 +224,21 @@ static const struct wl_seat_listener seat_listener = {
};
static void
+add_seat(struct touch *touch, uint32_t name, uint32_t version)
+{
+ struct seat *seat;
+
+ seat = malloc(sizeof *seat);
+ assert(seat);
+
+ seat-touch = touch;
+ seat-wl_touch = NULL;
+ seat-seat = wl_registry_bind(touch-registry, name,
+ wl_seat_interface, 1);
+ wl_seat_add_listener(seat-seat, seat_listener, seat);
+}
+
+static void
handle_ping(void *data, struct wl_shell_surface *shell_surface,
uint32_t serial)
{
@@ -261,9 +281,7 @@ handle_global(void *data, struct wl_registry *registry,
wl_shm_interface, 1);
wl_shm_add_listener(touch-shm, shm_listener, touch);
} else if (strcmp(interface, wl_seat) == 0) {
- touch-seat = wl_registry_bind(registry, name,
- wl_seat_interface, 1);
- wl_seat_add_listener(touch-seat, seat_listener, touch);
+ add_seat(touch, name, version);
}
}
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
The rationale explained in the bug by Pekka and Emilio sounds OK to me. Explaining a bit more about your use case with your data visualization app might be helpful. What kinds of systems do you want your app to be run on? Generic desktop systems? If so, then you can't guarantee anything about utilizing hardware overlays, as the user might be watching a video at the same time, which should take HW overlay priority over your application to prevent a YUV - RGB conversion in software. If you have a special usecase like a Bloomberg terminal, then making your own shell and shell protocol like the IVI team is doing might be a better solution, so you can guarantee window position and HW utilization. The default desktop-shell is very much designed for desktop Linux use cases, where we don't want to expose global window positions or make any guarantees to the client about where they are on screen, precisely so you don't assume you are the only user of the HW. On Wed, May 7, 2014 at 5:51 AM, Rohit Nandan pulkitnan...@gmail.com wrote: Please go through this NOTABUG bug. https://bugs.freedesktop.org/show_bug.cgi?id=78372 Rohit Nandan ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 3/5] tests: load the right xwayland plugin
From: Pekka Paalanen pekka.paala...@collabora.co.uk
If we do not specify the full path to xwayland.so, Weston can find an
old one installed in a $prefix and use that instead of the freshly built
one.
Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk
---
tests/weston-tests-env | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/weston-tests-env b/tests/weston-tests-env
index 746ae27..fb9928a 100755
--- a/tests/weston-tests-env
+++ b/tests/weston-tests-env
@@ -22,13 +22,15 @@ if test -z $BACKEND; then
fi
BACKEND=$abs_builddir/.libs/$BACKEND
+TEST_PLUGIN=$abs_builddir/.libs/weston-test.so
+XWAYLAND_PLUGIN=$abs_builddir/.libs/xwayland.so
case $TESTNAME in
*.la|*.so)
$WESTON --backend=$BACKEND \
--no-config \
--socket=test-$(basename $TESTNAME) \
-
--modules=$abs_builddir/.libs/${TESTNAME/.la/.so},xwayland.so \
+
--modules=$abs_builddir/.libs/${TESTNAME/.la/.so},$XWAYLAND_PLUGIN \
--log=$SERVERLOG \
$OUTLOG
;;
@@ -38,6 +40,6 @@ case $TESTNAME in
--backend=$BACKEND \
--no-config \
--log=$SERVERLOG \
-
--modules=$abs_builddir/.libs/weston-test.so,xwayland.so \
+ --modules=$TEST_PLUGIN,$XWAYLAND_PLUGIN \
$OUTLOG
esac
--
1.8.5.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/5] tests: use --no-config
From: Pekka Paalanen pekka.paala...@collabora.co.uk
Use --no-config to avoid loading arbitrary weston.ini files from unit
tests. It may affect the unit test results.
I actually hit the following case:
[13:34:04.636] Using config file '/home/pq/local/etc/weston.ini'
[13:34:04.636] Loading module '/home/pq/git/weston/.libs/headless-backend.so'
[13:34:04.637] launching '/home/pq/local/libexec/weston-keyboard'
[13:34:04.644] Loading module '/home/pq/local/lib/weston/desktop-shell.so'
[13:34:04.644] Loading module '/home/pq/local/lib/weston/xwayland.so'
[13:34:04.648] unlinking stale lock file /tmp/.X1-lock
[13:34:04.648] xserver listening on display :1
[13:34:04.648] Loading module '/home/pq/git/weston/.libs/./xwayland.so'
[13:34:04.648] xserver listening on display :2
[13:34:04.648] Module '/home/pq/local/lib/weston/xwayland.so' already loaded
Weston tries to load xwayland module three times, or which twice it
succeeds. This might not make the xwayland test end well. Or at all,
actually.
Adding --no-config should remove one of these loads of xwayland.so.
Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk
---
tests/weston-tests-env | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/weston-tests-env b/tests/weston-tests-env
index 9180053..746ae27 100755
--- a/tests/weston-tests-env
+++ b/tests/weston-tests-env
@@ -26,6 +26,7 @@ BACKEND=$abs_builddir/.libs/$BACKEND
case $TESTNAME in
*.la|*.so)
$WESTON --backend=$BACKEND \
+ --no-config \
--socket=test-$(basename $TESTNAME) \
--modules=$abs_builddir/.libs/${TESTNAME/.la/.so},xwayland.so \
--log=$SERVERLOG \
@@ -35,6 +36,7 @@ case $TESTNAME in
WESTON_TEST_CLIENT_PATH=$abs_builddir/$TESTNAME $WESTON \
--socket=test-$(basename $TESTNAME) \
--backend=$BACKEND \
+ --no-config \
--log=$SERVERLOG \
--modules=$abs_builddir/.libs/weston-test.so,xwayland.so \
$OUTLOG
--
1.8.5.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 0/5] test suite fixes
From: Pekka Paalanen pekka.paala...@collabora.co.uk Hi, random little things here. I mostly wanted to make the Xwayland unit test work again. This patch series at least makes it run the right thing, but it still fails. Is the Xwayland test supposed to even work at all now? Are there some requirements for the xserver ./configure, so that it would work? Pekka Paalanen (5): compositor: add --no-config command line option tests: use --no-config tests: load the right xwayland plugin tests: load the right shell plugin tests: rename xwayland test Makefile.am| 8 man/weston.man | 6 ++ src/compositor.c | 8 ++-- tests/weston-tests-env | 11 +-- 4 files changed, 25 insertions(+), 8 deletions(-) -- 1.8.5.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 5/5] tests: rename xwayland test
From: Pekka Paalanen pekka.paala...@collabora.co.uk If the test is named xwayland.weston, then the automake test harness keys it off xwayland.log. Making xwayland.log runs the test. The test harness has implicit rules to create a %.log from all of %$TEST_EXTENSIONS. So we have implicit rules to create %.log from %.la and %.log from %.weston. We also build xwayland.so, which produces xwayland.la. When the test harness goes running the xwayland test, it ends up using the %.la rule, which is wrong. It passes xwayland.la as the test name to weston-tests-env, which then loads it as a plugin into Weston and waits for Weston to exit. Which it never does. Fix this by making the test have a different name than the Xwayland plugin. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- Makefile.am | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Makefile.am b/Makefile.am index a247c3d..177ce2e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -927,10 +927,10 @@ buffer_count_weston_LDADD = libtest-client.la $(EGL_TESTS_LIBS) endif if ENABLE_XWAYLAND_TEST -weston_tests +=xwayland.weston -xwayland_weston_SOURCES = tests/xwayland-test.c -xwayland_weston_CFLAGS = $(GCC_CFLAGS) $(XWAYLAND_TEST_CFLAGS) -xwayland_weston_LDADD = libtest-client.la $(XWAYLAND_TEST_LIBS) +weston_tests +=xwayland-test.weston +xwayland_test_weston_SOURCES = tests/xwayland-test.c +xwayland_test_weston_CFLAGS = $(GCC_CFLAGS) $(XWAYLAND_TEST_CFLAGS) +xwayland_test_weston_LDADD = libtest-client.la $(XWAYLAND_TEST_LIBS) endif matrix_test_SOURCES = \ -- 1.8.5.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 1/5] compositor: add --no-config command line option
From: Pekka Paalanen pekka.paala...@collabora.co.uk
Useful for unit tests. If Weston finds a weston.ini during unit tests,
it will load it and all the modules it asks for. We need a way to
prevent loading arbitrary modules from the command line.
Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk
---
man/weston.man | 6 ++
src/compositor.c | 8 ++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/man/weston.man b/man/weston.man
index fd1c7a5..735235f 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -130,6 +130,12 @@ suite. The file is searched for in
.IR __weston_modules_dir__ ,
or you can pass an absolute path.
.TP
+.BR \-\-no-config
+Do not read
+.I weston.ini
+for the compositor. Avoids e.g. loading compositor modules via the
+configuration file, which is useful for unit tests.
+.TP
\fB\-\^S\fR\fIname\fR, \fB\-\-socket\fR=\fIname\fR
Weston will listen in the Wayland socket called
.IR name .
diff --git a/src/compositor.c b/src/compositor.c
index cd1ca9a..574db2d 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4042,6 +4042,7 @@ usage(int error_code)
-i, --idle-time=SECS\tIdle time in seconds\n
--modules\t\tLoad the comma-separated list of modules\n
--log==FILE\t\tLog to the given file\n
+ --no-config\t\tDo not read weston.ini\n
-h, --help\t\tThis help message\n\n);
fprintf(stderr,
@@ -4152,7 +4153,8 @@ int main(int argc, char *argv[])
int32_t help = 0;
char *socket_name = wayland-0;
int32_t version = 0;
- struct weston_config *config;
+ int32_t noconfig = 0;
+ struct weston_config *config = NULL;
struct weston_config_section *section;
struct wl_client *primary_client;
struct wl_listener primary_client_destroyed;
@@ -4166,6 +4168,7 @@ int main(int argc, char *argv[])
{ WESTON_OPTION_STRING, log, 0, log },
{ WESTON_OPTION_BOOLEAN, help, 'h', help },
{ WESTON_OPTION_BOOLEAN, version, 0, version },
+ { WESTON_OPTION_BOOLEAN, no-config, 0, noconfig },
};
parse_options(core_options, ARRAY_LENGTH(core_options), argc, argv);
@@ -4204,7 +4207,8 @@ int main(int argc, char *argv[])
signals[3] = wl_event_loop_add_signal(loop, SIGCHLD, sigchld_handler,
NULL);
- config = weston_config_parse(weston.ini);
+ if (noconfig == 0)
+ config = weston_config_parse(weston.ini);
if (config != NULL) {
weston_log(Using config file '%s'\n,
weston_config_get_full_path(config));
--
1.8.5.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 4/5] tests: load the right shell plugin
From: Pekka Paalanen pekka.paala...@collabora.co.uk
Again, load the shell plugin with full path, rather than possibly find an
old version from a previous installation.
Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk
---
tests/weston-tests-env | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/weston-tests-env b/tests/weston-tests-env
index fb9928a..473e092 100755
--- a/tests/weston-tests-env
+++ b/tests/weston-tests-env
@@ -22,6 +22,7 @@ if test -z $BACKEND; then
fi
BACKEND=$abs_builddir/.libs/$BACKEND
+SHELL_PLUGIN=$abs_builddir/.libs/desktop-shell.so
TEST_PLUGIN=$abs_builddir/.libs/weston-test.so
XWAYLAND_PLUGIN=$abs_builddir/.libs/xwayland.so
@@ -29,6 +30,7 @@ case $TESTNAME in
*.la|*.so)
$WESTON --backend=$BACKEND \
--no-config \
+ --shell=$SHELL_PLUGIN \
--socket=test-$(basename $TESTNAME) \
--modules=$abs_builddir/.libs/${TESTNAME/.la/.so},$XWAYLAND_PLUGIN \
--log=$SERVERLOG \
@@ -39,6 +41,7 @@ case $TESTNAME in
--socket=test-$(basename $TESTNAME) \
--backend=$BACKEND \
--no-config \
+ --shell=$SHELL_PLUGIN \
--log=$SERVERLOG \
--modules=$TEST_PLUGIN,$XWAYLAND_PLUGIN \
$OUTLOG
--
1.8.5.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/3] compositor-wayland: assign the correct mode
I love the simple typos like this. LGTM.
On Tue, May 6, 2014 at 5:50 PM, U. Artie Eoff ullysses.a.e...@intel.comwrote:
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
--
Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] compositor: Add a comment around the WAYLAND_DISPLAY envvar setting
On Wed, 7 May 2014 09:07:26 -0400
Jasper St. Pierre jstpie...@mecheye.net wrote:
This took me a few minutes to figure out, so document it for the
next person who stumbles in here.
---
src/compositor.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index 3d65e4c..120818f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4245,7 +4245,13 @@ int main(int argc, char *argv[])
ec-idle_time = idle_time;
ec-default_pointer_grab = NULL;
- setenv(WAYLAND_DISPLAY, socket_name, 1);
+ if (socket_name) {
+ setenv(WAYLAND_DISPLAY, socket_name, 1);
+ } else {
+ /* Overwrite WAYLAND_DISPLAY so that nested Weston
+ * instances don't try to open the parent's socket. */
+ setenv(WAYLAND_DISPLAY, NULL, 1);
+ }
if (option_shell)
shell = strdup(option_shell);
Hi,
this seems a little strange to me. How could socket_name ever be NULL?
I think the compositor needs to set WAYLAND_DISPLAY always, so that
clients have it in their environment, like weston-desktop-shell and so
everything.
The only case where WAYLAND_DISPLAY should be cleared is when the
WAYLAND_SERVER_SOCKET thing prevents the normal socket from being
created. I don't see that matching with socket_name==NULL.
I already mentioned on IRC about the setenv(..., NULL, 1).
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] compositor: Use libwayland to find a good default socket name for us
On Wed, 7 May 2014 09:07:27 -0400
Jasper St. Pierre jstpie...@mecheye.net wrote:
---
src/compositor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index 120818f..85a75bf 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4306,7 +4306,7 @@ int main(int argc, char *argv[])
wl_client_add_destroy_listener(primary_client,
primary_client_destroyed);
} else {
- if (wl_display_add_socket(display, socket_name)) {
+ if (wl_display_add_socket(display, NULL)) {
weston_log(fatal: failed to add socket: %m\n);
ret = EXIT_FAILURE;
goto out;
This would break the weston commandline option -S / --socket, no?
The server should actually be listening on the socket it gets told to.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] simple-touch: Handle multiple seats
Previously simple-touch would only handle one seat. If there were
multiple seats it would lose track of whether there is a touch device
available depending on what order the capability events arrive in.
This makes it keep a linked list of seats and to track a separate
touch device for each seat so that it doesn't matter what order they
arrive in.
https://bugs.freedesktop.org/show_bug.cgi?id=78365
---
clients/simple-touch.c | 77 +++---
1 file changed, 60 insertions(+), 17 deletions(-)
diff --git a/clients/simple-touch.c b/clients/simple-touch.c
index b5a84d7..a45de46 100644
--- a/clients/simple-touch.c
+++ b/clients/simple-touch.c
@@ -42,18 +42,25 @@ struct touch {
struct wl_compositor *compositor;
struct wl_shell *shell;
struct wl_shm *shm;
- struct wl_seat *seat;
- struct wl_touch *wl_touch;
struct wl_pointer *pointer;
struct wl_keyboard *keyboard;
struct wl_surface *surface;
struct wl_shell_surface *shell_surface;
struct wl_buffer *buffer;
+ struct wl_list seats;
int has_argb;
int width, height;
void *data;
};
+struct touch_seat {
+ struct touch *touch;
+ struct wl_touch *wl_touch;
+ struct wl_seat *wl_seat;
+ struct wl_list link;
+ uint32_t name;
+};
+
static void
create_shm_buffer(struct touch *touch)
{
@@ -156,7 +163,8 @@ touch_handle_down(void *data, struct wl_touch *wl_touch,
uint32_t serial, uint32_t time, struct wl_surface *surface,
int32_t id, wl_fixed_t x_w, wl_fixed_t y_w)
{
- struct touch *touch = data;
+ struct touch_seat *seat = data;
+ struct touch *touch = seat-touch;
float x = wl_fixed_to_double(x_w);
float y = wl_fixed_to_double(y_w);
@@ -173,7 +181,8 @@ static void
touch_handle_motion(void *data, struct wl_touch *wl_touch,
uint32_t time, int32_t id, wl_fixed_t x_w, wl_fixed_t y_w)
{
- struct touch *touch = data;
+ struct touch_seat *seat = data;
+ struct touch *touch = seat-touch;
float x = wl_fixed_to_double(x_w);
float y = wl_fixed_to_double(y_w);
@@ -199,18 +208,18 @@ static const struct wl_touch_listener touch_listener = {
};
static void
-seat_handle_capabilities(void *data, struct wl_seat *seat,
+seat_handle_capabilities(void *data, struct wl_seat *wl_seat,
enum wl_seat_capability caps)
{
- struct touch *touch = data;
-
- if ((caps WL_SEAT_CAPABILITY_TOUCH) !touch-wl_touch) {
- touch-wl_touch = wl_seat_get_touch(seat);
- wl_touch_set_user_data(touch-wl_touch, touch);
- wl_touch_add_listener(touch-wl_touch, touch_listener, touch);
- } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) touch-wl_touch) {
- wl_touch_destroy(touch-wl_touch);
- touch-wl_touch = NULL;
+ struct touch_seat *seat = data;
+
+ if ((caps WL_SEAT_CAPABILITY_TOUCH) !seat-wl_touch) {
+ seat-wl_touch = wl_seat_get_touch(wl_seat);
+ wl_touch_set_user_data(seat-wl_touch, seat);
+ wl_touch_add_listener(seat-wl_touch, touch_listener, seat);
+ } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) seat-wl_touch) {
+ wl_touch_destroy(seat-wl_touch);
+ seat-wl_touch = NULL;
}
}
@@ -243,6 +252,31 @@ static const struct wl_shell_surface_listener
shell_surface_listener = {
};
static void
+add_seat(struct touch *touch, uint32_t name)
+{
+ struct touch_seat *seat;
+
+ seat = malloc(sizeof *seat);
+ seat-touch = touch;
+ seat-wl_seat = wl_registry_bind(touch-registry, name,
+wl_seat_interface, 1);
+ seat-name = name;
+ seat-wl_touch = NULL;
+ wl_seat_add_listener(seat-wl_seat, seat_listener, seat);
+ wl_list_insert(touch-seats, seat-link);
+}
+
+static void
+remove_seat(struct touch_seat *seat)
+{
+ if (seat-wl_touch)
+ wl_touch_destroy(seat-wl_touch);
+ wl_seat_destroy(seat-wl_seat);
+ wl_list_remove(seat-link);
+ free(seat);
+}
+
+static void
handle_global(void *data, struct wl_registry *registry,
uint32_t name, const char *interface, uint32_t version)
{
@@ -261,15 +295,22 @@ handle_global(void *data, struct wl_registry *registry,
wl_shm_interface, 1);
wl_shm_add_listener(touch-shm, shm_listener, touch);
} else if (strcmp(interface, wl_seat) == 0) {
- touch-seat = wl_registry_bind(registry, name,
- wl_seat_interface, 1);
- wl_seat_add_listener(touch-seat, seat_listener, touch);
+ add_seat(touch, name);
}
}
static void
handle_global_remove(void *data, struct wl_registry *registry, uint32_t name)
{
Re: [PATCH weston] simple-touch: Handle multiple seats
Looks mostly the same as Ander's patch here:
http://lists.freedesktop.org/archives/wayland-devel/2014-May/014658.html
Same review applies :)
On Wed, May 7, 2014 at 10:00 AM, Neil Roberts n...@linux.intel.com wrote:
Previously simple-touch would only handle one seat. If there were
multiple seats it would lose track of whether there is a touch device
available depending on what order the capability events arrive in.
This makes it keep a linked list of seats and to track a separate
touch device for each seat so that it doesn't matter what order they
arrive in.
https://bugs.freedesktop.org/show_bug.cgi?id=78365
---
clients/simple-touch.c | 77
+++---
1 file changed, 60 insertions(+), 17 deletions(-)
diff --git a/clients/simple-touch.c b/clients/simple-touch.c
index b5a84d7..a45de46 100644
--- a/clients/simple-touch.c
+++ b/clients/simple-touch.c
@@ -42,18 +42,25 @@ struct touch {
struct wl_compositor *compositor;
struct wl_shell *shell;
struct wl_shm *shm;
- struct wl_seat *seat;
- struct wl_touch *wl_touch;
struct wl_pointer *pointer;
struct wl_keyboard *keyboard;
struct wl_surface *surface;
struct wl_shell_surface *shell_surface;
struct wl_buffer *buffer;
+ struct wl_list seats;
int has_argb;
int width, height;
void *data;
};
+struct touch_seat {
+ struct touch *touch;
+ struct wl_touch *wl_touch;
+ struct wl_seat *wl_seat;
+ struct wl_list link;
+ uint32_t name;
+};
+
static void
create_shm_buffer(struct touch *touch)
{
@@ -156,7 +163,8 @@ touch_handle_down(void *data, struct wl_touch
*wl_touch,
uint32_t serial, uint32_t time, struct wl_surface
*surface,
int32_t id, wl_fixed_t x_w, wl_fixed_t y_w)
{
- struct touch *touch = data;
+ struct touch_seat *seat = data;
+ struct touch *touch = seat-touch;
float x = wl_fixed_to_double(x_w);
float y = wl_fixed_to_double(y_w);
@@ -173,7 +181,8 @@ static void
touch_handle_motion(void *data, struct wl_touch *wl_touch,
uint32_t time, int32_t id, wl_fixed_t x_w, wl_fixed_t
y_w)
{
- struct touch *touch = data;
+ struct touch_seat *seat = data;
+ struct touch *touch = seat-touch;
float x = wl_fixed_to_double(x_w);
float y = wl_fixed_to_double(y_w);
@@ -199,18 +208,18 @@ static const struct wl_touch_listener touch_listener
= {
};
static void
-seat_handle_capabilities(void *data, struct wl_seat *seat,
+seat_handle_capabilities(void *data, struct wl_seat *wl_seat,
enum wl_seat_capability caps)
{
- struct touch *touch = data;
-
- if ((caps WL_SEAT_CAPABILITY_TOUCH) !touch-wl_touch) {
- touch-wl_touch = wl_seat_get_touch(seat);
- wl_touch_set_user_data(touch-wl_touch, touch);
- wl_touch_add_listener(touch-wl_touch, touch_listener,
touch);
- } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) touch-wl_touch) {
- wl_touch_destroy(touch-wl_touch);
- touch-wl_touch = NULL;
+ struct touch_seat *seat = data;
+
+ if ((caps WL_SEAT_CAPABILITY_TOUCH) !seat-wl_touch) {
+ seat-wl_touch = wl_seat_get_touch(wl_seat);
+ wl_touch_set_user_data(seat-wl_touch, seat);
+ wl_touch_add_listener(seat-wl_touch, touch_listener,
seat);
+ } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) seat-wl_touch) {
+ wl_touch_destroy(seat-wl_touch);
+ seat-wl_touch = NULL;
}
}
@@ -243,6 +252,31 @@ static const struct wl_shell_surface_listener
shell_surface_listener = {
};
static void
+add_seat(struct touch *touch, uint32_t name)
+{
+ struct touch_seat *seat;
+
+ seat = malloc(sizeof *seat);
+ seat-touch = touch;
+ seat-wl_seat = wl_registry_bind(touch-registry, name,
+wl_seat_interface, 1);
+ seat-name = name;
+ seat-wl_touch = NULL;
+ wl_seat_add_listener(seat-wl_seat, seat_listener, seat);
+ wl_list_insert(touch-seats, seat-link);
+}
+
+static void
+remove_seat(struct touch_seat *seat)
+{
+ if (seat-wl_touch)
+ wl_touch_destroy(seat-wl_touch);
+ wl_seat_destroy(seat-wl_seat);
+ wl_list_remove(seat-link);
+ free(seat);
+}
+
+static void
handle_global(void *data, struct wl_registry *registry,
uint32_t name, const char *interface, uint32_t version)
{
@@ -261,15 +295,22 @@ handle_global(void *data, struct wl_registry
*registry,
wl_shm_interface, 1);
wl_shm_add_listener(touch-shm, shm_listener, touch);
} else if (strcmp(interface, wl_seat) == 0) {
-
[PATCH v3] client: extend error handling
When an error occurs, wl_display_get_error() does not
provide any way of getting know if it was a local error or if it was
an error event, respectively what object caused the error and what
the error was.
This patch introduces a new function wl_display_get_protocol_error()
which will return error code, interface and id of the object that
generated the error.
wl_display_get_error() will work the same way as before.
wl_display_get_protocol_error() DOES NOT indicate that a non-protocol
error happened. It returns valid information only in that case that
(protocol) error occurred, so it should be used after calling
wl_display_get_error() with positive result.
Thanks to Pekka Paalanen ppaala...@gmail.com for pointing out
issues in the first versions of this patch.
---
src/wayland-client.c | 138 ---
src/wayland-client.h | 3 ++
2 files changed, 123 insertions(+), 18 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index bd40313..c9f8f4f 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -78,7 +78,24 @@ struct wl_event_queue {
struct wl_display {
struct wl_proxy proxy;
struct wl_connection *connection;
+
+ /* errno of the last wl_display error */
int last_error;
+
+ /* When display gets an error event from some object, it stores
+* information about it here, so that client can get this
+* information afterwards */
+ struct {
+ /* Code of the error. It can be compared to
+* the interface's errors enumeration. */
+ uint32_t code;
+ /* interface (protocol) in which the error occurred */
+ const struct wl_interface *interface;
+ /* id of the proxy that caused the error. There's no warranty
+* that the proxy is still valid. It's up to client how it will
+* use it */
+ uint32_t id;
+ } protocol_error;
int fd;
pthread_t display_thread;
struct wl_map objects;
@@ -96,6 +113,14 @@ struct wl_display {
static int debug_client = 0;
+/**
+ * This function is called for local errors (no memory, server hung up)
+ *
+ * \param display
+ * \param errorerror value (EINVAL, EFAULT, ...)
+ *
+ * \note this function is called with display mutex locked
+ */
static void
display_fatal_error(struct wl_display *display, int error)
{
@@ -105,7 +130,7 @@ display_fatal_error(struct wl_display *display, int error)
return;
if (!error)
- error = 1;
+ error = EFAULT;
display-last_error = error;
@@ -113,11 +138,56 @@ display_fatal_error(struct wl_display *display, int error)
pthread_cond_broadcast(iter-cond);
}
+/**
+ * This function is called for error events
+ * and idicates that in some object occured an error.
+ * Difference between this function and display_fatal_error()
+ * is that this one handles errors that will come in wire, whereas
+ * display_fatal_error() is called for local errors.
+ *
+ * \param display
+ * \param codeerror code
+ * \param id id of the object that generated the error
+ * \param intfprotocol interface
+ */
static void
-wl_display_fatal_error(struct wl_display *display, int error)
+display_protocol_error(struct wl_display *display, uint32_t code,
+ uint32_t id, const struct wl_interface *intf)
{
+ struct wl_event_queue *iter;
+ int err;
+
+ if (display-last_error)
+ return;
+
+ /* set correct errno */
+ if (wl_interface_equal(intf, wl_display_interface)) {
+ switch (code) {
+ case WL_DISPLAY_ERROR_INVALID_OBJECT:
+ case WL_DISPLAY_ERROR_INVALID_METHOD:
+ err = EINVAL;
+ break;
+ case WL_DISPLAY_ERROR_NO_MEMORY:
+ err = ENOMEM;
+ break;
+ default:
+ err = EFAULT;
+ }
+ } else {
+ err = EPROTO;
+ }
+
pthread_mutex_lock(display-mutex);
- display_fatal_error(display, error);
+
+ display-last_error = err;
+
+ display-protocol_error.code = code;
+ display-protocol_error.id = id;
+ display-protocol_error.interface = intf;
+
+ wl_list_for_each(iter, display-event_queue_list, link)
+ pthread_cond_broadcast(iter-cond);
+
pthread_mutex_unlock(display-mutex);
}
@@ -579,25 +649,12 @@ display_handle_error(void *data,
uint32_t code, const char *message)
{
struct wl_proxy *proxy = object;
- int err;
wl_log(%s@%u: error %d: %s\n,
proxy-object.interface-name, proxy-object.id, code, message);
- switch (code) {
- case WL_DISPLAY_ERROR_INVALID_OBJECT:
- case WL_DISPLAY_ERROR_INVALID_METHOD:
-
Re: [PATCH v3] client: extend error handling
On 5 May 2014 15:02, Pekka Paalanen ppaala...@gmail.com wrote:
On Wed, 30 Apr 2014 10:11:01 +0200
Marek Chalupa mchqwe...@gmail.com wrote:
When an error occurs, wl_display_get_error() does not
provide any way of getting know if it was a local error or if it was
an error event, respectively what object caused the error and what
the error was.
This patch introduces a new function wl_display_get_protocol_error()
which will return error code, interface and id of the object that
generated the error.
wl_display_get_error() will work the same way as before.
wl_display_get_protocol_error() DOES NOT indicate that a non-protocol
error happened. It returns valid information only in that case that
(protocol) error occurred, so it should be used after calling
wl_display_get_error() with positive result.
Thanks to Pekka Paalanen ppaala...@gmail.com for pointing out
issues in the first versions of this patch.
---
src/wayland-client.c | 138
---
src/wayland-client.h | 3 ++
2 files changed, 123 insertions(+), 18 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index bd40313..8dd8804 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -78,7 +78,24 @@ struct wl_event_queue {
struct wl_display {
struct wl_proxy proxy;
struct wl_connection *connection;
+
+ /* errno of the last wl_display error */
int last_error;
+
+ /* When display gets an error event from some object, it stores
+ * information about it here, so that client can get this
+ * information afterwards */
+ struct {
+ /* Code of the error. It can be compared to
+ * the interface's errors enumeration. */
+ int code;
I just checked in wl_display::error specification, and the type of the
error code is uint32_t.
+ /* interface (protocol) in which the error occurred */
+ const struct wl_interface *interface;
+ /* id of the proxy that caused the error. There's no
warranty
+ * that the proxy is still valid. It's up to client how it
will
+ * use it */
+ uint32_t id;
+ } protocol_error;
int fd;
pthread_t display_thread;
struct wl_map objects;
@@ -96,6 +113,14 @@ struct wl_display {
static int debug_client = 0;
+/**
+ * This function is called for local errors (no memory, server hung up)
+ *
+ * \param display
+ * \param errorerror value (EINVAL, EFAULT, ...)
+ *
+ * \note this function is called with display mutex locked
+ */
static void
display_fatal_error(struct wl_display *display, int error)
{
@@ -105,7 +130,7 @@ display_fatal_error(struct wl_display *display, int
error)
return;
if (!error)
- error = 1;
+ error = EFAULT;
display-last_error = error;
@@ -113,11 +138,56 @@ display_fatal_error(struct wl_display *display,
int error)
pthread_cond_broadcast(iter-cond);
}
+/**
+ * This function is called for error events
+ * and idicates that in some object occured an error.
+ * Difference between this function and display_fatal_error()
+ * is that this one handles errors that will come in wire, whereas
+ * display_fatal_error() is called for local errors.
+ *
+ * \param display
+ * \param codeerror code
+ * \param id id of the object that generated the error
+ * \param intfprotocol interface
+ */
static void
-wl_display_fatal_error(struct wl_display *display, int error)
+display_protocol_error(struct wl_display *display, int code,
+unsigned int id, const struct wl_interface *intf)
{
+ struct wl_event_queue *iter;
+ int err;
+
+ if (display-last_error)
+ return;
+
+ /* set correct errno */
+ if (wl_interface_equal(intf, wl_display_interface)) {
+ switch (code) {
+ case WL_DISPLAY_ERROR_INVALID_OBJECT:
+ case WL_DISPLAY_ERROR_INVALID_METHOD:
+ err = EINVAL;
+ break;
+ case WL_DISPLAY_ERROR_NO_MEMORY:
+ err = ENOMEM;
+ break;
+ default:
+ err = EFAULT;
+ }
+ } else {
+ err = EPROTO;
+ }
+
pthread_mutex_lock(display-mutex);
- display_fatal_error(display, error);
+
+ display-last_error = err;
+
+ display-protocol_error.code = code;
+ display-protocol_error.id = id;
+ display-protocol_error.interface = intf;
+
+ wl_list_for_each(iter, display-event_queue_list, link)
+ pthread_cond_broadcast(iter-cond);
+
pthread_mutex_unlock(display-mutex);
}
@@ -579,25 +649,12 @@
[PATCH wayland 0/3] Add API to automatically select a display name
v2 of my patch series. v1 was broken because I didn't test it properly. This one should actually work. First patch also had a resource leak fixed. Second patch is the same. Third patch takes a new approach. Jasper St. Pierre (3): server: Create the socket FD after taking the lock server: Split out code to open sockets for a specific display name server: Add a simple API to find a good default display src/wayland-server.c | 78 src/wayland-server.h | 2 ++ 2 files changed, 57 insertions(+), 23 deletions(-) -- 1.9.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 2/3] server: Split out code to open sockets for a specific display name
We'll use this to autodetect a good socket to open on.
---
src/wayland-server.c | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index d0fd280..6bc8dc3 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1039,11 +1039,9 @@ get_socket_lock(struct wl_socket *socket)
return fd_lock;
}
-WL_EXPORT int
-wl_display_add_socket(struct wl_display *display, const char *name)
+static int
+open_socket_for_display_name(struct wl_socket *s, const char *name)
{
- struct wl_socket *s;
- socklen_t size;
int name_size;
const char *runtime_dir;
@@ -1057,15 +1055,6 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
return -1;
}
- s = malloc(sizeof *s);
- if (s == NULL)
- return -1;
-
- if (name == NULL)
- name = getenv(WAYLAND_DISPLAY);
- if (name == NULL)
- name = wayland-0;
-
memset(s-addr, 0, sizeof s-addr);
s-addr.sun_family = AF_LOCAL;
name_size = snprintf(s-addr.sun_path, sizeof s-addr.sun_path,
@@ -1075,7 +1064,6 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
if (name_size (int)sizeof s-addr.sun_path) {
wl_log(error: socket path \%s/%s\ plus null terminator
exceeds 108 bytes\n, runtime_dir, name);
- free(s);
/* to prevent programs reporting
* failed to add socket: Success */
errno = ENAMETOOLONG;
@@ -1084,6 +1072,28 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
s-fd_lock = get_socket_lock(s);
if (s-fd_lock 0) {
+ return -1;
+ }
+
+ return 0;
+}
+
+WL_EXPORT int
+wl_display_add_socket(struct wl_display *display, const char *name)
+{
+ struct wl_socket *s;
+ socklen_t size;
+
+ s = malloc(sizeof *s);
+ if (s == NULL)
+ return -1;
+
+ if (name == NULL)
+ name = getenv(WAYLAND_DISPLAY);
+ if (name == NULL)
+ name = wayland-0;
+
+ if (open_socket_for_display_name(s, name) 0) {
free(s);
return -1;
}
@@ -1095,7 +1105,7 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
return -1;
}
- size = offsetof (struct sockaddr_un, sun_path) + name_size;
+ size = offsetof (struct sockaddr_un, sun_path) +
strlen(s-addr.sun_path);
if (bind(s-fd, (struct sockaddr *) s-addr, size) 0) {
wl_log(bind() failed with error: %m\n);
close(s-fd);
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 1/3] server: Create the socket FD after taking the lock
---
src/wayland-server.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index e850d48..d0fd280 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1061,12 +1061,6 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
if (s == NULL)
return -1;
- s-fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
- if (s-fd 0) {
- free(s);
- return -1;
- }
-
if (name == NULL)
name = getenv(WAYLAND_DISPLAY);
if (name == NULL)
@@ -1081,7 +1075,6 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
if (name_size (int)sizeof s-addr.sun_path) {
wl_log(error: socket path \%s/%s\ plus null terminator
exceeds 108 bytes\n, runtime_dir, name);
- close(s-fd);
free(s);
/* to prevent programs reporting
* failed to add socket: Success */
@@ -1091,7 +1084,13 @@ wl_display_add_socket(struct wl_display *display, const
char *name)
s-fd_lock = get_socket_lock(s);
if (s-fd_lock 0) {
- close(s-fd);
+ free(s);
+ return -1;
+ }
+
+ s-fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
+ if (s-fd 0) {
+ close(s-fd_lock);
free(s);
return -1;
}
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 3/3] server: Add a simple API to find a good default display
This allows compositors to easily select a good display to listen on.
---
src/wayland-server.c | 23 +++
src/wayland-server.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 6bc8dc3..5624199 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1078,6 +1078,29 @@ open_socket_for_display_name(struct wl_socket *s, const
char *name)
return 0;
}
+WL_EXPORT char *
+wl_choose_default_display(void)
+{
+ struct wl_socket s = { 0 };
+ int displayno = 0;
+ char display_name[16] = ;
+
+ /* A reasonable number of maximum default sockets. If
+* you need more than this, set WAYLAND_DISPLAY explicitly. */
+ const int MAX_DISPLAYNO = 32;
+
+ do {
+ snprintf(display_name, sizeof display_name, wayland-%d,
displayno);
+ if (open_socket_for_display_name(s, display_name) = 0) {
+ close(s-fd_lock);
+ return strdup(display_name);
+ }
+ } while (displayno++ MAX_DISPLAYNO);
+
+ errno = EINVAL;
+ return NULL;
+}
+
WL_EXPORT int
wl_display_add_socket(struct wl_display *display, const char *name)
{
diff --git a/src/wayland-server.h b/src/wayland-server.h
index 7fc5b47..c9834f1 100644
--- a/src/wayland-server.h
+++ b/src/wayland-server.h
@@ -88,6 +88,8 @@ struct wl_listener *wl_event_loop_get_destroy_listener(
struct wl_event_loop *loop,
wl_notify_func_t notify);
+char *wl_choose_default_socket(void);
+
struct wl_display *wl_display_create(void);
void wl_display_destroy(struct wl_display *display);
struct wl_event_loop *wl_display_get_event_loop(struct wl_display *display);
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] compositor: Use libwayland to find a good default display for us
--- src/compositor.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/compositor.c b/src/compositor.c index 3d65e4c..1906441 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -4150,7 +4150,7 @@ int main(int argc, char *argv[]) char *server_socket = NULL, *end; int32_t idle_time = 300; int32_t help = 0; - char *socket_name = wayland-0; + char *socket_name = NULL; int32_t version = 0; struct weston_config *config; struct weston_config_section *section; @@ -4245,6 +4245,9 @@ int main(int argc, char *argv[]) ec-idle_time = idle_time; ec-default_pointer_grab = NULL; + if (socket_name == NULL) + socket_name = wl_choose_default_display(); + setenv(WAYLAND_DISPLAY, socket_name, 1); if (option_shell) -- 1.9.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/3] simple-touch: Handle multiple seats properly
Oh no, I didn't notice this patch buried in the patch series and
implemented the same thing:
http://lists.freedesktop.org/archives/wayland-devel/2014-May/014690.html
Ander, it would be really helpful if you could leave a little note on
the bug report if you post a patch to reduce that chance that I'll waste
time looking at the same bug.
Regards,
- Neil
Ander Conselvan de Oliveira conselv...@gmail.com writes:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
If simple-touch ran on a compositor with multiple seats, and the first
one happened to have the touch capability while the second one didn't,
the handler for seat capabilities would destroy the wl_touch device it
created on the first call for the first seat when it was called a again
for the second seat that has not touch capabilities.
Fix this problem by creating a separate struct for each seat.
https://bugs.freedesktop.org/show_bug.cgi?id=78365
---
clients/simple-touch.c | 48 +---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/clients/simple-touch.c b/clients/simple-touch.c
index b5a84d7..d8439ac 100644
--- a/clients/simple-touch.c
+++ b/clients/simple-touch.c
@@ -36,14 +36,18 @@
#define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
+struct seat {
+ struct touch *touch;
+ struct wl_seat *seat;
+ struct wl_touch *wl_touch;
+};
+
struct touch {
struct wl_display *display;
struct wl_registry *registry;
struct wl_compositor *compositor;
struct wl_shell *shell;
struct wl_shm *shm;
- struct wl_seat *seat;
- struct wl_touch *wl_touch;
struct wl_pointer *pointer;
struct wl_keyboard *keyboard;
struct wl_surface *surface;
@@ -199,18 +203,19 @@ static const struct wl_touch_listener touch_listener = {
};
static void
-seat_handle_capabilities(void *data, struct wl_seat *seat,
+seat_handle_capabilities(void *data, struct wl_seat *wl_seat,
enum wl_seat_capability caps)
{
- struct touch *touch = data;
-
- if ((caps WL_SEAT_CAPABILITY_TOUCH) !touch-wl_touch) {
- touch-wl_touch = wl_seat_get_touch(seat);
- wl_touch_set_user_data(touch-wl_touch, touch);
- wl_touch_add_listener(touch-wl_touch, touch_listener, touch);
- } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) touch-wl_touch) {
- wl_touch_destroy(touch-wl_touch);
- touch-wl_touch = NULL;
+ struct seat *seat = data;
+ struct touch *touch = seat-touch;
+
+ if ((caps WL_SEAT_CAPABILITY_TOUCH) !seat-wl_touch) {
+ seat-wl_touch = wl_seat_get_touch(wl_seat);
+ wl_touch_set_user_data(seat-wl_touch, touch);
+ wl_touch_add_listener(seat-wl_touch, touch_listener, touch);
+ } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) seat-wl_touch) {
+ wl_touch_destroy(seat-wl_touch);
+ seat-wl_touch = NULL;
}
}
@@ -219,6 +224,21 @@ static const struct wl_seat_listener seat_listener = {
};
static void
+add_seat(struct touch *touch, uint32_t name, uint32_t version)
+{
+ struct seat *seat;
+
+ seat = malloc(sizeof *seat);
+ assert(seat);
+
+ seat-touch = touch;
+ seat-wl_touch = NULL;
+ seat-seat = wl_registry_bind(touch-registry, name,
+ wl_seat_interface, 1);
+ wl_seat_add_listener(seat-seat, seat_listener, seat);
+}
+
+static void
handle_ping(void *data, struct wl_shell_surface *shell_surface,
uint32_t serial)
{
@@ -261,9 +281,7 @@ handle_global(void *data, struct wl_registry *registry,
wl_shm_interface, 1);
wl_shm_add_listener(touch-shm, shm_listener, touch);
} else if (strcmp(interface, wl_seat) == 0) {
- touch-seat = wl_registry_bind(registry, name,
-wl_seat_interface, 1);
- wl_seat_add_listener(touch-seat, seat_listener, touch);
+ add_seat(touch, name, version);
}
}
--
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: Bug 78372 - create multiple windows with offset
Yes i'm working for embedded platform where with current desktop shell we cant debug two overlays visually running same apps with same size. Thanks You . Rohit Nandan On Wed, May 7, 2014 at 6:49 PM, Jasper St. Pierre jstpie...@mecheye.netwrote: The rationale explained in the bug by Pekka and Emilio sounds OK to me. Explaining a bit more about your use case with your data visualization app might be helpful. What kinds of systems do you want your app to be run on? Generic desktop systems? If so, then you can't guarantee anything about utilizing hardware overlays, as the user might be watching a video at the same time, which should take HW overlay priority over your application to prevent a YUV - RGB conversion in software. If you have a special usecase like a Bloomberg terminal, then making your own shell and shell protocol like the IVI team is doing might be a better solution, so you can guarantee window position and HW utilization. The default desktop-shell is very much designed for desktop Linux use cases, where we don't want to expose global window positions or make any guarantees to the client about where they are on screen, precisely so you don't assume you are the only user of the HW. On Wed, May 7, 2014 at 5:51 AM, Rohit Nandan pulkitnan...@gmail.comwrote: Please go through this NOTABUG bug. https://bugs.freedesktop.org/show_bug.cgi?id=78372 Rohit Nandan ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
On 05/07/2014 01:47 AM, Pekka Paalanen wrote: It is for normal windows like registered with xdg_shell where sub-surfaces are not suitable for tooltips. A sub-surface is a part of the window, not another window. A tooltip is not expected to change the window geometry, but a sub-surface does count into the window geometry. Extruding sub-surfaces therefore affect the (parent) window geometry. It is in the protocol spec. Are you saying that a sub-surface that extends outside the area of the parent surface should cause mouse/touch events in this extended area to be delivered to the parent? My personal feeling is that the intuitive approach that events are delivered normally to subsurfaces is the correct one. Especially if subsurfaces are going to be the method of embedding one client inside another. I think it is ok to say that subsurfaces with non-empty input areas are broken in toytoolkit. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
Events aren't delivered to surfaces. They're delivered to clients. On Wed, May 7, 2014 at 2:02 PM, Bill Spitzak spit...@gmail.com wrote: On 05/07/2014 01:47 AM, Pekka Paalanen wrote: It is for normal windows like registered with xdg_shell where sub-surfaces are not suitable for tooltips. A sub-surface is a part of the window, not another window. A tooltip is not expected to change the window geometry, but a sub-surface does count into the window geometry. Extruding sub-surfaces therefore affect the (parent) window geometry. It is in the protocol spec. Are you saying that a sub-surface that extends outside the area of the parent surface should cause mouse/touch events in this extended area to be delivered to the parent? My personal feeling is that the intuitive approach that events are delivered normally to subsurfaces is the correct one. Especially if subsurfaces are going to be the method of embedding one client inside another. I think it is ok to say that subsurfaces with non-empty input areas are broken in toytoolkit. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: More build problems: dri2proto
On 05/07/2014 03:04 AM, Pekka Paalanen wrote: Maybe you forgot to set some of the environment variables from here: http://wayland.freedesktop.org/building.html Don't play with the foofoo_CFLAGS and foofoo_LIBS variables, it is much better to fix pkg-config to find the right .pc files. Thank you, yes I forgot to export the variables. Not sure why I managed to get so far without them (for instance building a local copy of glproto fixed things), but I guess most of the autoconf scripts use the --prefix switch, but for some reason mesa only uses the environment variables in this one case. Any chance this is a bug, and which version is wrong? I can see reasons that --prefix should only effect the output of compilation and not the input so in fact mesa is the only one doing this right, and only for dri2proto... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] compositor-wayland: fix leak in create_cursor when theme load fails
Free the theme configuration string right after wl_cursor_load_theme
since we're done using it. This fixes a leak when the cursor theme
could not be loaded.
Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com
---
src/compositor-wayland.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index a08b71a..f7ccded 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1869,13 +1869,13 @@ create_cursor(struct wayland_compositor *c, struct
weston_config *config)
weston_config_section_get_int(s, cursor-size, size, 32);
c-cursor_theme = wl_cursor_theme_load(theme, size, c-parent.shm);
+ free(theme);
+
if (!c-cursor_theme) {
fprintf(stderr, could not load cursor theme\n);
return;
}
- free(theme);
-
c-cursor = NULL;
for (i = 0; !c-cursor i ARRAY_LENGTH(left_ptrs); ++i)
c-cursor = wl_cursor_theme_get_cursor(c-cursor_theme,
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
Sorry, what I meant was the surface id and xy location in events. If a subsurface belongs to a different client than the parent surface, though, does this mean the child client will get events that have an xy position relative to the parent surface? On 05/07/2014 11:05 AM, Jasper St. Pierre wrote: Events aren't delivered to surfaces. They're delivered to clients. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
On 7 May 2014 20:23, Bill Spitzak spit...@gmail.com wrote: If a subsurface belongs to a different client than the parent surface, though, does this mean the child client will get events that have an xy position relative to the parent surface? As a fundamental design point of the Wayland protocol is that clients cannot reference objects from other clients, this cannot happen. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 2/5] clients: Use x*alloc routines for memory allocation
This fixes a few possible NULL deref's, too... not that it matters much
once you're in an OOM situation.
LGTM
-- U. Artie
-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On
Behalf Of Bryce W. Harrington
Sent: Tuesday, May 06, 2014 7:13 PM
To: wayland-devel@lists.freedesktop.org
Cc: Bryce W. Harrington
Subject: [PATCH 2/5] clients: Use x*alloc routines for memory allocation
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;
weston logind and display managers
Hi, I'm porting sddm (QtQuick based display manager) to Wayland, it's still work in progress but close to be in a usable state and you can find it here: https://github.com/plfiorini/sddm/tree/wayland There are some multiple screen issues specific to how sddm work compared to wl_fullscreen_shell but at least i've got it to display a window on the primary screen and that's good enough for now. All is going well so far however it's still not capable of running a weston session. I managed to acquire a new tty every time a wayland session is started, then I set the owner and read/write permission only to the user that just logged in and open an fd for the tty but weston fails with the following errors: logind: cannot set K_OFF KB-mode on /dev/tty2: Operation not permitted logind: cannot setup systemd-logind helper (-1), using legacy fallback fatal: drm backend should be run using weston-launch binary or as root fatal: failed to create compositor Is there something I'm missing in setting up the tty? -- Out of the box experience http://www.maui-project.org/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 1/3] server: Create the socket FD after taking the lock
Yeah, this looks good to me. It does change the order of a couple of
system calls, but it looks ok to me.
Reviewed-by: Jason Ekstrand ja...@jlekstrand.net
On Wed, May 7, 2014 at 9:25 AM, Jasper St. Pierre jstpie...@mecheye.netwrote:
---
src/wayland-server.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index e850d48..d0fd280 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1061,12 +1061,6 @@ wl_display_add_socket(struct wl_display *display,
const char *name)
if (s == NULL)
return -1;
- s-fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
- if (s-fd 0) {
- free(s);
- return -1;
- }
-
if (name == NULL)
name = getenv(WAYLAND_DISPLAY);
if (name == NULL)
@@ -1081,7 +1075,6 @@ wl_display_add_socket(struct wl_display *display,
const char *name)
if (name_size (int)sizeof s-addr.sun_path) {
wl_log(error: socket path \%s/%s\ plus null terminator
exceeds 108 bytes\n, runtime_dir, name);
- close(s-fd);
free(s);
/* to prevent programs reporting
* failed to add socket: Success */
@@ -1091,7 +1084,13 @@ wl_display_add_socket(struct wl_display *display,
const char *name)
s-fd_lock = get_socket_lock(s);
if (s-fd_lock 0) {
- close(s-fd);
+ free(s);
+ return -1;
+ }
+
+ s-fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
+ if (s-fd 0) {
+ close(s-fd_lock);
free(s);
return -1;
}
--
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 2/3] server: Split out code to open sockets for a specific display name
Comments below,
--Jason Ekstrand
On Wed, May 7, 2014 at 9:25 AM, Jasper St. Pierre jstpie...@mecheye.netwrote:
We'll use this to autodetect a good socket to open on.
---
src/wayland-server.c | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index d0fd280..6bc8dc3 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1039,11 +1039,9 @@ get_socket_lock(struct wl_socket *socket)
return fd_lock;
}
-WL_EXPORT int
-wl_display_add_socket(struct wl_display *display, const char *name)
+static int
+open_socket_for_display_name(struct wl_socket *s, const char *name)
Perhaps, this should be named differently. How about wl_socket_try_lock.
The problem is that it doesn't really open the socket (assuming I put this
and the previous patch together correctly in my head).
{
- struct wl_socket *s;
- socklen_t size;
int name_size;
const char *runtime_dir;
@@ -1057,15 +1055,6 @@ wl_display_add_socket(struct wl_display *display,
const char *name)
return -1;
}
- s = malloc(sizeof *s);
- if (s == NULL)
- return -1;
-
- if (name == NULL)
- name = getenv(WAYLAND_DISPLAY);
- if (name == NULL)
- name = wayland-0;
-
memset(s-addr, 0, sizeof s-addr);
s-addr.sun_family = AF_LOCAL;
name_size = snprintf(s-addr.sun_path, sizeof s-addr.sun_path,
@@ -1075,7 +1064,6 @@ wl_display_add_socket(struct wl_display *display,
const char *name)
if (name_size (int)sizeof s-addr.sun_path) {
wl_log(error: socket path \%s/%s\ plus null terminator
exceeds 108 bytes\n, runtime_dir, name);
- free(s);
/* to prevent programs reporting
* failed to add socket: Success */
errno = ENAMETOOLONG;
Why are we filling addr structure here and doing nothing with it? Perhaps
filling the addr structure should stay in wl_display_add_socket?
@@ -1084,6 +1072,28 @@ wl_display_add_socket(struct wl_display *display,
const char *name)
s-fd_lock = get_socket_lock(s);
if (s-fd_lock 0) {
+ return -1;
+ }
This is right before opening the socket, so it returns with an invalid
value in s-fd.
+
+ return 0;
+}
+
+WL_EXPORT int
+wl_display_add_socket(struct wl_display *display, const char *name)
+{
+ struct wl_socket *s;
+ socklen_t size;
+
+ s = malloc(sizeof *s);
+ if (s == NULL)
+ return -1;
+
+ if (name == NULL)
+ name = getenv(WAYLAND_DISPLAY);
+ if (name == NULL)
+ name = wayland-0;
+
+ if (open_socket_for_display_name(s, name) 0) {
free(s);
return -1;
}
@@ -1095,7 +1105,7 @@ wl_display_add_socket(struct wl_display *display,
const char *name)
return -1;
}
- size = offsetof (struct sockaddr_un, sun_path) + name_size;
+ size = offsetof (struct sockaddr_un, sun_path) +
strlen(s-addr.sun_path);
if (bind(s-fd, (struct sockaddr *) s-addr, size) 0) {
wl_log(bind() failed with error: %m\n);
close(s-fd);
--
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 3/3] server: Add a simple API to find a good default display
On Wed, May 7, 2014 at 9:25 AM, Jasper St. Pierre jstpie...@mecheye.netwrote:
This allows compositors to easily select a good display to listen on.
---
src/wayland-server.c | 23 +++
src/wayland-server.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 6bc8dc3..5624199 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1078,6 +1078,29 @@ open_socket_for_display_name(struct wl_socket *s,
const char *name)
return 0;
}
+WL_EXPORT char *
+wl_choose_default_display(void)
I mentioned this on IRC, but this seems like an awkward name. Perhaps
something like wl_display_choose_default_name? See also below.
+{
+ struct wl_socket s = { 0 };
+ int displayno = 0;
+ char display_name[16] = ;
+
+ /* A reasonable number of maximum default sockets. If
+* you need more than this, set WAYLAND_DISPLAY explicitly. */
+ const int MAX_DISPLAYNO = 32;
+
+ do {
+ snprintf(display_name, sizeof display_name, wayland-%d,
displayno);
+ if (open_socket_for_display_name(s, display_name) = 0) {
+ close(s-fd_lock);
+ return strdup(display_name);
We have a race condition here. If two compositors start up at the same
time, it's possible that wl_choose_default_display will return wayland-1
but then, before we get a chance to actually re-lock and connect to it,
some other compositor opens it. Honestly, this probably isn't going to be
a huge problem in practice. However, we may want to re-think the API a bit.
One option would be to do the enumeration in wl_display_add_socket if the
given name is NULL. This is a small API break, but all it changes is if
name==NULL and WAYLAND_DISPLAY is not set and wayland-0 is taken, fail to
if name==NULL and WAYLAND_DISPLAY is not set and wayland-0 is taken, try
wayland-1 etc.. It slightly changes default behavior, but I don't really
see why failing on wayland-0 being taken is a good thing.
Thanks,
--Jason Ekstrand
+ }
+ } while (displayno++ MAX_DISPLAYNO);
+
+ errno = EINVAL;
+ return NULL;
+}
+
WL_EXPORT int
wl_display_add_socket(struct wl_display *display, const char *name)
{
diff --git a/src/wayland-server.h b/src/wayland-server.h
index 7fc5b47..c9834f1 100644
--- a/src/wayland-server.h
+++ b/src/wayland-server.h
@@ -88,6 +88,8 @@ struct wl_listener *wl_event_loop_get_destroy_listener(
struct wl_event_loop *loop,
wl_notify_func_t notify);
+char *wl_choose_default_socket(void);
+
struct wl_display *wl_display_create(void);
void wl_display_destroy(struct wl_display *display);
struct wl_event_loop *wl_display_get_event_loop(struct wl_display
*display);
--
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 1/2] cairo-util: Add frame_touch_motion support
On Tue, May 6, 2014 at 9:46 PM, Boyan Ding stu_...@126.com wrote:
---
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);
Are you sure that these are the semantics we want? Most touch interfaces,
don't let you slide onto a button. For instance, given the way this is
written, if you put your finger down, slide onto the close button and then
slide off without picking up your finger, the close button will see a press
and a release and the window will close. I think what we want to do here
is to mirror what is done for a mouse pointer. Only press the button on
finger down and then, on finger up either release or cancel the button
depending on whether the finger is still on the button or not.
+}
+
+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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] weston: Add touch support to nested wayland backend
Boyan, Thanks for picking this up! I'm making some comments on the patches themselves. Unfortunately, I don't have touch hardware to test it with, but I hope my comments are helpful none the less. --Jason Ekstrand On Tue, May 6, 2014 at 9:46 PM, Boyan Ding stu_...@126.com wrote: 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] compositor-wayland: Add touch support
Boyan,
By and large, this looks really good! I have just a few comments below.
As I said in another e-mail, I don't have any touch hardware I can test
this on, so I wasn't able to actually test it.
On Tue, May 6, 2014 at 9:46 PM, Boyan Ding stu_...@126.com wrote:
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);
You probably want to handle FRAME_STATUS_MOVE here. See also
input_handle_button.
+
+ 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);
+
You need to handle FRAME_STATUS_CLOSE here. See also input_handle_button.
Perhaps, we want to add a wayland_output_handle_frame_status function to
handle all of these so they can all be put in one place. If we want to do
that, then it should probably be in it's own patch.
+ 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)
+{
We should add a frame_touch_cancel function to frame.c and call it here.
Also, we should probably add support for WL_TOUCH_CANCEL in notify_touch in
input.c and call it here. If that's a little too involved for now, that's
ok. Just call notify_touch(input-base, 0, -1, 0, 0, WL_TOUCH_CANCEL)
here and we can implement it in notify_touch later. It's just a big switch
statement, so this won't hurt anything.
+}
+
+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);
+
Re: [PATCH] Do not distribute generated headers
I won't claim to be an autotools expert, but this looks sane to me.
Probably something we want to take care of for 1.5.
Reviewed-by: Jason Ekstrand ja...@jlekstrand.net
On Wed, May 7, 2014 at 7:09 AM, Thierry Reding thierry.red...@gmail.comwrote:
From: Thierry Reding tred...@nvidia.com
The wayland-server-protocol.h and wayland-client-protocol.h headers are
currently being shipped in tarballs created using make dist. This causes
out-of-tree builds to fail since make will detect that the headers exist
by looking at the source directory (via VPATH) and not regenerate them.
But as opposed to ${top_builddir}/protocol, ${top_srcdir}/protocol is
not part of the include path and therefore the shipped files can't be
found during compilation.
Two solutions exist to this problem: 1) add ${top_srcdir}/protocol to
the include path to allow shipped files to be used if available or 2)
don't ship these generated files in release tarballs. The latter seems
the most appropriate. wayland-scanner is already a prerequisite in order
to generate wayland-protocol.c, so it is either built as part of the
package or provided externally. Generating all files from the protocol
definition at build time also ensures that they don't get out of sync.
Both of the generated headers are already listed in Makefile.am as
nodist_*_SOURCES, but at the same time they appear in include_HEADERS,
which will cause them to be added to the list of distributable files
after all. To prevent that, split them off into nodist_include_HEADERS.
Note that this problem will be hidden if a previous version of wayland
has been installed, since these files will exist in /usr/include and be
included from there. So this build error will only show for out-of-tree
builds on systems that don't have wayland installed yet.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Makefile.am | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index f1584d5bfc12..0ec6f47ab2c7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -20,13 +20,15 @@ noinst_LTLIBRARIES = libwayland-util.la
include_HEADERS = \
src/wayland-util.h \
- protocol/wayland-server-protocol.h \
src/wayland-server.h\
- protocol/wayland-client-protocol.h \
src/wayland-client.h\
src/wayland-egl.h \
src/wayland-version.h
+nodist_include_HEADERS = \
+ protocol/wayland-server-protocol.h \
+ protocol/wayland-client-protocol.h
+
libwayland_util_la_SOURCES = \
src/connection.c\
src/wayland-util.c \
--
1.9.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 wayland 3/3] server: Add a simple API to find a good default display
On Wed, May 7, 2014 at 9:31 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
On Wed, May 7, 2014 at 9:25 AM, Jasper St. Pierre
jstpie...@mecheye.netwrote:
This allows compositors to easily select a good display to listen on.
---
src/wayland-server.c | 23 +++
src/wayland-server.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 6bc8dc3..5624199 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1078,6 +1078,29 @@ open_socket_for_display_name(struct wl_socket *s,
const char *name)
return 0;
}
+WL_EXPORT char *
+wl_choose_default_display(void)
I mentioned this on IRC, but this seems like an awkward name. Perhaps
something like wl_display_choose_default_name? See also below.
+{
+ struct wl_socket s = { 0 };
+ int displayno = 0;
+ char display_name[16] = ;
+
+ /* A reasonable number of maximum default sockets. If
+* you need more than this, set WAYLAND_DISPLAY explicitly. */
+ const int MAX_DISPLAYNO = 32;
+
+ do {
+ snprintf(display_name, sizeof display_name, wayland-%d,
displayno);
+ if (open_socket_for_display_name(s, display_name) = 0) {
+ close(s-fd_lock);
+ return strdup(display_name);
We have a race condition here. If two compositors start up at the same
time, it's possible that wl_choose_default_display will return wayland-1
but then, before we get a chance to actually re-lock and connect to it,
some other compositor opens it. Honestly, this probably isn't going to be
a huge problem in practice. However, we may want to re-think the API a bit.
One option would be to do the enumeration in wl_display_add_socket if the
given name is NULL. This is a small API break, but all it changes is if
name==NULL and WAYLAND_DISPLAY is not set and wayland-0 is taken, fail to
if name==NULL and WAYLAND_DISPLAY is not set and wayland-0 is taken, try
wayland-1 etc.. It slightly changes default behavior, but I don't really
see why failing on wayland-0 being taken is a good thing.
This was my initial approach, but then there's no way for a compositor to
know which display name was chosen, so it can set WAYLAND_DISPLAY. We could
save the name we used in the wl_display, if you'd prefer that.
Thanks,
--Jason Ekstrand
+ }
+ } while (displayno++ MAX_DISPLAYNO);
+
+ errno = EINVAL;
+ return NULL;
+}
+
WL_EXPORT int
wl_display_add_socket(struct wl_display *display, const char *name)
{
diff --git a/src/wayland-server.h b/src/wayland-server.h
index 7fc5b47..c9834f1 100644
--- a/src/wayland-server.h
+++ b/src/wayland-server.h
@@ -88,6 +88,8 @@ struct wl_listener *wl_event_loop_get_destroy_listener(
struct wl_event_loop *loop,
wl_notify_func_t notify);
+char *wl_choose_default_socket(void);
+
struct wl_display *wl_display_create(void);
void wl_display_destroy(struct wl_display *display);
struct wl_event_loop *wl_display_get_event_loop(struct wl_display
*display);
--
1.9.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3] client: extend error handling
On Wed, 7 May 2014 16:21:24 +0200
Marek Chalupa mchqwe...@gmail.com wrote:
When an error occurs, wl_display_get_error() does not
provide any way of getting know if it was a local error or if it was
an error event, respectively what object caused the error and what
the error was.
This patch introduces a new function wl_display_get_protocol_error()
which will return error code, interface and id of the object that
generated the error.
wl_display_get_error() will work the same way as before.
wl_display_get_protocol_error() DOES NOT indicate that a non-protocol
error happened. It returns valid information only in that case that
(protocol) error occurred, so it should be used after calling
wl_display_get_error() with positive result.
Thanks to Pekka Paalanen ppaala...@gmail.com for pointing out
issues in the first versions of this patch.
---
src/wayland-client.c | 138
---
src/wayland-client.h | 3 ++
2 files changed, 123 insertions(+), 18 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index bd40313..c9f8f4f 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -78,7 +78,24 @@ struct wl_event_queue {
struct wl_display {
struct wl_proxy proxy;
struct wl_connection *connection;
+
+ /* errno of the last wl_display error */
int last_error;
+
+ /* When display gets an error event from some object, it stores
+ * information about it here, so that client can get this
+ * information afterwards */
+ struct {
+ /* Code of the error. It can be compared to
+ * the interface's errors enumeration. */
+ uint32_t code;
+ /* interface (protocol) in which the error occurred */
+ const struct wl_interface *interface;
+ /* id of the proxy that caused the error. There's no warranty
+ * that the proxy is still valid. It's up to client how it will
+ * use it */
+ uint32_t id;
+ } protocol_error;
int fd;
pthread_t display_thread;
struct wl_map objects;
@@ -96,6 +113,14 @@ struct wl_display {
static int debug_client = 0;
+/**
+ * This function is called for local errors (no memory, server hung up)
+ *
+ * \param display
+ * \param errorerror value (EINVAL, EFAULT, ...)
+ *
+ * \note this function is called with display mutex locked
+ */
static void
display_fatal_error(struct wl_display *display, int error)
{
@@ -105,7 +130,7 @@ display_fatal_error(struct wl_display *display, int error)
return;
if (!error)
- error = 1;
+ error = EFAULT;
display-last_error = error;
@@ -113,11 +138,56 @@ display_fatal_error(struct wl_display *display, int
error)
pthread_cond_broadcast(iter-cond);
}
+/**
+ * This function is called for error events
+ * and idicates that in some object occured an error.
+ * Difference between this function and display_fatal_error()
+ * is that this one handles errors that will come in wire, whereas
+ * display_fatal_error() is called for local errors.
+ *
+ * \param display
+ * \param codeerror code
+ * \param id id of the object that generated the error
+ * \param intfprotocol interface
+ */
static void
-wl_display_fatal_error(struct wl_display *display, int error)
+display_protocol_error(struct wl_display *display, uint32_t code,
+uint32_t id, const struct wl_interface *intf)
{
+ struct wl_event_queue *iter;
+ int err;
+
+ if (display-last_error)
+ return;
+
+ /* set correct errno */
+ if (wl_interface_equal(intf, wl_display_interface)) {
+ switch (code) {
+ case WL_DISPLAY_ERROR_INVALID_OBJECT:
+ case WL_DISPLAY_ERROR_INVALID_METHOD:
+ err = EINVAL;
+ break;
+ case WL_DISPLAY_ERROR_NO_MEMORY:
+ err = ENOMEM;
+ break;
+ default:
+ err = EFAULT;
+ }
+ } else {
+ err = EPROTO;
+ }
+
pthread_mutex_lock(display-mutex);
- display_fatal_error(display, error);
+
+ display-last_error = err;
+
+ display-protocol_error.code = code;
+ display-protocol_error.id = id;
+ display-protocol_error.interface = intf;
+
+ wl_list_for_each(iter, display-event_queue_list, link)
+ pthread_cond_broadcast(iter-cond);
+
pthread_mutex_unlock(display-mutex);
}
@@ -579,25 +649,12 @@ display_handle_error(void *data,
uint32_t code, const char *message)
{
struct wl_proxy *proxy = object;
- int err;
wl_log(%s@%u: error %d: %s\n,
proxy-object.interface-name, proxy-object.id, code, message);
- switch (code) {
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
Please always use reply-to-all, you have dropped a lot people from CC. On Wed, 07 May 2014 11:02:56 -0700 Bill Spitzak spit...@gmail.com wrote: On 05/07/2014 01:47 AM, Pekka Paalanen wrote: It is for normal windows like registered with xdg_shell where sub-surfaces are not suitable for tooltips. A sub-surface is a part of the window, not another window. A tooltip is not expected to change the window geometry, but a sub-surface does count into the window geometry. Extruding sub-surfaces therefore affect the (parent) window geometry. It is in the protocol spec. Are you saying that a sub-surface that extends outside the area of the parent surface should cause mouse/touch events in this extended area to be delivered to the parent? No. If a sub-surface can receive input events, the input events will refer the sub-surface's wl_surface. However, the window geometry for window management purposes is a very different thing. My personal feeling is that the intuitive approach that events are delivered normally to subsurfaces is the correct one. Especially if subsurfaces are going to be the method of embedding one client inside another. I think it is ok to say that subsurfaces with non-empty input areas are broken in toytoolkit. Sub-surfaces cannot be used to embed another client. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
On Wed, 07 May 2014 13:10:31 -0700 Bill Spitzak spit...@gmail.com wrote: Good to see there is an actual bug on this, but I need to ask for our exact case: No, there is not. The bug report was not a valid bug, and is now closed. Our app can be configured to have 2 (well actually any number) of windows. Normally each window is maximized or fullscreen on a different output. User expects to be able to rearrange the windows, change their size and whether they are fullscreen/maximized, and then do save layout, and later when they run the software again or do a load layout they get EXACTLY the same arrangement of windows. In particular the windows must not be on different outputs than they were previously, they cannot overlap and there must be absolutely no way they can be swapped no matter what order the client creates them. This is similar to session save/restore, lacking a better term for it. We do not even pretend to support or enable this yet. It is just yet one more feature that the shell protocol suite for desktop should cover, but so far no-one has done any work on it AFAIK. If there is not one already, you are welcome to open a feature request bug about application layout save/restore. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
