[RFC wayland 1/2] connection: Move some definitions

2014-07-19 Thread Boyan Ding
wayland-tracer will need them

Signed-off-by: Boyan Ding 
---
 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


[RFC wayland 0/2] Wayland protocol dumper

2014-07-19 Thread Boyan Ding
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

2014-07-19 Thread Boyan Ding
Signed-off-by: Boyan Ding 
---
 .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=Look 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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 functions are taken from wayland-client.c*/
+static int
+tracer_connect_to_socket(con

Re: Fwd: [PATCH weston] xdg-shell: Make stable

2014-07-19 Thread Manuel Bachmann
Hi Jasper, Jaspon, thanks for taking good arguments to the table,

"Destroying and creating an xdg_surface will, certainly."

Yes, that's what we have been doing for some time, but it has the serious
drawback that the new surface will not be positioned the same.

"xdg_surface_present_window()"

"window" may be an excessive high-level word ; what do you think of
"xdg_surface_present()" alone ?

"I do want to make the guarantee that it isn't "immediate""
"The point here is that we don't want minimize/unminimize to get abused by
apps."

I fully understand this. One on the reasons the patch was still WIP is that
I wanted to avoid application abuses of this API -by trying to steal the
focus or to keep their window constantly in foreground by
minimizing/unminimizing quickly e.g..

"So, what is the use case for unset_minimized?"

Take the case when an application has been minimized, and an event happens
(nerdopolis gave the case of opening a new document, could be an alert) the
application wants you to know so you can easily bring its surface back if
needed.

"Unfortunately, toolkits really like to work in terms of show/hide which,
while easy, doesn't fit exactly."

Agreed. In the EFL, we mapped "xdg_surface_set_minimized()" to
"ecore_wl_window_iconified_set()". One could argue about the "iconified"
word ; however we didn't want to use "hide()" which does something
different.

"when a window gets unminimized and things of that nature
need to be determined by two things:  App intentions communicated to the
compositor, and compositor policy.  If the app has important information
for the user, it should indicate that to the compositor.  The compositor
can then respond by showing the window, switching workspaces, making
something blink/bounce, etc. depending on its *policy*.  For something like
Tizen, that could be "if the app has the focus-stealing permission, show
the window, otherwise blink the notification bar" or something like that."

I think you summed it up nicely. We want the window to be able to be shown
back, however not in all cases.

I could demonstrate the API use case by doing the following in a temp
Weston patch : if an application sends the "xdg_surface_present()" request,
then a little blinking balloon, technically similar to a panel tooltip,
will appear at the bottom of the screen for some time.
When clicked, the balloon would then make the surface appear back on the
current screen, positioned as it was before.

What do you think of that ?


2014-07-18 18:55 GMT+02:00 Jason Ekstrand :

>
>
>
> On Fri, Jul 18, 2014 at 5:31 AM, nerdopolis <
> bluescreen_aven...@verizon.net> wrote:
>
>> On Friday, July 18, 2014 08:25:33 AM Jasper St. Pierre wrote:
>> > The lack of an unset_minimized feature is very intentional. The *goal*,
>> it
>> > sounds like, is to present the window immediately again, but an
>> > unset_minimized won't do that. What if the window is on a different
>> > workspace, or has been simply stacked behind another set of windows?
>> >
>> > unset_minimized won't solve any of these issues. Destroying and
>> creating an
>> > xdg_surface will, certainly.
>> >
>> > If there's a valid use case, and I'm *very* skeptical that there is, I
>> > would be fine in "present_window" request that tries as hard as
>> possible to
>> > present the window to the user (unminimizing, changing workspaces,
>> stacking
>> > to the top). However, I do want to make the guarantee that it isn't
>> > immediate. Compositors may implement this request by instead showing a
>> > blinking icon in the taskbar, to prevent an application from suddenly
>> > stealing the user's focus.
>> >
>> > So, what is the use case for unset_minimized?
>> >
>> I know for example when I open and minimize kate, (text editor), and then
>> I open another text file from my file manager, the existing kate window
>> unmimimizes itself, and opens the second file in the same window, instead
>> of staying minimized.
>>
>> I feel if kate didn't have this feature, if it was minimized, and unable
>> to unmiminize itself, it's probably easy to forget about the existing
>> instance, and it would seem irresponsive...
>>
>
> I really like Jasper's "present" request solution to this problem. (It
> could probably also be called "attention").  If kwin wants to implement
> that as "move to the appropriate workspace and unminimize, then it can do
> that.  Otherwise, it could start flashing the task-bar icon or something.
>
> The point here is that we don't want minimize/unminimize to get abused by
> apps.  The *only* reason for a minimized request is to allow an app to ask
> to be minimized.  That is all.  It is *not* so that the app can know if
> it's minimzied and stop drawing or so that it can show/hide itself.  We
> want to make the protocol describe the intention of the app, not the exact
> thing to do on-screen.  In the case of the kate example, the intention of
> kate is that is has new content now (requested by the user) that it would
> like the user to se