Re: [PATCH weston] protocol: move sub-surfaces to Wayland

[Kristian Høgsberg]

On Fri, Nov 15, 2013 at 04:12:13PM +0200, ppaala...@gmail.com wrote:
> From: Pekka Paalanen 
> 
> This reverts commit 2396aec6842c709a714f3825dbad9fd88478f2e6.
> 
> This exact version of the sub-surface protocol has been copied into
> Wayland core. Therefore it must be removed from here to avoid build
> conflicts and useless duplication.
> 
> No other changes to sub-surface protocol consumers are needed, the
> identical API is now offered by libwayland-client and libwayland-server.
> 
> The commit adding sub-surfaces to Wayland is:
> Author: Pekka Paalanen 
> 
> protocol: add sub-surfaces to the core
> 
> Signed-off-by: Pekka Paalanen 

Yup, about time - thanks Pekka.  Both patches applied.

Kristian

> ---
>  clients/.gitignore  |   2 -
>  clients/Makefile.am |   4 -
>  clients/window.h|   1 -
>  protocol/Makefile.am|   1 -
>  protocol/subsurface.xml | 244 
> 
>  src/.gitignore  |   3 -
>  src/Makefile.am |   4 -
>  src/compositor.c|   1 -
>  tests/.gitignore|   2 -
>  tests/Makefile.am   |   6 +-
>  tests/subsurface-test.c |   1 -
>  11 files changed, 1 insertion(+), 268 deletions(-)
>  delete mode 100644 protocol/subsurface.xml
> 
> diff --git a/clients/.gitignore b/clients/.gitignore
> index 23959cc..92e1659 100644
> --- a/clients/.gitignore
> +++ b/clients/.gitignore
> @@ -27,8 +27,6 @@ weston-keyboard
>  libtoytoolkit.a
>  screenshooter-client-protocol.h
>  screenshooter-protocol.c
> -subsurface-client-protocol.h
> -subsurface-protocol.c
>  tablet-shell-client-protocol.h
>  tablet-shell-protocol.c
>  text-client-protocol.h
> diff --git a/clients/Makefile.am b/clients/Makefile.am
> index 4f9dc48..032d900 100644
> --- a/clients/Makefile.am
> +++ b/clients/Makefile.am
> @@ -97,8 +97,6 @@ libtoytoolkit_la_SOURCES =  \
>   window.h\
>   text-cursor-position-protocol.c \
>   text-cursor-position-client-protocol.h  \
> - subsurface-protocol.c   \
> - subsurface-client-protocol.h\
>   workspaces-protocol.c   \
>   workspaces-client-protocol.h
>  
> @@ -227,8 +225,6 @@ BUILT_SOURCES =   \
>   desktop-shell-protocol.c\
>   tablet-shell-client-protocol.h  \
>   tablet-shell-protocol.c \
> - subsurface-client-protocol.h\
> - subsurface-protocol.c   \
>   workspaces-client-protocol.h\
>   workspaces-protocol.c
>  
> diff --git a/clients/window.h b/clients/window.h
> index 838ea4e..66cf985 100644
> --- a/clients/window.h
> +++ b/clients/window.h
> @@ -28,7 +28,6 @@
>  #include 
>  #include "../shared/config-parser.h"
>  #include "../shared/zalloc.h"
> -#include "subsurface-client-protocol.h"
>  
>  #define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
>  
> diff --git a/protocol/Makefile.am b/protocol/Makefile.am
> index d09d8eb..14a4b5a 100644
> --- a/protocol/Makefile.am
> +++ b/protocol/Makefile.am
> @@ -6,7 +6,6 @@ protocol_sources =\
>   text.xml\
>   input-method.xml\
>   workspaces.xml  \
> - subsurface.xml  \
>   text-cursor-position.xml\
>   wayland-test.xml
>  
> diff --git a/protocol/subsurface.xml b/protocol/subsurface.xml
> deleted file mode 100644
> index 9e4a658..000
> --- a/protocol/subsurface.xml
> +++ /dev/null
> @@ -1,244 +0,0 @@
> -
> -
> -
> -  
> -Copyright © 2012-2013 Collabora, Ltd.
> -
> -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.
> -  
> -
> -  
> -
> -  The global interface

[PATCH] client: Introduce functions to allocate and marshal proxies atomically

[Kristian Høgsberg]

The server requires clients to only allocate one ID ahead of the previously
highest ID in order to keep the ID range tight.  Failure to do so will
make the server close the client connection.  However, the way we allocate
new IDs is racy.  The generated code looks like:

  new_proxy = wl_proxy_create(...);
  wl_proxy_marshal(proxy, ... new_proxy, ...);

If two threads do this at the same time, there's a chance that thread A
will allocate a proxy, then get pre-empted by thread B which then allocates
a proxy and then passes it to wl_proxy_marshal().  The ID for thread As
proxy will be one higher that the currently highest ID, but the ID for
thread Bs proxy will be two higher.  But since thread B prempted thread A
before it could send its new ID, B will send its new ID first, the server
will see the ID from thread Bs proxy first, and will reject it.

We fix this by introducing wl_proxy_marshal_constructor().  This
function is identical to wl_proxy_marshal(), except that it will
allocate a wl_proxy for NEW_ID arguments and send it, all under the
display mutex.  By introducing a new function, we maintain backwards
compatibility with older code from the generator, and make sure that
the new generated code has an explicit dependency on a new enough
libwayland-client.so.

A virtual Wayland merit badge goes to Kalle Vahlman, who tracked this
down and analyzed the issue.

Reported-by: Kalle Vahlman 
---
 src/Makefile.am  |   2 +-
 src/scanner.c|  43 ++-
 src/wayland-client.c | 211 ++-
 src/wayland-client.h |   8 ++
 4 files changed, 189 insertions(+), 75 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 4226f63..fb2df1c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -27,7 +27,7 @@ libwayland_server_la_SOURCES =\
event-loop.c
 
 libwayland_client_la_LIBADD = $(FFI_LIBS) libwayland-util.la -lrt -lm
-libwayland_client_la_LDFLAGS = -version-info 1:0:1
+libwayland_client_la_LDFLAGS = -version-info 2:0:2
 libwayland_client_la_SOURCES = \
wayland-protocol.c  \
wayland-client.c
diff --git a/src/scanner.c b/src/scanner.c
index 9624618..a030181 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -699,31 +699,34 @@ emit_stubs(struct wl_list *message_list, struct interface 
*interface)
   "{\n");
if (ret) {
printf("\tstruct wl_proxy *%s;\n\n"
-  "\t%s = wl_proxy_create("
-  "(struct wl_proxy *) %s,\n",
-  ret->name, ret->name, interface->name);
+  "\t%s = wl_proxy_marshal_constructor("
+  "(struct wl_proxy *) %s,\n"
+  "\t\t\t %s_%s, ",
+  ret->name, ret->name,
+  interface->name,
+  interface->uppercase_name,
+  m->uppercase_name);
+
if (ret->interface_name == NULL)
-   printf("\t\t\t interface);\n");
+   printf("interface");
else
-   printf("\t\t\t &%s_interface);\n",
-  ret->interface_name);
-
-   printf("\tif (!%s)\n"
-  "\t\treturn NULL;\n\n",
-  ret->name);
+   printf("&%s_interface", ret->interface_name);
+   } else {
+   printf("\twl_proxy_marshal((struct wl_proxy *) %s,\n"
+  "\t\t\t %s_%s",
+  interface->name,
+  interface->uppercase_name,
+  m->uppercase_name);
}
 
-   printf("\twl_proxy_marshal((struct wl_proxy *) %s,\n"
-  "\t\t\t %s_%s",
-  interface->name,
-  interface->uppercase_name,
-  m->uppercase_name);
-
wl_list_for_each(a, &m->arg_list, link) {
-   if (a->type == NEW_ID && a->interface_name == NULL)
-   printf(", interface->name, version");
-   printf(", ");
-   printf("%s", a->name);
+   if (a->type == NEW_ID) {
+   if (a->interface_name == NULL)
+   printf(", interface->name, version");
+   printf(", NULL");
+   } else {
+   printf(", %s", a->name);
+   }
}
printf(");\n");
 
diff --git a/src/wayland-client.c b/src/wayland-client.c
index e92317a..1486b73 100644
--- a/sr

Re: [PATCH 3/3] shm: Avoid file descriptor leak upon unsuccessful mmap

[Kristian Høgsberg]

On Fri, Nov 15, 2013 at 02:17:56PM +0100, Lubomir Rintel wrote:
> It would be possible to make the compositor leak file descriptors by
> passing descriptors of open unmmapable files to it, such as /dev/null.
> 
> Signed-off-by: Lubomir Rintel 
> ---
>  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 ad92dba..0bae6da 100644
> --- a/src/wayland-shm.c
> +++ b/src/wayland-shm.c
> @@ -248,7 +248,7 @@ shm_create_pool(struct wl_client *client, struct 
> wl_resource *resource,
>   wl_resource_post_error(resource,
>  WL_SHM_ERROR_INVALID_FD,
>  "failed mmap fd %d", fd);
> - goto err_free;
> + goto err_close;

Good find, fix applied.

Kristian

>   }
>   close(fd);
>  
> -- 
> 1.8.4.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/3] shm: Do not attempt mmap if no file descriptor was received

[Kristian Høgsberg]

On Fri, Nov 15, 2013 at 02:17:55PM +0100, Lubomir Rintel wrote:
> This is just for the sake of  cleanliness and correct error handling.
> Without this the mmap would fail emitting an error message about failed
> mapping to the client and a close of bogus file descriptor would be
> attempted, which is harmless since it can not fail.

Cf the comments, on patch 1/3, we'll never get a -1 fd.

Kristian

> Signed-off-by: Lubomir Rintel 
> ---
>  src/wayland-shm.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
> index 28f52f4..ad92dba 100644
> --- a/src/wayland-shm.c
> +++ b/src/wayland-shm.c
> @@ -220,6 +220,13 @@ shm_create_pool(struct wl_client *client, struct 
> wl_resource *resource,
>  {
>   struct wl_shm_pool *pool;
>  
> + if (fd < 0) {
> + wl_resource_post_error(resource,
> +WL_SHM_ERROR_INVALID_FD,
> +"file descriptor expected");
> + return;
> + }
> +
>   pool = malloc(sizeof *pool);
>   if (pool == NULL) {
>   wl_client_post_no_memory(client);
> -- 
> 1.8.4.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/3] connection: Only read file descriptor if it was actually received

[Kristian Høgsberg]

On Fri, Nov 15, 2013 at 02:17:54PM +0100, Lubomir Rintel wrote:
> Otherwise the tail of fds_in buffer would just shift beyond the beginning.
> That confuses the actual request handler and results in a crash further on
> due to corrupted tail.
> 
> Signal the lack of file descriptor with -1, so that the request handler
> can determine that no valid file descriptor was received via anciliary
> data.

I think this should be an error condition similar to how a string can
be too short, for example.  Set errno to EINVAL, goto err.

Kristian

> Signed-off-by: Lubomir Rintel 
> ---
>  src/connection.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/src/connection.c b/src/connection.c
> index 451b93e..48a5398 100644
> --- a/src/connection.c
> +++ b/src/connection.c
> @@ -605,7 +605,7 @@ wl_connection_demarshal(struct wl_connection *connection,
>   const struct wl_message *message)
>  {
>   uint32_t *p, *next, *end, length, id;
> - int fd;
> + int fd = -1;
>   char *s;
>   unsigned int i, count, num_arrays;
>   const char *signature;
> @@ -744,8 +744,10 @@ wl_connection_demarshal(struct wl_connection *connection,
>   p = next;
>   break;
>   case 'h':
> - wl_buffer_copy(&connection->fds_in, &fd, sizeof fd);
> - connection->fds_in.tail += sizeof fd;
> + if (connection->fds_in.tail != connection->fds_in.head) 
> {
> + wl_buffer_copy(&connection->fds_in, &fd, sizeof 
> fd);
> + connection->fds_in.tail += sizeof fd;
> + }
>   closure->args[i].h = fd;
>   break;
>   default:
> -- 
> 1.8.4.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Add [core] backend option

[Kristian Høgsberg]

On Fri, Nov 15, 2013 at 02:18:15PM +0100, Lubomir Rintel wrote:
> This allows specifying a particular backend to load in a manner similar to
> modules.
> 
> Signed-off-by: Lubomir Rintel 

Yes, that's a good addition, committed.

Kristian

> ---
>  man/weston.ini.man | 17 +
>  src/compositor.c   | 24 +++-
>  2 files changed, 32 insertions(+), 9 deletions(-)
> 
> diff --git a/man/weston.ini.man b/man/weston.ini.man
> index ecb7ebb..4ff313d 100644
> --- a/man/weston.ini.man
> +++ b/man/weston.ini.man
> @@ -105,6 +105,23 @@ directory are:
>  .fi
>  .RE
>  .TP 7
> +.TP 7
> +.BI "backend=" headless-backend.so
> +overrides defaults backend. Available backend modules in the
> +.IR "__weston_modules_dir__"
> +directory are:
> +.PP
> +.RS 10
> +.nf
> +.BR drm-backend.so
> +.BR fbdev-backend.so
> +.BR headless-backend.so
> +.BR rdp-backend.so
> +.BR rpi-backend.so
> +.BR wayland-backend.so
> +.BR x11-backend.so
> +.fi
> +.RE
>  .BI "gbm-format="format
>  sets the GBM format used for the framebuffer for the GBM backend. Can be
>  .B xrgb,
> diff --git a/src/compositor.c b/src/compositor.c
> index c6cf682..52fd67e 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -3757,6 +3757,7 @@ int main(int argc, char *argv[])
>struct weston_config *config);
>   int i;
>   char *backend = NULL;
> + char *option_backend = NULL;
>   char *shell = NULL;
>   char *modules, *option_modules = NULL;
>   char *log = NULL;
> @@ -3768,7 +3769,7 @@ int main(int argc, char *argv[])
>   struct weston_config_section *section;
>  
>   const struct weston_option core_options[] = {
> - { WESTON_OPTION_STRING, "backend", 'B', &backend },
> + { WESTON_OPTION_STRING, "backend", 'B', &option_backend },
>   { WESTON_OPTION_STRING, "shell", 0, &shell },
>   { WESTON_OPTION_STRING, "socket", 'S', &socket_name },
>   { WESTON_OPTION_INTEGER, "idle-time", 'i', &idle_time },
> @@ -3814,6 +3815,19 @@ int main(int argc, char *argv[])
>   signals[3] = wl_event_loop_add_signal(loop, SIGCHLD, sigchld_handler,
> NULL);
>  
> + config = weston_config_parse("weston.ini");
> + if (config != NULL) {
> + weston_log("Using config file '%s'\n",
> +weston_config_get_full_path(config));
> + } else {
> + weston_log("Starting with no config file.\n");
> + }
> + section = weston_config_get_section(config, "core", NULL, NULL);
> +
> + weston_config_section_get_string(section, "backend", &backend, NULL);
> + if (option_backend) {
> + backend = option_backend;
> + }
>   if (!backend) {
>   if (getenv("WAYLAND_DISPLAY"))
>   backend = "wayland-backend.so";
> @@ -3823,14 +3837,6 @@ int main(int argc, char *argv[])
>   backend = WESTON_NATIVE_BACKEND;
>   }
>  
> - config = weston_config_parse("weston.ini");
> - if (config != NULL) {
> - weston_log("Using config file '%s'\n",
> -weston_config_get_full_path(config));
> - } else {
> - weston_log("Starting with no config file.\n");
> - }
> - section = weston_config_get_section(config, "core", NULL, NULL);
>   weston_config_section_get_string(section, "modules", &modules, "");
>  
>   backend_init = weston_load_module(backend, "backend_init");
> -- 
> 1.8.4.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 5/5] shell: override the default pointer grab interface

[Giulio Camuffo]

I agree. I wondered indeed if it made more sense to remove the default
implementations in input.c and mandate all the shells to have a
default grab.
I'm not sure how a flag would work given it not only does need to not
pick a surface, but also pick another one. A "don't pick and pick its
private_configure instead" flag would look really ugly imho, besides
moving a shell implementation detail into the compositor.

Giulio

2013/11/15 Kristian Høgsberg :
> On Thu, Nov 14, 2013 at 11:42:54PM +0100, Giulio Camuffo wrote:
>> when a fullscreen surface hides the cursor, such as mpv, we must
>> make sure that the cursor gets hidden also when it is over the
>> underlying black surface. so check if the surface under the pointer
>> is a black surface and focus on its parent surface instead.
>> this results in sending pointer coordinates that are outside of
>> the surface geometry.
>
> I can't help thinking that this is an awful lot of code to duplicate
> just to avoid picking the black surface.  Maybe we could just have a
> weston-internal (ie, not protocol exposed) surface flag to indicate
> "don't pick me" or such...
>
> Patches 1-4 look good all applied, but I'm not sure about this one.
>
> Kristian
>
>>  src/shell.c | 91 
>> +
>>  1 file changed, 91 insertions(+)
>>
>> diff --git a/src/shell.c b/src/shell.c
>> index fe332e1..fd6f57d 100644
>> --- a/src/shell.c
>> +++ b/src/shell.c
>> @@ -4892,6 +4892,96 @@ shell_add_bindings(struct weston_compositor *ec, 
>> struct desktop_shell *shell)
>> debug_binding, shell);
>>  }
>>
>> +static void
>> +default_grab_focus(struct weston_pointer_grab *grab)
>> +{
>> + struct weston_pointer *pointer = grab->pointer;
>> + struct weston_view *view;
>> + wl_fixed_t sx, sy;
>> +
>> + if (pointer->button_count > 0)
>> + return;
>> +
>> + view = weston_compositor_pick_view(pointer->seat->compositor,
>> +pointer->x, pointer->y,
>> +&sx, &sy);
>> +
>> + if (view && view->surface->configure == &black_surface_configure) {
>> + view = view->surface->configure_private;
>> + }
>> + if (pointer->focus != view)
>> + weston_pointer_set_focus(pointer, view, sx, sy);
>> +}
>> +
>> +static void
>> +default_grab_motion(struct weston_pointer_grab *grab, uint32_t time,
>> + wl_fixed_t x, wl_fixed_t y)
>> +{
>> + struct weston_pointer *pointer = grab->pointer;
>> + wl_fixed_t sx, sy;
>> + struct wl_list *resource_list;
>> + struct wl_resource *resource;
>> +
>> + weston_pointer_move(pointer, x, y);
>> +
>> + resource_list = &pointer->focus_resource_list;
>> + wl_resource_for_each(resource, resource_list) {
>> + weston_view_from_global_fixed(pointer->focus,
>> +   pointer->x, pointer->y,
>> +   &sx, &sy);
>> + wl_pointer_send_motion(resource, time, sx, sy);
>> + }
>> +}
>> +
>> +static void
>> +default_grab_button(struct weston_pointer_grab *grab,
>> + uint32_t time, uint32_t button, uint32_t state_w)
>> +{
>> + struct weston_pointer *pointer = grab->pointer;
>> + struct weston_compositor *compositor = pointer->seat->compositor;
>> + struct weston_view *view;
>> + struct wl_resource *resource;
>> + uint32_t serial;
>> + enum wl_pointer_button_state state = state_w;
>> + struct wl_display *display = compositor->wl_display;
>> + wl_fixed_t sx, sy;
>> + struct wl_list *resource_list;
>> +
>> + resource_list = &pointer->focus_resource_list;
>> + if (!wl_list_empty(resource_list)) {
>> + serial = wl_display_next_serial(display);
>> + wl_resource_for_each(resource, resource_list)
>> + wl_pointer_send_button(resource,
>> +serial,
>> +  time,
>> +  button,
>> +  state_w);
>> + }
>> +
>> + if (pointer->button_count == 0 &&
>> + state == WL_POINTER_BUTTON_STATE_RELEASED) {
>> + view = weston_compositor_pick_view(compositor,
>> +pointer->x, pointer->y,
>> +  &sx, &sy);
>> +
>> + weston_pointer_set_focus(pointer, view, sx, sy);
>> + }
>> +}
>> +
>> +static void
>> +default_grab_cancel(struct weston_pointer_grab *grab)
>> +{
>> +}
>> +
>> +
>> +static const struct weston_pointer_grab_interface
>> + default_pointer_grab_interface = {
>> + default_grab_focus,
>> + default_grab_motion,
>> + default_grab_button,
>> + default_grab_cancel
>> +};
>> +
>>  WL_EXPORT int
>>  module_init(struct weston_compositor *ec,
>>   int *argc, char *argv[]

Re: [PATCH weston 5/5] shell: override the default pointer grab interface

[Kristian Høgsberg]

On Thu, Nov 14, 2013 at 11:42:54PM +0100, Giulio Camuffo wrote:
> when a fullscreen surface hides the cursor, such as mpv, we must
> make sure that the cursor gets hidden also when it is over the
> underlying black surface. so check if the surface under the pointer
> is a black surface and focus on its parent surface instead.
> this results in sending pointer coordinates that are outside of
> the surface geometry.

I can't help thinking that this is an awful lot of code to duplicate
just to avoid picking the black surface.  Maybe we could just have a
weston-internal (ie, not protocol exposed) surface flag to indicate
"don't pick me" or such...

Patches 1-4 look good all applied, but I'm not sure about this one.

Kristian

>  src/shell.c | 91 
> +
>  1 file changed, 91 insertions(+)
> 
> diff --git a/src/shell.c b/src/shell.c
> index fe332e1..fd6f57d 100644
> --- a/src/shell.c
> +++ b/src/shell.c
> @@ -4892,6 +4892,96 @@ shell_add_bindings(struct weston_compositor *ec, 
> struct desktop_shell *shell)
> debug_binding, shell);
>  }
>  
> +static void
> +default_grab_focus(struct weston_pointer_grab *grab)
> +{
> + struct weston_pointer *pointer = grab->pointer;
> + struct weston_view *view;
> + wl_fixed_t sx, sy;
> +
> + if (pointer->button_count > 0)
> + return;
> +
> + view = weston_compositor_pick_view(pointer->seat->compositor,
> +pointer->x, pointer->y,
> +&sx, &sy);
> +
> + if (view && view->surface->configure == &black_surface_configure) {
> + view = view->surface->configure_private;
> + }
> + if (pointer->focus != view)
> + weston_pointer_set_focus(pointer, view, sx, sy);
> +}
> +
> +static void
> +default_grab_motion(struct weston_pointer_grab *grab, uint32_t time,
> + wl_fixed_t x, wl_fixed_t y)
> +{
> + struct weston_pointer *pointer = grab->pointer;
> + wl_fixed_t sx, sy;
> + struct wl_list *resource_list;
> + struct wl_resource *resource;
> +
> + weston_pointer_move(pointer, x, y);
> +
> + resource_list = &pointer->focus_resource_list;
> + wl_resource_for_each(resource, resource_list) {
> + weston_view_from_global_fixed(pointer->focus,
> +   pointer->x, pointer->y,
> +   &sx, &sy);
> + wl_pointer_send_motion(resource, time, sx, sy);
> + }
> +}
> +
> +static void
> +default_grab_button(struct weston_pointer_grab *grab,
> + uint32_t time, uint32_t button, uint32_t state_w)
> +{
> + struct weston_pointer *pointer = grab->pointer;
> + struct weston_compositor *compositor = pointer->seat->compositor;
> + struct weston_view *view;
> + struct wl_resource *resource;
> + uint32_t serial;
> + enum wl_pointer_button_state state = state_w;
> + struct wl_display *display = compositor->wl_display;
> + wl_fixed_t sx, sy;
> + struct wl_list *resource_list;
> +
> + resource_list = &pointer->focus_resource_list;
> + if (!wl_list_empty(resource_list)) {
> + serial = wl_display_next_serial(display);
> + wl_resource_for_each(resource, resource_list)
> + wl_pointer_send_button(resource,
> +serial,
> +  time,
> +  button,
> +  state_w);
> + }
> +
> + if (pointer->button_count == 0 &&
> + state == WL_POINTER_BUTTON_STATE_RELEASED) {
> + view = weston_compositor_pick_view(compositor,
> +pointer->x, pointer->y,
> +  &sx, &sy);
> +
> + weston_pointer_set_focus(pointer, view, sx, sy);
> + }
> +}
> +
> +static void
> +default_grab_cancel(struct weston_pointer_grab *grab)
> +{
> +}
> +
> +
> +static const struct weston_pointer_grab_interface
> + default_pointer_grab_interface = {
> + default_grab_focus,
> + default_grab_motion,
> + default_grab_button,
> + default_grab_cancel
> +};
> +
>  WL_EXPORT int
>  module_init(struct weston_compositor *ec,
>   int *argc, char *argv[])
> @@ -4932,6 +5022,7 @@ module_init(struct weston_compositor *ec,
>   ec->shell_interface.resize = surface_resize;
>   ec->shell_interface.set_title = set_title;
>  
> + weston_compositor_set_default_pointer_grab(ec, 
> &default_pointer_grab_interface);
>   wl_list_init(&shell->input_panel.surfaces);
>  
>   weston_layer_init(&shell->fullscreen_layer, &ec->cursor_layer.link);
> -- 
> 1.8.4.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinf

Re: [PATCH weston 2/5] zoom: use the new pointer motion signal to move the zoom frame.

[Kristian Høgsberg]

On Thu, Nov 14, 2013 at 11:42:51PM +0100, Giulio Camuffo wrote:
> ---
>  src/compositor.h |  3 +++
>  src/input.c  |  8 
>  src/shell.c  |  3 +--
>  src/zoom.c   | 27 +++
>  4 files changed, 31 insertions(+), 10 deletions(-)

That is nice, I like it a lot.

Kristian

> diff --git a/src/compositor.h b/src/compositor.h
> index 624d475..95928a4 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -155,6 +155,7 @@ struct weston_output_zoom {
>   struct weston_fixed_point from;
>   struct weston_fixed_point to;
>   struct weston_fixed_point current;
> + struct wl_listener motion_listener;
>  };
>  
>  /* bit compatible with drm definitions. */
> @@ -1148,6 +1149,8 @@ weston_output_init_zoom(struct weston_output *output);
>  void
>  weston_output_update_zoom(struct weston_output *output);
>  void
> +weston_output_activate_zoom(struct weston_output *output);
> +void
>  weston_output_update_matrix(struct weston_output *output);
>  void
>  weston_output_move(struct weston_output *output, int x, int y);
> diff --git a/src/input.c b/src/input.c
> index e6b070d..f1cf938 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -712,9 +712,7 @@ weston_pointer_clamp(struct weston_pointer *pointer, 
> wl_fixed_t *fx, wl_fixed_t
>  static void
>  move_pointer(struct weston_seat *seat, wl_fixed_t x, wl_fixed_t y)
>  {
> - struct weston_compositor *ec = seat->compositor;
>   struct weston_pointer *pointer = seat->pointer;
> - struct weston_output *output;
>   int32_t ix, iy;
>  
>   weston_pointer_clamp (pointer, &x, &y);
> @@ -725,12 +723,6 @@ move_pointer(struct weston_seat *seat, wl_fixed_t x, 
> wl_fixed_t y)
>   ix = wl_fixed_to_int(x);
>   iy = wl_fixed_to_int(y);
>  
> - wl_list_for_each(output, &ec->output_list, link)
> - if (output->zoom.active &&
> - pixman_region32_contains_point(&output->region,
> -ix, iy, NULL))
> - weston_output_update_zoom(output);
> -
>   if (pointer->sprite) {
>   weston_view_set_position(pointer->sprite,
>ix - pointer->hotspot_x,
> diff --git a/src/shell.c b/src/shell.c
> index 9a9127b..cbb741a 100644
> --- a/src/shell.c
> +++ b/src/shell.c
> @@ -3052,8 +3052,7 @@ do_zoom(struct weston_seat *seat, uint32_t time, 
> uint32_t key, uint32_t axis,
>   else if (output->zoom.level > output->zoom.max_level)
>   output->zoom.level = output->zoom.max_level;
>   else if (!output->zoom.active) {
> - output->zoom.active = 1;
> - output->disable_planes++;
> + weston_output_activate_zoom(output);
>   }
>  
>   output->zoom.spring_z.target = output->zoom.level;
> diff --git a/src/zoom.c b/src/zoom.c
> index 962ed6d..622c0d7 100644
> --- a/src/zoom.c
> +++ b/src/zoom.c
> @@ -45,6 +45,7 @@ weston_zoom_frame_z(struct weston_animation *animation,
>   if (output->zoom.active && output->zoom.level <= 0.0) {
>   output->zoom.active = 0;
>   output->disable_planes--;
> + wl_list_remove(&output->zoom.motion_listener.link);
>   }
>   output->zoom.spring_z.current = output->zoom.level;
>   wl_list_remove(&animation->link);
> @@ -236,6 +237,31 @@ weston_output_update_zoom(struct weston_output *output)
>   weston_output_update_zoom_transform(output);
>  }
>  
> +static void
> +motion(struct wl_listener *listener, void *data)
> +{
> + struct weston_output_zoom *zoom =
> + container_of(listener, struct weston_output_zoom, 
> motion_listener);
> + struct weston_output *output =
> + container_of(zoom, struct weston_output, zoom);
> +
> + weston_output_update_zoom(output);
> +}
> +
> +WL_EXPORT void
> +weston_output_activate_zoom(struct weston_output *output)
> +{
> + struct weston_seat *seat = weston_zoom_pick_seat(output->compositor);
> +
> + if (output->zoom.active)
> + return;
> +
> + output->zoom.active = 1;
> + output->disable_planes++;
> + wl_signal_add(&seat->pointer->motion_signal,
> +   &output->zoom.motion_listener);
> +}
> +
>  WL_EXPORT void
>  weston_output_init_zoom(struct weston_output *output)
>  {
> @@ -253,4 +279,5 @@ weston_output_init_zoom(struct weston_output *output)
>   output->zoom.spring_xy.friction = 1000;
>   output->zoom.animation_xy.frame = weston_zoom_frame_xy;
>   wl_list_init(&output->zoom.animation_xy.link);
> + output->zoom.motion_listener.notify = motion;
>  }
> -- 
> 1.8.4.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland

Re: [PATCH] Add documentation for wl_shm_buffer_begin/end_access

[Kristian Høgsberg]

On Thu, Nov 14, 2013 at 12:28:51PM +, Neil Roberts wrote:
> It's not obvious that these functions are needed so it would be good
> to have some documentation for them.
> ---
>  doc/doxygen/Makefile.am |  3 ++-
>  src/wayland-shm.c   | 64 
> +
>  2 files changed, 66 insertions(+), 1 deletion(-)

Very nice, applied.

Kristian

> diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am
> index 0351c1e..078506d 100644
> --- a/doc/doxygen/Makefile.am
> +++ b/doc/doxygen/Makefile.am
> @@ -14,7 +14,8 @@ scanned_src_files_client =  \
>  scanned_src_files_server =   \
>   $(scanned_src_files_shared) \
>   $(top_srcdir)/src/wayland-server.c  \
> - $(top_srcdir)/src/wayland-server.h
> + $(top_srcdir)/src/wayland-server.h  \
> + $(top_srcdir)/src/wayland-shm.c
>  
>  # find all man/man3/wl_foo.3 pages
>  # for this to work, we need to create them before the man target (hence
> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
> index 28f52f4..814a4cf 100644
> --- a/src/wayland-shm.c
> +++ b/src/wayland-shm.c
> @@ -358,6 +358,23 @@ wl_shm_buffer_get_stride(struct wl_shm_buffer *buffer)
>   return buffer->stride;
>  }
>  
> +
> +/** Get a pointer to the memory for the SHM buffer
> + *
> + * \param buffer The buffer object
> + *
> + * Returns a pointer which can be used to read the data contained in
> + * the given SHM buffer.
> + *
> + * As this buffer is memory-mapped, reading it from may generate
> + * SIGBUS signals. This can happen if the client claims that the
> + * buffer is larger than it is or if something truncates the
> + * underlying file. To prevent this signal from causing the compositor
> + * to crash you should call wl_shm_buffer_begin_access and
> + * wl_shm_buffer_end_access around code that reads from the memory.
> + *
> + * \memberof wl_shm_buffer
> + */
>  WL_EXPORT void *
>  wl_shm_buffer_get_data(struct wl_shm_buffer *buffer)
>  {
> @@ -454,6 +471,42 @@ init_sigbus_data_key(void)
>   pthread_key_create(&wl_shm_sigbus_data_key, destroy_sigbus_data);
>  }
>  
> +/** Mark that the given SHM buffer is about to be accessed
> + *
> + * \param buffer The SHM buffer
> + *
> + * An SHM buffer is a memory-mapped file given by the client.
> + * According to POSIX, reading from a memory-mapped region that
> + * extends off the end of the file will cause a SIGBUS signal to be
> + * generated. Normally this would cause the compositor to terminate.
> + * In order to make the compositor robust against clients that change
> + * the size of the underlying file or lie about its size, you should
> + * protect access to the buffer by calling this function before
> + * reading from the memory and call wl_shm_buffer_end_access
> + * afterwards. This will install a signal handler for SIGBUS which
> + * will prevent the compositor from crashing.
> + *
> + * After calling this function the signal handler will remain
> + * installed for the lifetime of the compositor process. Note that
> + * this function will not work properly if the compositor is also
> + * installing its own handler for SIGBUS.
> + *
> + * If a SIGBUS signal is received for an address within the range of
> + * the SHM pool of the given buffer then the client will be sent an
> + * error event when wl_shm_buffer_end_access is called. If the signal
> + * is for an address outside that range then the signal handler will
> + * reraise the signal which would will likely cause the compositor to
> + * terminate.
> + *
> + * It is safe to nest calls to these functions as long as the nested
> + * calls are all accessing the same buffer. The number of calls to
> + * wl_shm_buffer_end_access must match the number of calls to
> + * wl_shm_buffer_begin_access. These functions are thread-safe and it
> + * is allowed to simultaneously access different buffers or the same
> + * buffer from multiple threads.
> + *
> + * \memberof wl_shm_buffer
> + */
>  WL_EXPORT void
>  wl_shm_buffer_begin_access(struct wl_shm_buffer *buffer)
>  {
> @@ -480,6 +533,17 @@ wl_shm_buffer_begin_access(struct wl_shm_buffer *buffer)
>   sigbus_data->access_count++;
>  }
>  
> +/** Ends the access to a buffer started by wl_shm_buffer_begin_access
> + *
> + * \param buffer The SHM buffer
> + *
> + * This should be called after wl_shm_buffer_begin_access once the
> + * buffer is no longer being accessed. If a SIGBUS signal was
> + * generated in-between these two calls then the resource for the
> + * given buffer will be sent an error.
> + *
> + * \memberof wl_shm_buffer
> + */
>  WL_EXPORT void
>  wl_shm_buffer_end_access(struct wl_shm_buffer *buffer)
>  {
> -- 
> 1.8.3.1
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayla

[PATCH weston 2/2] compositor: set weston_surface:resource to NULL when destroyed

[Giulio Camuffo]

with the previous patch the resource isn't used inside weston_surface_destroy()
anymore (aside sending events unuseful for a closing client), so we can safely
reset it.

Reviewed-by: Jason Ekstrand 
---
 src/compositor.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/compositor.c b/src/compositor.c
index c6cf682..1cf63c8 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1339,6 +1339,10 @@ destroy_surface(struct wl_resource *resource)
 {
struct weston_surface *surface = wl_resource_get_user_data(resource);
 
+   /* Set the resource to NULL, since we don't want to leave a
+* dangling pointer if the surface was refcounted and survives
+* the weston_surface_destroy() call. */
+   surface->resource = NULL;
weston_surface_destroy(surface);
 }
 
-- 
1.8.4.2

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

[PATCH weston 1/2] input: set the focus to NULL when the focus's resource is destroyed

[Giulio Camuffo]

with the surface ref-count feature a surface may live on after its
resource was destroyed. so listen for the resource destroy signal
and set the focus to NULL.

Reviewed-by: Jason Ekstrand 
---
 src/compositor.h |  3 +++
 src/input.c  | 50 +-
 2 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/src/compositor.h b/src/compositor.h
index c2de99f..610edd4 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -305,6 +305,7 @@ struct weston_pointer {
struct wl_list resource_list;
struct wl_list focus_resource_list;
struct weston_view *focus;
+   struct wl_listener focus_listener;
uint32_t focus_serial;
struct wl_signal focus_signal;
 
@@ -330,6 +331,7 @@ struct weston_touch {
struct wl_list resource_list;
struct wl_list focus_resource_list;
struct weston_view *focus;
+   struct wl_listener focus_listener;
uint32_t focus_serial;
struct wl_signal focus_signal;
 
@@ -425,6 +427,7 @@ struct weston_keyboard {
struct wl_list resource_list;
struct wl_list focus_resource_list;
struct weston_surface *focus;
+   struct wl_listener focus_listener;
uint32_t focus_serial;
struct wl_signal focus_signal;
 
diff --git a/src/input.c b/src/input.c
index 153bcb6..a678350 100644
--- a/src/input.c
+++ b/src/input.c
@@ -71,6 +71,33 @@ weston_compositor_idle_release(struct weston_compositor 
*compositor)
 }
 
 static void
+lose_pointer_focus(struct wl_listener *listener, void *data)
+{
+   struct weston_pointer *pointer =
+   container_of(listener, struct weston_pointer, focus_listener);
+
+   weston_pointer_set_focus(pointer, NULL, 0, 0);
+}
+
+static void
+lose_keyboard_focus(struct wl_listener *listener, void *data)
+{
+   struct weston_keyboard *keyboard =
+   container_of(listener, struct weston_keyboard, focus_listener);
+
+   weston_keyboard_set_focus(keyboard, NULL);
+}
+
+static void
+lose_touch_focus(struct wl_listener *listener, void *data)
+{
+   struct weston_touch *touch =
+   container_of(listener, struct weston_touch, focus_listener);
+
+   weston_touch_set_focus(touch->seat, NULL);
+}
+
+static void
 move_resources(struct wl_list *destination, struct wl_list *source)
 {
wl_list_insert_list(destination, source);
@@ -388,6 +415,8 @@ weston_pointer_create(void)
 
wl_list_init(&pointer->resource_list);
wl_list_init(&pointer->focus_resource_list);
+   wl_list_init(&pointer->focus_listener.link);
+   pointer->focus_listener.notify = lose_pointer_focus;
pointer->default_grab.interface = &default_pointer_grab_interface;
pointer->default_grab.pointer = pointer;
pointer->grab = &pointer->default_grab;
@@ -409,7 +438,7 @@ weston_pointer_destroy(struct weston_pointer *pointer)
pointer_unmap_sprite(pointer);
 
/* XXX: What about pointer->resource_list? */
-
+   wl_list_remove(&pointer->focus_listener.link);
free(pointer);
 }
 
@@ -424,6 +453,8 @@ weston_keyboard_create(void)
 
wl_list_init(&keyboard->resource_list);
wl_list_init(&keyboard->focus_resource_list);
+   wl_list_init(&keyboard->focus_listener.link);
+   keyboard->focus_listener.notify = lose_keyboard_focus;
wl_array_init(&keyboard->keys);
keyboard->default_grab.interface = &default_keyboard_grab_interface;
keyboard->default_grab.keyboard = keyboard;
@@ -439,6 +470,7 @@ weston_keyboard_destroy(struct weston_keyboard *keyboard)
/* XXX: What about keyboard->resource_list? */
 
wl_array_release(&keyboard->keys);
+   wl_list_remove(&keyboard->focus_listener.link);
free(keyboard);
 }
 
@@ -453,6 +485,8 @@ weston_touch_create(void)
 
wl_list_init(&touch->resource_list);
wl_list_init(&touch->focus_resource_list);
+   wl_list_init(&touch->focus_listener.link);
+   touch->focus_listener.notify = lose_touch_focus;
touch->default_grab.interface = &default_touch_grab_interface;
touch->default_grab.touch = touch;
touch->grab = &touch->default_grab;
@@ -466,6 +500,7 @@ weston_touch_destroy(struct weston_touch *touch)
 {
/* XXX: What about touch->resource_list? */
 
+   wl_list_remove(&touch->focus_listener.link);
free(touch);
 }
 
@@ -513,6 +548,8 @@ weston_pointer_set_focus(struct weston_pointer *pointer,
  
pointer->focus->surface->resource);
}
 
+   wl_list_remove(&pointer->focus_listener.link);
+   wl_list_init(&pointer->focus_listener.link);
move_resources(&pointer->resource_list, focus_resource_list);
}
 
@@ -541,6 +578,8 @@ weston_pointer_set_focus(struct weston_pointer *pointer,
}
 
pointer->focus_serial = serial;
+   wl_resource_add_destroy_l

Re: Thoughts about decoration information in the xdg_shell

[Bill Spitzak]

One thing everybody seems to be ignoring is that current wl_shell 
already has a "don't draw CSD" flag. It is the "fullscreen" indicator.


As I see it:

- Clients must be able to draw CSD.

- The compositor can tell the client whether to draw CSD and can change 
this over time. It can also tell it to draw "parts" of the CSD, in 
particular it can tell it to remove any of the 4 resize+shadow edges 
without removing the "titlebar". This information is added to the 
configure request. Client must obey this, and if it is drawing widgets 
it needs in the CSD it must move them or insure that the lost 
functionality is not critical.


- There *may* need to be an api for the client to tell the compositor 
how "thick" the CSD is. This is so the compositor can smoothly do 
snap-to-edge.


- There is no need for a client to indicate whether it "prefers" CSD.

By far the main reason for a client to not draw CSD is not because the 
compositor is doing SSD, but because it does not want any decorations! 
Actual SSD is only for remote display on a system that cannot work 
unless it adds it's own frame around the window (ie old X or Windows).

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

Re: [RFC] Common input device library

[Bill Spitzak]

Jasper St. Pierre wrote:
It's because the keyboard is a surprisingly complicated tool with 
multiple modes of operating, probably without you ever realizing it, and 
clients need all of that power:


  If I'm typing text, the *labels* of the keys matter, and input methods 
allow us to translate sequences of key presses and releases into a 
Unicode character on the screen.


  We also have "chords", where holding down a certain key could affect 
operation. For instance holding the "Shift" key causes the letters typed 
to be capitalized. However, some users can't accurately hold down a 
shift key, though, so we have accessibility support like latched keys 
(press Shift, press "S"), and sticky keys (press Shift, press "S", then 
press Shift again to turn it off).


  If I'm playing a game, the *locations* of the keys matter. Games use a 
WASD scheme not because the letters "W", "A", "S", and "D" mean 
anything, but because their location on a QWERTY keyboard make a 
left-handed arrow key shape. On alternate keyboard layouts, we still 
need them to make that arrow shape, and not give users a layout where 
going forward means you have to reach half-way across the keyboard.


  We also have "key shortcuts", which combine both worlds: Ctrl+Z, 
Ctrl+X, Ctrl+C, and Ctrl+V are all location-based, but Ctrl+F is word-based.


The typical approach, as done by Windows, OS X, and XKB (and now 
Wayland) is to send the client an opaque integer that corresponds to "a 
key", along with a map of how the keys are laid out, and then have the 
client look up whatever information it needs.


This is not exactly true.

Windows + OS/X send a symbol that is much more like an X "keysym". There 
are no scan codes. The driver has removed the layout information. If a 
client wants key positions they must back-translate the keysym by using 
a different api to determine the hardware and what location on it 
produced each keysym.


And sticky keys and so on are done by the driver. The client can see the 
shift keys being pressed, and perhaps deduce from this the sticky key 
setting, but they don't have to, as the shift flags are set correctly on 
the key event.


All text should go through the input method. This would consume 
keystrokes and may use it's own surfaces (as Chinese input does), and 
occasionally spit out piece of UTF-8 that the client inserts into the 
typed text. The client never looks at key events for this. It looks like 
about 90% of the complexity of XKB is to produce symbols for European 
languages, including dead key compositing. This should all be scrapped 
so that clients are forced to use the input methods.


And you seem to be doing some bikeshedding, such as saying that Ctrl+Z 
is "location based". Yes, that is why the Ctrl+Z combination was chosen. 
However NOBODY types the lower-left key. They type the key with the 'Z' 
on it, or they use an api to change what letter the shortcut is and type 
that letter.

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

Re: [PATCH xwayland 2/3] Check for frame being NULL before setting/unsetting flags

[Dima Ryazanov]

You're right, your fix does look better!


On Fri, Nov 15, 2013 at 5:07 AM, Axel Davy  wrote:

>  I've posted a patch, which prevents wm->focus_window to be a window
> without frame.
>
> This solves the same bug than this patch, but looks better to me.
>
>
> http://lists.freedesktop.org/archives/wayland-devel/2013-November/012008.html
>
> Axel Davy
>
> Le 15/11/2013 11:25, Axel Davy a écrit :
>
> This patch (Again, I had the same), solves the last bugs for XWayland,
> but for this one, I'm not sure it is the correct fix.
>
> In fact it would mean than focus_window would be an unmapped windows,
> which looks strange to me.
>
> Axel Davy
>
> Le 15/11/2013 11:01, Dima Ryazanov a écrit :
>
> Fixes a crash in Firefox when clicking an "install plugin" popup.
>
> Signed-off-by: Dima Ryazanov  
> ---
>   src/xwayland/window-manager.c | 6 --
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
> index 5ee9480..6d29026 100644
> --- a/src/xwayland/window-manager.c
> +++ b/src/xwayland/window-manager.c
> @@ -695,12 +695,14 @@ weston_wm_window_activate(struct wl_listener
> *listener, void *data)
>   }
> if (wm->focus_window) {
> -frame_unset_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
> +if (wm->focus_window->frame)
> +frame_unset_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
>   weston_wm_window_schedule_repaint(wm->focus_window);
>   }
>   wm->focus_window = window;
>   if (wm->focus_window) {
> -frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
> +if (wm->focus_window->frame)
> +frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
>   weston_wm_window_schedule_repaint(wm->focus_window);
>   }
>   }
>
>
> ___
> 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 7/9] exposay: add cancel impl to the kbd grab iface

[Emilio Pozuelo Monfort]

Otherwise we'll crash when cancel is called.

Signed-off-by: Emilio Pozuelo Monfort 
---
 src/shell.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/shell.c b/src/shell.c
index 2ffd37f..accf4de 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -5337,9 +5337,19 @@ exposay_modifier(struct weston_keyboard_grab *grab, 
uint32_t serial,
 {
 }
 
+static void
+exposay_cancel(struct weston_keyboard_grab *grab)
+{
+   struct desktop_shell *shell =
+   container_of(grab, struct desktop_shell, exposay.grab_kbd);
+
+   exposay_set_state(shell, EXPOSAY_TARGET_CANCEL, shell->exposay.seat);
+}
+
 static const struct weston_keyboard_grab_interface exposay_kbd_grab = {
exposay_key,
exposay_modifier,
+   exposay_cancel,
 };
 
 /**
-- 
1.8.4.rc3

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

[PATCH 5/9] input: Don't send leave events to destroyed views

[Emilio Pozuelo Monfort]

If a view which has focus is destroyed, we would send a leave
event while changing focus, causing a segfault. Prevent this
by listening to the view's destroy signal and removing it from
the pointer focus.

Signed-off-by: Emilio Pozuelo Monfort 
---
 src/compositor.h |  1 +
 src/input.c  | 25 +
 2 files changed, 26 insertions(+)

diff --git a/src/compositor.h b/src/compositor.h
index 6087468..0c24b00 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -306,6 +306,7 @@ struct weston_pointer {
struct wl_list focus_resource_list;
struct weston_view *focus;
uint32_t focus_serial;
+   struct wl_listener focus_listener;
struct wl_signal focus_signal;
 
struct weston_view *sprite;
diff --git a/src/input.c b/src/input.c
index ed3e06f..b1486ed 100644
--- a/src/input.c
+++ b/src/input.c
@@ -392,6 +392,7 @@ weston_pointer_create(void)
pointer->default_grab.pointer = pointer;
pointer->grab = &pointer->default_grab;
wl_signal_init(&pointer->focus_signal);
+   wl_list_init(&pointer->focus_listener.link);
 
pointer->sprite_destroy_listener.notify = pointer_handle_sprite_destroy;
 
@@ -487,6 +488,23 @@ seat_send_updated_caps(struct weston_seat *seat)
}
 }
 
+static void
+destroy_pointer_focus(struct wl_listener *listener, void *data)
+{
+   struct weston_pointer *pointer;
+
+   pointer = container_of(listener, struct weston_pointer,
+  focus_listener);
+
+   pointer->focus = NULL;
+   move_resources(&pointer->resource_list, &pointer->focus_resource_list);
+
+   wl_list_remove(&pointer->focus_listener.link);
+   wl_list_init(&pointer->focus_listener.link);
+
+   wl_signal_emit(&pointer->focus_signal, pointer);
+}
+
 WL_EXPORT void
 weston_pointer_set_focus(struct weston_pointer *pointer,
 struct weston_view *view,
@@ -543,7 +561,14 @@ weston_pointer_set_focus(struct weston_pointer *pointer,
pointer->focus_serial = serial;
}
 
+   if (!wl_list_empty(&pointer->focus_listener.link)) {
+   wl_list_remove(&pointer->focus_listener.link);
+   wl_list_init(&pointer->focus_listener.link);
+   }
pointer->focus = view;
+   pointer->focus_listener.notify = destroy_pointer_focus;
+   if (view)
+   wl_signal_add(&view->destroy_signal, &pointer->focus_listener);
wl_signal_emit(&pointer->focus_signal, pointer);
 }
 
-- 
1.8.4.rc3

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

Re: [RFC] Common input device library

[Artsiom Anikeyenka]

Hmm, that's quite interesting, I've never thought of keyboard this way,
really. And I think this is because all of that is redundant actually.
Client should provide you with the ability to configure which button and
for what reason you want to press. For example when you install ubuntu it
asks you - press some letters so I can create a "view" into your keyboard.
Later on, each programm can create it's own "view" on top of DE's "view".
So this is still from bottom to top, one way flow :P And what you mean is
probably how people thought back in 80s, grandpa :D No offense really I'm
just kidding, I can still be wrong and it's late friday I just want to have
some smiles.

Have a good weekend guys!


On Fri, Nov 15, 2013 at 7:26 PM, Jasper St. Pierre wrote:

> It's because the keyboard is a surprisingly complicated tool with multiple
> modes of operating, probably without you ever realizing it, and clients
> need all of that power:
>
>   If I'm typing text, the *labels* of the keys matter, and input methods
> allow us to translate sequences of key presses and releases into a Unicode
> character on the screen.
>
>   We also have "chords", where holding down a certain key could affect
> operation. For instance holding the "Shift" key causes the letters typed to
> be capitalized. However, some users can't accurately hold down a shift key,
> though, so we have accessibility support like latched keys (press Shift,
> press "S"), and sticky keys (press Shift, press "S", then press Shift again
> to turn it off).
>
>   If I'm playing a game, the *locations* of the keys matter. Games use a
> WASD scheme not because the letters "W", "A", "S", and "D" mean anything,
> but because their location on a QWERTY keyboard make a left-handed arrow
> key shape. On alternate keyboard layouts, we still need them to make that
> arrow shape, and not give users a layout where going forward means you have
> to reach half-way across the keyboard.
>
>   We also have "key shortcuts", which combine both worlds: Ctrl+Z, Ctrl+X,
> Ctrl+C, and Ctrl+V are all location-based, but Ctrl+F is word-based.
>
> The typical approach, as done by Windows, OS X, and XKB (and now Wayland)
> is to send the client an opaque integer that corresponds to "a key", along
> with a map of how the keys are laid out, and then have the client look up
> whatever information it needs.
>
>
> On Fri, Nov 15, 2013 at 11:15 AM, Artsiom Anikeyenka <
> arty.ani...@gmail.com> wrote:
>
>> Thanks! That's strange... I mean... It sounds like there are extra levels
>> of responsibility. What I would expect is one way flow with 1 component
>> processing all the input. 1 person will hardly deal with more then 1 output
>> (though it may use several inputs at a time). That's y the concept of 1
>> active window will always remain (unless we get to heads one day). So y do
>> one want to have some input processed on the level of compositor and some
>> input on the level of a client. So I would assume sort of input linear flow
>>  (meaning it won't split at some point). And if it's not split on some
>> level so why do one want to move responsibility over the levels. Does it
>> make sense?
>>
>> Thanks.
>>
>>
>> On Fri, Nov 15, 2013 at 6:07 PM, Jasper St. Pierre > > wrote:
>>
>>> If by libxcbcommon you mean libxkbcommon, no.
>>>
>>> libxkbcommon is about the complex ways of interpreting key events, with
>>> client-side key maps, modifiers, accessibility features (latched keys,
>>> sticky keys, etc.). It's meant to be used from both the compositor and the
>>> client.
>>>
>>> libinput is about replacing all of the xorg-x11-drv infrastructure on
>>> the server, like the special -synaptics driver. It's meant to be used from
>>> compositors only.
>>>
>>> It's very likely that libinput will use libxkbcommon.
>>>
>>>
>>> On Fri, Nov 15, 2013 at 10:01 AM, Artsiom Anikeyenka <
>>> arty.ani...@gmail.com> wrote:
>>>
 Is libinput supposed to be sort of replacement for libxcbcommon?

 Thanks.


 On Thu, Nov 14, 2013 at 4:58 PM, Artsiom Anikeyenka <
 arty.ani...@gmail.com> wrote:

> I like the generalized architecture of any input handling as well. I
> didn't look into the code because I will hardly understand it yet. I also
> don't understand a lot yet but what I'd do is also some sort of dispatcher
> of the input object queue. I.e. when each device is watched by the wrapper
> which wraps any event from the device into input_object with interface
> which can be understood by libinput easily. Thus we create sort of 
> protocol
> which allows easy adding of new devices. After interpreting the event
> libinput passes it further. Such architecture is very simple and
> straightforward, easy to maintain and document.
>
> Disregard this email if it doesn't make any sense ha-ha-ha :D
>
> The best way to learn is to start making mistakes.
>
> Cheers!!!
>
>
> On Thu, Nov 14, 2013 at 9:30 AM, Peter Hutterer <

[PATCH 9/9] shell: Set output on the focus_surfaces' view

[Emilio Pozuelo Monfort]

Otherwise we crash when animating the view.

Signed-off-by: Emilio Pozuelo Monfort 
---
 src/shell.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/shell.c b/src/shell.c
index 08d2627..fd158eb 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -615,6 +615,7 @@ create_focus_surface(struct weston_compositor *ec,
surface->configure_private = fsurf;
 
fsurf->view = weston_view_create (surface);
+   fsurf->view->output = output;
 
weston_view_configure(fsurf->view, output->x, output->y,
 output->width, output->height);
-- 
1.8.4.rc3

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

[PATCH 6/9] shell: Implement alt-tab switcher

[Emilio Pozuelo Monfort]

Signed-off-by: Emilio Pozuelo Monfort 
---
 src/shell.c | 248 
 1 file changed, 248 insertions(+)

diff --git a/src/shell.c b/src/shell.c
index d7e7240..2ffd37f 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -,6 +,251 @@ terminate_binding(struct weston_seat *seat, uint32_t 
time, uint32_t key,
 }
 
 static void
+lower_fullscreen_layer(struct desktop_shell *shell);
+
+struct alt_tab {
+   struct desktop_shell *shell;
+   struct weston_keyboard_grab grab;
+
+   struct wl_list *current;
+
+   struct wl_list preview_list;
+};
+
+struct alt_tab_preview {
+   struct alt_tab *alt_tab;
+
+   struct weston_view *view;
+   struct weston_transform transform;
+
+   struct wl_listener listener;
+
+   struct wl_list link;
+};
+
+static void
+alt_tab_next(struct alt_tab *alt_tab)
+{
+   alt_tab->current = alt_tab->current->next;
+
+   /* Make sure we're not pointing to the list header e.g. after
+* cycling through the whole list. */
+   if (alt_tab->current->next == alt_tab->preview_list.next)
+   alt_tab->current = alt_tab->current->next;
+}
+
+static void
+alt_tab_destroy(struct alt_tab *alt_tab)
+{
+   struct alt_tab_preview *preview, *next;
+   struct weston_keyboard *keyboard = alt_tab->grab.keyboard;
+
+   if (alt_tab->current && alt_tab->current != &alt_tab->preview_list) {
+   preview = wl_container_of(alt_tab->current, preview, link);
+
+   activate(alt_tab->shell, preview->view->surface,
+(struct weston_seat *) keyboard->seat);
+   }
+
+   wl_list_for_each_safe(preview, next, &alt_tab->preview_list, link) {
+   wl_list_remove(&preview->link);
+   wl_list_remove(&preview->listener.link);
+   weston_view_destroy(preview->view);
+   free(preview);
+   }
+
+   weston_keyboard_end_grab(keyboard);
+   if (keyboard->input_method_resource)
+   keyboard->grab = &keyboard->input_method_grab;
+
+   free(alt_tab);
+}
+
+static void
+alt_tab_handle_surface_destroy(struct wl_listener *listener, void *data)
+{
+   struct alt_tab_preview *preview =
+   container_of(listener, struct alt_tab_preview, listener);
+   struct alt_tab *alt_tab = preview->alt_tab;
+   int advance = 0;
+
+   /* If the preview that we're removing is the currently selected one,
+* we want to move to the next one. So we move to ->prev and then
+* call _next() after removing the preview. */
+   if (alt_tab->current == &preview->link) {
+   alt_tab->current = alt_tab->current->prev;
+   advance = 1;
+   }
+
+   wl_list_remove(&preview->listener.link);
+   wl_list_remove(&preview->link);
+
+   free(preview);
+
+   if (advance)
+   alt_tab_next(alt_tab);
+
+   /* If the last preview goes away, stop the alt-tab */
+   if (wl_list_empty(alt_tab->current))
+   alt_tab_destroy(alt_tab);
+}
+
+static void
+alt_tab_key(struct weston_keyboard_grab *grab,
+   uint32_t time, uint32_t key, uint32_t state_w)
+{
+   struct alt_tab *alt_tab = container_of(grab, struct alt_tab, grab);
+   enum wl_keyboard_key_state state = state_w;
+
+   if (key == KEY_TAB && state == WL_KEYBOARD_KEY_STATE_PRESSED)
+   alt_tab_next(alt_tab);
+}
+
+static void
+alt_tab_modifier(struct weston_keyboard_grab *grab, uint32_t serial,
+uint32_t mods_depressed, uint32_t mods_latched,
+uint32_t mods_locked, uint32_t group)
+{
+   struct alt_tab *alt_tab = container_of(grab, struct alt_tab, grab);
+   struct weston_seat *seat = (struct weston_seat *) grab->keyboard->seat;
+
+   if ((seat->modifier_state & MODIFIER_ALT) == 0)
+   alt_tab_destroy(alt_tab);
+}
+
+static void
+alt_tab_cancel(struct weston_keyboard_grab *grab)
+{
+   struct alt_tab *alt_tab = container_of(grab, struct alt_tab, grab);
+
+   alt_tab_destroy(alt_tab);
+}
+
+static const struct weston_keyboard_grab_interface alt_tab_grab = {
+   alt_tab_key,
+   alt_tab_modifier,
+   alt_tab_cancel,
+};
+
+static int
+view_for_alt_tab(struct weston_view *view)
+{
+   if (!get_shell_surface(view->surface))
+   return 0;
+
+   if (get_shell_surface_type(view->surface) == SHELL_SURFACE_TRANSIENT)
+   return 0;
+
+   if (view != get_default_view(view->surface))
+   return 0;
+
+   return 1;
+}
+
+static void
+alt_tab_binding(struct weston_seat *seat, uint32_t time, uint32_t key,
+   void *data)
+{
+   struct alt_tab *alt_tab;
+   struct desktop_shell *shell = data;
+   struct weston_output *output = get_default_output(shell->compositor);
+   struct workspace *ws;
+   struct weston_view *view;
+   int num_surfaces = 0;
+   int x, y, side, margin;
+
+ 

[PATCH 3/9] Add move/scale animation

[Emilio Pozuelo Monfort]

From: Daniel Stone 

Add an animation which moves a surface to a new location, at the same
time as also rescaling it to a different size from the origin, rather
than the existing scale animation which resizes from the centre.

[pochu: rebased, ported to weston_view]
---
 src/animation.c  | 62 
 src/compositor.h |  6 ++
 2 files changed, 68 insertions(+)

diff --git a/src/animation.c b/src/animation.c
index 8739f19..f717b33 100644
--- a/src/animation.c
+++ b/src/animation.c
@@ -377,3 +377,65 @@ weston_slide_run(struct weston_view *view, float start, 
float stop,
 
return animation;
 }
+
+struct weston_move_animation {
+   int dx;
+   int dy;
+   int reverse;
+   weston_view_animation_done_func_t done;
+};
+
+static void
+move_frame(struct weston_view_animation *animation)
+{
+   struct weston_move_animation *move = animation->private;
+   float scale;
+   float progress = animation->spring.current;
+
+   if (move->reverse)
+   progress = 1.0 - progress;
+
+   scale = animation->start +
+(animation->stop - animation->start) *
+progress;
+   weston_matrix_init(&animation->transform.matrix);
+   weston_matrix_scale(&animation->transform.matrix, scale, scale, 1.0f);
+   weston_matrix_translate(&animation->transform.matrix,
+move->dx * progress, move->dy * progress,
+   0);
+}
+
+static void
+move_done(struct weston_view_animation *animation, void *data)
+{
+   struct weston_move_animation *move = animation->private;
+
+   if (move->done)
+   move->done(animation, data);
+
+   free(move);
+}
+
+WL_EXPORT struct weston_view_animation *
+weston_move_scale_run(struct weston_view *view, int dx, int dy,
+ float start, float end, int reverse,
+ weston_view_animation_done_func_t done, void *data)
+{
+   struct weston_move_animation *move;
+   struct weston_view_animation *animation;
+
+   move = malloc(sizeof(*move));
+   if (!move)
+   return NULL;
+   move->dx = dx;
+   move->dy = dy;
+   move->reverse = reverse;
+   move->done = done;
+
+   animation = weston_view_animation_run(view, start, end, move_frame,
+ NULL, move_done, data, move);
+   animation->spring.k = 400;
+   animation->spring.friction = 1150;
+
+   return animation;
+}
diff --git a/src/compositor.h b/src/compositor.h
index b67b993..6087468 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -1281,6 +1281,12 @@ struct weston_view_animation *
 weston_fade_run(struct weston_view *view,
float start, float end, float k,
weston_view_animation_done_func_t done, void *data);
+
+struct weston_view_animation *
+weston_move_scale_run(struct weston_view *view, int dx, int dy,
+ float start, float end, int reverse,
+ weston_view_animation_done_func_t done, void *data);
+
 void
 weston_fade_update(struct weston_view_animation *fade, float target);
 
-- 
1.8.4.rc3

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

[PATCH 4/9] Add Exposay

[Emilio Pozuelo Monfort]

From: Daniel Stone 

Exposay provides window overview functions which, when a key which
produces the binding modifier is pressed on its own, scales all
currently-open windows down to be shown overlaid on the desktop,
providing keyboard and mouse navigation to be able to switch window
focus.

[pochu: rebased, ported to weston_view]
---
 src/shell.c | 575 
 1 file changed, 575 insertions(+)

diff --git a/src/shell.c b/src/shell.c
index 038feae..d7e7240 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1,6 +1,7 @@
 /*
  * Copyright © 2010-2012 Intel Corporation
  * Copyright © 2011-2012 Collabora, Ltd.
+ * Copyright © 2013 Raspberry Pi Foundation
  *
  * Permission to use, copy, modify, distribute, and sell this software and
  * its documentation for any purpose is hereby granted without fee, provided
@@ -56,6 +57,19 @@ enum fade_type {
FADE_OUT
 };
 
+enum exposay_target_state {
+   EXPOSAY_TARGET_OVERVIEW, /* show all windows */
+   EXPOSAY_TARGET_CANCEL, /* return to normal, same focus */
+   EXPOSAY_TARGET_SWITCH, /* return to normal, switch focus */
+};
+
+enum exposay_layout_state {
+   EXPOSAY_LAYOUT_INACTIVE = 0, /* normal desktop */
+   EXPOSAY_LAYOUT_ANIMATE_TO_INACTIVE, /* in transition to normal */
+   EXPOSAY_LAYOUT_OVERVIEW, /* show all windows */
+   EXPOSAY_LAYOUT_ANIMATE_TO_OVERVIEW, /* in transition to all windows */
+};
+
 struct focus_state {
struct weston_seat *seat;
struct workspace *ws;
@@ -180,6 +194,34 @@ struct desktop_shell {
struct wl_event_source *startup_timer;
} fade;
 
+   struct exposay {
+   /* XXX: Make these exposay_surfaces. */
+   struct weston_view *focus_prev;
+   struct weston_view *focus_current;
+   struct weston_view *clicked;
+   struct workspace *workspace;
+   struct weston_seat *seat;
+   struct wl_list surface_list;
+
+   struct weston_keyboard_grab grab_kbd;
+   struct weston_pointer_grab grab_ptr;
+
+enum exposay_target_state state_target;
+enum exposay_layout_state state_cur;
+   int in_flight; /* number of animations still running */
+
+   int num_surfaces;
+   int grid_size;
+   int surface_size;
+
+   int hpadding_outer;
+   int vpadding_outer;
+   int padding_inner;
+
+   int row_current;
+   int column_current;
+   } exposay;
+
uint32_t binding_modifier;
enum animation_type win_animation_type;
enum animation_type startup_animation_type;
@@ -4661,6 +4703,534 @@ switcher_binding(struct weston_seat *seat, uint32_t 
time, uint32_t key,
switcher_next(switcher);
 }
 
+struct exposay_surface {
+   struct desktop_shell *shell;
+   struct weston_surface *surface;
+   struct weston_view *view;
+   struct wl_list link;
+
+   int x;
+   int y;
+   int width;
+   int height;
+   double scale;
+
+   int row;
+   int column;
+
+   /* The animations only apply a transformation for their own lifetime,
+* and don't have an option to indefinitely maintain the
+* transformation in a steady state - so, we apply our own once the
+* animation has finished. */
+   struct weston_transform transform;
+};
+
+static void exposay_set_state(struct desktop_shell *shell,
+  enum exposay_target_state state,
+ struct weston_seat *seat);
+static void exposay_check_state(struct desktop_shell *shell);
+
+static void
+exposay_in_flight_inc(struct desktop_shell *shell)
+{
+   shell->exposay.in_flight++;
+}
+
+static void
+exposay_in_flight_dec(struct desktop_shell *shell)
+{
+   if (--shell->exposay.in_flight > 0)
+   return;
+
+   exposay_check_state(shell);
+}
+
+static void
+exposay_animate_in_done(struct weston_view_animation *animation, void *data)
+{
+   struct exposay_surface *esurface = data;
+
+   wl_list_insert(&esurface->view->geometry.transformation_list,
+  &esurface->transform.link);
+   weston_matrix_init(&esurface->transform.matrix);
+   weston_matrix_scale(&esurface->transform.matrix,
+   esurface->scale, esurface->scale, 1.0f);
+   weston_matrix_translate(&esurface->transform.matrix,
+   esurface->x - esurface->view->geometry.x,
+   esurface->y - esurface->view->geometry.y,
+   0);
+
+   weston_view_geometry_dirty(esurface->view);
+   weston_compositor_schedule_repaint(esurface->view->surface->compositor);
+
+   exposay_in_flight_dec(esurface->shell);
+}
+
+static void
+exposay_animate_in(struct exposay_surface *esurface)
+{
+   exposay_in_flight_

[PATCH 8/9] exposay: Activate a surface when hovering it

[Emilio Pozuelo Monfort]

This causes the surface to get the keyboard focus, which in turn
causes focus-animation to nicely work with exposay, making the
not focused surfaces to be dimmed.

Signed-off-by: Emilio Pozuelo Monfort 
---
 src/shell.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/shell.c b/src/shell.c
index accf4de..08d2627 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -5064,8 +5064,7 @@ exposay_highlight_surface(struct desktop_shell *shell,
view = esurface->view;
}
 
-   animate_focus_change(shell, shell->exposay.workspace,
-shell->exposay.focus_current, view);
+   activate(shell, view->surface, shell->exposay.seat);
shell->exposay.focus_current = view;
 }
 
-- 
1.8.4.rc3

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

[PATCH 0/9] exposay & alt-tab

[Emilio Pozuelo Monfort]

The following series adds exposay as previously submitted on the list
but rebased on master. It also adds an alt-tab switcher which is a
nice demonstration of weston_views. In addition there's a bug fix
in the input code that is easily triggered by exposay.

Daniel Stone (3):
  Add modifier-only binding
  Add move/scale animation
  Add Exposay

Emilio Pozuelo Monfort (5):
  input: Don't send leave events to destroyed views
  shell: Implement alt-tab switcher
  exposay: add cancel impl to the kbd grab iface
  exposay: Activate a surface when hovering it
  shell: Set output on the focus_surfaces' view

Louis-Francis Ratté-Boulianne (1):
  animation, shell: add kbd focus change animation

 src/animation.c  |  115 +-
 src/bindings.c   |   58 +++
 src/compositor.c |1 +
 src/compositor.h |   31 ++
 src/input.c  |   63 
 src/shell.c  | 1095 --
 6 files changed, 1333 insertions(+), 30 deletions(-)

-- 
1.8.4.rc3

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

[PATCH 2/9] Add modifier-only binding

[Emilio Pozuelo Monfort]

From: Daniel Stone 

Add the ability to bind to modifiers; the binding is armed when a key
which sets the requested modifier is pressed, and triggered if the key
is released with no other keys having been pressed in the meantime, as
well as mouse buttons or scroll axes.

This only works for direct modifiers (e.g. Shift and Alt), not modifiers
which latch or lock.

[pochu: rebased]
---
 src/bindings.c   | 58 
 src/compositor.c |  1 +
 src/compositor.h | 16 
 src/input.c  | 38 +
 4 files changed, 113 insertions(+)

diff --git a/src/bindings.c b/src/bindings.c
index 7cbded9..fb758d1 100644
--- a/src/bindings.c
+++ b/src/bindings.c
@@ -76,6 +76,24 @@ weston_compositor_add_key_binding(struct weston_compositor 
*compositor,
 }
 
 WL_EXPORT struct weston_binding *
+weston_compositor_add_modifier_binding(struct weston_compositor *compositor,
+  uint32_t modifier,
+  weston_modifier_binding_handler_t 
handler,
+  void *data)
+{
+   struct weston_binding *binding;
+
+   binding = weston_compositor_add_binding(compositor, 0, 0, 0,
+   modifier, handler, data);
+   if (binding == NULL)
+   return NULL;
+
+   wl_list_insert(compositor->modifier_binding_list.prev, &binding->link);
+
+   return binding;
+}
+
+WL_EXPORT struct weston_binding *
 weston_compositor_add_button_binding(struct weston_compositor *compositor,
 uint32_t button, uint32_t modifier,
 weston_button_binding_handler_t handler,
@@ -248,6 +266,10 @@ weston_compositor_run_key_binding(struct weston_compositor 
*compositor,
if (state == WL_KEYBOARD_KEY_STATE_RELEASED)
return;
 
+   /* Invalidate all active modifier bindings. */
+   wl_list_for_each(b, &compositor->modifier_binding_list, link)
+   b->key = key;
+
wl_list_for_each(b, &compositor->key_binding_list, link) {
if (b->key == key && b->modifier == seat->modifier_state) {
weston_key_binding_handler_t handler = b->handler;
@@ -264,6 +286,34 @@ weston_compositor_run_key_binding(struct weston_compositor 
*compositor,
 }
 
 WL_EXPORT void
+weston_compositor_run_modifier_binding(struct weston_compositor *compositor,
+  struct weston_seat *seat,
+  enum weston_keyboard_modifier modifier,
+  enum wl_keyboard_key_state state)
+{
+   struct weston_binding *b;
+
+   wl_list_for_each(b, &compositor->modifier_binding_list, link) {
+   weston_modifier_binding_handler_t handler = b->handler;
+
+   if (b->modifier != modifier)
+   continue;
+
+   /* Prime the modifier binding. */
+   if (state == WL_KEYBOARD_KEY_STATE_PRESSED) {
+   b->key = 0;
+   continue;
+   }
+   /* Ignore the binding if a key was pressed in between. */
+   else if (b->key != 0) {
+   return;
+   }
+
+   handler(seat, modifier, b->data);
+   }
+}
+
+WL_EXPORT void
 weston_compositor_run_button_binding(struct weston_compositor *compositor,
 struct weston_seat *seat,
 uint32_t time, uint32_t button,
@@ -274,6 +324,10 @@ weston_compositor_run_button_binding(struct 
weston_compositor *compositor,
if (state == WL_POINTER_BUTTON_STATE_RELEASED)
return;
 
+   /* Invalidate all active modifier bindings. */
+   wl_list_for_each(b, &compositor->modifier_binding_list, link)
+   b->key = button;
+
wl_list_for_each(b, &compositor->button_binding_list, link) {
if (b->button == button && b->modifier == seat->modifier_state) 
{
weston_button_binding_handler_t handler = b->handler;
@@ -308,6 +362,10 @@ weston_compositor_run_axis_binding(struct 
weston_compositor *compositor,
 {
struct weston_binding *b;
 
+   /* Invalidate all active modifier bindings. */
+   wl_list_for_each(b, &compositor->modifier_binding_list, link)
+   b->key = axis;
+
wl_list_for_each(b, &compositor->axis_binding_list, link) {
if (b->axis == axis && b->modifier == seat->modifier_state) {
weston_axis_binding_handler_t handler = b->handler;
diff --git a/src/compositor.c b/src/compositor.c
index c6cf682..34c0551 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3332,6 +3332,7 @@ weston_compositor_init(struct weston_compositor *ec,
wl_list_init(&ec->seat_list);
wl_list_init(&ec->ou

[PATCH 1/9] animation, shell: add kbd focus change animation

[Emilio Pozuelo Monfort]

From: Louis-Francis Ratté-Boulianne 

When enabled, this will make all but the keyboard-focused window dim.
Also the background gets dimmed, if there are any windows open. The
panel is not dimmed.

When the keyboard focus changes, the change in dimming is animated.

The dimming is implemented with transparent solid-color surfaces, two at
most. The net effect of two overlapping dim surfaces is kept constant
during animations (stable fade animation).

There is a new weston.ini option "focus-animation", that defaults to
none, and can be set to "dim-layer" to enable the focus change
animation.

[pq: Sliced, squashed, and rebased the patch series. Fixed surface alpha
interaction with the switcher. Wrote the commit message.]

[pochu: rebased, ported to weston_view]
---
 src/animation.c  |  53 +--
 src/compositor.h |   8 ++
 src/shell.c  | 262 +--
 3 files changed, 293 insertions(+), 30 deletions(-)

diff --git a/src/animation.c b/src/animation.c
index c71b506..8739f19 100644
--- a/src/animation.c
+++ b/src/animation.c
@@ -127,9 +127,10 @@ struct weston_view_animation {
weston_view_animation_frame_func_t reset;
weston_view_animation_done_func_t done;
void *data;
+   void *private;
 };
 
-static void
+WL_EXPORT void
 weston_view_animation_destroy(struct weston_view_animation *animation)
 {
wl_list_remove(&animation->animation.link);
@@ -185,7 +186,8 @@ weston_view_animation_run(struct weston_view *view,
  weston_view_animation_frame_func_t frame,
  weston_view_animation_frame_func_t reset,
  weston_view_animation_done_func_t done,
- void *data)
+ void *data,
+ void *private)
 {
struct weston_view_animation *animation;
 
@@ -200,6 +202,7 @@ weston_view_animation_run(struct weston_view *view,
animation->data = data;
animation->start = start;
animation->stop = stop;
+   animation->private = private;
weston_matrix_init(&animation->transform.matrix);
wl_list_insert(&view->geometry.transformation_list,
   &animation->transform.link);
@@ -257,7 +260,7 @@ weston_zoom_run(struct weston_view *view, float start, 
float stop,
 
zoom = weston_view_animation_run(view, start, stop,
 zoom_frame, reset_alpha,
-done, data);
+done, data, NULL);
 
weston_spring_init(&zoom->spring, 300.0, start, stop);
zoom->spring.friction = 1400;
@@ -286,7 +289,7 @@ weston_fade_run(struct weston_view *view,
 
fade = weston_view_animation_run(view, 0, end,
 fade_frame, reset_alpha,
-done, data);
+done, data, NULL);
 
weston_spring_init(&fade->spring, k, start, end);
 
@@ -305,6 +308,46 @@ weston_fade_update(struct weston_view_animation *fade, 
float target)
 }
 
 static void
+stable_fade_frame(struct weston_view_animation *animation)
+{
+   struct weston_view *back_view;
+
+   if (animation->spring.current > 0.999)
+   animation->view->alpha = 1;
+   else if (animation->spring.current < 0.001 )
+   animation->view->alpha = 0;
+   else
+   animation->view->alpha = animation->spring.current;
+
+   back_view = (struct weston_view *) animation->private;
+   back_view->alpha =
+   (animation->spring.target - animation->view->alpha) /
+   (1.0 - animation->view->alpha);
+   weston_view_geometry_dirty(back_view);
+}
+
+WL_EXPORT struct weston_view_animation *
+weston_stable_fade_run(struct weston_view *front_view, float start,
+   struct weston_view *back_view, float end,
+   weston_view_animation_done_func_t done, void *data)
+{
+   struct weston_view_animation *fade;
+
+   fade = weston_view_animation_run(front_view, 0, 0,
+   stable_fade_frame, NULL,
+   done, data, back_view);
+
+
+   weston_spring_init(&fade->spring, 400, start, end);
+   fade->spring.friction = 1150;
+
+   front_view->alpha = start;
+   back_view->alpha = end;
+
+   return fade;
+}
+
+static void
 slide_frame(struct weston_view_animation *animation)
 {
float scale;
@@ -324,7 +367,7 @@ weston_slide_run(struct weston_view *view, float start, 
float stop,
 
animation = weston_view_animation_run(view, start, stop,
  slide_frame, NULL, done,
- data);
+ data, NULL);
if (!animation)
return NULL;
 
diff --git a/src/composit

Re: [RFC] Common input device library

[Jasper St. Pierre]

It's because the keyboard is a surprisingly complicated tool with multiple
modes of operating, probably without you ever realizing it, and clients
need all of that power:

  If I'm typing text, the *labels* of the keys matter, and input methods
allow us to translate sequences of key presses and releases into a Unicode
character on the screen.

  We also have "chords", where holding down a certain key could affect
operation. For instance holding the "Shift" key causes the letters typed to
be capitalized. However, some users can't accurately hold down a shift key,
though, so we have accessibility support like latched keys (press Shift,
press "S"), and sticky keys (press Shift, press "S", then press Shift again
to turn it off).

  If I'm playing a game, the *locations* of the keys matter. Games use a
WASD scheme not because the letters "W", "A", "S", and "D" mean anything,
but because their location on a QWERTY keyboard make a left-handed arrow
key shape. On alternate keyboard layouts, we still need them to make that
arrow shape, and not give users a layout where going forward means you have
to reach half-way across the keyboard.

  We also have "key shortcuts", which combine both worlds: Ctrl+Z, Ctrl+X,
Ctrl+C, and Ctrl+V are all location-based, but Ctrl+F is word-based.

The typical approach, as done by Windows, OS X, and XKB (and now Wayland)
is to send the client an opaque integer that corresponds to "a key", along
with a map of how the keys are laid out, and then have the client look up
whatever information it needs.


On Fri, Nov 15, 2013 at 11:15 AM, Artsiom Anikeyenka
wrote:

> Thanks! That's strange... I mean... It sounds like there are extra levels
> of responsibility. What I would expect is one way flow with 1 component
> processing all the input. 1 person will hardly deal with more then 1 output
> (though it may use several inputs at a time). That's y the concept of 1
> active window will always remain (unless we get to heads one day). So y do
> one want to have some input processed on the level of compositor and some
> input on the level of a client. So I would assume sort of input linear flow
>  (meaning it won't split at some point). And if it's not split on some
> level so why do one want to move responsibility over the levels. Does it
> make sense?
>
> Thanks.
>
>
> On Fri, Nov 15, 2013 at 6:07 PM, Jasper St. Pierre 
> wrote:
>
>> If by libxcbcommon you mean libxkbcommon, no.
>>
>> libxkbcommon is about the complex ways of interpreting key events, with
>> client-side key maps, modifiers, accessibility features (latched keys,
>> sticky keys, etc.). It's meant to be used from both the compositor and the
>> client.
>>
>> libinput is about replacing all of the xorg-x11-drv infrastructure on the
>> server, like the special -synaptics driver. It's meant to be used from
>> compositors only.
>>
>> It's very likely that libinput will use libxkbcommon.
>>
>>
>> On Fri, Nov 15, 2013 at 10:01 AM, Artsiom Anikeyenka <
>> arty.ani...@gmail.com> wrote:
>>
>>> Is libinput supposed to be sort of replacement for libxcbcommon?
>>>
>>> Thanks.
>>>
>>>
>>> On Thu, Nov 14, 2013 at 4:58 PM, Artsiom Anikeyenka <
>>> arty.ani...@gmail.com> wrote:
>>>
 I like the generalized architecture of any input handling as well. I
 didn't look into the code because I will hardly understand it yet. I also
 don't understand a lot yet but what I'd do is also some sort of dispatcher
 of the input object queue. I.e. when each device is watched by the wrapper
 which wraps any event from the device into input_object with interface
 which can be understood by libinput easily. Thus we create sort of protocol
 which allows easy adding of new devices. After interpreting the event
 libinput passes it further. Such architecture is very simple and
 straightforward, easy to maintain and document.

 Disregard this email if it doesn't make any sense ha-ha-ha :D

 The best way to learn is to start making mistakes.

 Cheers!!!


 On Thu, Nov 14, 2013 at 9:30 AM, Peter Hutterer <
 peter.hutte...@who-t.net> wrote:

> On Wed, Nov 13, 2013 at 01:22:26PM +0100, Jonas Ådahl wrote:
> > On Wed, Nov 13, 2013 at 7:22 AM, Peter Hutterer
> >  wrote:
> > > Hi Jonas,
> > >
> > > On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
> > >> Wayland compositors are expected to deal with input device
> processing
> > >> themselves providing input events according to the Wayland
> protocol to
> > >> the clients. So far only weston has had more than basic support
> for
> > >> processing raw input events from evdev.
> > >>
> > >> In order to avoid reimplementing support for various types of
> input
> > >> devices over and over again for every compositor, I extracted the
> input
> > >> device code from weston and put it in a new library called
> libinput.
> > >
> > > funny timing, I just started o

Re: [RFC] Common input device library

[Artsiom Anikeyenka]

Thanks! That's strange... I mean... It sounds like there are extra levels
of responsibility. What I would expect is one way flow with 1 component
processing all the input. 1 person will hardly deal with more then 1 output
(though it may use several inputs at a time). That's y the concept of 1
active window will always remain (unless we get to heads one day). So y do
one want to have some input processed on the level of compositor and some
input on the level of a client. So I would assume sort of input linear
flow (meaning
it won't split at some point). And if it's not split on some level so why
do one want to move responsibility over the levels. Does it make sense?

Thanks.


On Fri, Nov 15, 2013 at 6:07 PM, Jasper St. Pierre wrote:

> If by libxcbcommon you mean libxkbcommon, no.
>
> libxkbcommon is about the complex ways of interpreting key events, with
> client-side key maps, modifiers, accessibility features (latched keys,
> sticky keys, etc.). It's meant to be used from both the compositor and the
> client.
>
> libinput is about replacing all of the xorg-x11-drv infrastructure on the
> server, like the special -synaptics driver. It's meant to be used from
> compositors only.
>
> It's very likely that libinput will use libxkbcommon.
>
>
> On Fri, Nov 15, 2013 at 10:01 AM, Artsiom Anikeyenka <
> arty.ani...@gmail.com> wrote:
>
>> Is libinput supposed to be sort of replacement for libxcbcommon?
>>
>> Thanks.
>>
>>
>> On Thu, Nov 14, 2013 at 4:58 PM, Artsiom Anikeyenka <
>> arty.ani...@gmail.com> wrote:
>>
>>> I like the generalized architecture of any input handling as well. I
>>> didn't look into the code because I will hardly understand it yet. I also
>>> don't understand a lot yet but what I'd do is also some sort of dispatcher
>>> of the input object queue. I.e. when each device is watched by the wrapper
>>> which wraps any event from the device into input_object with interface
>>> which can be understood by libinput easily. Thus we create sort of protocol
>>> which allows easy adding of new devices. After interpreting the event
>>> libinput passes it further. Such architecture is very simple and
>>> straightforward, easy to maintain and document.
>>>
>>> Disregard this email if it doesn't make any sense ha-ha-ha :D
>>>
>>> The best way to learn is to start making mistakes.
>>>
>>> Cheers!!!
>>>
>>>
>>> On Thu, Nov 14, 2013 at 9:30 AM, Peter Hutterer <
>>> peter.hutte...@who-t.net> wrote:
>>>
 On Wed, Nov 13, 2013 at 01:22:26PM +0100, Jonas Ådahl wrote:
 > On Wed, Nov 13, 2013 at 7:22 AM, Peter Hutterer
 >  wrote:
 > > Hi Jonas,
 > >
 > > On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
 > >> Wayland compositors are expected to deal with input device
 processing
 > >> themselves providing input events according to the Wayland
 protocol to
 > >> the clients. So far only weston has had more than basic support for
 > >> processing raw input events from evdev.
 > >>
 > >> In order to avoid reimplementing support for various types of input
 > >> devices over and over again for every compositor, I extracted the
 input
 > >> device code from weston and put it in a new library called
 libinput.
 > >
 > > funny timing, I just started on something similar recently :)
 >
 > Well, it is needed, so no surprise there are more efforts going on :)
 >
 > >
 > > In my case it was more inspired by the xorg synaptics driver where
 I keep
 > > running into issues that can't be fixed without a rewrite. so I
 started
 > > with a library that should handle touchpads and can be used by X and
 > > wayland compositors.
 > >
 > > I just committed the current state, polished it a bit and pushed it
 to
 > > github: https://github.com/whot/libtouchpad
 > >
 > > The eventual goal was that Weston can use that for touchpads, but
 so far I
 > > only have a shell X driver for it. Please have a look at that and
 let me
 > > know what you think. There's something of an API, the basic design
 is
 > > inspired by Weston.
 > >
 > > fwiw, one reason I didn't just take evdev-touchpad.c is that I
 believe that
 > > it's not possible to write a good touchpad driver without the driver
 > > tracking and handling each touchpoint separately. weston currently
 doesn't
 > > do that.
 >
 > I think individual touch point tracking should not be something
 > required by a touchpad driver mostly because many touchpads don't
 > report it. As the main author of weston's evdev-touchpad.c I can say
 > that it does not track touch points individually simply because my
 > touchpad device doesn't report them as such (and it's not that old of
 > a laptop). It was not an active design choice not to track them.

 I did a quick check on the various big laptop makers and I can't find a
 new
 model that doesn't have a cl

Re: [RFC] Common input device library

[Jasper St. Pierre]

If by libxcbcommon you mean libxkbcommon, no.

libxkbcommon is about the complex ways of interpreting key events, with
client-side key maps, modifiers, accessibility features (latched keys,
sticky keys, etc.). It's meant to be used from both the compositor and the
client.

libinput is about replacing all of the xorg-x11-drv infrastructure on the
server, like the special -synaptics driver. It's meant to be used from
compositors only.

It's very likely that libinput will use libxkbcommon.


On Fri, Nov 15, 2013 at 10:01 AM, Artsiom Anikeyenka
wrote:

> Is libinput supposed to be sort of replacement for libxcbcommon?
>
> Thanks.
>
>
> On Thu, Nov 14, 2013 at 4:58 PM, Artsiom Anikeyenka  > wrote:
>
>> I like the generalized architecture of any input handling as well. I
>> didn't look into the code because I will hardly understand it yet. I also
>> don't understand a lot yet but what I'd do is also some sort of dispatcher
>> of the input object queue. I.e. when each device is watched by the wrapper
>> which wraps any event from the device into input_object with interface
>> which can be understood by libinput easily. Thus we create sort of protocol
>> which allows easy adding of new devices. After interpreting the event
>> libinput passes it further. Such architecture is very simple and
>> straightforward, easy to maintain and document.
>>
>> Disregard this email if it doesn't make any sense ha-ha-ha :D
>>
>> The best way to learn is to start making mistakes.
>>
>> Cheers!!!
>>
>>
>> On Thu, Nov 14, 2013 at 9:30 AM, Peter Hutterer > > wrote:
>>
>>> On Wed, Nov 13, 2013 at 01:22:26PM +0100, Jonas Ådahl wrote:
>>> > On Wed, Nov 13, 2013 at 7:22 AM, Peter Hutterer
>>> >  wrote:
>>> > > Hi Jonas,
>>> > >
>>> > > On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
>>> > >> Wayland compositors are expected to deal with input device
>>> processing
>>> > >> themselves providing input events according to the Wayland protocol
>>> to
>>> > >> the clients. So far only weston has had more than basic support for
>>> > >> processing raw input events from evdev.
>>> > >>
>>> > >> In order to avoid reimplementing support for various types of input
>>> > >> devices over and over again for every compositor, I extracted the
>>> input
>>> > >> device code from weston and put it in a new library called libinput.
>>> > >
>>> > > funny timing, I just started on something similar recently :)
>>> >
>>> > Well, it is needed, so no surprise there are more efforts going on :)
>>> >
>>> > >
>>> > > In my case it was more inspired by the xorg synaptics driver where I
>>> keep
>>> > > running into issues that can't be fixed without a rewrite. so I
>>> started
>>> > > with a library that should handle touchpads and can be used by X and
>>> > > wayland compositors.
>>> > >
>>> > > I just committed the current state, polished it a bit and pushed it
>>> to
>>> > > github: https://github.com/whot/libtouchpad
>>> > >
>>> > > The eventual goal was that Weston can use that for touchpads, but so
>>> far I
>>> > > only have a shell X driver for it. Please have a look at that and
>>> let me
>>> > > know what you think. There's something of an API, the basic design is
>>> > > inspired by Weston.
>>> > >
>>> > > fwiw, one reason I didn't just take evdev-touchpad.c is that I
>>> believe that
>>> > > it's not possible to write a good touchpad driver without the driver
>>> > > tracking and handling each touchpoint separately. weston currently
>>> doesn't
>>> > > do that.
>>> >
>>> > I think individual touch point tracking should not be something
>>> > required by a touchpad driver mostly because many touchpads don't
>>> > report it. As the main author of weston's evdev-touchpad.c I can say
>>> > that it does not track touch points individually simply because my
>>> > touchpad device doesn't report them as such (and it's not that old of
>>> > a laptop). It was not an active design choice not to track them.
>>>
>>> I did a quick check on the various big laptop makers and I can't find a
>>> new
>>> model that doesn't have a clickpad (dell gives me 404s but I don't think
>>> they
>>> do either). My x220 is now about 2 years old and it wasn't the first
>>> with a
>>> clickpad either.
>>>
>>> Laptops can last a lot longer of course, but imo we should be focusing on
>>> what's coming out now or in the immediate future and maybe tack support
>>> for
>>> older models on top, rather than the other way round. One reason the xorg
>>> synaptics driver is so bad is because it had MT support tacked on top
>>> (while
>>> trying to support multiple non-evdev backends), especially while MT
>>> support
>>> in touchpads was less-than-ideal (e.g. the Dell mini 10 touchpad from
>>> hell).
>>>
>>> > > also, I don't yet know if this will or can turn into a generic input
>>> > > library. I wanted to get the touchpad case sorted first since it's
>>> the most
>>> > > complicated. having said that, libtouchpad could be sitting
>>> underneath
>>> > > a more generic libinput (in

Re: [RFC] Common input device library

[Artsiom Anikeyenka]

Is libinput supposed to be sort of replacement for libxcbcommon?

Thanks.


On Thu, Nov 14, 2013 at 4:58 PM, Artsiom Anikeyenka
wrote:

> I like the generalized architecture of any input handling as well. I
> didn't look into the code because I will hardly understand it yet. I also
> don't understand a lot yet but what I'd do is also some sort of dispatcher
> of the input object queue. I.e. when each device is watched by the wrapper
> which wraps any event from the device into input_object with interface
> which can be understood by libinput easily. Thus we create sort of protocol
> which allows easy adding of new devices. After interpreting the event
> libinput passes it further. Such architecture is very simple and
> straightforward, easy to maintain and document.
>
> Disregard this email if it doesn't make any sense ha-ha-ha :D
>
> The best way to learn is to start making mistakes.
>
> Cheers!!!
>
>
> On Thu, Nov 14, 2013 at 9:30 AM, Peter Hutterer 
> wrote:
>
>> On Wed, Nov 13, 2013 at 01:22:26PM +0100, Jonas Ådahl wrote:
>> > On Wed, Nov 13, 2013 at 7:22 AM, Peter Hutterer
>> >  wrote:
>> > > Hi Jonas,
>> > >
>> > > On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
>> > >> Wayland compositors are expected to deal with input device processing
>> > >> themselves providing input events according to the Wayland protocol
>> to
>> > >> the clients. So far only weston has had more than basic support for
>> > >> processing raw input events from evdev.
>> > >>
>> > >> In order to avoid reimplementing support for various types of input
>> > >> devices over and over again for every compositor, I extracted the
>> input
>> > >> device code from weston and put it in a new library called libinput.
>> > >
>> > > funny timing, I just started on something similar recently :)
>> >
>> > Well, it is needed, so no surprise there are more efforts going on :)
>> >
>> > >
>> > > In my case it was more inspired by the xorg synaptics driver where I
>> keep
>> > > running into issues that can't be fixed without a rewrite. so I
>> started
>> > > with a library that should handle touchpads and can be used by X and
>> > > wayland compositors.
>> > >
>> > > I just committed the current state, polished it a bit and pushed it to
>> > > github: https://github.com/whot/libtouchpad
>> > >
>> > > The eventual goal was that Weston can use that for touchpads, but so
>> far I
>> > > only have a shell X driver for it. Please have a look at that and let
>> me
>> > > know what you think. There's something of an API, the basic design is
>> > > inspired by Weston.
>> > >
>> > > fwiw, one reason I didn't just take evdev-touchpad.c is that I
>> believe that
>> > > it's not possible to write a good touchpad driver without the driver
>> > > tracking and handling each touchpoint separately. weston currently
>> doesn't
>> > > do that.
>> >
>> > I think individual touch point tracking should not be something
>> > required by a touchpad driver mostly because many touchpads don't
>> > report it. As the main author of weston's evdev-touchpad.c I can say
>> > that it does not track touch points individually simply because my
>> > touchpad device doesn't report them as such (and it's not that old of
>> > a laptop). It was not an active design choice not to track them.
>>
>> I did a quick check on the various big laptop makers and I can't find a
>> new
>> model that doesn't have a clickpad (dell gives me 404s but I don't think
>> they
>> do either). My x220 is now about 2 years old and it wasn't the first with
>> a
>> clickpad either.
>>
>> Laptops can last a lot longer of course, but imo we should be focusing on
>> what's coming out now or in the immediate future and maybe tack support
>> for
>> older models on top, rather than the other way round. One reason the xorg
>> synaptics driver is so bad is because it had MT support tacked on top
>> (while
>> trying to support multiple non-evdev backends), especially while MT
>> support
>> in touchpads was less-than-ideal (e.g. the Dell mini 10 touchpad from
>> hell).
>>
>> > > also, I don't yet know if this will or can turn into a generic input
>> > > library. I wanted to get the touchpad case sorted first since it's
>> the most
>> > > complicated. having said that, libtouchpad could be sitting underneath
>> > > a more generic libinput (in design, not as separate library), similar
>> to how
>> > > evdev-touchpad is underneath evdev.c
>> >
>> > Regarding having a libtouchpad, I don't like the idea of separating
>> > touchpad from other input device handling. In weston (and this PoC
>> > libinput) parts of the input processing is designed to be shared
>> > between mouse devices and touchpads for example pointer acceleration,
>>
>> I agree, and I wasn't planning on having pointer acceleration in the
>> touchpad library. It still spits out everything in device coordinate,
>> leaving the rest to the next level.
>>
>> > and possibly other things. I much more prefer the idea of a library
>> > that handles touc

Re: [chromium-dev] Re: PSA: Chromium Wayland preview

[Prabhu S]

Got the chorme-ozone working for ARM with proprietary GPU drivers. It is
neat!
WebGL also working very good.

I recommend to use gold linker and latest ninja(1.4).

I have to make only the following change

@@ -117,7 +117,7 @@ bool GLSurfaceEGL::InitializeOneOff() {
 LOG(ERROR) << "OZONE failed to initialize hardware";
 return false;
   }
-  g_native_display = surface_factory->GetNativeDisplay();
+  g_native_display =
(EGLNativeDisplayType)surface_factory->GetNativeDisplay();
 #else
   g_native_display = EGL_DEFAULT_DISPLAY;
 #endif



On Tue, Nov 12, 2013 at 1:09 PM, Tiago Vignatti wrote:

> argh, Pekka (pq) just told me in #wayland that we're probably talking
> about two different things here. Sorry, my confusion.
>
> If you were mentioning about building an Gentoo package out of Chromium
> Wayland, then no, I don't think anyone tried that yet. As mentioned in the
> blog announcement message, we expect that the distribution packagers people
> will come and build the package for themselves, in principle.
>
> Tiago
>
>
> On 11/12/2013 03:43 PM, Tiago Vignatti wrote:
>
>> no, there isn't any automated compilation tool yet.
>>
>> To be honest I'm not entirely sure whether it's worthing having such
>> tool. We basically have Ozone-Wayland repository to be cloned in which
>> pulls in all the remaining dependencies (well, not libwayland...) and
>> for that we'd need about half dozen of commands before it starts the
>> actual built process. Do you think we can do better with an ebuild?
>>
>> Thanks,
>>
>> Tiago
>>
>> On 11/12/2013 03:25 PM, Mike Lothian wrote:
>>
>>> Hi
>>>
>>> Out of interest is there an ebuild available for this?
>>>
>>> Cheers
>>>
>>> Mike
>>>
>>> On 11 Nov 2013 21:40, "Tiago Vignatti" >> > wrote:
>>>
>>>
>>> We are happy to announce the first "preview" of Chromium browser
>>> with Wayland support, using Ozone-Wayland implementation. Check the
>>> announcement and the details here please:
>>>
>>>
>>> https://01.org/ozone-wayland/__blogs/tiagovignatti/2013/__
>>> chromium-browser-wayland-__preview-release
>>>
>>>
>>> >> chromium-browser-wayland-preview-release>
>>>
>>>
>>> Tiago
>>> _
>>> wayland-devel mailing list
>>> wayland-devel@lists.__freedesktop.org
>>> 
>>> http://lists.freedesktop.org/__mailman/listinfo/wayland-devel
>>> 
>>>
>>> --
>>> --
>>> Chromium Developers mailing list: chromium-...@chromium.org
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/a/chromium.org/group/chromium-dev
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to chromium-dev+unsubscr...@chromium.org.
>>>
>>
>>
> ___
> 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 mesa v5 2/2] wayland: Add support for eglSwapInterval

[Axel Davy]

I'm not sure waiting 10ms when all the buffers aren't released is the 
best solution.


In fact, I experimented a eglSwapInterval(0) behaviour with a simple 
patch to enable it:
having 4 back buffers and using a roundtrip after commiting (that is: a 
bit similar to what you do, but without the poll)


And with glmark2, for all the benchmarks (10 seconds by benchmark) I had 
4-5 egl error messages

because there was no buffer free in get_back_bo (the benchmarks continued).

That makes me think that the poll case might happen more often than you 
think.


I suggest to have a lighter solution: for example poll a first time with 
1ms instead of 10ms,

and then if no buffers are free, try again with a poll of 10ms.
Why not doing directly another roundtrip?

Axel Davy

Le 15/11/2013 14:50, Neil Roberts a écrit :

The Wayland EGL platform now respects the eglSwapInterval value. The value is
clamped to either 0 or 1 because it is difficult (and probably not useful) to
sync to more than 1 redraw.

The main change is that if the swap interval is 0 then Mesa won't install a
frame callback so that eglSwapBuffers can be executed as often as necessary.
Instead it will do a sync request after the swap buffers. It will block for
sync complete event in get_back_bo instead of the frame callback. The
compositor is likely to send a release event while processing the new buffer
attach and this makes sure we will receive that before deciding whether to
allocate a new buffer.

If there are no buffers available then instead of returning with an error,
get_back_bo will now poll the compositor by repeatedly sending sync requests
every 10ms. This is a last resort and in theory this shouldn't happen because
there should be no reason for the compositor to hold on to more than three
buffers. That means whenever we attach the fourth buffer we should always get
an immediate release event which should come in with the notification for the
first sync request that we are throttled to.

When the compositor is directly scanning out from the application's buffer it
may end up holding on to three buffers. These are the one that is is currently
scanning out from, one that has been given to DRM as the next buffer to flip
to, and one that has been attached and will be given to DRM as soon as the
previous flip completes. When we attach a fourth buffer to the compositor it
should replace that third buffer so we should get a release event immediately
after that. This patch therefore also changes the number of buffer slots to 4
so that we can accomodate that situation.

If DRM eventually gets a way to cancel a pending page flip then the compositors
can be changed to only need to hold on to two buffers and this value can be
put back to 3.

This also moves the vblank configuration defines from platform_x11.c to the
common egl_dri2.h header so they can be shared by both platforms.
---
  src/egl/drivers/dri2/egl_dri2.h |  10 +-
  src/egl/drivers/dri2/platform_wayland.c | 199 +++-
  src/egl/drivers/dri2/platform_x11.c |   6 -
  3 files changed, 179 insertions(+), 36 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 8c303d9..d29dd98 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -174,7 +174,7 @@ struct dri2_egl_surface
 struct wl_egl_window  *wl_win;
 intdx;
 intdy;
-   struct wl_callback*frame_callback;
+   struct wl_callback*throttle_callback;
 int  format;
  #endif
  
@@ -194,7 +194,7 @@ struct dri2_egl_surface

  #endif
int locked;
int age;
-   } color_buffers[3], *back, *current;
+   } color_buffers[4], *back, *current;
  #endif
  
  #ifdef HAVE_ANDROID_PLATFORM

@@ -220,6 +220,12 @@ struct dri2_egl_image
 __DRIimage *dri_image;
  };
  
+/* From xmlpool/options.h, user exposed so should be stable */

+#define DRI_CONF_VBLANK_NEVER 0
+#define DRI_CONF_VBLANK_DEF_INTERVAL_0 1
+#define DRI_CONF_VBLANK_DEF_INTERVAL_1 2
+#define DRI_CONF_VBLANK_ALWAYS_SYNC 3
+
  /* standard typecasts */
  _EGL_DRIVER_STANDARD_TYPECASTS(dri2_egl)
  _EGL_DRIVER_TYPECAST(dri2_egl_image, _EGLImage, obj)
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 5ce8981..fca35db 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -34,6 +34,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "egl_dri2.h"
  
@@ -183,8 +184,16 @@ dri2_create_window_surface(_EGLDriver *drv, _EGLDisplay *disp,

   _EGLConfig *conf, EGLNativeWindowType window,
   const EGLint *attrib_list)
  {
-   return dri2_create_surface(drv, disp, EGL_WINDOW_BIT, conf,
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   _EGLSurface *surf;
+
+   surf = dri2_create_surface(drv, disp, E

[PATCH weston] protocol: move sub-surfaces to Wayland

[ppaalanen]

From: Pekka Paalanen 

This reverts commit 2396aec6842c709a714f3825dbad9fd88478f2e6.

This exact version of the sub-surface protocol has been copied into
Wayland core. Therefore it must be removed from here to avoid build
conflicts and useless duplication.

No other changes to sub-surface protocol consumers are needed, the
identical API is now offered by libwayland-client and libwayland-server.

The commit adding sub-surfaces to Wayland is:
Author: Pekka Paalanen 

protocol: add sub-surfaces to the core

Signed-off-by: Pekka Paalanen 
---
 clients/.gitignore  |   2 -
 clients/Makefile.am |   4 -
 clients/window.h|   1 -
 protocol/Makefile.am|   1 -
 protocol/subsurface.xml | 244 
 src/.gitignore  |   3 -
 src/Makefile.am |   4 -
 src/compositor.c|   1 -
 tests/.gitignore|   2 -
 tests/Makefile.am   |   6 +-
 tests/subsurface-test.c |   1 -
 11 files changed, 1 insertion(+), 268 deletions(-)
 delete mode 100644 protocol/subsurface.xml

diff --git a/clients/.gitignore b/clients/.gitignore
index 23959cc..92e1659 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -27,8 +27,6 @@ weston-keyboard
 libtoytoolkit.a
 screenshooter-client-protocol.h
 screenshooter-protocol.c
-subsurface-client-protocol.h
-subsurface-protocol.c
 tablet-shell-client-protocol.h
 tablet-shell-protocol.c
 text-client-protocol.h
diff --git a/clients/Makefile.am b/clients/Makefile.am
index 4f9dc48..032d900 100644
--- a/clients/Makefile.am
+++ b/clients/Makefile.am
@@ -97,8 +97,6 @@ libtoytoolkit_la_SOURCES =\
window.h\
text-cursor-position-protocol.c \
text-cursor-position-client-protocol.h  \
-   subsurface-protocol.c   \
-   subsurface-client-protocol.h\
workspaces-protocol.c   \
workspaces-client-protocol.h
 
@@ -227,8 +225,6 @@ BUILT_SOURCES = \
desktop-shell-protocol.c\
tablet-shell-client-protocol.h  \
tablet-shell-protocol.c \
-   subsurface-client-protocol.h\
-   subsurface-protocol.c   \
workspaces-client-protocol.h\
workspaces-protocol.c
 
diff --git a/clients/window.h b/clients/window.h
index 838ea4e..66cf985 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -28,7 +28,6 @@
 #include 
 #include "../shared/config-parser.h"
 #include "../shared/zalloc.h"
-#include "subsurface-client-protocol.h"
 
 #define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
 
diff --git a/protocol/Makefile.am b/protocol/Makefile.am
index d09d8eb..14a4b5a 100644
--- a/protocol/Makefile.am
+++ b/protocol/Makefile.am
@@ -6,7 +6,6 @@ protocol_sources =  \
text.xml\
input-method.xml\
workspaces.xml  \
-   subsurface.xml  \
text-cursor-position.xml\
wayland-test.xml
 
diff --git a/protocol/subsurface.xml b/protocol/subsurface.xml
deleted file mode 100644
index 9e4a658..000
--- a/protocol/subsurface.xml
+++ /dev/null
@@ -1,244 +0,0 @@
-
-
-
-  
-Copyright © 2012-2013 Collabora, Ltd.
-
-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.
-  
-
-  
-
-  The global interface exposing sub-surface compositing capabilities.
-  A wl_surface, that has sub-surfaces associated, is called the
-  parent surface. Sub-surfaces can be arbitrarily nested and create
-  a tree of sub-surfaces.
-
-  The root surface in a tree of sub-surfaces is the main
-  surface. The main surface cannot be a sub-surface, becaus

[PATCH wayland] protocol: add sub-surfaces to the core

[ppaalanen]

From: Pekka Paalanen 

The sub-surface protocol was originally committed into Weston on May
10th, 2013, in commit 2396aec6842c709a714f3825dbad9fd88478f2e6. The
design for the protocol had started in the beginning of December 2012. I
think it is high time to move this into the core now.

This patch copies the sub-surface protocol as it was in Weston on Nov
15th, 2013, into Wayland. Weston gets a patch to remove the protocol from
there.

Sub-surface is a wl_surface role. You create a wl_surface as usual, and
assign it the sub-surface role and a parent wl_surface. Sub-surfaces are
an integral part of the parent surface, and stay glued to the parent.
For window management, a window is the union of the top-level
wl_surface and all its sub-surfaces. Sub-surfaces are not clipped to the
parent, and the union of the surface tree can be larger than the
(top-level) wl_surface at its root.

The representative use case for sub-surfaces is a video player window.
When the video content is given its own wl_surface, there is no need to
modify the video frame contents after decoding or copy them into a whole
window sized buffer before submitting it to the compositor. This allows
efficient, zero-copy video presentation paths, where video decoding
hardware produces a (YUV) buffer, which eventually ends up in a
(YUV-capable) hardware overlay and is scanned out directly.

This can also be used for zero-copy presentation of windowed OpenGL
content, where the OpenGL rendering engine does not need to draw or
avoid window decorations.

Sub-surfaces allow mixing different buffer types into the same window,
e.g. software-rendered decorations in wl_shm buffers, and live content
in EGL-based buffers.

However, the sub-surface extension does not offer clipping or scaling
facilities, or accurate presentation timing. Those are topics for
additional extensions.

Signed-off-by: Pekka Paalanen 
---
 protocol/wayland.xml | 217 +++
 1 file changed, 217 insertions(+)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index a1df007..61fde84 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -4,6 +4,7 @@
   
 Copyright © 2008-2011 Kristian Høgsberg
 Copyright © 2010-2011 Intel Corporation
+Copyright © 2012-2013 Collabora, Ltd.
 
 Permission to use, copy, modify, distribute, and sell this
 software and its documentation for any purpose is hereby granted
@@ -1795,4 +1796,220 @@
 
   
 
+  
+
+  The global interface exposing sub-surface compositing capabilities.
+  A wl_surface, that has sub-surfaces associated, is called the
+  parent surface. Sub-surfaces can be arbitrarily nested and create
+  a tree of sub-surfaces.
+
+  The root surface in a tree of sub-surfaces is the main
+  surface. The main surface cannot be a sub-surface, because
+  sub-surfaces must always have a parent.
+
+  A main surface with its sub-surfaces forms a (compound) window.
+  For window management purposes, this set of wl_surface objects is
+  to be considered as a single window, and it should also behave as
+  such.
+
+  The aim of sub-surfaces is to offload some of the compositing work
+  within a window from clients to the compositor. A prime example is
+  a video player with decorations and video in separate wl_surface
+  objects. This should allow the compositor to pass YUV video buffer
+  processing to dedicated overlay hardware when possible.
+
+
+
+  
+   Informs the server that the client will not be using this
+   protocol object anymore. This does not affect any other
+   objects, wl_subsurface objects included.
+  
+
+
+
+  
+
+
+
+  
+   Create a sub-surface interface for the given surface, and
+   associate it with the given parent surface. This turns a
+   plain wl_surface into a sub-surface.
+
+   The to-be sub-surface must not already have a dedicated
+   purpose, like any shell surface type, cursor image, drag icon,
+   or sub-surface. Otherwise a protocol error is raised.
+  
+
+  
+  
+  
+
+  
+
+  
+
+  An additional interface to a wl_surface object, which has been
+  made a sub-surface. A sub-surface has one parent surface. A
+  sub-surface's size and position are not limited to that of the parent.
+  Particularly, a sub-surface is not automatically clipped to its
+  parent's area.
+
+  A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
+  and the parent surface is mapped. The order of which one happens
+  first is irrelevant. A sub-surface is hidden if the parent becomes
+  hidden, or if a NULL wl_buffer is applied. These rules apply
+  recursively through the tree of surfaces.
+
+  The behaviour of wl_surface.commit request on a sub-surface
+  depends on the sub-surface's mode. The possible modes are
+  synchronized and desynchron

Re: Thoughts about decoration information in the xdg_shell

[Armin K.]

On 11/15/2013 01:50 PM, Jasper St. Pierre wrote:
> Ah, whoops, I read your email wrong. It sounds like you're also in favor
> of requiring CSD support from the client.
> 
> That said, I'm curious about cases like Nautilus under SSD. Should we
> hide the close button, or do anything like that to make it adapt to an
> SSD environment?
> 

This is already an issue under Xfce. xfwm4 draws SSD even though
Nautilus has CSD, so you get SSD and CSD together.
<>___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH mesa v5 2/2] wayland: Add support for eglSwapInterval

[Neil Roberts]

The Wayland EGL platform now respects the eglSwapInterval value. The value is
clamped to either 0 or 1 because it is difficult (and probably not useful) to
sync to more than 1 redraw.

The main change is that if the swap interval is 0 then Mesa won't install a
frame callback so that eglSwapBuffers can be executed as often as necessary.
Instead it will do a sync request after the swap buffers. It will block for
sync complete event in get_back_bo instead of the frame callback. The
compositor is likely to send a release event while processing the new buffer
attach and this makes sure we will receive that before deciding whether to
allocate a new buffer.

If there are no buffers available then instead of returning with an error,
get_back_bo will now poll the compositor by repeatedly sending sync requests
every 10ms. This is a last resort and in theory this shouldn't happen because
there should be no reason for the compositor to hold on to more than three
buffers. That means whenever we attach the fourth buffer we should always get
an immediate release event which should come in with the notification for the
first sync request that we are throttled to.

When the compositor is directly scanning out from the application's buffer it
may end up holding on to three buffers. These are the one that is is currently
scanning out from, one that has been given to DRM as the next buffer to flip
to, and one that has been attached and will be given to DRM as soon as the
previous flip completes. When we attach a fourth buffer to the compositor it
should replace that third buffer so we should get a release event immediately
after that. This patch therefore also changes the number of buffer slots to 4
so that we can accomodate that situation.

If DRM eventually gets a way to cancel a pending page flip then the compositors
can be changed to only need to hold on to two buffers and this value can be
put back to 3.

This also moves the vblank configuration defines from platform_x11.c to the
common egl_dri2.h header so they can be shared by both platforms.
---
 src/egl/drivers/dri2/egl_dri2.h |  10 +-
 src/egl/drivers/dri2/platform_wayland.c | 199 +++-
 src/egl/drivers/dri2/platform_x11.c |   6 -
 3 files changed, 179 insertions(+), 36 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 8c303d9..d29dd98 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -174,7 +174,7 @@ struct dri2_egl_surface
struct wl_egl_window  *wl_win;
intdx;
intdy;
-   struct wl_callback*frame_callback;
+   struct wl_callback*throttle_callback;
int   format;
 #endif
 
@@ -194,7 +194,7 @@ struct dri2_egl_surface
 #endif
   int locked;
   int age;
-   } color_buffers[3], *back, *current;
+   } color_buffers[4], *back, *current;
 #endif
 
 #ifdef HAVE_ANDROID_PLATFORM
@@ -220,6 +220,12 @@ struct dri2_egl_image
__DRIimage *dri_image;
 };
 
+/* From xmlpool/options.h, user exposed so should be stable */
+#define DRI_CONF_VBLANK_NEVER 0
+#define DRI_CONF_VBLANK_DEF_INTERVAL_0 1
+#define DRI_CONF_VBLANK_DEF_INTERVAL_1 2
+#define DRI_CONF_VBLANK_ALWAYS_SYNC 3
+
 /* standard typecasts */
 _EGL_DRIVER_STANDARD_TYPECASTS(dri2_egl)
 _EGL_DRIVER_TYPECAST(dri2_egl_image, _EGLImage, obj)
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 5ce8981..fca35db 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "egl_dri2.h"
 
@@ -183,8 +184,16 @@ dri2_create_window_surface(_EGLDriver *drv, _EGLDisplay 
*disp,
   _EGLConfig *conf, EGLNativeWindowType window,
   const EGLint *attrib_list)
 {
-   return dri2_create_surface(drv, disp, EGL_WINDOW_BIT, conf,
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   _EGLSurface *surf;
+
+   surf = dri2_create_surface(drv, disp, EGL_WINDOW_BIT, conf,
  window, attrib_list);
+
+   if (surf != NULL)
+  drv->API.SwapInterval(drv, disp, surf, dri2_dpy->default_swap_interval);
+
+   return surf;
 }
 
 /**
@@ -217,8 +226,8 @@ dri2_destroy_surface(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *surf)
  dri2_dpy->dri2->releaseBuffer(dri2_dpy->dri_screen,
dri2_surf->dri_buffers[i]);
 
-   if (dri2_surf->frame_callback)
-  wl_callback_destroy(dri2_surf->frame_callback);
+   if (dri2_surf->throttle_callback)
+  wl_callback_destroy(dri2_surf->throttle_callback);
 
if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
   dri2_surf->wl_win->private = NULL;
@@ -257,41 +266,99 @@ dri2_release_buffers(struct dri2_egl_surface *dri2_surf)
 }
 
 static int
+poll_compositor(struct dri2_egl_display *dri2_

[PATCH mesa 1/2] wayland: Block for the frame callback in get_back_bo not dri2_swap_buffers

[Neil Roberts]

As per Kristian's suggestion we can avoid the problem of effectively
disabling the event queuing mechanism by only doing the sync request
when the swap interval is zero. To fix the bug of using three buffers
we can just block for the frame callback in get_back_bo instead of
swap_buffers. I was originally a bit reluctant to do this because it
will end up blocking in an unusual place (ie, usually in glClear) but
I suppose that doesn't really matter.

I've split that change out into a separate patch because it is an
independent problem. The new swap interval patch can now share the
callback variable with the frame callback because they are now blocked
for in the same place.

Just to note, in addition to these two patches I think it would be
good to apply these other two patches which are buried in this thread
(although they are not required):

http://lists.freedesktop.org/archives/wayland-devel/2013-October/011766.html
http://lists.freedesktop.org/archives/wayland-devel/2013-September/010967.html

- Neil

--- >8 --- (use git am --scissors to automatically chop here)

Consider a typical game-style main loop which might be like this:

while (1) {
draw_something();
eglSwapBuffers();
}

In this case the game is relying on eglSwapBuffers to throttle to a sensible
frame rate. Previously this game would end up using three buffers even though
it should only need two. This is because Mesa decides whether to allocate a
new buffer in get_back_bo which would be before it has tried to read any
events from the compositor so it wouldn't have seen any buffer release events
yet.

This patch just moves the block for the frame callback to get_back_bo.
Typically the compositor will send a release event immediately after one of
the attaches so if we block for the frame callback here then we can be sure to
have completed at least one roundtrip and received that release event after
attaching the previous buffer before deciding whether to allocate a new one.

dri2_swap_buffers always calls get_back_bo so even if the client doesn't
render anything we will still be sure to block to the frame callback. The code
to create the new frame callback has been moved to after this call so that we
can be sure to have cleared the previous frame callback before requesting a
new one.
---
 src/egl/drivers/dri2/platform_wayland.c | 34 +++--
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index f9065bb..5ce8981 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -263,8 +263,19 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
   dri2_egl_display(dri2_surf->base.Resource.Display);
int i;
 
-   /* There might be a buffer release already queued that wasn't processed */
-   wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, dri2_dpy->wl_queue);
+   if (dri2_surf->frame_callback == NULL) {
+  /* There might be a buffer release already queued that wasn't processed 
*/
+  wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, dri2_dpy->wl_queue);
+   } else {
+  /* We throttle to the frame callback here so that we can be sure to have
+   * received any release events before trying to decide whether to
+   * allocate a new buffer */
+  do {
+ if (wl_display_dispatch_queue(dri2_dpy->wl_dpy,
+   dri2_dpy->wl_queue) == -1)
+return EGL_FALSE;
+  } while (dri2_surf->frame_callback != NULL);
+   }
 
if (dri2_surf->back == NULL) {
   for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
@@ -557,18 +568,7 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
-   int i, ret = 0;
-
-   while (dri2_surf->frame_callback && ret != -1)
-  ret = wl_display_dispatch_queue(dri2_dpy->wl_dpy, dri2_dpy->wl_queue);
-   if (ret < 0)
-  return EGL_FALSE;
-
-   dri2_surf->frame_callback = wl_surface_frame(dri2_surf->wl_win->surface);
-   wl_callback_add_listener(dri2_surf->frame_callback,
-&frame_listener, dri2_surf);
-   wl_proxy_set_queue((struct wl_proxy *) dri2_surf->frame_callback,
-  dri2_dpy->wl_queue);
+   int i;
 
for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++)
   if (dri2_surf->color_buffers[i].age > 0)
@@ -581,6 +581,12 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
   return EGL_FALSE;
}
 
+   dri2_surf->frame_callback = wl_surface_frame(dri2_surf->wl_win->surface);
+   wl_callback_add_listener(dri2_surf->frame_callback,
+&frame_listener, dri2_surf);
+   wl_proxy_set_queue((struct wl_proxy *) dri2_surf->frame_callback,
+  dri2_dpy->wl_queue);
+
dri2_surf->back->age = 1;
dri2_surf->current = dri2_

Re: Globals deletion

[Pekka Paalanen]

On Mon, 21 Oct 2013 11:09:46 +0200
Marek Ch  wrote:

> Hi,
> 
> I have got one question. In documentation of wl_registry's global_remove
> event is:
> 
> "This event notifies the client that the global identified by name is no
> longer available. If the client bound to the global using the bind request,
> the client should now destroy that object.
> The object remains valid and **requests to the object will be ignored until
> the client destroys it** ... ."
> 
> Consider this code (I'll choose wl_seat as a global):
> 
> 
> DISPLAYCLIENT
> \\ create display, globals, etc.. 
>     seat = get
> wl_seat proxy ..
>     \\
> do something
>wl_global_destroy(seat)   
>  
> 
>  
> wl_seat_get_pointer(seat)
>  
> wl_seat_get_touch(seat)
> 
> If I understand the documentation correctly then the
> wl_seat_get_{pointer|touch} should be ignored, because these are requests
> to already deleted object. Or am I missing something?

Correct. However, since wl_seat_get_pointer creates a new protocol
object, and the client might not yet know that the wl_seat global is
gone, a new inert wl_pointer protocol object must be created. Otherwise
any requests the client does on the wl_pointer, like 'release', would
lead to a protocol error and disconnecting the client.

Awkward, but I don't see any other way to deal with requests
creating new objects from an inert object.


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

Re: Wayland integration tests

[Marek Ch]

Hi,

Amed assrs a result of previous mailing I've merged
wayland-integration-tests into wayland. And, with a tear in my eye, renaead
and asswrite xD (actually, I renamed all functions. I removed prefixes).

Here's repo with the first version:
https://github.com/mchalupa/wayland/tree/wits

Regards,
Marek Ch


On 31 October 2013 16:46, Marek Ch  wrote:

> > "assread(...)" and "asswrite(...)" are not clever function names ;-)
>
> I know but I couldn't help myself xD Of course I can change the names.
>
> >
>
> >> This is very similar to what we're trying to do in weston tests/.  Did
> > >you consider just building out the current weston in-tree test suite?
>
> Yes, I did. But I agree with U. Artie that it is slightly different (and
> it should be
> otherwise I failed writing what I intended)
>
> > I think it's a little more "generic", though.   This test suite doesn't
> have dependencies
> > on any particular compositor implementation (except for the internal
> "mock"
> > server and client).  Also, it appears it is completely independent of
> any particular
> > "graphics" layers (??).
>
> Yes, it is completely independent of any compositor except the internal
> one as well as
> of any other layer. The aim of the tests is to test the protocol itself.
>
> > Although it's an integration test suite, it feels like just one step
> beyond "unit"
> > testing for the core wayland protocols (which is not a bad thing).  I
> think this
> > suite would be a nice addition to the current test framework in the
> "wayland"
> > source tree rather than a standalone project.
>
> Actually, I begun to develop these tests in wayland tree but split it off
> later.
> The main reason was that there was complete mess in files (but it can be
> easily solved
> by moving non-test files into subdirectory) and the tests depend only
> on libwayland-{client,server}.so. So there was no need to keep it in
> wayland tree
> at that times and creating standalone project was a great move toward
> readability
> of structure and the code.
>
> > Adding it to the wayland tree
> > would certainly encourage developers and testers to adopt and use it more
> > and provide a nice framework for "generic" client<->server protocol
> testing.
>
> Yes, this definitely would be a huge advantage.
>
>
> > Would you be willing to entertain the idea of adding it to wayland?
>
> Sure, since it has only pros (contributors, access to wayland-private.h
> and so on)
> I think it would be good.
>
> Thanks,
> Marek Ch
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Add [core] backend option

[Lubomir Rintel]

This allows specifying a particular backend to load in a manner similar to
modules.

Signed-off-by: Lubomir Rintel 
---
 man/weston.ini.man | 17 +
 src/compositor.c   | 24 +++-
 2 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/man/weston.ini.man b/man/weston.ini.man
index ecb7ebb..4ff313d 100644
--- a/man/weston.ini.man
+++ b/man/weston.ini.man
@@ -105,6 +105,23 @@ directory are:
 .fi
 .RE
 .TP 7
+.TP 7
+.BI "backend=" headless-backend.so
+overrides defaults backend. Available backend modules in the
+.IR "__weston_modules_dir__"
+directory are:
+.PP
+.RS 10
+.nf
+.BR drm-backend.so
+.BR fbdev-backend.so
+.BR headless-backend.so
+.BR rdp-backend.so
+.BR rpi-backend.so
+.BR wayland-backend.so
+.BR x11-backend.so
+.fi
+.RE
 .BI "gbm-format="format
 sets the GBM format used for the framebuffer for the GBM backend. Can be
 .B xrgb,
diff --git a/src/compositor.c b/src/compositor.c
index c6cf682..52fd67e 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3757,6 +3757,7 @@ int main(int argc, char *argv[])
 struct weston_config *config);
int i;
char *backend = NULL;
+   char *option_backend = NULL;
char *shell = NULL;
char *modules, *option_modules = NULL;
char *log = NULL;
@@ -3768,7 +3769,7 @@ int main(int argc, char *argv[])
struct weston_config_section *section;
 
const struct weston_option core_options[] = {
-   { WESTON_OPTION_STRING, "backend", 'B', &backend },
+   { WESTON_OPTION_STRING, "backend", 'B', &option_backend },
{ WESTON_OPTION_STRING, "shell", 0, &shell },
{ WESTON_OPTION_STRING, "socket", 'S', &socket_name },
{ WESTON_OPTION_INTEGER, "idle-time", 'i', &idle_time },
@@ -3814,6 +3815,19 @@ int main(int argc, char *argv[])
signals[3] = wl_event_loop_add_signal(loop, SIGCHLD, sigchld_handler,
  NULL);
 
+   config = weston_config_parse("weston.ini");
+   if (config != NULL) {
+   weston_log("Using config file '%s'\n",
+  weston_config_get_full_path(config));
+   } else {
+   weston_log("Starting with no config file.\n");
+   }
+   section = weston_config_get_section(config, "core", NULL, NULL);
+
+   weston_config_section_get_string(section, "backend", &backend, NULL);
+   if (option_backend) {
+   backend = option_backend;
+   }
if (!backend) {
if (getenv("WAYLAND_DISPLAY"))
backend = "wayland-backend.so";
@@ -3823,14 +3837,6 @@ int main(int argc, char *argv[])
backend = WESTON_NATIVE_BACKEND;
}
 
-   config = weston_config_parse("weston.ini");
-   if (config != NULL) {
-   weston_log("Using config file '%s'\n",
-  weston_config_get_full_path(config));
-   } else {
-   weston_log("Starting with no config file.\n");
-   }
-   section = weston_config_get_section(config, "core", NULL, NULL);
weston_config_section_get_string(section, "modules", &modules, "");
 
backend_init = weston_load_module(backend, "backend_init");
-- 
1.8.4.2

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

[PATCH 3/3] shm: Avoid file descriptor leak upon unsuccessful mmap

[Lubomir Rintel]

It would be possible to make the compositor leak file descriptors by
passing descriptors of open unmmapable files to it, such as /dev/null.

Signed-off-by: Lubomir Rintel 
---
 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 ad92dba..0bae6da 100644
--- a/src/wayland-shm.c
+++ b/src/wayland-shm.c
@@ -248,7 +248,7 @@ shm_create_pool(struct wl_client *client, struct 
wl_resource *resource,
wl_resource_post_error(resource,
   WL_SHM_ERROR_INVALID_FD,
   "failed mmap fd %d", fd);
-   goto err_free;
+   goto err_close;
}
close(fd);
 
-- 
1.8.4.2

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

[PATCH 1/3] connection: Only read file descriptor if it was actually received

[Lubomir Rintel]

Otherwise the tail of fds_in buffer would just shift beyond the beginning.
That confuses the actual request handler and results in a crash further on
due to corrupted tail.

Signal the lack of file descriptor with -1, so that the request handler
can determine that no valid file descriptor was received via anciliary
data.

Signed-off-by: Lubomir Rintel 
---
 src/connection.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/connection.c b/src/connection.c
index 451b93e..48a5398 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -605,7 +605,7 @@ wl_connection_demarshal(struct wl_connection *connection,
const struct wl_message *message)
 {
uint32_t *p, *next, *end, length, id;
-   int fd;
+   int fd = -1;
char *s;
unsigned int i, count, num_arrays;
const char *signature;
@@ -744,8 +744,10 @@ wl_connection_demarshal(struct wl_connection *connection,
p = next;
break;
case 'h':
-   wl_buffer_copy(&connection->fds_in, &fd, sizeof fd);
-   connection->fds_in.tail += sizeof fd;
+   if (connection->fds_in.tail != connection->fds_in.head) 
{
+   wl_buffer_copy(&connection->fds_in, &fd, sizeof 
fd);
+   connection->fds_in.tail += sizeof fd;
+   }
closure->args[i].h = fd;
break;
default:
-- 
1.8.4.2

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

[PATCH 2/3] shm: Do not attempt mmap if no file descriptor was received

[Lubomir Rintel]

This is just for the sake of  cleanliness and correct error handling.
Without this the mmap would fail emitting an error message about failed
mapping to the client and a close of bogus file descriptor would be
attempted, which is harmless since it can not fail.

Signed-off-by: Lubomir Rintel 
---
 src/wayland-shm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/wayland-shm.c b/src/wayland-shm.c
index 28f52f4..ad92dba 100644
--- a/src/wayland-shm.c
+++ b/src/wayland-shm.c
@@ -220,6 +220,13 @@ shm_create_pool(struct wl_client *client, struct 
wl_resource *resource,
 {
struct wl_shm_pool *pool;
 
+   if (fd < 0) {
+   wl_resource_post_error(resource,
+  WL_SHM_ERROR_INVALID_FD,
+  "file descriptor expected");
+   return;
+   }
+
pool = malloc(sizeof *pool);
if (pool == NULL) {
wl_client_post_no_memory(client);
-- 
1.8.4.2

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

Re: Thoughts about decoration information in the xdg_shell

[Martin Graesslin]

On Friday 15 November 2013 07:50:55 Jasper St. Pierre wrote:
> Ah, whoops, I read your email wrong. It sounds like you're also in favor of
> requiring CSD support from the client.
Yep, I'm fine with ensuring that CSD is the required fallback. As said: I don't 
want to force anybody to SSD :-)
> 
> That said, I'm curious about cases like Nautilus under SSD. Should we hide
> the close button, or do anything like that to make it adapt to an SSD
> environment?
I think that depends on whether the Nautilus developers want to have it 
integrate in other desktop shells than GNOME Shell. If you consider Nautilus 
to be a GNOME Shell only solution, then it certainly is not needed to adjust. 
If you on the other hand want to have Nautilus for as many users as possible I 
would recommend to adjust to the environment and remove the custom close 
button. After all it would be quite out of place in an environment where no 
other window has a close button like that. In an environment like Plasma 
Active it would certainly break the intended work flow to have such a button. 
Also for tiling concepts I would say it's better to hide. Also from experience 
I can tell that at least our users care about having windows behave the same 
way.

Cheers
Martin
> 
> On Fri, Nov 15, 2013 at 7:14 AM, Jasper St. Pierre 
wrote:
> > On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin wrote:
> >> Hi all,
> >> 
> >> this is a reply to the topic of whether to have information about
> >> decorations
> >> in the xdg_shell at all (see [1]). Sorry that I don't reply to the right
> >> message, had not been subscribed to the list.
> >> 
> >> I want to outline why we in the KDE Plasma team would prefer to have the
> >> possibility to tell clients whether to draw decorations or not. In Plasma
> >> we
> >> have multiple shells and will be able to switch at runtime. From the
> >> window
> >> manager perspective the main difference is currently the handling of
> >> window
> >> decorations. Our touch oriented shell doesn't have decorated windows, our
> >> netbook shell only has decorated windows for dialogs and our desktop
> >> shell has
> >> a typical window decorated style, but not enforcing SSD (there are valid
> >> use
> >> cases like yakuake).
> >> 
> >> This gives us quite some flexibility to adjust at runtime (add keyboard
> >> to
> >> tablet to get a desktop). An application doesn't need to know what the
> >> shell
> >> currently looks like. The shell takes care of handling all of that.
> >> 
> >> If we don't have information about whether the window should be decorated
> >> or
> >> not in the xdg_shell we would need to adjust all applications to know
> >> about
> >> our various shells. Otherwise a consistent user experience would not be
> >> possible. Also it removes all possibilities to take this further in the
> >> future.
> >> 
> >> Now I don't want to force SSD to anybody nor do I want to be forced to
> >> CSD.
> >> Therefore I want to have a very simple spec, which allows the compositor
> >> to
> >> tell the clients whether they are expected to render decos themselves
> >> (enforce
> >> CSD, e.g. GNOME Shell), whether the compositor doesn't care, but prefer
> >> them
> >> to not render themselves (e.g. Plasma Desktop case) or whether the
> >> compositor
> >> wants the client to not render any handles at all (enforce SSD, Plasma
> >> Active
> >> case).
> >> 
> >> In addition the client should tell the compositor whether it draws
> >> handles or
> >> not. So that the SSD-supporting compositor doesn't add a decoration
> >> around a
> >> CSD client.
> >> 
> >> I think this would be a good solution. It would require clients to
> >> support
> >> CSD, but also to not render them in shells, which prefer to not have
> >> them.
> >> Also it doesn't force CSD applications to support it. They could just
> >> announce
> >> that they do CSD no matter what.
> >> 
> >> Opinions? Would that be acceptable for everybody?
> > 
> > I think the trap that I personally don't want to run into is the case
> > where we have a compositor that doesn't support SSD coupled to a client
> > that doesn't support CSD. Nobody can draw the decorations, and at this
> > point we've engineered the user into a corner.
> > 
> > For me, the debate about window decorations and Wayland is that we need
> > *something* to be mandated to be supported. GNOME wants that to be CSD,
> > and
> > KDE wants that to be SSD.
> > 
> > From the GNOME side, we're heavily using CSD features in our apps [0]
> > (such that we'd probably even ignore the Wayland hint to ignore CSD,
> > actually), and SSD code in mutter is a large pile of code I would not like
> > to maintain, as it's quite complicated, so it's natural for us to want to
> > encourage CSD.
> > 
> > I also think that CSD has technical advantages for complex server effects:
> > if we simply paint surfaces around the window, if we put the window into
> > e.g. Coverflow Alt-Tab, we won't see seams around the window. (And
> > personally, I'm of the

Re: Thoughts about decoration information in the xdg_shell

[Jasper St. Pierre]

On Fri, Nov 15, 2013 at 8:07 AM, Alex Elsayed  wrote:

> Jasper St. Pierre wrote:
>
> > On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin
> >  wrote:
> >
> 
> >
> > I think the trap that I personally don't want to run into is the case
> > where we have a compositor that doesn't support SSD coupled to a client
> > that doesn't support CSD. Nobody can draw the decorations, and at this
> > point we've engineered the user into a corner.
> >
> > For me, the debate about window decorations and Wayland is that we need
> > *something* to be mandated to be supported. GNOME wants that to be CSD,
> > and KDE wants that to be SSD.
>
> From Martin's message: "It would require clients to support CSD"
>

Yeah, I read his message wrong. I thought he was saying that requiring CSD
was a bad idea, and his proposal was a negotiation mechanism where we
support either.


> What he's advocating is that, yes, everything must include _support_ for
> CSD. But enabling it at _runtime_ should not be mandatory.
>
> > From the GNOME side, we're heavily using CSD features in our apps [0]
> > (such that we'd probably even ignore the Wayland hint to ignore CSD,
> > actually), and SSD code in mutter is a large pile of code I would not
> like
> > to maintain, as it's quite complicated, so it's natural for us to want to
> > encourage CSD.
>
> And his proposal explicitly allows that. All it is is a communication
> channel; the compositor politely requesting "I'd prefer [not] to draw the
> decorations for you" and the application saying "I am [not] drawing my own
> decorations."
>
> Without this, the two sides have no clean way to communicate that
> information, and to do so requires ad-hoc, hackish attempts to support it
> at
> a layer that support does not belong in. With it, at least the left hand
> and
> right hand can tell what the other is doing.
>
> > I also think that CSD has technical advantages for complex server
> effects:
> > if we simply paint surfaces around the window, if we put the window into
> > e.g. Coverflow Alt-Tab, we won't see seams around the window. (And
> > personally, I'm of the opinion that any design changes you'd need to make
> > to apps to make them usable on a touch device vs. regular device stem far
> > beyond the window decorations they use in the end.)
>
> As far as design changes between the devices, those are smaller than you
> might think (especially with Qt Quick 2 and the work going on with that;
> see
> [1] and [2])
>
> > I'm fine with a hint telling apps to not draw decorations, but I'd like
> to
> > mandate that CSD is supported by everything.
>
> As I noted, Martin's mail said the same thing.
>
> > [0]
> http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png
> Link is a 404.
>

Yeah, this links to our live continuous integration server, and if it's
re-running the applications test, the URL can point to an unfinished
result. Here's a recent build that completed this morning:

http://build.gnome.org/ostree/buildmaster/builds/20131115.17/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png

[1]
> http://aseigo.blogspot.com/2012/10/one-code-base-multiple-form-factors.html
> [2]
> http://www.notmart.org/index.php/Software/Components_towards_a_new_plasma
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



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

Re: Thoughts about decoration information in the xdg_shell

[Alex Elsayed]

Jasper St. Pierre wrote:

> On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin
>  wrote:
> 

> 
> I think the trap that I personally don't want to run into is the case
> where we have a compositor that doesn't support SSD coupled to a client
> that doesn't support CSD. Nobody can draw the decorations, and at this
> point we've engineered the user into a corner.
>
> For me, the debate about window decorations and Wayland is that we need
> *something* to be mandated to be supported. GNOME wants that to be CSD,
> and KDE wants that to be SSD.

From Martin's message: "It would require clients to support CSD"

What he's advocating is that, yes, everything must include _support_ for
CSD. But enabling it at _runtime_ should not be mandatory.
 
> From the GNOME side, we're heavily using CSD features in our apps [0]
> (such that we'd probably even ignore the Wayland hint to ignore CSD,
> actually), and SSD code in mutter is a large pile of code I would not like
> to maintain, as it's quite complicated, so it's natural for us to want to
> encourage CSD.

And his proposal explicitly allows that. All it is is a communication
channel; the compositor politely requesting "I'd prefer [not] to draw the
decorations for you" and the application saying "I am [not] drawing my own
decorations."

Without this, the two sides have no clean way to communicate that
information, and to do so requires ad-hoc, hackish attempts to support it at
a layer that support does not belong in. With it, at least the left hand and
right hand can tell what the other is doing.

> I also think that CSD has technical advantages for complex server effects:
> if we simply paint surfaces around the window, if we put the window into
> e.g. Coverflow Alt-Tab, we won't see seams around the window. (And
> personally, I'm of the opinion that any design changes you'd need to make
> to apps to make them usable on a touch device vs. regular device stem far
> beyond the window decorations they use in the end.)

As far as design changes between the devices, those are smaller than you
might think (especially with Qt Quick 2 and the work going on with that; see
[1] and [2])

> I'm fine with a hint telling apps to not draw decorations, but I'd like to
> mandate that CSD is supported by everything.

As I noted, Martin's mail said the same thing.

> [0] 
> http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png
Link is a 404.

[1] http://aseigo.blogspot.com/2012/10/one-code-base-multiple-form-factors.html
[2] http://www.notmart.org/index.php/Software/Components_towards_a_new_plasma

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

Re: [PATCH xwayland 2/3] Check for frame being NULL before setting/unsetting flags

[Axel Davy]

I've posted a patch, which prevents wm->focus_window to be a window 
without frame.


This solves the same bug than this patch, but looks better to me.

http://lists.freedesktop.org/archives/wayland-devel/2013-November/012008.html

Axel Davy

Le 15/11/2013 11:25, Axel Davy a écrit :

This patch (Again, I had the same), solves the last bugs for XWayland,
but for this one, I'm not sure it is the correct fix.

In fact it would mean than focus_window would be an unmapped windows,
which looks strange to me.

Axel Davy

Le 15/11/2013 11:01, Dima Ryazanov a écrit :

Fixes a crash in Firefox when clicking an "install plugin" popup.

Signed-off-by: Dima Ryazanov 
---
  src/xwayland/window-manager.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c 
b/src/xwayland/window-manager.c

index 5ee9480..6d29026 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -695,12 +695,14 @@ weston_wm_window_activate(struct wl_listener 
*listener, void *data)

  }
if (wm->focus_window) {
-frame_unset_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+if (wm->focus_window->frame)
+frame_unset_flag(wm->focus_window->frame, 
FRAME_FLAG_ACTIVE);

weston_wm_window_schedule_repaint(wm->focus_window);
  }
  wm->focus_window = window;
  if (wm->focus_window) {
-frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+if (wm->focus_window->frame)
+frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm->focus_window);
  }
  }


___
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] XWayland: do not set wm->focus_window to a window with no frame

[Axel Davy]

An unmapped window shouldn't be the input focus.
This solves some remaining Weston crashes with XWayland,
because we assume wm->focus_window has a frame.

Signed-off-by: Axel Davy 
---
 src/xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 7783d2c..70244ab 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -671,6 +671,8 @@ weston_wm_window_activate(struct wl_listener *listener, 
void *data)
 
if (surface) {
window = get_wm_window(surface);
+   if (window && !window->frame)
+   window = NULL;
}
 
if (window) {
-- 
1.8.1.2

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

Re: [PATCH weston 3/8] westoy: Use subsurfaces for tooltips instead of transient windows

[Daniel Stone]

Hi,

On 14 November 2013 20:47, Bill Spitzak  wrote:
> Jasper St. Pierre wrote:
>> Transients, as they existed in wl_shell_surface, have been removed from
>> xdg_shell and aren't coming back. There is a new set_transient_for request,
>> but it's more to provide something like the ICCCM WM_TRANSIENT_FOR property:
>> associating modal dialogs with their "parent window".
>
> My main concern is that this not be screwed up in Wayland. Gregory Merchan
> is also trying to get this to not be screwed up. The client MUST be in
> charge of window stacking and whether a window is mapped or not.

I think it's fair to say you've made your point now.

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

Re: Thoughts about decoration information in the xdg_shell

[Jasper St. Pierre]

Ah, whoops, I read your email wrong. It sounds like you're also in favor of
requiring CSD support from the client.

That said, I'm curious about cases like Nautilus under SSD. Should we hide
the close button, or do anything like that to make it adapt to an SSD
environment?

On Fri, Nov 15, 2013 at 7:14 AM, Jasper St. Pierre wrote:

> On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin wrote:
>
>> Hi all,
>>
>> this is a reply to the topic of whether to have information about
>> decorations
>> in the xdg_shell at all (see [1]). Sorry that I don't reply to the right
>> message, had not been subscribed to the list.
>>
>> I want to outline why we in the KDE Plasma team would prefer to have the
>> possibility to tell clients whether to draw decorations or not. In Plasma
>> we
>> have multiple shells and will be able to switch at runtime. From the
>> window
>> manager perspective the main difference is currently the handling of
>> window
>> decorations. Our touch oriented shell doesn't have decorated windows, our
>> netbook shell only has decorated windows for dialogs and our desktop
>> shell has
>> a typical window decorated style, but not enforcing SSD (there are valid
>> use
>> cases like yakuake).
>>
>> This gives us quite some flexibility to adjust at runtime (add keyboard to
>> tablet to get a desktop). An application doesn't need to know what the
>> shell
>> currently looks like. The shell takes care of handling all of that.
>>
>> If we don't have information about whether the window should be decorated
>> or
>> not in the xdg_shell we would need to adjust all applications to know
>> about
>> our various shells. Otherwise a consistent user experience would not be
>> possible. Also it removes all possibilities to take this further in the
>> future.
>>
>> Now I don't want to force SSD to anybody nor do I want to be forced to
>> CSD.
>> Therefore I want to have a very simple spec, which allows the compositor
>> to
>> tell the clients whether they are expected to render decos themselves
>> (enforce
>> CSD, e.g. GNOME Shell), whether the compositor doesn't care, but prefer
>> them
>> to not render themselves (e.g. Plasma Desktop case) or whether the
>> compositor
>> wants the client to not render any handles at all (enforce SSD, Plasma
>> Active
>> case).
>>
>> In addition the client should tell the compositor whether it draws
>> handles or
>> not. So that the SSD-supporting compositor doesn't add a decoration
>> around a
>> CSD client.
>>
>> I think this would be a good solution. It would require clients to support
>> CSD, but also to not render them in shells, which prefer to not have them.
>> Also it doesn't force CSD applications to support it. They could just
>> announce
>> that they do CSD no matter what.
>>
>> Opinions? Would that be acceptable for everybody?
>>
>
> I think the trap that I personally don't want to run into is the case
> where we have a compositor that doesn't support SSD coupled to a client
> that doesn't support CSD. Nobody can draw the decorations, and at this
> point we've engineered the user into a corner.
>
> For me, the debate about window decorations and Wayland is that we need
> *something* to be mandated to be supported. GNOME wants that to be CSD, and
> KDE wants that to be SSD.
>
> From the GNOME side, we're heavily using CSD features in our apps [0]
> (such that we'd probably even ignore the Wayland hint to ignore CSD,
> actually), and SSD code in mutter is a large pile of code I would not like
> to maintain, as it's quite complicated, so it's natural for us to want to
> encourage CSD.
>
> I also think that CSD has technical advantages for complex server effects:
> if we simply paint surfaces around the window, if we put the window into
> e.g. Coverflow Alt-Tab, we won't see seams around the window. (And
> personally, I'm of the opinion that any design changes you'd need to make
> to apps to make them usable on a touch device vs. regular device stem far
> beyond the window decorations they use in the end.)
>
> I'm fine with a hint telling apps to not draw decorations, but I'd like to
> mandate that CSD is supported by everything.
>
> [0]
> http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png
>
> Cheers
>> Martin Gräßlin
>>
>> [1]
>> http://lists.freedesktop.org/archives/wayland-devel/2013-November/011980.html
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>
>
> --
>   Jasper
>



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

Re: Thoughts about decoration information in the xdg_shell

[Jasper St. Pierre]

On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin  wrote:

> Hi all,
>
> this is a reply to the topic of whether to have information about
> decorations
> in the xdg_shell at all (see [1]). Sorry that I don't reply to the right
> message, had not been subscribed to the list.
>
> I want to outline why we in the KDE Plasma team would prefer to have the
> possibility to tell clients whether to draw decorations or not. In Plasma
> we
> have multiple shells and will be able to switch at runtime. From the window
> manager perspective the main difference is currently the handling of window
> decorations. Our touch oriented shell doesn't have decorated windows, our
> netbook shell only has decorated windows for dialogs and our desktop shell
> has
> a typical window decorated style, but not enforcing SSD (there are valid
> use
> cases like yakuake).
>
> This gives us quite some flexibility to adjust at runtime (add keyboard to
> tablet to get a desktop). An application doesn't need to know what the
> shell
> currently looks like. The shell takes care of handling all of that.
>
> If we don't have information about whether the window should be decorated
> or
> not in the xdg_shell we would need to adjust all applications to know about
> our various shells. Otherwise a consistent user experience would not be
> possible. Also it removes all possibilities to take this further in the
> future.
>
> Now I don't want to force SSD to anybody nor do I want to be forced to CSD.
> Therefore I want to have a very simple spec, which allows the compositor to
> tell the clients whether they are expected to render decos themselves
> (enforce
> CSD, e.g. GNOME Shell), whether the compositor doesn't care, but prefer
> them
> to not render themselves (e.g. Plasma Desktop case) or whether the
> compositor
> wants the client to not render any handles at all (enforce SSD, Plasma
> Active
> case).
>
> In addition the client should tell the compositor whether it draws handles
> or
> not. So that the SSD-supporting compositor doesn't add a decoration around
> a
> CSD client.
>
> I think this would be a good solution. It would require clients to support
> CSD, but also to not render them in shells, which prefer to not have them.
> Also it doesn't force CSD applications to support it. They could just
> announce
> that they do CSD no matter what.
>
> Opinions? Would that be acceptable for everybody?
>

I think the trap that I personally don't want to run into is the case where
we have a compositor that doesn't support SSD coupled to a client that
doesn't support CSD. Nobody can draw the decorations, and at this point
we've engineered the user into a corner.

For me, the debate about window decorations and Wayland is that we need
*something* to be mandated to be supported. GNOME wants that to be CSD, and
KDE wants that to be SSD.

>From the GNOME side, we're heavily using CSD features in our apps [0] (such
that we'd probably even ignore the Wayland hint to ignore CSD, actually),
and SSD code in mutter is a large pile of code I would not like to
maintain, as it's quite complicated, so it's natural for us to want to
encourage CSD.

I also think that CSD has technical advantages for complex server effects:
if we simply paint surfaces around the window, if we put the window into
e.g. Coverflow Alt-Tab, we won't see seams around the window. (And
personally, I'm of the opinion that any design changes you'd need to make
to apps to make them usable on a touch device vs. regular device stem far
beyond the window decorations they use in the end.)

I'm fine with a hint telling apps to not draw decorations, but I'd like to
mandate that CSD is supported by everything.

[0]
http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png

Cheers
> Martin Gräßlin
>
> [1]
> http://lists.freedesktop.org/archives/wayland-devel/2013-November/011980.html
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


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

Thoughts about decoration information in the xdg_shell

[Martin Gräßlin]

Hi all,

this is a reply to the topic of whether to have information about decorations 
in the xdg_shell at all (see [1]). Sorry that I don't reply to the right 
message, had not been subscribed to the list.

I want to outline why we in the KDE Plasma team would prefer to have the 
possibility to tell clients whether to draw decorations or not. In Plasma we 
have multiple shells and will be able to switch at runtime. From the window 
manager perspective the main difference is currently the handling of window 
decorations. Our touch oriented shell doesn't have decorated windows, our 
netbook shell only has decorated windows for dialogs and our desktop shell has 
a typical window decorated style, but not enforcing SSD (there are valid use 
cases like yakuake).

This gives us quite some flexibility to adjust at runtime (add keyboard to 
tablet to get a desktop). An application doesn't need to know what the shell 
currently looks like. The shell takes care of handling all of that.

If we don't have information about whether the window should be decorated or 
not in the xdg_shell we would need to adjust all applications to know about 
our various shells. Otherwise a consistent user experience would not be 
possible. Also it removes all possibilities to take this further in the 
future.

Now I don't want to force SSD to anybody nor do I want to be forced to CSD. 
Therefore I want to have a very simple spec, which allows the compositor to 
tell the clients whether they are expected to render decos themselves (enforce 
CSD, e.g. GNOME Shell), whether the compositor doesn't care, but prefer them 
to not render themselves (e.g. Plasma Desktop case) or whether the compositor 
wants the client to not render any handles at all (enforce SSD, Plasma Active 
case).

In addition the client should tell the compositor whether it draws handles or 
not. So that the SSD-supporting compositor doesn't add a decoration around a 
CSD client.

I think this would be a good solution. It would require clients to support 
CSD, but also to not render them in shells, which prefer to not have them. 
Also it doesn't force CSD applications to support it. They could just announce 
that they do CSD no matter what.

Opinions? Would that be acceptable for everybody?

Cheers
Martin Gräßlin

[1] 
http://lists.freedesktop.org/archives/wayland-devel/2013-November/011980.html


signature.asc
Description: This is a digitally signed message part.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland 2/3] Check for frame being NULL before setting/unsetting flags

[Axel Davy]

This patch (Again, I had the same), solves the last bugs for XWayland,
but for this one, I'm not sure it is the correct fix.

In fact it would mean than focus_window would be an unmapped windows,
which looks strange to me.

Axel Davy

Le 15/11/2013 11:01, Dima Ryazanov a écrit :

Fixes a crash in Firefox when clicking an "install plugin" popup.

Signed-off-by: Dima Ryazanov 
---
  src/xwayland/window-manager.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 5ee9480..6d29026 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -695,12 +695,14 @@ weston_wm_window_activate(struct wl_listener *listener, 
void *data)
}
  
  	if (wm->focus_window) {

-   frame_unset_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+   if (wm->focus_window->frame)
+   frame_unset_flag(wm->focus_window->frame, 
FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm->focus_window);
}
wm->focus_window = window;
if (wm->focus_window) {
-   frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+   if (wm->focus_window->frame)
+   frame_set_flag(wm->focus_window->frame, 
FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm->focus_window);
}
  }


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

Re: [PATCH xwayland 3/3] Check if the frame exists before reading its size

[Axel Davy]

You were faster than me!

I was just about sending this very same patch.

The patch is correct as I was explaining in my commit message:
"XWayland: Don't access the frame field for unmapped windows.

There are situations where weston_wm_window_get_frame_size
and weston_wm_window_get_child_position are called on
an unmapped window.
In these cases, the decorations are not yet drawn,
so we must behave as if there was no decoration.
"

Correct the commit message ("I don't know if this correct" shouldn't be in),
and this is
Reviewed-by: Axel Davy 


Axel Davy

On 15/11/2013 , Dima Ryazanov wrote :

This fixes crashes caused by popup windows that don't have override_redirect
(e.g., menus in VLC and KDE apps), though I don't know if this is correct.

Signed-off-by: Dima Ryazanov 
---
  src/xwayland/window-manager.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 6d29026..eea0349 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -497,7 +497,7 @@ weston_wm_window_get_frame_size(struct weston_wm_window 
*window,
if (window->fullscreen) {
*width = window->width;
*height = window->height;
-   } else if (window->decorate) {
+   } else if (window->decorate && window->frame) {
*width = frame_width(window->frame);
*height = frame_height(window->frame);
} else {
@@ -515,7 +515,7 @@ weston_wm_window_get_child_position(struct weston_wm_window 
*window,
if (window->fullscreen) {
*x = 0;
*y = 0;
-   } else if (window->decorate) {
+   } else if (window->decorate && window->frame) {
frame_interior(window->frame, x, y, NULL, NULL);
} else {
*x = t->margin;


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

Re: [PATCH xwayland] Set the view to NULL when unmapping an X11 window

[Axel Davy]

I've looked deeply in the code to find the remaining xwayland bugs.

I'll publish later a fix for these. The remaining bugs are due to 
accessing to the frame field on

unmapped windows.

Your patch solves all the issues with the view field.

Your patch is tested and
Reviewed-by: Axel Davy 

Axel Davy
Le 15/11/2013 09:44, Axel Davy a écrit :
I have tested your patch, but it doesn't solve all the bugs occuring 
in XWayland because of views (take vlc, go to the menu, crash).


It appears ok to me to set view to NULL at these locations, but 
there's probably something more to do.


Axel Davy

On 15/11/2013, Dima Ryazanov wrote :

Ping :)


On Fri, Nov 1, 2013 at 12:46 AM, Dima Ryazanov > wrote:


Fixes a crash caused by accessing a deleted view in
weston_wm_window_schedule_repaint. It can be easily reproduced by
switching between menus in Firefox.

Signed-off-by: Dima Ryazanov mailto:d...@gmail.com>>
---
 src/xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/xwayland/window-manager.c
b/src/xwayland/window-manager.c
index b2776a0..5ee9480 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct
weston_wm *wm, xcb_generic_event_t *event)
wl_list_remove(&window->surface_destroy_listener.link);
window->surface = NULL;
window->shsurf = NULL;
+   window->view = NULL;
xcb_unmap_window(wm->conn, window->frame_id);
 }

@@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener
*listener, void *data)
Don't try to use it later. */
window->shsurf = NULL;
window->surface = NULL;
+   window->view = NULL;
 }

 static struct weston_wm_window *
--
1.8.3.2




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




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


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

[PATCH xwayland 2/3] Check for frame being NULL before setting/unsetting flags

[Dima Ryazanov]

Fixes a crash in Firefox when clicking an "install plugin" popup.

Signed-off-by: Dima Ryazanov 
---
 src/xwayland/window-manager.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 5ee9480..6d29026 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -695,12 +695,14 @@ weston_wm_window_activate(struct wl_listener *listener, 
void *data)
}
 
if (wm->focus_window) {
-   frame_unset_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+   if (wm->focus_window->frame)
+   frame_unset_flag(wm->focus_window->frame, 
FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm->focus_window);
}
wm->focus_window = window;
if (wm->focus_window) {
-   frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+   if (wm->focus_window->frame)
+   frame_set_flag(wm->focus_window->frame, 
FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm->focus_window);
}
 }
-- 
1.8.3.2

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

[PATCH xwayland 1/3] Set the view to NULL when unmapping an X11 window

[Dima Ryazanov]

Fixes a crash caused by accessing a deleted view in 
weston_wm_window_schedule_repaint. It can be easily reproduced by switching 
between menus in Firefox.

Signed-off-by: Dima Ryazanov 
---
 src/xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index b2776a0..5ee9480 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct weston_wm *wm, 
xcb_generic_event_t *event)
wl_list_remove(&window->surface_destroy_listener.link);
window->surface = NULL;
window->shsurf = NULL;
+   window->view = NULL;
xcb_unmap_window(wm->conn, window->frame_id);
 }
 
@@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener *listener, void *data)
Don't try to use it later. */
window->shsurf = NULL;
window->surface = NULL;
+   window->view = NULL;
 }
 
 static struct weston_wm_window *
-- 
1.8.3.2

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

[PATCH xwayland 3/3] Check if the frame exists before reading its size

[Dima Ryazanov]

This fixes crashes caused by popup windows that don't have override_redirect
(e.g., menus in VLC and KDE apps), though I don't know if this is correct.

Signed-off-by: Dima Ryazanov 
---
 src/xwayland/window-manager.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 6d29026..eea0349 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -497,7 +497,7 @@ weston_wm_window_get_frame_size(struct weston_wm_window 
*window,
if (window->fullscreen) {
*width = window->width;
*height = window->height;
-   } else if (window->decorate) {
+   } else if (window->decorate && window->frame) {
*width = frame_width(window->frame);
*height = frame_height(window->frame);
} else {
@@ -515,7 +515,7 @@ weston_wm_window_get_child_position(struct weston_wm_window 
*window,
if (window->fullscreen) {
*x = 0;
*y = 0;
-   } else if (window->decorate) {
+   } else if (window->decorate && window->frame) {
frame_interior(window->frame, x, y, NULL, NULL);
} else {
*x = t->margin;
-- 
1.8.3.2

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

Re: [PATCH xwayland] Set the view to NULL when unmapping an X11 window

[Dima Ryazanov]

Oh interesting... I can fix the crash by checking for a NULL pointer,
though I don't know if that's the proper fix. Anyways, I'll send out the
new patches.


On Fri, Nov 15, 2013 at 12:44 AM, Axel Davy  wrote:

>  I have tested your patch, but it doesn't solve all the bugs occuring in
> XWayland because of views (take vlc, go to the menu, crash).
>
> It appears ok to me to set view to NULL at these locations, but there's
> probably something more to do.
>
> Axel Davy
>
> On 15/11/2013, Dima Ryazanov wrote :
>
> Ping :)
>
>
> On Fri, Nov 1, 2013 at 12:46 AM, Dima Ryazanov  wrote:
>
>> Fixes a crash caused by accessing a deleted view in
>> weston_wm_window_schedule_repaint. It can be easily reproduced by switching
>> between menus in Firefox.
>>
>> Signed-off-by: Dima Ryazanov 
>> ---
>>  src/xwayland/window-manager.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
>> index b2776a0..5ee9480 100644
>> --- a/src/xwayland/window-manager.c
>> +++ b/src/xwayland/window-manager.c
>> @@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct weston_wm *wm,
>> xcb_generic_event_t *event)
>> wl_list_remove(&window->surface_destroy_listener.link);
>> window->surface = NULL;
>> window->shsurf = NULL;
>> +   window->view = NULL;
>> xcb_unmap_window(wm->conn, window->frame_id);
>>  }
>>
>> @@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener *listener, void
>> *data)
>> Don't try to use it later. */
>> window->shsurf = NULL;
>> window->surface = NULL;
>> +   window->view = NULL;
>>  }
>>
>>  static struct weston_wm_window *
>> --
>> 1.8.3.2
>>
>>
>
>
> ___
> wayland-devel mailing 
> listwayland-devel@lists.freedesktop.orghttp://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 xwayland] Set the view to NULL when unmapping an X11 window

[Axel Davy]

I have tested your patch, but it doesn't solve all the bugs occuring in 
XWayland because of views (take vlc, go to the menu, crash).


It appears ok to me to set view to NULL at these locations, but there's 
probably something more to do.


Axel Davy

On 15/11/2013, Dima Ryazanov wrote :

Ping :)


On Fri, Nov 1, 2013 at 12:46 AM, Dima Ryazanov > wrote:


Fixes a crash caused by accessing a deleted view in
weston_wm_window_schedule_repaint. It can be easily reproduced by
switching between menus in Firefox.

Signed-off-by: Dima Ryazanov mailto:d...@gmail.com>>
---
 src/xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/xwayland/window-manager.c
b/src/xwayland/window-manager.c
index b2776a0..5ee9480 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct weston_wm
*wm, xcb_generic_event_t *event)
wl_list_remove(&window->surface_destroy_listener.link);
window->surface = NULL;
window->shsurf = NULL;
+   window->view = NULL;
xcb_unmap_window(wm->conn, window->frame_id);
 }

@@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener
*listener, void *data)
Don't try to use it later. */
window->shsurf = NULL;
window->surface = NULL;
+   window->view = NULL;
 }

 static struct weston_wm_window *
--
1.8.3.2




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


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

Re: [RFC v2] surface crop & scale protocol extension

[Pekka Paalanen]

On Thu, 14 Nov 2013 12:27:22 -0800
Bill Spitzak  wrote:

> Pekka Paalanen wrote:
> 
> > Yes, you cannot use non-integer surface sizes. You cannot express a
> > surface size, that would result in a 1024x1024 area in output pixels,
> > because 1024 is not divisible by output_scale=3.
> 
> Thanks. That is indeed exactly the problem I am concerned about.
> 
> > This limitation exists also before crop & scale. Crop & scale cannot
> > remove this limitation, because the whole Wayland protocol has been
> > built on surface coordinates and especially surface sizes are integers.
> 
> I thought the proposed crop+scale used fixed point to specify the 
> destination rectangle, which is a solution. I don't like it but I 
> thought it was done on purpose for this.

If you read the proposal, it does not, exactly because it was written
in the way that the destination rectangle size becomes directly the
surface size, and hence it must be integers.

The source rectangle is in wl_fixed_t.

> The buffer size sent with attach is also in buffer pixels. So a client 
> can make a surface any size. But because the offset is in "surface 
> coordinates" they cannot resize the origin corner except in multiples of 
> buffer_scale. However they *can* resize the opposite corner in pixels. 
> This seems pretty inconsistent and it would be nice to fix it too.

Buffer size is the property of a wl_buffer. The size is not explicitly
sent on attach. You are right about the offset.

Clients cannot "resize the opposite corner" in the way you
assume, because the protocol requires that the buffer size is a
multiple of buffer_scale, so that it always results in a surface size in
integers.

Buffer size must always be a multiple of buffer_scale. That was defined
when buffer_scale was added to the protocol.

So, there are two different cases for surface size:
1. Crop & scale not used: surface size is determined from buffer size
   via buffer_transform and buffer_scale.
2. Crop & scale is used: surface size is directly dst_width,dst_height.

In both cases, surface size is guaranteed to be in integers.

Surface size is always in integers. Nothing I have proposed, or in the
current protocol, allows otherwise.

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