If a client is terminated due to some reason, it should always be
possible to retrieve protocol error associated with the termination.
Test that, while either using the dispatch helpers
(wl_display_dispatch(_queue)() or the prepare read API, it should be
possible to retrieve the error after EPIPE.
If flushing hits EPIPE it should not make it a fatal error since it
would make it impossible to process the rest of the data available in
the buffer. Instead, let reading the socket make EPIPE fatal, letting
the client have the possibility to process the last messages including
any error causing th
The current documentation about wl_display_dispatch() states one may not
mix wl_display_dispatch(_queue)() with wl_display_prepare_read() and
friends, but this is a misconception about how
wl_display_dispatch(_queue)() works. The fact is that the dispatch
functions does the equivalent of what the p
We currently wait for clients in the wl_client destroy signal, which is
called before the client is destructed and the socket is closed. If test
clients rely on being closed due to the socket being closed we'd dead
lock. Avoid this by synchronizing in an idle task that is called after
the client is
wl_display_flush() may fail with EAGAIN which means that not all data
waiting in the buffer has been flushed. We later block until there
data to read, which could mean that we block on input from the
compositor without having sent out all data from the client. Avoid this
by fully flushing the socke
Change the API to pass an "void *" argument to the client main
function, allowing the caller to call the same main function with
different input.
A helper (client_create_noarg) is added for when no argument is passed,
and the existing test cases are changed to use this function instead.
Signed-of
There was documentation about how to integrate the display server file
descriptor in the documentation about wl_display_dispatch_pending().
This is not the right place to put it, and it also had incorrect usage
of the API (calling wl_display_dispatch_queue() on input on an unrelated
fd) as an examp
Instead of doing things that do the equivalent of using
wl_display_prepare_read() and friends, just use the public API. The
only semantical difference is that we will now unlock and lock the mutex
more times compared to before.
Signed-off-by: Jonas Ådahl
---
src/wayland-client.c | 45 ++-
Signed-off-by: Jonas Ådahl
---
src/wayland-shm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/wayland-shm.c b/src/wayland-shm.c
index 359c3bd..8e7adc9 100644
--- a/src/wayland-shm.c
+++ b/src/wayland-shm.c
@@ -404,7 +404,7 @@ wl_shm_buffer_ref_pool(struct wl_shm_buffer
Put the various misplaced functions in the right class; partly because
its where they belong, and partly to make intra-class \ref(erences)
happy.
Signed-off-by: Jonas Ådahl
---
src/wayland-client-core.h | 4 ++--
src/wayland-client.c | 10 +-
2 files changed, 7 insertions(+), 7 del
Signed-off-by: Jonas Ådahl
---
src/connection.c | 4 ++--
src/wayland-client.c | 12 +++-
src/wayland-private.h | 6 ++
src/wayland-server.c | 6 ++
src/wayland-shm.c | 4 +---
5 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/src/connection.c b/src/c
If an event or request have a "since" attribute that is larger than
the version of the interface it is in, fail with an explaining error
message.
Signed-off-by: Jonas Ådahl
---
src/scanner.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/scanner.c b/src/scanner.c
in
There are lots of warnings about fields and other things not being
documented, and many of those will probably never be documented, so
stop warning about it.
Signed-off-by: Jonas Ådahl
---
doc/doxygen/wayland.doxygen.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/doxygen/wayland.doxy
A statement was added at the same indentation level as the true branch
of the if statement, but since there were no brackets, it would be
executed independently of the result of the if condition.
Signed-off-by: Jonas Ådahl
---
src/scanner.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Hello,
I'd like to try to experiment with Wayland/Weston and write a tiling window
manager as a Weston plugin. I was wondering if there's any way for compositor to
tell if the wl_shell_surface or xdg_surface belongs to a `floating window', by
which I mean for example:
- error information d
15 matches
Mail list logo