Re: [PATCH V2] wayland.xml: add enum, bitfield and is_bitfield attributes
On Mon, 2014-09-22 at 11:27 -0700, Jason Ekstrand wrote: I'm a little unsure. I think trying to completely solve this problem in a way that will truly make strongly typed languages happy is insanity. That said, I'm cautiously ok with defining bitfields and enums as long as we are very careful in scoping what bitfield and enum mean. A bitfield should have only power of two values and the result should always be interpreted as an OR of those values. An enum should have every possible value enumerated. If anyone has a good example of something that validly doesn't fit into either of these, please speak up. The example of wl_output.transform is an enum because every possibility is enumerated. From C or a similar language, you can do fun stuff like if (transform WL_OUTPUT_TRANSFORM_FLIPPED) to determine if there is a flip. In a strongly typed language, you can't do this and we shouldn't bend over backwards to make it possible. If we try and come up with some convoluted system that makes this possible with typed languages, we're going to cause far more pain than it's worth. One other thing that we need to keep in mind here is the primary target audience of Wayland and its libraries. That audience is compositors and toolkits. Most of those are written in C and C++. What we don't want to do is to do a bunch of things for the sake of 1% of the target audience that makes the rest have to bend over backwards. When I said cautiously OK, I mean that I don't see that happening yet and I don't see a valid use for an enum that doesn't follow one of those two rules. However, if we have a plausible case where doing so would make everyone's lives easier, I'm going to not be a big fan. Please note that I'm not trying to insult Haskel or other functional or strongly typed languages or the people who use them. I'm simply trying to be pragmatic and recognize that people who want to write an app in haskel that manually bangs the Wayland protocol isn't the target audience. --Jason Completely agree with Jason here. Actually the present enum are just mnemotic to 32-bit int or uint values (and that's why the type field in current protocol is int or uint instead of things like enum). Though developers of strongly-typed languages may not like it, it is versatile and makes sense. Any attempt to define what an enum or bitfield is will change the current semantics and introduce a lot of complexity. There may exist a way to make it work perfectly (and I'm okay with it if it really exists), but I doubt whether the effort worth it since it doesn't do any good to C or C++ wayland programmers, who are the main targeted audience of wayland. Regards, Boyan Ding ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] extras: list three Wayland protocol dumping tools
On Thu, 2014-09-11 at 10:14 +0300, Pekka Paalanen wrote: On Fri, 5 Sep 2014 16:22:25 +0300 Pekka Paalanen ppaala...@gmail.com wrote: No replies... no-one wants their tracer advertised on the Wayland website? :-P Sorry, I didn't notice this. It's your projects, and even more so as I still haven't tried any of them, so I need your ack before putting them up. I agree with adding this section. Since protocol dumper can help people debugging or learning the protocol, and each of these tools has its point. As of mine, I've been busy with other stuff lately and haven't worked on it for a while, but it is quite usable now and I hope I'll take some time to further improve it in the future. So, Acked-by: Boyan Ding stu_...@126.com Thanks, Boyan Ding Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] update protocol specification to match wire protocol
Hi, Actually it is not a hack, it is a very well-defined behavior (though not clearly documented at present). We'll update the documentation to reflect that. The mechanic of creating objects undergoes some change as Pekka mentioned [1] and now it's been stable and won't change anymore (I have to iterate again that if you change how it works now, the world will break before you). The tool you mentioned seems implement an older version of the specification and if you want to use that tool, you should change the code generation to the way wayland-scanner works now. Regards, Boyan Ding [1] http://lists.freedesktop.org/archives/wayland-devel/2014-September/017087.html On Thu, 2014-09-04 at 22:05 -0500, Paul Sbarra wrote: I agree it's a hack, but it's also one that invalidates the protocol specification. If the wire protocol requires four arguments then the specification needs to reflect that. Currently if another tool or protocol implementation (like the gowl example previously mentioned) attempts to generate code from the specification they end up code that is not compatible with libwayland applications. In my opinion that's a pretty bad outcome for a hack, documented or not. Attached is a patch that resolves the problem (at least it limits the scope of the hack to the wayland code generator) while maintaining the existing api. Thank you in advance for reviewing and considering this patch. Paul On Wed, Sep 3, 2014 at 11:04 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: The fact that we have an undocumented hack like that in our scanner clearly isn't great. We need to document it. On Sep 3, 2014 8:55 PM, Boyan Ding stu_...@126.com wrote: Hi, It is actually not a fault in wayland, instead it is designed to be so. new_id's without interface specified in the protocol (such as the one in wl_registry::bind) must come with 3 arguments (s: interface name, u: version, n: the actual new_id). That's why 'n' turns into 'sun'. If a language binding generates the wrong code, please contact the author of the language binding and let him correct it. If you are changing how wayland-scanner (the official C code generator) works, the whole world will break before you. Refer to How protocol objects are created section in [1] to see the details. Regards, Boyan Ding [1] http://ppaalanen.blogspot.fi/2014/07/wayland-protocol-design-object-lifespan.html On Wed, 2014-09-03 at 22:32 -0500, Paul Sbarra wrote: I tried to start some discussion on this topic previously, but it apparently didn't make it through the moderator, so I'm trying again having now joined the list. I've recently taken an interest in the gowl implementation of the wayland protocol and noticed that the specification doesn't match the interface that gets generated by the wayland scanner. If I attempt to code-gen gowl using the wayland.xml file the wl_registry bind interface is missing a couple arguments that weston expects, resulting in the following runtime error: libwayland: message too short, object (2), message bind(usun) However, the spec indicates a bind request signature of un. I tracked this down into some curious logic in the scanner and have been working on a patch to try and allow the corrected signature to be specified in the protocol. Unfortunately this has become more interesting then I'd anticipated. Attached is my naive attempt at resolving this issue. I'm horrified by the string-interface lookup and the wl_registry_bind api change but I'm not sure what else one can do. Any feedback or additional help would be appreciated. Note that this patch applies to the 1.5.91 tagged
[PATCH weston] xwm: Check whether the seat is NULL when needed in weston_wm_handle_button
XCB and wayland input event handling exists together in xwm, which can
cause problems. weston_wm_handle_button is called via XCB events, while
it calls weston_wm_pick_seat_for_window, which uses info from compositor
(pure wayland). It is also true in setting and removing flags of frames.
Races can happen in between, when resize of moving flag of the frame is
still set while the button has been released, the picked seat will be
NULL in weston_wm_handle_button, causing crash. We can safely ignore
moving or resizing if this happens. The same applies to c06a180d.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82827
Signed-off-by: Boyan Ding stu_...@126.com
---
xwayland/window-manager.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index a216b76..f633324 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1648,12 +1648,14 @@ weston_wm_handle_button(struct weston_wm *wm,
xcb_generic_event_t *event)
weston_wm_window_schedule_repaint(window);
if (frame_status(window-frame) FRAME_STATUS_MOVE) {
- shell_interface-move(window-shsurf, seat);
+ if (seat != NULL)
+ shell_interface-move(window-shsurf, seat);
frame_status_clear(window-frame, FRAME_STATUS_MOVE);
}
if (frame_status(window-frame) FRAME_STATUS_RESIZE) {
- shell_interface-resize(window-shsurf, seat, location);
+ if (seat != NULL)
+ shell_interface-resize(window-shsurf, seat, location);
frame_status_clear(window-frame, FRAME_STATUS_RESIZE);
}
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland specification doesn't match code generation
Hi, It is actually not a fault in wayland, instead it is designed to be so. new_id's without interface specified in the protocol (such as the one in wl_registry::bind) must come with 3 arguments (s: interface name, u: version, n: the actual new_id). That's why 'n' turns into 'sun'. If a language binding generates the wrong code, please contact the author of the language binding and let him correct it. If you are changing how wayland-scanner (the official C code generator) works, the whole world will break before you. Refer to How protocol objects are created section in [1] to see the details. Regards, Boyan Ding [1] http://ppaalanen.blogspot.fi/2014/07/wayland-protocol-design-object-lifespan.html On Wed, 2014-09-03 at 22:32 -0500, Paul Sbarra wrote: I tried to start some discussion on this topic previously, but it apparently didn't make it through the moderator, so I'm trying again having now joined the list. I've recently taken an interest in the gowl implementation of the wayland protocol and noticed that the specification doesn't match the interface that gets generated by the wayland scanner. If I attempt to code-gen gowl using the wayland.xml file the wl_registry bind interface is missing a couple arguments that weston expects, resulting in the following runtime error: libwayland: message too short, object (2), message bind(usun) However, the spec indicates a bind request signature of un. I tracked this down into some curious logic in the scanner and have been working on a patch to try and allow the corrected signature to be specified in the protocol. Unfortunately this has become more interesting then I'd anticipated. Attached is my naive attempt at resolving this issue. I'm horrified by the string-interface lookup and the wl_registry_bind api change but I'm not sure what else one can do. Any feedback or additional help would be appreciated. Note that this patch applies to the 1.5.91 tagged commit and compiles cleanly (for wayland). Weston didn't like having the lookup function defined in multiple files, so maybe there would be a better place to put such functionality. Thanks, Paul ___ 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: Wayland specification doesn't match code generation
On Wed, 2014-09-03 at 21:04 -0700, Jasper St. Pierre wrote: The fact that we have an undocumented hack like that in our scanner clearly isn't great. We need to document it. I totally agree. This can really confuse every beginner. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Xwayland/glamor broken after glamor-next merge
On Mon, 2014-09-01 at 10:08 +0100, Steven Newbury wrote: Since commit 6d4954884908ea9894fcfe9836db1ba7bb45be61 (Merge remote-tracking branch 'origin/master' into glamor-next) I've just been getting completely black windows with anything other than really simple xlib apps such as xterm. I've biscected it down the the above merge commit by running glxgears on each checkout. Am I the only one seeing this? No. You aren't. See https://bugs.freedesktop.org/show_bug.cgi?id=81800 But I wonder if there is anyone working on it. Regards, Boyan Ding ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] xwm: Check whether the seat is NULL sometimes in weston_wm_handle_button
On Mon, 2014-09-01 at 12:14 +0300, Pekka Paalanen wrote:
On Fri, 29 Aug 2014 22:10:32 +0800
Boyan Ding stu_...@126.com wrote:
Under some certain circumstances, pointer button may have been released
when frame is still being resized/moved. When this happens, the picked
seat is NULL and it will segfault when moving/resizing surfaces. Check
whether the seat is NULL and ignore move/resize in that case.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82827
Signed-off-by: Boyan Ding stu_...@126.com
---
xwayland/window-manager.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index a216b76..f633324 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1648,12 +1648,14 @@ weston_wm_handle_button(struct weston_wm *wm,
xcb_generic_event_t *event)
weston_wm_window_schedule_repaint(window);
if (frame_status(window-frame) FRAME_STATUS_MOVE) {
- shell_interface-move(window-shsurf, seat);
+ if (seat != NULL)
+ shell_interface-move(window-shsurf, seat);
frame_status_clear(window-frame, FRAME_STATUS_MOVE);
}
if (frame_status(window-frame) FRAME_STATUS_RESIZE) {
- shell_interface-resize(window-shsurf, seat, location);
+ if (seat != NULL)
+ shell_interface-resize(window-shsurf, seat, location);
frame_status_clear(window-frame, FRAME_STATUS_RESIZE);
}
Hi,
do you know if this condition is something that should be silently
ignored like in your patch, or should we at least print an error that
something unexpected is happening and being papered over?
Looking at how the seat is found:
static struct weston_seat *
weston_wm_pick_seat_for_window(struct weston_wm_window *window)
{
struct weston_wm *wm = window-wm;
struct weston_seat *seat, *s;
seat = NULL;
wl_list_for_each(s, wm-server-compositor-seat_list, link) {
if (s-pointer != NULL
s-pointer-focus == window-view
s-pointer-button_count 0
(seat == NULL ||
s-pointer-grab_serial -
seat-pointer-grab_serial (1 30)))
seat = s;
}
return seat;
}
and that gets called as a response to an XCB input event via
weston_wm_handle_button...
The function will return NULL if there are no buttons pressed, even if
the pointer is focused on the window. Does that make sense in general?
Does it not cause every last-button-up event to hit seat==NULL?
So why don't we see this problem more often?
Could there be a problem in the shared frame code, maybe it makes
assumptions that won't work with X11?
At least I think weston_wm_pick_seat_for_window makes sense where it is
used. If no button is down, things like resizing can be safely ignored.
And I don't think it has anything to do with X11 since input handling
here (and in Xwayland) is pure wayland.
I guess (it's only a guess) maybe it's caused by some race conditions in
frame and the event handling here?
Thanks,
Boyan Ding
If no-one knows (i.e. no-one replies assuring one way or the other), I
can merge this patch if someone at least confirms it fixes an issue.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] xwm: Check whether the seat is NULL sometimes in weston_wm_handle_button
On Mon, 2014-09-01 at 12:14 +0300, Pekka Paalanen wrote:
On Fri, 29 Aug 2014 22:10:32 +0800
Boyan Ding stu_...@126.com wrote:
Under some certain circumstances, pointer button may have been released
when frame is still being resized/moved. When this happens, the picked
seat is NULL and it will segfault when moving/resizing surfaces. Check
whether the seat is NULL and ignore move/resize in that case.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82827
Signed-off-by: Boyan Ding stu_...@126.com
---
xwayland/window-manager.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index a216b76..f633324 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1648,12 +1648,14 @@ weston_wm_handle_button(struct weston_wm *wm,
xcb_generic_event_t *event)
weston_wm_window_schedule_repaint(window);
if (frame_status(window-frame) FRAME_STATUS_MOVE) {
- shell_interface-move(window-shsurf, seat);
+ if (seat != NULL)
+ shell_interface-move(window-shsurf, seat);
frame_status_clear(window-frame, FRAME_STATUS_MOVE);
}
if (frame_status(window-frame) FRAME_STATUS_RESIZE) {
- shell_interface-resize(window-shsurf, seat, location);
+ if (seat != NULL)
+ shell_interface-resize(window-shsurf, seat, location);
frame_status_clear(window-frame, FRAME_STATUS_RESIZE);
}
Hi,
do you know if this condition is something that should be silently
ignored like in your patch, or should we at least print an error that
something unexpected is happening and being papered over?
Looking at how the seat is found:
static struct weston_seat *
weston_wm_pick_seat_for_window(struct weston_wm_window *window)
{
struct weston_wm *wm = window-wm;
struct weston_seat *seat, *s;
seat = NULL;
wl_list_for_each(s, wm-server-compositor-seat_list, link) {
if (s-pointer != NULL
s-pointer-focus == window-view
s-pointer-button_count 0
(seat == NULL ||
s-pointer-grab_serial -
seat-pointer-grab_serial (1 30)))
seat = s;
}
return seat;
}
and that gets called as a response to an XCB input event via
weston_wm_handle_button...
The function will return NULL if there are no buttons pressed, even if
the pointer is focused on the window. Does that make sense in general?
Does it not cause every last-button-up event to hit seat==NULL?
So why don't we see this problem more often?
Could there be a problem in the shared frame code, maybe it makes
assumptions that won't work with X11?
Sorry I was in a rush when replying the last mail before leaving my
table. Now I think it may be because the race in X and wayland.
FRAME_STATUS_RESIZE (and so on) are set in frame.c, using wayland event
handling, and are cleared in xwm, using XCB. The pointer may have been
released between the two events. So the picked seat may be NULL while we
have FRAME_STATUS_RESIZE set. I think we can safely ignore the event if
pointer is released between the two.
Regards,
Boyan Ding
If no-one knows (i.e. no-one replies assuring one way or the other), I
can merge this patch if someone at least confirms it fixes an issue.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] xwm: Check whether the seat is NULL sometimes in weston_wm_handle_button
Under some certain circumstances, pointer button may have been released
when frame is still being resized/moved. When this happens, the picked
seat is NULL and it will segfault when moving/resizing surfaces. Check
whether the seat is NULL and ignore move/resize in that case.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82827
Signed-off-by: Boyan Ding stu_...@126.com
---
xwayland/window-manager.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index a216b76..f633324 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1648,12 +1648,14 @@ weston_wm_handle_button(struct weston_wm *wm,
xcb_generic_event_t *event)
weston_wm_window_schedule_repaint(window);
if (frame_status(window-frame) FRAME_STATUS_MOVE) {
- shell_interface-move(window-shsurf, seat);
+ if (seat != NULL)
+ shell_interface-move(window-shsurf, seat);
frame_status_clear(window-frame, FRAME_STATUS_MOVE);
}
if (frame_status(window-frame) FRAME_STATUS_RESIZE) {
- shell_interface-resize(window-shsurf, seat, location);
+ if (seat != NULL)
+ shell_interface-resize(window-shsurf, seat, location);
frame_status_clear(window-frame, FRAME_STATUS_RESIZE);
}
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] xwm: Do not activate override redirect windows
We shouldn't do WM-y things on an O-R window, including setting input
focus to it.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=81273
Signed-off-by: Boyan Ding stu_...@126.com
---
xwayland/window-manager.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index a216b76..bf39fab 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -701,6 +701,9 @@ weston_wm_window_activate(struct wl_listener *listener,
void *data)
}
if (window) {
+ if (window-override_redirect)
+ return;
+
client_message.response_type = XCB_CLIENT_MESSAGE;
client_message.format = 32;
client_message.window = window-id;
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] desktop-shell: Get rid of the racy shell client's destroy listener
The only thing that desktop_shell_client_destroy() do is setting
shell-child.client NULL, and is also done by desktop_shell_sigchld().
Getting rid of it and the shell client's destroy_listener is safe and
avoids a handful of race conditions.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82957
Signed-off-by: Boyan Ding stu_...@126.com
---
desktop-shell/shell.c | 16
desktop-shell/shell.h | 1 -
2 files changed, 17 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 99f3343..07700cf 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -5322,17 +5322,6 @@ desktop_shell_sigchld(struct weston_process *process,
int status)
}
static void
-desktop_shell_client_destroy(struct wl_listener *listener, void *data)
-{
- struct desktop_shell *shell;
-
- shell = container_of(listener, struct desktop_shell,
-child.client_destroy_listener);
-
- shell-child.client = NULL;
-}
-
-static void
launch_desktop_shell_process(void *data)
{
struct desktop_shell *shell = data;
@@ -5344,11 +5333,6 @@ launch_desktop_shell_process(void *data)
if (!shell-child.client)
weston_log(not able to start %s\n, shell-client);
-
- shell-child.client_destroy_listener.notify =
- desktop_shell_client_destroy;
- wl_client_add_destroy_listener(shell-child.client,
- shell-child.client_destroy_listener);
}
static void
diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
index c6ea328..3ddaa89 100644
--- a/desktop-shell/shell.h
+++ b/desktop-shell/shell.h
@@ -137,7 +137,6 @@ struct desktop_shell {
struct weston_process process;
struct wl_client *client;
struct wl_resource *desktop_shell;
- struct wl_listener client_destroy_listener;
unsigned deathcount;
uint32_t deathstamp;
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] desktop-shell: Get rid of the racy shell client's destroy listener
I forgot to go through my mails before sending, completely the same with
http://lists.freedesktop.org/archives/wayland-devel/2014-August/016816.html
. Ignore mine. Sorry
Boyan Ding
On Sat, 2014-08-23 at 15:02 +0800, Boyan Ding wrote:
The only thing that desktop_shell_client_destroy() do is setting
shell-child.client NULL, and is also done by desktop_shell_sigchld().
Getting rid of it and the shell client's destroy_listener is safe and
avoids a handful of race conditions.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82957
Signed-off-by: Boyan Ding stu_...@126.com
---
desktop-shell/shell.c | 16
desktop-shell/shell.h | 1 -
2 files changed, 17 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 99f3343..07700cf 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -5322,17 +5322,6 @@ desktop_shell_sigchld(struct weston_process *process,
int status)
}
static void
-desktop_shell_client_destroy(struct wl_listener *listener, void *data)
-{
- struct desktop_shell *shell;
-
- shell = container_of(listener, struct desktop_shell,
- child.client_destroy_listener);
-
- shell-child.client = NULL;
-}
-
-static void
launch_desktop_shell_process(void *data)
{
struct desktop_shell *shell = data;
@@ -5344,11 +5333,6 @@ launch_desktop_shell_process(void *data)
if (!shell-child.client)
weston_log(not able to start %s\n, shell-client);
-
- shell-child.client_destroy_listener.notify =
- desktop_shell_client_destroy;
- wl_client_add_destroy_listener(shell-child.client,
-shell-child.client_destroy_listener);
}
static void
diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
index c6ea328..3ddaa89 100644
--- a/desktop-shell/shell.h
+++ b/desktop-shell/shell.h
@@ -137,7 +137,6 @@ struct desktop_shell {
struct weston_process process;
struct wl_client *client;
struct wl_resource *desktop_shell;
- struct wl_listener client_destroy_listener;
unsigned deathcount;
uint32_t deathstamp;
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gtk: cannot open display error
Hi, Google chrome (and chromium) doesn't have native wayland support (there is ozone for wayland but not official yet) at present so if you want to use it in wayland environment, you need Xwayland. You have to install weston = 1.5.0 and enable xwayland in xorg-server 1.16.0 (refer to [1], git version not recommended because xwayland now is affected by an outstanding bug [2]). I can launch chrome successfully on my machine but I have to warn that there are still some bugs and the user experience may not be smooth. Regards, Boyan Ding [1] http://wayland.freedesktop.org/xserver.html [2] https://bugs.freedesktop.org/show_bug.cgi?id=81800 On Sat, 2014-08-23 at 22:44 -0400, Hongze Zhao wrote: Hi All, Sorry for noob question again. I am running weston-launch in a tty, which I suppose should launch a weston compositor outside X. In the desktop showed, I can launch weston-terminal and other sample programs listed in the end of http://wayland.freedesktop.org/building.html. However, nothing happens after I clicked the chrome icon in the upper left corner. In the terminal after I executed google-chrome, it says: ERROR: browser main loop.cc(209)] Gtk: cannot open display: Could anyone give me some hints to solve this problem? I guess I missed setting some environment variables? Thanks, Hongze ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 weston 1/2] xwm: Use cursor theme and size in weston.ini
to make it consistent with native wayland apps
v2: use the config in weston_compositor instead of reparsing weston.ini
Signed-off-by: Boyan Ding stu_...@126.com
---
xwayland/window-manager.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 6cac278..997153b 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -38,6 +38,7 @@
#include cairo-util.h
#include compositor.h
+#include config-parser.h
#include hash.h
struct wm_size_hints {
@@ -269,22 +270,22 @@ xcb_cursor_images_load_cursor(struct weston_wm *wm, const
XcursorImages *images)
static xcb_cursor_t
xcb_cursor_library_load_cursor(struct weston_wm *wm, const char *file)
{
+ struct weston_config *config = wm-server-compositor-config;
+ struct weston_config_section *s;
xcb_cursor_t cursor;
XcursorImages *images;
- char *v = NULL;
+ char *theme = NULL;
int size = 0;
if (!file)
return 0;
- v = getenv (XCURSOR_SIZE);
- if (v)
- size = atoi(v);
+ s = weston_config_get_section(config, shell, NULL, NULL);
+ weston_config_section_get_string(s, cursor-theme, theme, NULL);
+ weston_config_section_get_int(s, cursor-size, size, 32);
- if (!size)
- size = 32;
-
- images = XcursorLibraryLoadImages (file, NULL, size);
+ images = XcursorLibraryLoadImages (file, theme, size);
+ free(theme);
if (!images)
return -1;
--
2.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/2] build: do not run xwayland test for distcheck
These two patches are Reviewed-by: Boyan Ding stu_...@126.com On Wed, 2014-08-20 at 12:21 +0300, Pekka Paalanen wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk The Xwayland test has been broken ever since the migration to the stand-alone Xwayland server binary. Disable the test, so 'make distcheck' can actually run. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk --- Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index a8ca3ba..b2d6893 100644 --- a/Makefile.am +++ b/Makefile.am @@ -8,7 +8,8 @@ module_LTLIBRARIES = noinst_LTLIBRARIES = BUILT_SOURCES = -AM_DISTCHECK_CONFIGURE_FLAGS = --disable-setuid-install +# Do not run xwayland test while it is known broken. +AM_DISTCHECK_CONFIGURE_FLAGS = --disable-setuid-install --disable-xwayland-test EXTRA_DIST = weston.ini.in ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 3/3] shell: constrain resize grabs so titlebars don't go under the panel
Well, there's been quite a few patches seeking to solve this problem.
I'm okay with any of these. Actually the ability of rotating windows in
weston makes resizing window out of screen quite easily regardless of
how you constrain pointer position but resizing it easily under the
panel is really annoying.
Cheers,
Boyan Ding
On Wed, 2014-08-20 at 10:37 +0200, Jonny Lamb wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=80228
---
desktop-shell/shell.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 9cb81d5..b9d5f39 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1758,6 +1758,30 @@ struct weston_resize_grab {
};
static void
+constrain_resize_grab(struct weston_pointer_grab *grab,
+ int32_t *width, int32_t *height)
+{
+ struct weston_resize_grab *resize = (struct weston_resize_grab *) grab;
+ struct shell_surface *shsurf = resize-base.shsurf;
+
+ int32_t height_difference;
+
+ height_difference = *height - shsurf-geometry.height;
+
+ /* we're only trying to make sure titlebars don't go under the panel */
+ if (shsurf-shell-panel_position == DESKTOP_SHELL_PANEL_POSITION_TOP
+ resize-edges WL_SHELL_SURFACE_RESIZE_TOP
+ height_difference 0) {
+ int32_t top;
+
+ top = shsurf-view-geometry.y - height_difference;
+
+ if (top 0)
+ *height = shsurf-geometry.height;
+ }
+}
+
+static void
resize_grab_motion(struct weston_pointer_grab *grab, uint32_t time,
wl_fixed_t x, wl_fixed_t y)
{
@@ -1793,6 +1817,8 @@ resize_grab_motion(struct weston_pointer_grab *grab,
uint32_t time,
height += wl_fixed_to_int(to_y - from_y);
}
+ constrain_resize_grab(grab, width, height);
+
shsurf-client-send_configure(shsurf-surface, width, height);
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 weston 1/2] xwm: Use cursor theme and size in weston.ini
On Wed, 2014-08-20 at 14:47 +0300, Pekka Paalanen wrote: Hi, yeah, that's better, but I do wonder if that is actually what we want. I see that this changes the cursors only for the decorations, but not for the X11 apps themselves. So before, I think the cursors on X11 apps and decors were the same, but did not match Wayland apps. Now cursors on X11 app decors match the Wayland apps, but not the X11 apps. Is this wanted? Or should this rather need more fixes, so that weston.ini settings would be reflected in the environment of the X11 apps? But then would that not overwrite the settings made in e.g. Gtk themes or such? Should weston.ini settings be reflected in Xwayland at all, and if yes, what is the right way to accomplish that? Thanks, pq Yeah, you are quite right. I didn't think carefully about that before. The theme here only controls decoration and now I believe that it should be consistent with X applications. But I don't know much about how theming is done in X. I wrote this patch just because I found the default cursor size (32) looks ridiculously large, the cursor size on my machine is 24 elsewhere. I don't think it is right behavior but I wonder how to correct it. Thanks, Boyan Ding ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 3/3] shell: constrain resize grabs so titlebars don't go under the panel
Hi, On Wed, 2014-08-20 at 17:50 +0300, Pekka Paalanen wrote: Hi, on first glance, it looks like this completely ignores window rotation, but when I briefly tested on a rotated window, it seemed work well enough! :-o I can't figure out why. Now, Boyan's patch at least tries to take rotation into account: http://lists.freedesktop.org/archives/wayland-devel/2014-June/015658.html but will not work since I merged the two patches from Jonny, and needs a rebase if we choose it. Then there was the patch from Vivek: http://lists.freedesktop.org/archives/wayland-devel/2014-June/015528.html which I don't think handles rotated windows either? The same reason to rebase as for Boyan's patch. Were there others I missed? Boyan, can you see if Jonny's patch is right, or did I just not poke it the right way to make it break? Just merging that would be the easiest. If you don't like it, could you two agree on who makes the next one? Or do we just not care enough about rotated windows? :-) (I'd be fine with that, on resizing.) After comparing mine and Jonny's patches the more carefully, I found the patches' idea are different. Jonny's patch puts a hard requirement that when expanding in height on the top edge, titlebar shouldn't go under top panel or the resizing won't take effect (quite tricky here). While mine will clamp the y-coordinate of cursor position if it's on the panel. I admit that my approach is somewhat too conservative. But there are some tricky edge case under which Jonny's approach doesn't work very well. Rotate a window clockwise 60-75 degrees, move it up until it can't be moved further. You will find the top edge can't expand (actually expanding the top edge here does no harm I think). More seriously, You'll find that if you shrink the top edge a little, it can't resize back! This behavior, in my opinion, is unacceptable, since too much constraint is put on rotated windows. Also, if you rotate a window 90 degrees and expand the edge that is now on the top. It will go under the panel. This behavior isn't change by Jonny's patch but will be changed by mine since I believe the cursor position in panel shouldn't be used in resizing, regardless of which edge we are resizing, at least a clamped coordinate should be used. I think an ideal solution should surely ensure an unrotated window not to be expanded under panel, but don't place too much restriction on rotated windows. What's your idea? Btw. it seems that rotated windows already have issues with move constraints. Try to open a window fairly big, rotate it 180 degrees, grab the window's bottom (which is now facing up), and resize the window to very short. Then, try to move the window around the desktop. I cannot move the window up past some arbitrary point in the middle of the desktop, while there clearly is room to move. Yeah, I also noticed that. Maybe we should change that, too. Cheers, Boyan Ding Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/2] xwm: check whether the picked seat can be NULL
On Tue, 2014-08-19 at 16:53 +0300, Pekka Paalanen wrote: I was not able to reproduce the crash without the patch, and using gnome-terminal, either. Actually I'm also curious about how is the problem triggered, and I reproduced it on my machine just now. And I'm even more astonished to see this [1], though I can't reproduce it myself. It said that the picked seat can be NULL even in weston_wm_handle_button! I guess somewhere might be wrong in X (just a wild guess). Cheers, Boyan Ding [1] https://bugs.archlinux.org/task/41456 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The road to Wayland/Weston 1.6 and 1.5.1
Hi, On Mon, 2014-08-18 at 14:35 +0300, Pekka Paalanen wrote: Hi all, in the release announcement of 1.5.0[1] it was said that the alpha release towards 1.6 should come out mid-August. That time is now, so how about we target Friday, Aug 22nd (European time)? [...] Also, it was said that 1.5.1 should have come out in a few weeks and it has been 3 months now. I will try and check the patches already in 'master' of both Wayland and Weston and pick them to the 1.5 branches, but if you know of patches that should be in stable, especially ones without review or not in 'master', let me know and I try do something. My selection, especially for Wayland, will probably be very conservative, though, as my priority is 1.6. There are two patches for xwayland part in weston that has stood for quite a while: http://lists.freedesktop.org/archives/wayland-devel/2014-July/015885.html http://lists.freedesktop.org/archives/wayland-devel/2014-July/015886.html with the first one being a little feature and the second one a simple bugfix. Also another patch that doesn't got reviewed but quite important: http://lists.freedesktop.org/archives/wayland-devel/2014-August/016307.html It should follow c4902124 and 9c5aedff in master (and also in 1.5 branch) but I left that out then. Thanks for all the efforts. Regards, Boyan Ding Thanks, pq [1] http://lists.freedesktop.org/archives/wayland-devel/2014-May/014955.html ___ 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: How to take screenshots under weston?
Hi, Screenshot works okay under x11-backend on my weston (the git version). Please note that the screenshot seems to be in the directory where you launch weston (not always $HOME). BTW, I was wrong about screenshot binding. It's always Super + S, not Mod + S. Regards, Boyan Ding On Fri, 2014-08-15 at 17:08 -0400, Hongze Zhao wrote: Hi Boyan, Thanks for your reply. I tried to capture screen in two different scenarios. If the weston is running outside X, which is launched in a tty, the screenshooter works. If the weston is running in side X, after I press win + S, the terminal says launching '/home/hongze/install/libexec/weston-screenshooter' and nothing more. Do you know whats wrong with it or the screenshooter is not supposed to run in a weston inside X? Thanks, Hongze ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to take screenshots under weston?
Hi, Mod key is defined by weston configure, the default of which is Super (win key). You can also specify that in weston.ini. Refer to manpage of weston.ini(5) for details. Cheers, Boyan Ding On Thu, 2014-08-14 at 17:21 -0400, Hongze Zhao wrote: I am new to wayland and weston. I just built wayland weston on Ubuntu 14.04. The weston version is 1.3.93. I am trying to take a screenshot under weston. Some posts say I should press mod + S to take a screenshot, which i suppose is right shift + S on Ubuntu. I tried the combo both on weston outside X and inside X but nothing happens. Could anyone give me some help about it? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] cairo-util: Draw solid titlebar for frames with only buttons
Previously geometry was changed to leave space for titlebar if a frame
has only buttons but no title. This patch fixes theme_render_frame to
avoid transparent titlebar.
Signed-off-by: Boyan Ding stu_...@126.com
---
shared/cairo-util.c | 8 +---
shared/cairo-util.h | 5 -
shared/frame.c | 2 +-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/shared/cairo-util.c b/shared/cairo-util.c
index 2a33249..26286c5 100644
--- a/shared/cairo-util.c
+++ b/shared/cairo-util.c
@@ -28,6 +28,7 @@
#include string.h
#include stdio.h
#include math.h
+#include wayland-util.h
#include cairo.h
#include cairo-util.h
@@ -413,7 +414,8 @@ theme_destroy(struct theme *t)
void
theme_render_frame(struct theme *t,
cairo_t *cr, int width, int height,
- const char *title, uint32_t flags)
+ const char *title, struct wl_list *buttons,
+ uint32_t flags)
{
cairo_text_extents_t extents;
cairo_font_extents_t font_extents;
@@ -439,7 +441,7 @@ theme_render_frame(struct theme *t,
else
source = t-inactive_frame;
- if (title)
+ if (title || !wl_list_empty(buttons))
top_margin = t-titlebar_height;
else
top_margin = t-width;
@@ -449,7 +451,7 @@ theme_render_frame(struct theme *t,
width - margin * 2, height - margin * 2,
t-width, top_margin);
- if (title) {
+ if (title || !wl_list_empty(buttons)) {
cairo_rectangle (cr, margin + t-width, margin,
width - (margin + t-width) * 2,
t-titlebar_height - t-width);
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 4493b0d..fb25c34 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -26,6 +26,8 @@
#include stdint.h
#include cairo.h
+#include wayland-util.h
+
void
surface_flush_device(cairo_surface_t *surface);
@@ -69,7 +71,8 @@ theme_set_background_source(struct theme *t, cairo_t *cr,
uint32_t flags);
void
theme_render_frame(struct theme *t,
cairo_t *cr, int width, int height,
- const char *title, uint32_t flags);
+ const char *title, struct wl_list *buttons,
+ uint32_t flags);
enum theme_location {
THEME_LOCATION_INTERIOR = 0,
diff --git a/shared/frame.c b/shared/frame.c
index 53f3f5f..5ea0e12 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -853,7 +853,7 @@ frame_repaint(struct frame *frame, cairo_t *cr)
cairo_save(cr);
theme_render_frame(frame-theme, cr, frame-width, frame-height,
- frame-title, flags);
+ frame-title, frame-buttons, flags);
cairo_restore(cr);
wl_list_for_each(button, frame-buttons, link)
--
2.0.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
An status update of wayland-tracer - a wayland protocol dumper
Hi all, Previously I posted patches about wayland-tracer, a wire protocol dumper for wayland. It has turned into a self-contained project and a lot of development have taken place. Now, I'm happy to announce that XML parser and protocol analyzer has been added so it can produce a human-readable format similar to WAYLAND_DEBUG, making the tool practical to use. People who are interested can visit the repository on github: https://github.com/dboyan/wayland-tracer and feedbacks are welcomed. Regards, Boyan Ding ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland v2 0/2] Wayland protocol dumper
Hi, Thanks for all the advice. I also found integrating the code in wayland repository is not very comfortable. Actually I had to make a separate branch to keep track of my own development and format patches before sending them here. So I set up a self-contained repository on github [1] and my development will continue there. The code now is identical to v2 patches I sent, with stripped (to avoid unneeded depenencies) version of wayland utilities. As for the choice between reusing and duplicating, I prefer to reuse a little code about low level connection handling and duplicate others. I'll keep my code as clean as possible. My point is to keep code simple and not to make reusing code a burden. Regards, Boyan Ding [1] https://github.com/dboyan/wayland-tracer On Fri, 2014-07-25 at 15:53 +0300, Pekka Paalanen wrote: On Wed, 23 Jul 2014 16:21:19 +0800 Boyan Ding stu_...@126.com wrote: The v2 of patches sees a lot of new code and the most notable change is the introduction of server mode. Under server mode, the program will act as a wayland server and can accept multiple clients via WAYLAND_DISPLAY variable. An interesting usecase of this feature is to trace all clients of a compositor. To make it run under server mode, run shell wayland-tracer -S SOCKET_NAME SOCKET_NAME is a value like wayland-0 or so. If we set WAYLAND_DISPLAY environment variable to SOCKET_NAME and launch a wayland app, that app will be traced. To make it run under default mode (now called single mode), run shell wayland-tracer -- program arguments ... Also, EPOLLHUP is handled correctly in this version. The next step will be adding xml protocol parsing and wire data analysing according to protocol files. This will be much tougher but I hope I can finish that. Boyan Ding (2): connection: Move definitions Add a wayland protocol dumper wayland-tracer .gitignore| 1 + Makefile.am | 10 + configure.ac | 7 + src/connection.c | 18 +- src/tracer.c | 689 ++ src/wayland-private.h | 18 +- 6 files changed, 727 insertions(+), 16 deletions(-) create mode 100644 src/tracer.c Hi, excellent work! :-) As I understand there are also other people writing protocol dumpers, and I do not see any technical reason why it should live in the wayland repository, I would suggest creating your own project. I believe it will be much more comfortable for you, being in total control, not having to rebase/merge and so on. This is also what I tried to refer to with the self-contained project in my original call-out. You can freely pick your dependencies and frameworks there, which is not something you can easily do in the wayland repository. It would also be nicer for your users, as they don't need two different checkouts of libwayland, other one just for building the dumper. In any case you are welcome to post news on your progress to wayland-devel. A bit of competition might be insipiring, and I wouldn't want to announce the winner on the starting line by merging this too soon. :-) I think you should rather duplicate than re-use the few bits from libwayland internals, I feel that would be a cleaner approach and it's not that much code anyway (is it?). You are free copy anything you need from Wayland and Weston code bases under the given licence (don't forget to copy the copyrights). If all goes well and you are happy with the work, you could very soon be running a FOSS project of your own! Or if you just want to develop this once, push it upstream, and then move on, that is ok too. Or maybe someone else would like to take over the project later. Do you have plans in this regard? I think your project should live for a while so we see where it is going, and at least do the decoding with XML into text form before we look into merging it into wayland repository. I think anything with a GUI (which would be awesome!) is getting beyond the scope of the wayland repository. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland v2 0/2] Wayland protocol dumper
Hi, On Thu, 2014-07-24 at 18:01 -0700, Bryce Harrington wrote: Hmm, do I understand the directions correctly? In one terminal after building and installing the patched wayland, I've run: $ ./wayland-tracer -S wayland-0 Then in another terminal window, I rebuild weston and: $ WAYLAND_DISPLAY=wayland-0 ~/Wayland/weston/weston-flower failed to connect to Wayland display: No such file or directory failed to create display: No such file or directory $ Oh, you should have a compositor first. This tool is only used to redirecting data on the wire. Suppose you have a compositor which runs on wayland-0. You can run (Supposed environment variable WAYLAND_DISPLAY=wayland-0) $ ./wayland-tracer -S wayland-1 Then if you run under another terminal $ WAYLAND_DISPLAY=wayland-1 weston-flower You'll see weston-flower and in the compositor and the communication dumped. To make it run under default mode (now called single mode), run shell wayland-tracer -- program arguments ... Not sure what this mode is, but it seems not to do much for me: $ ./wayland-tracer -- ~/Wayland/weston/weston-flower 0: = Data dumped: 12 bytes: 01 00 00 00 01 00 0c 00 02 00 00 00 You also got to have a running compositor. But this reminds me to check whether the connection is successful. Cheers, Boyan Ding ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC wayland v2 2/2] Add a wayland protocol dumper wayland-tracer
Signed-off-by: Boyan Ding stu_...@126.com
---
.gitignore | 1 +
Makefile.am | 10 +
configure.ac | 7 +
src/tracer.c | 689 +++
4 files changed, 707 insertions(+)
create mode 100644 src/tracer.c
diff --git a/.gitignore b/.gitignore
index c146bac..510b7ae 100644
--- a/.gitignore
+++ b/.gitignore
@@ -54,4 +54,5 @@ sanity-test
signal-test
socket-test
wayland-scanner
+wayland-tracer
protocol/*.[ch]
diff --git a/Makefile.am b/Makefile.am
index fee19ab..61827dd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -70,6 +70,16 @@ $(BUILT_SOURCES) : wayland-scanner
pkgconfig_DATA += src/wayland-scanner.pc
else
wayland_scanner = wayland-scanner
+bin_PROGRAMS =
+endif
+
+if ENABLE_TRACER
+wayland_tracer = $(top_builddir)/wayland-tracer
+bin_PROGRAMS += wayland-tracer
+wayland_tracer_SOURCES = src/tracer.c
+wayland_tracer_LDADD = libwayland-util.la $(FFI_LIBS) -lrt
+else
+wayland_tracer = wayland-tracer
endif
protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
diff --git a/configure.ac b/configure.ac
index e16c5b5..b3e81a7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -64,7 +64,14 @@ AC_ARG_ENABLE([documentation],
[],
[enable_documentation=yes])
+AC_ARG_ENABLE([tracer],
+ [AC_HELP_STRING([--disable-tracer],
+ [Disable compilation of wayland-tracer])],
+ [],
+ [enable_tracer=yes])
+
AM_CONDITIONAL(ENABLE_SCANNER, test x$enable_scanner = xyes)
+AM_CONDITIONAL(ENABLE_TRACER, test x$enable_tracer = xyes)
AC_ARG_WITH(icondir, [ --with-icondir=dirLook for cursor icons here],
[ ICONDIR=$withval],
diff --git a/src/tracer.c b/src/tracer.c
new file mode 100644
index 000..9adb21f
--- /dev/null
+++ b/src/tracer.c
@@ -0,0 +1,689 @@
+/*
+ * Copyright © 2014 Boyan Ding
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided as
+ * is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include stddef.h
+#include string.h
+#include unistd.h
+#include fcntl.h
+#include sys/epoll.h
+#include sys/types.h
+#include sys/socket.h
+#include sys/stat.h
+#include sys/file.h
+#include sys/un.h
+#include stdint.h
+#include errno.h
+#include assert.h
+
+#include wayland-os.h
+#include wayland-private.h
+#include wayland-util.h
+
+#define TRACER_SERVER_SIDE 0
+#define TRACER_CLIENT_SIDE 1
+
+#define TRACER_MODE_SINGLE 0
+#define TRACER_MODE_SERVER 1
+
+#ifndef UNIX_PATH_MAX
+#define UNIX_PATH_MAX 108
+#endif
+
+#define LOCK_SUFFIX .lock
+#define LOCK_SUFFIXLEN 5
+struct tracer;
+struct tracer_instance;
+
+struct tracer_connection {
+ struct wl_connection *wl_conn;
+ struct tracer_connection *peer;
+ struct tracer_instance *instance;
+ int side;
+};
+
+struct tracer_instance {
+ int id;
+ struct tracer_connection *client_conn;
+ struct tracer_connection *server_conn;
+ struct tracer *tracer;
+ struct wl_list link;
+};
+
+/* A simple copy of wl_socket in wayland-server.c */
+struct tracer_socket {
+ int fd;
+ int fd_lock;
+ struct sockaddr_un addr;
+ char lock_addr[UNIX_PATH_MAX + LOCK_SUFFIXLEN];
+};
+
+struct tracer {
+ struct tracer_socket *socket;
+ int32_t epollfd;
+ int next_id;
+ struct wl_list instance_list;
+};
+
+struct tracer_options {
+ int mode;
+ char **spawn_args;
+ char *socket;
+};
+
+static int
+tracer_dump_bin(struct tracer_connection *connection)
+{
+ int i, len, fdlen, fd;
+ char buf[4096];
+ struct wl_connection *wl_conn= connection-wl_conn;
+ struct tracer_connection *peer = connection-peer;
+ struct tracer_instance *instance = connection-instance;
+
+ len = wl_buffer_size(wl_conn-in);
+ if (len == 0)
+ return 0;
+
+ wl_connection_copy(wl_conn, buf, len);
+
+ printf
[RFC wayland v2 0/2] Wayland protocol dumper
The v2 of patches sees a lot of new code and the most notable change is the introduction of server mode. Under server mode, the program will act as a wayland server and can accept multiple clients via WAYLAND_DISPLAY variable. An interesting usecase of this feature is to trace all clients of a compositor. To make it run under server mode, run shell wayland-tracer -S SOCKET_NAME SOCKET_NAME is a value like wayland-0 or so. If we set WAYLAND_DISPLAY environment variable to SOCKET_NAME and launch a wayland app, that app will be traced. To make it run under default mode (now called single mode), run shell wayland-tracer -- program arguments ... Also, EPOLLHUP is handled correctly in this version. The next step will be adding xml protocol parsing and wire data analysing according to protocol files. This will be much tougher but I hope I can finish that. Boyan Ding (2): connection: Move definitions Add a wayland protocol dumper wayland-tracer .gitignore| 1 + Makefile.am | 10 + configure.ac | 7 + src/connection.c | 18 +- src/tracer.c | 689 ++ src/wayland-private.h | 18 +- 6 files changed, 727 insertions(+), 16 deletions(-) create mode 100644 src/tracer.c -- 2.0.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC wayland v2 1/2] connection: Move definitions
wayland-tracer will use them.
Signed-off-by: Boyan Ding stu_...@126.com
---
src/connection.c | 18 +++---
src/wayland-private.h | 18 +-
2 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index f292853..79197c9 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -44,23 +44,11 @@
#define DIV_ROUNDUP(n, a) ( ((n) + ((a) - 1)) / (a) )
-struct wl_buffer {
- char data[4096];
- uint32_t head, tail;
-};
-
#define MASK(i) ((i) 4095)
#define MAX_FDS_OUT28
#define CLEN (CMSG_LEN(MAX_FDS_OUT * sizeof(int32_t)))
-struct wl_connection {
- struct wl_buffer in, out;
- struct wl_buffer fds_in, fds_out;
- int fd;
- int want_flush;
-};
-
static int
wl_buffer_put(struct wl_buffer *b, const void *data, size_t count)
{
@@ -135,7 +123,7 @@ wl_buffer_get_iov(struct wl_buffer *b, struct iovec *iov,
int *count)
}
}
-static void
+void
wl_buffer_copy(struct wl_buffer *b, void *data, size_t count)
{
uint32_t tail, size;
@@ -150,7 +138,7 @@ wl_buffer_copy(struct wl_buffer *b, void *data, size_t
count)
}
}
-static uint32_t
+uint32_t
wl_buffer_size(struct wl_buffer *b)
{
return b-head - b-tail;
@@ -394,7 +382,7 @@ wl_message_count_arrays(const struct wl_message *message)
return arrays;
}
-static int
+int
wl_connection_put_fd(struct wl_connection *connection, int32_t fd)
{
if (wl_buffer_size(connection-fds_out) == MAX_FDS_OUT * sizeof fd) {
diff --git a/src/wayland-private.h b/src/wayland-private.h
index 67e8783..ad5313e 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -78,13 +78,28 @@ void *wl_map_lookup(struct wl_map *map, uint32_t i);
uint32_t wl_map_lookup_flags(struct wl_map *map, uint32_t i);
void wl_map_for_each(struct wl_map *map, wl_iterator_func_t func, void *data);
-struct wl_connection;
+
+struct wl_buffer {
+ char data[4096];
+ uint32_t head, tail;
+};
+
+struct wl_connection {
+ struct wl_buffer in, out;
+ struct wl_buffer fds_in, fds_out;
+ int fd;
+ int want_flush;
+};
+
struct wl_closure;
struct wl_proxy;
int wl_interface_equal(const struct wl_interface *iface1,
const struct wl_interface *iface2);
+void wl_buffer_copy(struct wl_buffer *b, void *data, size_t count);
+uint32_t wl_buffer_size(struct wl_buffer *b);
+
struct wl_connection *wl_connection_create(int fd);
void wl_connection_destroy(struct wl_connection *connection);
void wl_connection_copy(struct wl_connection *connection, void *data, size_t
size);
@@ -96,6 +111,7 @@ int wl_connection_read(struct wl_connection *connection);
int wl_connection_write(struct wl_connection *connection, const void *data,
size_t count);
int wl_connection_queue(struct wl_connection *connection,
const void *data, size_t count);
+int wl_connection_put_fd(struct wl_connection *connection, int32_t fd);
struct wl_closure {
int count;
--
2.0.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] xwayland: set surface_id to 0 when client resource is found
Only when reading through mails today did I find I had duplicated
efforts [1], sorry.
This patch is
Reviewed-by: Boyan Ding stu_...@126.com
[1]
http://lists.freedesktop.org/archives/wayland-devel/2014-July/015943.html
On Wed, 2014-07-02 at 15:00 -0700, Tyler Veness wrote:
When Xwayland requests that a wl_surface be created and the X event is
handled before the wayland requests, a surface ID is stored to
window-surface_id and the window is added to the unpaired window list. When
weston_wm_create_surface is called, the window is removed from the list and
window-surface_id is set to zero. If window-surface_id is not zero when
weston_wm_window_destroy is called, the window is assumed to be in the
unpaired window list and wl_list_remove is called. If
weston_wm_window_handle_surface_id is called and the surface has already
been created, the window is not added to the unpaired window list, but
window-surface_id isn't set to zero. When the window is destroyed, removing
the window from the list is attempted anyway and a crash occurs.
This patch stores the surface ID in a temporary variable and only assigns it
to window-surface_id when the window is added to the unpaired window list.
Otherwise window-surface_id is set to zero to maintain its use as a flag
variable.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=80273
Signed-off-by: Tyler Veness calcmo...@gmail.com
---
xwayland/window-manager.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 2fb65b1..4c98baf 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1374,14 +1374,17 @@ weston_wm_window_handle_surface_id(struct
weston_wm_window *window,
* hasn't been created yet. In that case put the window on
* the unpaired window list and continue when the surface gets
* created. */
- window-surface_id = client_message-data.data32[0];
- resource = wl_client_get_object(wm-server-client,
- window-surface_id);
- if (resource)
+ uint32_t surface = client_message-data.data32[0];
+ resource = wl_client_get_object(wm-server-client, surface);
+ if (resource) {
+ window-surface_id = 0;
xserver_map_shell_surface(window,
wl_resource_get_user_data(resource));
- else
+ }
+ else {
+ window-surface_id = surface;
wl_list_insert(wm-unpaired_window_list, window-link);
+ }
}
static void
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC wayland 0/2] Wayland protocol dumper
The idea of wayland protocol dumper came from [1]. And this patch series implements a prototype of it. I found wayland utilities quite convenient so I decided to base my work on top of wayland (although not using libwayland-client or libwayland-server), so it temporarily (and I hope eventually it can) resides in the wayland source tree. The program is quite simple now, it uses a socketpair to communicate with a client and redirect that to the server, dumping the data on the wire in the process. It only dumps raw data at present. To use it, you can try: shell wayland-tracer [program you want to trace and arguments] It can be really easy to cut down the data to single messages, though, producing readable outputs about messages (names and argument values) is quite far ahead. My plan is to take .xml protocol files as input and learn things on the fly. I think it possible although I'm not very sure about details. Comments and suggestions are welcomed. Feel free to say something about whether it useful, where it is wrong, how it can improve, etc. Regards, Boyan Ding [1] http://lists.freedesktop.org/archives/wayland-devel/2014-April/014121.html Boyan Ding (2): connection: Move some definitions Add a wayland protocol dumper wayland-tracer .gitignore| 1 + Makefile.am | 10 ++ configure.ac | 7 + src/connection.c | 18 +-- src/tracer.c | 351 ++ src/wayland-private.h | 18 ++- 6 files changed, 389 insertions(+), 16 deletions(-) create mode 100644 src/tracer.c -- 2.0.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC wayland 2/2] Add a wayland protocol dumper wayland-tracer
Signed-off-by: Boyan Ding stu_...@126.com
---
.gitignore | 1 +
Makefile.am | 10 ++
configure.ac | 7 ++
src/tracer.c | 351 +++
4 files changed, 369 insertions(+)
create mode 100644 src/tracer.c
diff --git a/.gitignore b/.gitignore
index c146bac..510b7ae 100644
--- a/.gitignore
+++ b/.gitignore
@@ -54,4 +54,5 @@ sanity-test
signal-test
socket-test
wayland-scanner
+wayland-tracer
protocol/*.[ch]
diff --git a/Makefile.am b/Makefile.am
index c15d8b8..f234599 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -70,6 +70,16 @@ $(BUILT_SOURCES) : wayland-scanner
pkgconfig_DATA += src/wayland-scanner.pc
else
wayland_scanner = wayland-scanner
+bin_PROGRAMS =
+endif
+
+if ENABLE_TRACER
+wayland_tracer = $(top_builddir)/wayland-tracer
+bin_PROGRAMS += wayland-tracer
+wayland_tracer_SOURCES = src/tracer.c
+wayland_tracer_LDADD = libwayland-util.la $(FFI_LIBS)
+else
+wayland_tracer = wayland-tracer
endif
protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
diff --git a/configure.ac b/configure.ac
index e16c5b5..b3e81a7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -64,7 +64,14 @@ AC_ARG_ENABLE([documentation],
[],
[enable_documentation=yes])
+AC_ARG_ENABLE([tracer],
+ [AC_HELP_STRING([--disable-tracer],
+ [Disable compilation of wayland-tracer])],
+ [],
+ [enable_tracer=yes])
+
AM_CONDITIONAL(ENABLE_SCANNER, test x$enable_scanner = xyes)
+AM_CONDITIONAL(ENABLE_TRACER, test x$enable_tracer = xyes)
AC_ARG_WITH(icondir, [ --with-icondir=dirLook for cursor icons here],
[ ICONDIR=$withval],
diff --git a/src/tracer.c b/src/tracer.c
new file mode 100644
index 000..23de75d
--- /dev/null
+++ b/src/tracer.c
@@ -0,0 +1,351 @@
+/*
+ * Copyright © 2014 Boyan Ding
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided as
+ * is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include stddef.h
+#include string.h
+#include unistd.h
+#include fcntl.h
+#include sys/epoll.h
+#include sys/types.h
+#include sys/socket.h
+#include sys/un.h
+#include stdint.h
+#include errno.h
+#include assert.h
+
+#include wayland-os.h
+#include wayland-private.h
+#include wayland-util.h
+
+#define TRACER_SERVER_SIDE 0
+#define TRACER_CLIENT_SIDE 1
+
+struct tracer_connection {
+ struct wl_connection *wl_conn;
+ struct tracer_connection *peer;
+ int side;
+};
+
+struct tracer {
+ struct tracer_connection *client_conn;
+ struct tracer_connection *server_conn;
+ int32_t epollfd;
+};
+
+static int
+tracer_dump_bin(struct tracer_connection *connection)
+{
+ int i, len, fdlen, fd;
+ char buf[4096];
+ struct wl_connection *wl_conn= connection-wl_conn;
+ struct tracer_connection *peer = connection-peer;
+
+ len = wl_buffer_size(wl_conn-in);
+ if (len == 0)
+ return 0;
+
+ wl_connection_copy(wl_conn, buf, len);
+
+ printf(%s Data dumped: %d bytes:\n,
+ connection-side == TRACER_SERVER_SIDE ? = : =, len);
+ for (i = 0; i len; i++) {
+ printf(%02x , (unsigned char)buf[i]);
+ }
+ printf(\n);
+ wl_connection_consume(wl_conn, len);
+ wl_connection_write(peer-wl_conn, buf, len);
+
+ fdlen = wl_buffer_size(wl_conn-fds_in);
+
+ wl_buffer_copy(wl_conn-fds_in, buf, fdlen);
+ fdlen /= sizeof(int32_t);
+
+ if (fdlen != 0)
+ printf(%d Fds in control data:, fdlen);
+
+ for (i = 0; i fdlen; i++) {
+ fd = ((int *) buf)[i];
+ printf(%d , fd);
+ wl_connection_put_fd(peer-wl_conn, fd);
+ }
+ printf(\n);
+
+ wl_conn-fds_in.tail += fdlen * sizeof(int32_t);
+ wl_connection_flush(peer-wl_conn);
+
+ return len;
+}
+
+/* The following two
[RFC wayland 1/2] connection: Move some definitions
wayland-tracer will need them
Signed-off-by: Boyan Ding stu_...@126.com
---
src/connection.c | 18 +++---
src/wayland-private.h | 18 +-
2 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index f292853..79197c9 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -44,23 +44,11 @@
#define DIV_ROUNDUP(n, a) ( ((n) + ((a) - 1)) / (a) )
-struct wl_buffer {
- char data[4096];
- uint32_t head, tail;
-};
-
#define MASK(i) ((i) 4095)
#define MAX_FDS_OUT28
#define CLEN (CMSG_LEN(MAX_FDS_OUT * sizeof(int32_t)))
-struct wl_connection {
- struct wl_buffer in, out;
- struct wl_buffer fds_in, fds_out;
- int fd;
- int want_flush;
-};
-
static int
wl_buffer_put(struct wl_buffer *b, const void *data, size_t count)
{
@@ -135,7 +123,7 @@ wl_buffer_get_iov(struct wl_buffer *b, struct iovec *iov,
int *count)
}
}
-static void
+void
wl_buffer_copy(struct wl_buffer *b, void *data, size_t count)
{
uint32_t tail, size;
@@ -150,7 +138,7 @@ wl_buffer_copy(struct wl_buffer *b, void *data, size_t
count)
}
}
-static uint32_t
+uint32_t
wl_buffer_size(struct wl_buffer *b)
{
return b-head - b-tail;
@@ -394,7 +382,7 @@ wl_message_count_arrays(const struct wl_message *message)
return arrays;
}
-static int
+int
wl_connection_put_fd(struct wl_connection *connection, int32_t fd)
{
if (wl_buffer_size(connection-fds_out) == MAX_FDS_OUT * sizeof fd) {
diff --git a/src/wayland-private.h b/src/wayland-private.h
index 67e8783..ad5313e 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -78,13 +78,28 @@ void *wl_map_lookup(struct wl_map *map, uint32_t i);
uint32_t wl_map_lookup_flags(struct wl_map *map, uint32_t i);
void wl_map_for_each(struct wl_map *map, wl_iterator_func_t func, void *data);
-struct wl_connection;
+
+struct wl_buffer {
+ char data[4096];
+ uint32_t head, tail;
+};
+
+struct wl_connection {
+ struct wl_buffer in, out;
+ struct wl_buffer fds_in, fds_out;
+ int fd;
+ int want_flush;
+};
+
struct wl_closure;
struct wl_proxy;
int wl_interface_equal(const struct wl_interface *iface1,
const struct wl_interface *iface2);
+void wl_buffer_copy(struct wl_buffer *b, void *data, size_t count);
+uint32_t wl_buffer_size(struct wl_buffer *b);
+
struct wl_connection *wl_connection_create(int fd);
void wl_connection_destroy(struct wl_connection *connection);
void wl_connection_copy(struct wl_connection *connection, void *data, size_t
size);
@@ -96,6 +111,7 @@ int wl_connection_read(struct wl_connection *connection);
int wl_connection_write(struct wl_connection *connection, const void *data,
size_t count);
int wl_connection_queue(struct wl_connection *connection,
const void *data, size_t count);
+int wl_connection_put_fd(struct wl_connection *connection, int32_t fd);
struct wl_closure {
int count;
--
2.0.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wcap-snapshot
Hi, The wcap-snapshot program is now integrated into wcap-decode now but the README didn't change, we should really fix that. So to extract a specific frame from a wcap file (recorded using Mod+R in weston), you can use wcap-decode capture.wcap --frame=frame Or more directly, if you just want a screenshot, you can use Mod+S in weston. Cheers, Boyan Ding ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] gitignore: add ./message-test
Yeah, this is necessary, but please insert this line according to alphabetical order (i.e. after map-test). Cheers, Boyan Ding On Sun, 2014-07-06 at 22:10 +0800, Guangyu Zhang wrote: ./message-test is generated by libtool and should be ignored by git. --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index c146bac..22e6301 100644 --- a/.gitignore +++ b/.gitignore @@ -55,3 +55,4 @@ signal-test socket-test wayland-scanner protocol/*.[ch] +message-test ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 1/2] xwm: Use cursor theme and size in weston.ini
to make it consistent with native wayland apps
Signed-off-by: Boyan Ding stu_...@126.com
---
xwayland/window-manager.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 2fb65b1..f64ef94 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -38,6 +38,7 @@
#include cairo-util.h
#include compositor.h
+#include config-parser.h
#include hash.h
struct wm_size_hints {
@@ -269,22 +270,24 @@ xcb_cursor_images_load_cursor(struct weston_wm *wm, const
XcursorImages *images)
static xcb_cursor_t
xcb_cursor_library_load_cursor(struct weston_wm *wm, const char *file)
{
+ struct weston_config *config;
+ struct weston_config_section *s;
xcb_cursor_t cursor;
XcursorImages *images;
- char *v = NULL;
+ char *theme = NULL;
int size = 0;
if (!file)
return 0;
- v = getenv (XCURSOR_SIZE);
- if (v)
- size = atoi(v);
+ config = weston_config_parse(weston.ini);
+ s = weston_config_get_section(config, shell, NULL, NULL);
+ weston_config_section_get_string(s, cursor-theme, theme, NULL);
+ weston_config_section_get_int(s, cursor-size, size, 32);
+ weston_config_destroy(config);
- if (!size)
- size = 32;
-
- images = XcursorLibraryLoadImages (file, NULL, size);
+ images = XcursorLibraryLoadImages (file, theme, size);
+ free(theme);
if (!images)
return -1;
--
2.0.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/2] xwm: check whether the picked seat can be NULL
The seat picked in weston_wm_window_handle_moveresize can sometimes be NULL when it is (somehow) triggered with all buttons released. This patch checks whether the seat is NULL to avoid NULL dereference. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=80837 Signed-off-by: Boyan Ding stu_...@126.com --- xwayland/window-manager.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c index f64ef94..6e74b89 100644 --- a/xwayland/window-manager.c +++ b/xwayland/window-manager.c @@ -1250,8 +1250,8 @@ weston_wm_window_handle_moveresize(struct weston_wm_window *window, struct weston_shell_interface *shell_interface = wm-server-compositor-shell_interface; - if (seat-pointer-button_count != 1 || !window-view - || seat-pointer-focus != window-view) + if (seat == NULL || seat-pointer-button_count != 1 + || !window-view || seat-pointer-focus != window-view) return; detail = client_message-data.data32[2]; -- 2.0.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] cairo-util: Fix geometry for frames with buttons but without title
There exist frames which have buttons without title such as a simple X application piped through xwayland which doesn't specify a title. We draw the title bar with buttons, but hide it under the window because geometry thinks a window needs titlebar only if it has title. This patch change the condition, making it titlebar is needed if a frame has title or has button(s), which makes more sense. Signed-off-by: Boyan Ding stu_...@126.com --- shared/frame.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/shared/frame.c b/shared/frame.c index 35e6b65..aacca60 100644 --- a/shared/frame.c +++ b/shared/frame.c @@ -426,7 +426,7 @@ frame_resize_inside(struct frame *frame, int32_t width, int32_t height) struct theme *t = frame-theme; int decoration_width, decoration_height, titlebar_height; - if (frame-title) + if (frame-title || !wl_list_empty(frame-buttons)) titlebar_height = t-titlebar_height; else titlebar_height = t-width; @@ -467,7 +467,7 @@ frame_refresh_geometry(struct frame *frame) if (!frame-geometry_dirty) return; - if (frame-title) + if (frame-title || !wl_list_empty(frame-buttons)) titlebar_height = t-titlebar_height; else titlebar_height = t-width; -- 2.0.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston v2] shell: fix segfault in fullscreen binding
Commit 9aa8ce69 forgot to set shsurf-fullscreen_output in fullscreen_binding(), causing segfault when fullscreening using key bindings. This patch fixes that. https://bugs.freedesktop.org/show_bug.cgi?id=79828 Signed-off-by: Boyan Ding stu_...@126.com --- desktop-shell/shell.c | 1 + 1 file changed, 1 insertion(+) diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index d267cde..f22cef8 100644 --- a/desktop-shell/shell.c +++ b/desktop-shell/shell.c @@ -4193,6 +4193,7 @@ fullscreen_binding(struct weston_seat *seat, uint32_t time, uint32_t button, voi shsurf-state_requested = true; shsurf-requested_state.fullscreen = !shsurf-state.fullscreen; + shsurf-fullscreen_output = shsurf-output; send_configure_for_surface(shsurf); } -- 2.0.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] desktop-shell: Don't resize into the panel
Previously we can resize windows into panel in weston. This patch puts
a constraint in position when resizing just like what was done in
moving to avoid resizing window into the panel.
https://bugs.freedesktop.org/show_bug.cgi?id=80228
Signed-off-by: Boyan Ding stu_...@126.com
---
desktop-shell/shell.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index d267cde..eccfa1e 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1689,6 +1689,35 @@ struct weston_resize_grab {
};
static void
+constrain_resize_position(struct weston_resize_grab *resize,
+ wl_fixed_t *from_x, wl_fixed_t *from_y,
+ wl_fixed_t *to_x, wl_fixed_t *to_y)
+{
+ struct shell_surface *shsurf = resize-base.shsurf;
+ struct weston_pointer *pointer = resize-base.grab.pointer;
+ int panel_height;
+ wl_fixed_t grab_x, grab_y, x, y, panel_height_fixed;
+
+ grab_x = pointer-grab_x;
+ grab_y = pointer-grab_y;
+ x = pointer-x;
+ y = pointer-y;
+
+ panel_height = get_output_panel_height(shsurf-shell,
+ shsurf-surface-output);
+ panel_height_fixed = wl_fixed_from_int(panel_height);
+
+ if (grab_y panel_height_fixed)
+ grab_y = panel_height_fixed;
+ if (y panel_height_fixed)
+ y = panel_height_fixed;
+
+ weston_view_from_global_fixed(shsurf-view, grab_x, grab_y,
+ from_x, from_y);
+ weston_view_from_global_fixed(shsurf-view, x, y, to_x, to_y);
+}
+
+static void
resize_grab_motion(struct weston_pointer_grab *grab, uint32_t time,
wl_fixed_t x, wl_fixed_t y)
{
@@ -1704,11 +1733,7 @@ resize_grab_motion(struct weston_pointer_grab *grab,
uint32_t time,
if (!shsurf)
return;
- weston_view_from_global_fixed(shsurf-view,
- pointer-grab_x, pointer-grab_y,
- from_x, from_y);
- weston_view_from_global_fixed(shsurf-view,
- pointer-x, pointer-y, to_x, to_y);
+ constrain_resize_position(resize, from_x, from_y, to_x, to_y);
width = resize-width;
if (resize-edges WL_SHELL_SURFACE_RESIZE_LEFT) {
--
2.0.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] desktop-shell: Don't resize into the panel
Oh, sorry I didn't go through the mails carefully...
On Thu, 2014-06-26 at 05:26 +, Vivek Ellur wrote:
Hi,
I think you have duplicated the effort :). I had submitted the patch
for the same bug few days before.
http://lists.freedesktop.org/archives/wayland-devel/2014-June/015528.html.
Regards,
Vivek Ellur
--- Original Message ---
Sender : Boyan Dingstu_...@126.com
Date : Jun 26, 2014 09:21 (GMT+05:30)
Title : [PATCH weston] desktop-shell: Don't resize into the panel
Previously we can resize windows into panel in weston. This patch puts
a constraint in position when resizing just like what was done in
moving to avoid resizing window into the panel.
https://bugs.freedesktop.org/show_bug.cgi?id=80228
Signed-off-by: Boyan Ding
---
desktop-shell/shell.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index d267cde..eccfa1e 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1689,6 +1689,35 @@ struct weston_resize_grab {
};
static void
+constrain_resize_position(struct weston_resize_grab *resize,
+ wl_fixed_t *from_x, wl_fixed_t *from_y,
+ wl_fixed_t *to_x, wl_fixed_t *to_y)
+{
+ struct shell_surface *shsurf = resize-base.shsurf;
+ struct weston_pointer *pointer = resize-base.grab.pointer;
+ int panel_height;
+ wl_fixed_t grab_x, grab_y, x, y, panel_height_fixed;
+
+ grab_x = pointer-grab_x;
+ grab_y = pointer-grab_y;
+ x = pointer-x;
+ y = pointer-y;
+
+ panel_height = get_output_panel_height(shsurf-shell,
+shsurf-surface-output);
+ panel_height_fixed = wl_fixed_from_int(panel_height);
+
+ if (grab_y panel_height_fixed)
+ grab_y = panel_height_fixed;
+ if (y panel_height_fixed)
+ y = panel_height_fixed;
+
+ weston_view_from_global_fixed(shsurf-view, grab_x, grab_y,
+ from_x, from_y);
+ weston_view_from_global_fixed(shsurf-view, x, y, to_x, to_y);
+}
+
+static void
resize_grab_motion(struct weston_pointer_grab *grab, uint32_t time,
wl_fixed_t x, wl_fixed_t y)
{
@@ -1704,11 +1733,7 @@ resize_grab_motion(struct weston_pointer_grab
*grab, uint32_t time,
if (!shsurf)
return;
- weston_view_from_global_fixed(shsurf-view,
- pointer-grab_x, pointer-grab_y,
- from_x, from_y);
- weston_view_from_global_fixed(shsurf-view,
- pointer-x, pointer-y, to_x, to_y);
+ constrain_resize_position(resize, from_x, from_y, to_x, to_y);
width = resize-width;
if (resize-edges WL_SHELL_SURFACE_RESIZE_LEFT) {
--
2.0.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
1 attachments
201406261057484_QKNMBDIF.gif(13K)
download preview
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] shell: fix segfault in fullscreen binding
On Tue, 2014-06-24 at 21:40 -0700, Jason Ekstrand wrote:
Yes we should fix this. I have one question below.
Actually I'm not very sure about that either, maybe we should ask
@Jasper for suggestion.
On Sat, Jun 7, 2014 at 2:40 AM, Boyan Ding stu_...@126.com wrote:
Commit 9aa8ce69 'shell: Don't use the helper methods in
xdg_shell
implementations' forgot to set shsurf-fullscreen_optput in
fullscreen_binding(), causing weston to segfault when
fullscreen
with the mod + shift + f binding. This patch fixed that issue.
---
desktop-shell/shell.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index dd0b2f9..56ffebf 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -4180,6 +4180,12 @@ fullscreen_binding(struct weston_seat
*seat, uint32_t time, uint32_t button, voi
shsurf-state_requested = true;
shsurf-requested_state.fullscreen = !
shsurf-state.fullscreen;
+
+ if (shsurf-requested_state.fullscreen) {
+ shell_surface_set_output(shsurf, NULL);
Why are we setting the output to null? Prior to 9aa8ce69, it was
getting set to shsurf-recommended_output. Was there a reason for the
change to null? Does it not matter?
Thanks,
--Jason Ekstrand
+ shsurf-fullscreen_output = shsurf-output;
+ }
+
send_configure_for_surface(shsurf);
}
--
1.9.3
___
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: How to develop an application based on opengles
Hi, I think you can refer to this example code [1] in weston for ideas about how to initialize EGL in wayland, which I think is quite easy to understand. Regards, Boyan Ding [1] http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c#n318 On Mon, 2014-06-23 at 11:13 +0800, Jacky (ZhiJun) Ni wrote: Hi all, I’m now porting my opengles application to wayland platform, what do I need to prepare while I’m calling “eglGetDisplay” and “eglCreateWindowSurface”? I’ve tryied the following codes in my program, Step1: wl_display_connect(NULL) à return a global g_nativeDisplay object, I see someone do it, so that I do it. Step2: wl_display_get_registry, wl_registry_add_listener, wl_display_dispatch - some APIs I’m not familiar, I see someone do it, so that I do it. Step3: wl_egl_window_create(NULL,1280,720) à return a nativeWindow object which will be passed for EGL to Create Window Surface, I believe that the “NULL”(wl_surface*) parameter lead to the crash. But I have no idea how to get a wl_surface object. Step4: eglGetDisplay, eglInitialize, eglChooseConfig, eglCreateContext, eglCreateWindowSurface, eglMakeCurrent, eglQuerySurface, these APIs all work fine, return no error. Step4: eglSwapBuffers, lead to the crash, trace the bt, I find that it is because wl_surface is NULL, (gdb) bt #0 0xb7e35a85 in wl_proxy_create () from /lib/libwayland-client.so.0 #1 0xb7e1ac10 in wl_surface_frame (wl_surface=0x0) at /home/jacky/Apps/Wayland/include/wayland-client-protocol.h:1355 #2 0xb7e1bfbb in dri2_wl_swap_buffers_with_damage (drv=0x8730f88, disp=0x8730300, draw=0x87cc380, rects=0x0, n_rects=0) at platform_wayland.c:617 #3 0xb7e1c309 in dri2_wl_swap_buffers (drv=0x8730f88, disp=0x8730300, draw=0x87cc380) at platform_wayland.c:702 #4 0xb7e19739 in dri2_swap_buffers (drv=0x8730f88, dpy=0x8730300, surf=0x87cc380) at egl_dri2.c:1074 #5 0xb7e0cd03 in eglSwapBuffers (dpy=0x8730300, surface=0x87cc380) at eglapi.c:811 I searched the internet but get less useful information, even now , I plan to make some fake data to initialize the wl_surface, but I have not got the definition for the struct “wl_surface”, just a url(http://wayland.freedesktop.org/docs/html/protocol-spec-interface-wl_surface.html ) describe how to use its function, no initialize function… It is so different from X11 who only need to prepare a window passed to EGL, So far, I’ve learned I need prepare a ”wl_egl_window” and a “wl_surface” for EGL on wayland, wl_egl_window need three parameters “wl_surface”, “width” and “height” to create, but “wl_surface” seems need compositor(API:”wl_compositor_create_surface” )to create, so compositor need what to create? May I need to create a compositor firstly? Best Regards, Jacky Ni CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] xdg-shell: Fix a typo in description
Signed-off-by: Boyan Ding stu_...@126.com --- protocol/xdg-shell.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml index 28add40..0327f40 100644 --- a/protocol/xdg-shell.xml +++ b/protocol/xdg-shell.xml @@ -304,7 +304,7 @@ /enum event name=configure - description summary=suggest a surface chnage + description summary=suggest a surface change The configure event asks the client to resize its surface. The width and height arguments specify a hint to the window -- 2.0.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Suggestions on implementing Wayland Protocol Dumper.
Hi, According to [1], from which the idea of protocol dumper came, the purpose of the protocol dumper is to track exactly how a client communicate with the server, and to make a difference with how WAYLAND_DEBUG=server works. So IMHO, the protocol dumper may be implemented as a standalone program, though it may probably reside in the wayland source tree. And it job is to reset the WAYLAND_DISPLAY environment argument, fork off the client wanted and redirect what the client send to the real server, dumping the data in the process -- just like a proxy. The benefit of this way of implementation is that it not only help weston but may also help the development of other projects (e.g. you may even use it under Gnome on Wayland). This is my advice. Regards, Boyan Ding On Mon, 2014-06-09 at 11:17 +0530, Srivardhan wrote: Hi, The following are the ways in which a Protocol Dumper can be implemented: 1. Just before sending a message or when a message is received, the message can be written to a file. This change can be done in libwayland under #ifdef DEBUG. So when built enabling DEBUG, we should get all the protocol messages. 2. We can introduce another layer in Weston for monitoring. This layer would act as Man in the middle. This layer would listen to a socket to which all the Wayland clients would attach and this layer would in turn attach to the server socket. This layer would print the messages it received from the client and would transfer to the server and vise a versa. This could be included in #ifdef DEBUG, so that it is enabled only in DEBUG builds. I feel the 1st approach is simpler, What are your thoughts? Thank-you, Hebbar ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] shell: fix segfault in fullscreen binding
Commit 9aa8ce69 'shell: Don't use the helper methods in xdg_shell
implementations' forgot to set shsurf-fullscreen_optput in
fullscreen_binding(), causing weston to segfault when fullscreen
with the mod + shift + f binding. This patch fixed that issue.
---
desktop-shell/shell.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index dd0b2f9..56ffebf 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -4180,6 +4180,12 @@ fullscreen_binding(struct weston_seat *seat, uint32_t
time, uint32_t button, voi
shsurf-state_requested = true;
shsurf-requested_state.fullscreen = !shsurf-state.fullscreen;
+
+ if (shsurf-requested_state.fullscreen) {
+ shell_surface_set_output(shsurf, NULL);
+ shsurf-fullscreen_output = shsurf-output;
+ }
+
send_configure_for_surface(shsurf);
}
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Maximizing window after fullscreening it in weston desktop shell
The handling about window states has been improved recently but there still seems some problem with that. When I was running weston-stacking with yesterday's snapshot of weston (weston-stacking in 1.5.0 is much more troublesome), I found if I press m (maximize) multiple times after fullscreening it, the fullscreened window will become brighter and brighter because the window is opaque and is drawn again and again instead of drawing on the black view. After analysing the code, I found when a window is requesting to maximize when it's fullscreen, we now will configure it for fullscreening again. And the black view somehow doesn't come to the front and we directly draw the new surface on the original one. I want to ask several question about it: 1. Is the behavior I talked about a desired behavior? 2. If not. How should we deal with that? For 1, I think that's undesired. And for 2, I came up with two ideas. One way is to ignore the maximizing request when it is (or will be) fullscreen. The other is to handle that in later stages of configuration. I don't know which is more appropriate. I'm still studying wayland and weston code, so feel free to point out my misunderstandings. Thanks, Boyan Ding ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston multitouch support?
Which backend are you running on?
On Sun, 2014-06-01 at 02:03 +0100, José Expósito wrote:
Hi all,
I'm running a very simple QML multitouch example using
MultiPointTouchArea, that works (more or less) on X11, here is the
code:
Rectangle {
width: 400; height: 400
MultiPointTouchArea {
anchors.fill: parent
touchPoints: [ TouchPoint { id: point1 }, TouchPoint { id:
point2 } ]
}
Rectangle { width: 30; height: 30; color: green; x:
point1.x; y: point1.y }
Rectangle { width: 30; height: 30; color: yellow; x:
point2.x; y: point2.y }
}
And I say more or less because it is necessary to put 3 fingers on the
trackpad to start moving the rectangles...
Anyway, the program is not working on Weston. My question is, is that
because Weston doesn't implement multitouch support or because Wayland
doesn't support it at the moment? Could it be possible to implement
multitouch support in a custom compositor?
This is my system information:
Macbook Air 2011 (clickpack)
Qt 5.3.0
Latest QtWayland source code (1/Jun/2014)
Weston 1.5.90
___
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: Weston multitouch support?
If you're using weston-launch there may be a problem somewhere -- I'm
not an expert in that. But I know there're some backends (e.g. nested
wayland) which doesn't support touch at all at present.
On Sun, 2014-06-01 at 03:24 +0100, José Expósito wrote:
Thank you for the quick answer.
It happens if I run Weston as X client (weston command) or using
weston-launch.
I'm not sure how can I check the backend...
El 01/06/2014 02:50, Boyan Ding stu_...@126.com escribió:
Which backend are you running on?
On Sun, 2014-06-01 at 02:03 +0100, José Expósito wrote:
Hi all,
I'm running a very simple QML multitouch example using
MultiPointTouchArea, that works (more or less) on X11, here
is the
code:
Rectangle {
width: 400; height: 400
MultiPointTouchArea {
anchors.fill: parent
touchPoints: [ TouchPoint { id: point1 },
TouchPoint { id:
point2 } ]
}
Rectangle { width: 30; height: 30; color: green;
x:
point1.x; y: point1.y }
Rectangle { width: 30; height: 30; color: yellow;
x:
point2.x; y: point2.y }
}
And I say more or less because it is necessary to put 3
fingers on the
trackpad to start moving the rectangles...
Anyway, the program is not working on Weston. My question
is, is that
because Weston doesn't implement multitouch support or
because Wayland
doesn't support it at the moment? Could it be possible to
implement
multitouch support in a custom compositor?
This is my system information:
Macbook Air 2011 (clickpack)
Qt 5.3.0
Latest QtWayland source code (1/Jun/2014)
Weston 1.5.90
___
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
___
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
Hi Jason, In writing v2 of the patches I found out frame_touch_motion isn't that easy as it seems. For there's something tricky. Without frame_touch_motion the code actually works all right - finger down on a button presses the button and finger up releases it, regardless of where the finger has gone. However, if frame_touch_motion is implemented, I think the behavior might be changed to this - finger down presses the button; once the finger leave the button, the press should be cancelled and if the finger enters the region of another button we'll just act as if we hover above the button. If it is implemented like that, we'll have to change the frame_touch structure to add a field that keep track of which button we hover on, just like hover_button in frame_pointer. I'll also add a frame_touch_cancel function, it seems not that hard. Just scan the list of touches and take appropriate actions (cancel button, destroy touch) will do. I wonder whether my ideas are appropriate. Regards, Boyan Ding ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] doc: Remove obsolete doxygen tags
--- doc/doxygen/wayland.doxygen.in | 28 1 file changed, 28 deletions(-) diff --git a/doc/doxygen/wayland.doxygen.in b/doc/doxygen/wayland.doxygen.in index dd98594..e64512f 100644 --- a/doc/doxygen/wayland.doxygen.in +++ b/doc/doxygen/wayland.doxygen.in @@ -310,22 +310,6 @@ INLINE_SIMPLE_STRUCTS = NO TYPEDEF_HIDES_STRUCT = NO -# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to -# determine which symbols to keep in memory and which to flush to disk. -# When the cache is full, less often used symbols will be written to disk. -# For small to medium size projects (1000 input files) the default value is -# probably good enough. For larger projects a too small cache size can cause -# doxygen to be busy swapping symbols to and from disk most of the time -# causing a significant performance penalty. -# If the system has enough physical memory increasing the cache will improve the -# performance by keeping more symbols in memory. Note that the value works on -# a logarithmic scale so increasing the size by one will roughly double the -# memory usage. The cache size is given by this formula: -# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0, -# corresponding to a cache size of 2^16 = 65536 symbols. - -SYMBOL_CACHE_SIZE = 0 - # Similar to the SYMBOL_CACHE_SIZE the size of the symbol lookup cache can be # set using LOOKUP_CACHE_SIZE. This cache is used to resolve symbols given # their name and scope. Since this can be an expensive process and often the @@ -1371,18 +1355,6 @@ GENERATE_XML = NO XML_OUTPUT = xml -# The XML_SCHEMA tag can be used to specify an XML schema, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_SCHEMA = - -# The XML_DTD tag can be used to specify an XML DTD, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_DTD= - # If the XML_PROGRAMLISTING tag is set to YES Doxygen will # dump the program listings (including syntax highlighting # and cross-referencing information) to the XML output. Note that -- 1.9.2 ___ 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
At 2014-05-08 09:55:23, Jason Ekstrand ja...@jlekstrand.net wrote:
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.
Unfortunately, I don't have touch hardware either. However I found a
interesting project [1] on github, though I'm still figuring out how to use 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.
I saw the code handling FRAME_STATUS_MOVE in input_handle_button returned after
handling that. Do we need to return here?
Also, I saw the pointer code notify the event only if the location is
THEME_LOCATION_CLIENT_AREA. Do we need to do the same thing? (I noticed the
change of return type of frame_touch_down from void to theme_location in [2]
but that patch hasn't been applied.
+
+ 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
[PATCH 0/2] weston: Add touch support to nested wayland backend
The following two patches add touch support to weston's nested wayland backend to facilitate testing. The first one adds motion support to cairo-util and the second actually add the touch listeners in the compositor. I'm new to wayland and weston and this is my first work. So any advice is welcomed. Boyan Ding (2): cairo-util: Add frame_touch_motion support compositor-wayland: Add touch support shared/cairo-util.h | 3 ++ shared/frame.c | 24 src/compositor-wayland.c | 95 3 files changed, 122 insertions(+) -- 1.9.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] cairo-util: Add frame_touch_motion support
---
shared/cairo-util.h | 3 +++
shared/frame.c | 24
2 files changed, 27 insertions(+)
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 4493b0d..7aebb65 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -211,6 +211,9 @@ void
frame_touch_up(struct frame *frame, void *data, int32_t id);
void
+frame_touch_motion(struct frame *frame, void *data, int32_t id, int x, int y);
+
+void
frame_repaint(struct frame *frame, cairo_t *cr);
#endif
diff --git a/shared/frame.c b/shared/frame.c
index 35e6b65..df51eca 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -837,6 +837,30 @@ frame_touch_up(struct frame *frame, void *data, int32_t id)
}
void
+frame_touch_motion(struct frame *frame, void *data, int32_t id, int x, int y)
+{
+ struct frame_touch *touch = frame_touch_get(frame, data);
+ struct frame_button *button = frame_find_button(frame, x, y);
+
+ if (id 0 || !touch)
+ return;
+
+ touch-x = x;
+ touch-y = y;
+
+ if (touch-button == button)
+ return ;
+
+ if (touch-button)
+ frame_button_release(touch-button);
+
+ touch-button = button;
+
+ if (touch-button)
+ frame_button_press(touch-button);
+}
+
+void
frame_repaint(struct frame *frame, cairo_t *cr)
{
struct frame_button *button;
--
1.9.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] compositor-wayland: Add touch support
Adding touch support to weston's nested wayland backend to make testing
easier.
https://bugs.freedesktop.org/show_bug.cgi?id=77769
---
src/compositor-wayland.c | 95
1 file changed, 95 insertions(+)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index a08b71a..45040d4 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1582,6 +1582,91 @@ static const struct wl_keyboard_listener
keyboard_listener = {
};
static void
+input_handle_touch_down(void *data, struct wl_touch *touch, uint32_t serial,
+ uint32_t time, struct wl_surface *surface, int32_t id,
+ wl_fixed_t x, wl_fixed_t y)
+{
+ struct wayland_input *input = data;
+ int32_t fx, fy;
+
+ if (input-output-frame) {
+ frame_touch_down(input-output-frame, input, id,
+wl_fixed_to_int(x), wl_fixed_to_int(y));
+ frame_interior(input-output-frame, fx, fy, NULL, NULL);
+ x -= wl_fixed_from_int(fx);
+ y -= wl_fixed_from_int(fy);
+
+ if (frame_status(input-output-frame) FRAME_STATUS_REPAINT)
+ weston_output_schedule_repaint(input-output-base);
+ }
+
+ weston_output_transform_coordinate(input-output-base, x, y, x, y);
+
+ notify_touch(input-base, time, id, x, y, WL_TOUCH_DOWN);
+}
+
+static void
+input_handle_touch_up(void *data, struct wl_touch *touch, uint32_t serial,
+ uint32_t time, int32_t id)
+{
+ struct wayland_input *input = data;
+
+ if (input-output-frame) {
+ frame_touch_up(input-output-frame, input, id);
+
+ if (frame_status(input-output-frame) FRAME_STATUS_REPAINT)
+ weston_output_schedule_repaint(input-output-base);
+ }
+
+ notify_touch(input-base, time, id, 0, 0, WL_TOUCH_UP);
+}
+
+static void
+input_handle_touch_motion(void *data, struct wl_touch *touch, uint32_t time,
+ int32_t id, wl_fixed_t x, wl_fixed_t y)
+{
+ struct wayland_input *input = data;
+ int32_t fx, fy;
+
+ if (input-output-frame) {
+ frame_touch_motion(input-output-frame, input, id,
+wl_fixed_to_int(x), wl_fixed_to_int(y));
+
+ frame_interior(input-output-frame, fx, fy, NULL, NULL);
+ x -= wl_fixed_from_int(fx);
+ y -= wl_fixed_from_int(fy);
+
+ if (frame_status(input-output-frame) FRAME_STATUS_REPAINT)
+ weston_output_schedule_repaint(input-output-base);
+ }
+
+ weston_output_transform_coordinate(input-output-base, x, y, x, y);
+
+ notify_touch(input-base, time, id, x, y, WL_TOUCH_MOTION);
+}
+
+static void
+input_handle_touch_frame(void *data, struct wl_touch *touch)
+{
+ struct wayland_input *input = data;
+
+ notify_touch_frame(input-base);
+}
+
+static void
+input_handle_touch_cancel(void *data, struct wl_touch *touch)
+{
+}
+
+static const struct wl_touch_listener touch_listener = {
+ input_handle_touch_down,
+ input_handle_touch_up,
+ input_handle_touch_motion,
+ input_handle_touch_frame,
+ input_handle_touch_cancel
+};
+
+static void
input_handle_capabilities(void *data, struct wl_seat *seat,
enum wl_seat_capability caps)
{
@@ -1607,6 +1692,16 @@ input_handle_capabilities(void *data, struct wl_seat
*seat,
wl_keyboard_destroy(input-parent.keyboard);
input-parent.keyboard = NULL;
}
+
+ if ((caps WL_SEAT_CAPABILITY_TOUCH) !input-parent.touch) {
+ input-parent.touch = wl_seat_get_touch(seat);
+ wl_touch_set_user_data(input-parent.touch, input);
+ wl_touch_add_listener(input-parent.touch,
+touch_listener, input);
+ } else if (!(caps WL_SEAT_CAPABILITY_TOUCH) input-parent.touch) {
+ wl_touch_destroy(input-parent.touch);
+ input-parent.touch = NULL;
+ }
}
static const struct wl_seat_listener seat_listener = {
--
1.9.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
