[PATCH] compositor: destroy modifier_binding_list

[Ryo Munakata]

Signed-off-by: Ryo Munakata 
---
 src/compositor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compositor.c b/src/compositor.c
index 4e88375..ec2be7d 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4558,6 +4558,7 @@ weston_compositor_shutdown(struct weston_compositor *ec)
ec->renderer->destroy(ec);
 
weston_binding_list_destroy_all(&ec->key_binding_list);
+   weston_binding_list_destroy_all(&ec->modifier_binding_list);
weston_binding_list_destroy_all(&ec->button_binding_list);
weston_binding_list_destroy_all(&ec->touch_binding_list);
weston_binding_list_destroy_all(&ec->axis_binding_list);
-- 
2.4.6

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

RE: weston-desktop-shell

[Nancy Zou]

Hi pekka

>Odd. You definitely should be getting first a black screen which then fades to 
>the desktop once weston-desktop-shell signals ready, because you have 
>startup-animation=fade.
Yes. I don't notice it before. There is a black screen flashed across before 
display Weston-desktop-shell.


Best Regards
Nancy






Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our 
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, 
www.youtube.com/user/CSRplc, Facebook, 
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at 
www.twitter.com/CSR_plc.
You can now access the wide range of products powered by aptX at www.aptx.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH][weston] build: don't duplicate rule for weston.desktop

[Bryce Harrington]

On Thu, Jul 16, 2015 at 08:56:32PM +0100, Ross Burton wrote:
> dist_wayland_session_DATA will distribute and install src/weston.desktop, so 
> the
> definition of wayland_session_DATA which also installs src/weston.desktop will
> result in the file being installed twice and (rarely) cause install to fail.
> 
> Spotted and fix by Roy Li .
> Signed-off-by: Ross Burton 

Thanks, pushed:
To ssh://git.freedesktop.org/git/wayland/weston
   2217f3f..315476f  master -> master

> ---
>  Makefile.am | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index f71587f..d7b45a8 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -182,8 +182,7 @@ pkgconfigdir = $(libdir)/pkgconfig
>  pkgconfig_DATA = src/weston.pc
>  
>  wayland_sessiondir = $(datadir)/wayland-sessions
> -wayland_session_DATA = src/weston.desktop
> -dist_wayland_session_DATA = $(wayland_session_DATA)
> +dist_wayland_session_DATA = src/weston.desktop
>  
>  westonincludedir = $(includedir)/weston
>  westoninclude_HEADERS =  \
> -- 
> 2.1.4
> 
> ___
> 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] shell: Switch middle and right mouse bindings

[Bryce Harrington]

On Fri, Jun 26, 2015 at 01:57:44PM +1000, Peter Hutterer wrote:
> On Thu, Jun 25, 2015 at 04:03:30PM -0500, Derek Foreman wrote:
> > Currently rotate is on the right mouse button and resize is on the middle.
> > 
> > As fantastic as rotating windows is, it's probably nicer to have resize on
> > the right button, especially for anyone with only 2 buttons.
> > 
> > Signed-off-by: Derek Foreman 
> 
> heresy! I think you should put wobble on the right button
> 
> Reviewed-by: Peter Hutterer 

Guess no one else has an opinion on this one?  Seems fine to me, so...

Pushed:
To ssh://git.freedesktop.org/git/wayland/weston
   6bc33d6..2217f3f  master -> master

 
> Cheers,
>Peter
> 
> > ---
> >  desktop-shell/shell.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> > index 0fe4658..e427c62 100644
> > --- a/desktop-shell/shell.c
> > +++ b/desktop-shell/shell.c
> > @@ -6405,14 +6405,14 @@ shell_add_bindings(struct weston_compositor *ec, 
> > struct desktop_shell *shell)
> > weston_compositor_add_button_binding(ec, BTN_LEFT, mod, move_binding,
> >  shell);
> > weston_compositor_add_touch_binding(ec, mod, touch_move_binding, shell);
> > -   weston_compositor_add_button_binding(ec, BTN_MIDDLE, mod,
> > +   weston_compositor_add_button_binding(ec, BTN_RIGHT, mod,
> >  resize_binding, shell);
> > weston_compositor_add_button_binding(ec, BTN_LEFT,
> >  mod | MODIFIER_SHIFT,
> >  resize_binding, shell);
> >  
> > if (ec->capabilities & WESTON_CAP_ROTATION_ANY)
> > -   weston_compositor_add_button_binding(ec, BTN_RIGHT, mod,
> > +   weston_compositor_add_button_binding(ec, BTN_MIDDLE, mod,
> >  rotate_binding, NULL);
> >  
> > weston_compositor_add_key_binding(ec, KEY_TAB, mod, switcher_binding,
> > -- 
> > 2.1.4
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 weston] log: Open log file CLOEXEC so child processes don't get the fd

[Bryce Harrington]

On Mon, Jun 08, 2015 at 11:37:31AM -0500, Derek Foreman wrote:
> Reviewed-by: Pekka Paalanen 
> Signed-off-by: Derek Foreman 

Thanks, pushed:
To ssh://git.freedesktop.org/git/wayland/weston
   4a8a3a1..6bc33d6  master -> master


> ---
> 
> Nested the os_fd_set_cloexec() call so calling weston_log_file_open() multiple
> times behaves as expected.
> 
>  shared/os-compatibility.c | 22 ++
>  shared/os-compatibility.h |  3 +++
>  src/log.c |  7 ++-
>  3 files changed, 23 insertions(+), 9 deletions(-)
> 
> diff --git a/shared/os-compatibility.c b/shared/os-compatibility.c
> index 611e7c8..d0ff1c8 100644
> --- a/shared/os-compatibility.c
> +++ b/shared/os-compatibility.c
> @@ -33,8 +33,8 @@
>  
>  #include "os-compatibility.h"
>  
> -static int
> -set_cloexec_or_close(int fd)
> +int
> +os_fd_set_cloexec(int fd)
>  {
>   long flags;
>  
> @@ -43,16 +43,22 @@ set_cloexec_or_close(int fd)
>  
>   flags = fcntl(fd, F_GETFD);
>   if (flags == -1)
> - goto err;
> + return -1;
>  
>   if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) == -1)
> - goto err;
> + return -1;
>  
> - return fd;
> + return 0;
> +}
>  
> -err:
> - close(fd);
> - return -1;
> +static int
> +set_cloexec_or_close(int fd)
> +{
> + if (os_fd_set_cloexec(fd) != 0) {
> + close(fd);
> + return -1;
> + }
> + return fd;
>  }
>  
>  int
> diff --git a/shared/os-compatibility.h b/shared/os-compatibility.h
> index 172bb7e..60ae7fd 100644
> --- a/shared/os-compatibility.h
> +++ b/shared/os-compatibility.h
> @@ -38,6 +38,9 @@ backtrace(void **buffer, int size)
>  #endif
>  
>  int
> +os_fd_set_cloexec(int fd);
> +
> +int
>  os_socketpair_cloexec(int domain, int type, int protocol, int *sv);
>  
>  int
> diff --git a/src/log.c b/src/log.c
> index 99bbe18..0dae3b2 100644
> --- a/src/log.c
> +++ b/src/log.c
> @@ -33,6 +33,8 @@
>  
>  #include "compositor.h"
>  
> +#include "os-compatibility.h"
> +
>  static FILE *weston_logfile = NULL;
>  
>  static int cached_tm_mday = -1;
> @@ -74,8 +76,11 @@ weston_log_file_open(const char *filename)
>  {
>   wl_log_set_handler_server(custom_handler);
>  
> - if (filename != NULL)
> + if (filename != NULL) {
>   weston_logfile = fopen(filename, "a");
> + if (weston_logfile)
> + os_fd_set_cloexec(fileno(weston_logfile));
> + }
>  
>   if (weston_logfile == NULL)
>   weston_logfile = stderr;
> -- 
> 2.1.4
> 
> ___
> 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 00/17] Don't allow direct use of seat->device pointers

[Bryce Harrington]

On Wed, Jul 15, 2015 at 01:00:31PM -0500, Derek Foreman wrote:
> "v7" of my "Don't allow direct use of seat->device pointers" stuff.
> 
> Those pointers are funny in that they only exist after a device has been
> plugged in, and they don't ever go away.  We're supposed to check if
> the associated _device_count > 0 before using them.  The final patch
> in this series adds helper functions that do that, renames the pointers
> in the seat struct and updates users accordingly.
> 
> Some of the previous series has landed and there are 4 new patches near
> the end.  This is all rebased against master as of today.
> 
> For the final patch there's still an open question wrt seat_get_* in the
> seat_interface: do we really have to use *_state directly here to avoid a
> race condition?
> 
> Derek Foreman (17):
>   text-backend: Replace focus_listener_initialized with a bool
>   exposay: Test keyboard presence before using keyboard pointer
>- style change
>   bindings: Stop exporting internal functions
>   compositor-drm: Simplify logic in setup_output_seat_constraint
>   input: Pass the appropriate pointer type to bindings instead of a seat
>- minor style change
>   desktop-shell: Make surface_touch_move take a touch instead of a seat
>   desktop-shell: Make surface_move take a pointer instead of a seat
>   desktop-shell: Make surface_rotate take a pointer instead of a seat
>   desktop-shell: Make surface_resize take a pointer instead of a seat
>   desktop-shell: Use the grabbed pointer in popup_grab_button
>   bindings: make install_binding_grab take a keyboard instead of a seat
>   bindings: Make run binding functions take apropriate device instead of
> a seat

Landed the above (plus one more seat->keyboard pointer that was hiding
from you)

To ssh://git.freedesktop.org/git/wayland/weston
   d0ead48..4a8a3a1  master -> master

> 
>   input: Check device counts in bind_seat()
>   desktop-shell: Don't call wl_list_init() in the middle of a list
>   desktop-shell: Check for device presence properly
>   fullscreen-shell: Test for device presence properly
> 
> 
>   input: Don't test keyboard/pointer/touch pointers
>style and grammar changes
>*_seat_caps_changed now use the helper functions
>the "real" pointers are now named *_state instead of *_ptr
>changes in bind_seat split into a new patch

Review still needed for the above.

Bryce
 
>  desktop-shell/exposay.c |  39 ++--
>  desktop-shell/input-panel.c |   7 +-
>  desktop-shell/shell.c   | 366 
> +---
>  desktop-shell/shell.h   |   2 +-
>  fullscreen-shell/fullscreen-shell.c |  18 +-
>  ivi-shell/hmi-controller.c  |  30 +--
>  ivi-shell/input-panel-ivi.c |   7 +-
>  ivi-shell/ivi-shell.c   |   4 +-
>  src/bindings.c  |  85 +
>  src/compositor-drm.c|  31 +--
>  src/compositor-fbdev.c  |   3 +-
>  src/compositor-rpi.c|   3 +-
>  src/compositor-wayland.c|  14 +-
>  src/compositor-x11.c|  18 +-
>  src/compositor.c|  29 +--
>  src/compositor.h|  38 ++--
>  src/data-device.c   |  41 ++--
>  src/gl-renderer.c   |   8 +-
>  src/input.c | 247 
>  src/libinput-seat.c |  15 +-
>  src/main.c  |   7 +-
>  src/pixman-renderer.c   |   2 +-
>  src/screenshooter.c |  14 +-
>  src/text-backend.c  |  25 +--
>  src/zoom.c  |   8 +-
>  tests/surface-screenshot.c  |  10 +-
>  tests/weston-test.c |   9 +-
>  xwayland/dnd.c  |   3 +-
>  xwayland/window-manager.c   |  23 ++-
>  29 files changed, 675 insertions(+), 431 deletions(-)
> 
> -- 
> 2.1.4
> 
> ___
> 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] README: introduce libweston

[Bryce Harrington]

On Thu, Jul 16, 2015 at 11:55:03AM +0300, Pekka Paalanen wrote:
> On Wed, 15 Jul 2015 09:52:38 -0700
> Bryce Harrington  wrote:
> 
> > On Wed, Jul 15, 2015 at 01:03:24PM +0100, Daniel Stone wrote:
> > > Hi,
> > > 
> > > On 14 July 2015 at 11:07, Pekka Paalanen  wrote:
> > > > From: Pekka Paalanen 
> > > >
> > > > What is libweston and where do we intend to go with it.
> > > 
> > > Sounds good to me, although the bit about always using
> > > --with-cairo=image just makes me lean even more towards removing the
> > > other options.
> > 
> > What exactly does that affect inside Weston?  Is it just some of the
> > example clients, or does it affect stuff that actual users would care
> > about?
> 
> It mainly affects the toytoolkit, which flavour of Cairo it will use
> for everything. It doesn't affect the compositor as such, but as it
> affects all demo clients which includes weston-desktop-shell, it will
> impact all users.
> 
> Until we actually fix that, I recommend people to build with the
> default flavour "image".
> 
> A quick fix would be to have a runtime switch in toytoolkit to ask for
> cairo-egl, and default to cairo-image. This way we'd limit the
> cairo-egl impact to just the demos that actually ask for it.
> 
> A more involved fix would be to get rid of cairo-egl completely, and
> remove the support from toytoolkit. Then demos that depended on it
> would need to get their decorations drawn with cairo-image, copied into
> textures, and blitted in GL to the surface.

Mind if we postpone eliminating this functionality for a few months?
I'd like to do some experimentation with cairo performance under wayland
and I'd like to quantify the benefit/cost of cairo-egl before we chuck
it.

Bryce

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

Re: Wayland Relative Pointer API Progress

[Bill Spitzak]

On Wed, Jul 15, 2015 at 5:09 AM, Daniel Stone  wrote:

> On 29 June 2015 at 20:22, Bill Spitzak  wrote:
> > On Sun, Jun 28, 2015 at 7:32 AM, x414e54  wrote:
> >> Clients do not draw the mouse cursor, either the GPU (using hardware
> >> overlays) or the WM does.
> >
> > Yes, I want to allow clients to use this CPU/WM support. Currently the
> > client *has* to draw the cursor (and hide the hardware one) to sync it's
> > position with the drawing. If instead the client just *moves* the cursor,
> > then the cursor is actually drawn by the compositor like you say.
>
> I haven't read the vast majority of this thread, but this isn't really
> true. There's nothing special about the cursor in drawing: just hide
> the cursor, create a small subsurface with SHM buffers, and Weston
> will use the hardware cursor as it would for an actual cursor surface.
> Problem solved.
>

The problem I have with that is that it is impossible to prevent an
incorrect composite where there is either no cursor or two cursors rendered.

The wayland api could be changed so that setting a cursor image is buffered
until a matching wl_surface commit, and this could fix the entry into
pointer-lock mode. However when locked mode is lost I don't see any way to
do it, as it may be a different client setting the cursor image than the
one that would be removing the subsurface with the fake cursor in it.

This is probably not a big deal except (as far as I can tell) it can be
fixed with a trivial change to the proposed pointer-lock. The current
proposal makes the cursor stop moving (which means the client has to hide
the cursor in any conceivable usage) and adds a "set_cursor_hint" request
that is used to set the xy position the cursor will be at when pointer lock
is lost. I want "set_cursor_hint" to actually move the cursor (and possibly
rename it to remove the word "hint"). If the client does not want that it
can hide the cursor, which it has to do anyway in the current proposal.

For some reason this has degraded into a big argument about whether locking
the cursor position to the rendered graphics is good or bad. But since the
alternative of using a subsurface would also do that, it does not matter
whether that is good or bad for deciding this.

This change combined with a pointer lock that lasts the exact same time
that the implicit grab for a button down lasts would be very useful to make
a "slow scrollbar" or a 3-D trackball where the cursor sticks to the
rendered ball's surface. Reusing an api designed for games for this seems
like a good idea to reduce Wayland's api size.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] protocol: Add pointer gestures (swipe/pinch) protocol

[Jonas Ådahl]

On Thu, Jul 16, 2015 at 08:17:44PM +0200, Carlos Garnacho wrote:
> Hey Jonas :),
> 
> On Thu, Jul 16, 2015 at 3:15 AM, Jonas Ådahl  wrote:
> > On Wed, Jul 15, 2015 at 08:02:10PM +0200, Carlos Garnacho wrote:
> >> The lifetime and progress of gestures is maintained by the separate
> >> wl_pointer_gesture_pinch and wl_pointer_gesture_swipe interfaces,
> >> each of these has begin/update(optional)/end phases, as transmitted
> >> by their events.
> >>
> >> The gesture interfaces can be obtained from the wl_pointer, and
> >> must be interpreted on the last surface entered by the pointer,
> >> starting from the pointer coordinates.
> >
> > Without having looked at the protocol details, did you consider whether
> > we should put this in weston first, as done with other non-trivial
> > protocol extensions (like wl_subcompositor, wl_relative_pointer,
> > wl_scalar, wl_text_input etc)? It might sure it should belong in
> > wl_pointer as well. We should try to avoid putting things in the core
> > objects when it doesn't make perfect sense, and in this case, I think
> > adding it as an optional extension seems reasonable.
> 
> Peter actually started out like that, with the pinch/gesture
> interfaces being taken from a wl_gestures global. I'm not opposed to
> the idea, but the extra indirection between pointer event handling and
> a global that's just loosely related to the seat struck as weird to me
> when getting my hands in the code, hence the early short-circuit into
> wl_pointer.

Having a wl_gestures where you do, just as in your current proposal,
extend wl_pointer with gesture data, would work just the same and is how
extensions in Wayland generally work. The difference would be that
instead of a 'get_swipe_gesture' that takes no argument, you'd pass a
wl_pointer. This way you'd get the benefit of making it obvious that you
actualy extend the pointer, and that it shares focus etc.

One major reason for not just putting more and more things into
wl_pointer, wl_surface, wl_seat etc, we will sooner or later end up with
protocol dept, i.e. legacy requests and events we will never ever be able
to remove. If we put additions that will have the slightest chance of
ever changing (like any non-trivial addition) and especially additions
that are quite isolated, I think it makes more sense to add them as
extensions instead of required functionality.

Also worth mentioning is that all backends might not be able to
implement gestures. Such backends will, instead of simply not exposing
the extension, have to implement non-working gesture objects.

> 
> Convenience-wise, I'm concerned about having to support multiple
> versions/namespaces of the protocol if we start out like that and this
> is deemed part of wayland.xml someday in a later future. Although if
> it does help on an early adoption, sure...

IMHO that is a reasonable pain to endure.


Jonas

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

Re: [PATCH][weston] build: don't duplicate rule for weston.desktop

[Derek Foreman]

Looks good to me,
Reviewed-By: Derek Foreman 


On 16/07/15 02:56 PM, Ross Burton wrote:
> dist_wayland_session_DATA will distribute and install src/weston.desktop, so 
> the
> definition of wayland_session_DATA which also installs src/weston.desktop will
> result in the file being installed twice and (rarely) cause install to fail.
> 
> Spotted and fix by Roy Li .
> Signed-off-by: Ross Burton 
> ---
>  Makefile.am | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index f71587f..d7b45a8 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -182,8 +182,7 @@ pkgconfigdir = $(libdir)/pkgconfig
>  pkgconfig_DATA = src/weston.pc
>  
>  wayland_sessiondir = $(datadir)/wayland-sessions
> -wayland_session_DATA = src/weston.desktop
> -dist_wayland_session_DATA = $(wayland_session_DATA)
> +dist_wayland_session_DATA = src/weston.desktop
>  
>  westonincludedir = $(includedir)/weston
>  westoninclude_HEADERS =  \
> 

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

[PATCH][weston] build: mkdir target weston.ini directories before writing

[Ross Burton]

In parallel out-of-tree builds it is possible for e.g. ivi-shell/weston.ini to
be written before ivi-shell/ exists.  Solve this by creating the target
directory first.

Signed-off-by: Ross Burton 
---
 Makefile.am | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index d7b45a8..76c91fd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -20,6 +20,7 @@ weston.ini : $(srcdir)/weston.ini.in
$< > $@
 
 ivi-shell/weston.ini : $(srcdir)/ivi-shell/weston.ini.in
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@)
$(AM_V_GEN)$(SED) \
-e 's|@bindir[@]|$(bindir)|g' \
-e 's|@abs_top_builddir[@]|$(abs_top_builddir)|g' \
@@ -29,6 +30,7 @@ ivi-shell/weston.ini : $(srcdir)/ivi-shell/weston.ini.in
$< > $@
 
 tests/weston-ivi.ini : $(srcdir)/ivi-shell/weston.ini.in
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@)
$(AM_V_GEN)$(SED) \
-e 's|@bindir[@]|$(bindir)|g' \
-e 's|@abs_top_builddir[@]|$(abs_top_builddir)|g' \
-- 
2.1.4

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

[PATCH][weston] build: don't duplicate rule for weston.desktop

[Ross Burton]

dist_wayland_session_DATA will distribute and install src/weston.desktop, so the
definition of wayland_session_DATA which also installs src/weston.desktop will
result in the file being installed twice and (rarely) cause install to fail.

Spotted and fix by Roy Li .
Signed-off-by: Ross Burton 
---
 Makefile.am | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index f71587f..d7b45a8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -182,8 +182,7 @@ pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = src/weston.pc
 
 wayland_sessiondir = $(datadir)/wayland-sessions
-wayland_session_DATA = src/weston.desktop
-dist_wayland_session_DATA = $(wayland_session_DATA)
+dist_wayland_session_DATA = src/weston.desktop
 
 westonincludedir = $(includedir)/weston
 westoninclude_HEADERS =\
-- 
2.1.4

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

Re: [PATCH wayland 3/3] shm: wl_shm_buffer_get_data() requires a valid pool.

[Derek Foreman]

On 16/07/15 03:02 AM, Hardening wrote:
> Le 01/07/2015 12:52, Marek Chalupa a écrit :
>>
>>
>> On Wed, Jul 1, 2015 at 11:25 AM, Marek Chalupa > > wrote:
>>
>>
>>
>> On Fri, Jun 26, 2015 at 6:35 PM, Derek Foreman
>> mailto:der...@osg.samsung.com>> wrote:
>>
>> There's no situation where a shm buffer without a pool makes sense,
>> so we enforce the pool's existence a little more rigidly.
>>
>> Signed-off-by: Derek Foreman > >
>> ---
>>  src/wayland-shm.c | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
>> index da11743..79b3886 100644
>> --- a/src/wayland-shm.c
>> +++ b/src/wayland-shm.c
>> @@ -353,10 +353,12 @@ wl_shm_buffer_get_stride(struct
>> wl_shm_buffer *buffer)
>>  WL_EXPORT void *
>>  wl_shm_buffer_get_data(struct wl_shm_buffer *buffer)
>>  {
>> -   if (buffer->pool)
>> -   return buffer->pool->data + buffer->offset;
>> -   else
>> -   return buffer + 1;
>> +   assert(buffer->pool);
>> +
>> +   if (!buffer->pool)
>> +   return NULL;
>>
>>
>> This condition is never true if the assert passed
>>
>>  
>> Yeah, but in non-debug build we do not have the assert, so it may make
>> sense to have this doubled. Ok.
>>  
> 
> I find it a little strange, that something that abort() in debug mode,
> just "silently" return NULL in production mode...
> 
> Checking with the Eclipse "Call hierarchy" tool, none of the callers of
> wl_shm_buffer_get_data() check the return value, so we may detect the
> bug quite far from the real source.
> 
> So my suggestion is either wl_shm_buffer_get_data is a "succeed or kill
> program" function (like xyzalloc functions), or the callers have to be
> updated if we can live with buffer->pool == NULL.
> 
> Best regards.


I'm wondering if buffer->pool can ever actually be NULL anyway...  I
have a suspicion that it can't, making the assert and the test a little
silly.

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

Re: [PATCH wayland] protocol: Add pointer gestures (swipe/pinch) protocol

[Carlos Garnacho]

Hey Jonas :),

On Thu, Jul 16, 2015 at 3:15 AM, Jonas Ådahl  wrote:
> On Wed, Jul 15, 2015 at 08:02:10PM +0200, Carlos Garnacho wrote:
>> The lifetime and progress of gestures is maintained by the separate
>> wl_pointer_gesture_pinch and wl_pointer_gesture_swipe interfaces,
>> each of these has begin/update(optional)/end phases, as transmitted
>> by their events.
>>
>> The gesture interfaces can be obtained from the wl_pointer, and
>> must be interpreted on the last surface entered by the pointer,
>> starting from the pointer coordinates.
>
> Without having looked at the protocol details, did you consider whether
> we should put this in weston first, as done with other non-trivial
> protocol extensions (like wl_subcompositor, wl_relative_pointer,
> wl_scalar, wl_text_input etc)? It might sure it should belong in
> wl_pointer as well. We should try to avoid putting things in the core
> objects when it doesn't make perfect sense, and in this case, I think
> adding it as an optional extension seems reasonable.

Peter actually started out like that, with the pinch/gesture
interfaces being taken from a wl_gestures global. I'm not opposed to
the idea, but the extra indirection between pointer event handling and
a global that's just loosely related to the seat struck as weird to me
when getting my hands in the code, hence the early short-circuit into
wl_pointer.

Convenience-wise, I'm concerned about having to support multiple
versions/namespaces of the protocol if we start out like that and this
is deemed part of wayland.xml someday in a later future. Although if
it does help on an early adoption, sure...

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

Re: [PATCH wayland] protocol: Add pointer gestures (swipe/pinch) protocol

[Carlos Garnacho]

Hey,

Keen eye on those :), my last proofreading wasn't as successful. I've
just sent a new patch that contains Pekka's suggestions, fixes for
your comments and your r-b.

Cheers,
  Carlos

On Thu, Jul 16, 2015 at 2:13 AM, Peter Hutterer
 wrote:
> On Wed, Jul 15, 2015 at 08:02:10PM +0200, Carlos Garnacho wrote:
>> The lifetime and progress of gestures is maintained by the separate
>> wl_pointer_gesture_pinch and wl_pointer_gesture_swipe interfaces,
>> each of these has begin/update(optional)/end phases, as transmitted
>> by their events.
>>
>> The gesture interfaces can be obtained from the wl_pointer, and
>> must be interpreted on the last surface entered by the pointer,
>> starting from the pointer coordinates.
>>
>> Signed-off-by: Carlos Garnacho 
>> ---
>>  protocol/wayland.xml | 153 
>> ++-
>>  1 file changed, 151 insertions(+), 2 deletions(-)
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index 42c9309..51effad 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -1329,7 +1329,7 @@
>>  
>> 
>>
>> -  
>> +  
>>  
>>A seat is a group of keyboards, pointer and touch devices. This
>>object is published as a global during start up, or when such a
>> @@ -1402,7 +1402,139 @@
>>
>>
>>
>> -  
>> +  
>> +
>> +  A swipe gesture object notifies a client about a multi-finger swipe
>> +  gesture detected on an indirect input device such as a touchpad.
>> +  The gesture is usually initiated by multiple fingers moving in the
>> +  same direction but once initiated the direction may change.
>> +  The precise conditions of when such a gesture is detected are
>> +  implementation-dependent.
>> +
>> +  A gesture consists of three stages: begin, update (optional) and end.
>> +
>> +  A gesture may be cancelled by the compositor or the hardware.
>> +  Destructive actions should not be considered until the end of a
>> +  gesture has been received.
>> +
>> +
>> +
>> +  
>> +
>> +
>> +
>> +  
>> + This event is sent when a multi-finger swipe gesture is detected
>> + on the device.
>> +  
>> +  
>> +  
>> +  
>> +
>> +
>> +
>> +  
>> + This event is sent when a multi-finger swipe gesture changes the
>> + position of the logical center.
>> +
>> + The dx and dy coordinates are relative coordinates of the logical
>> + center of the gesture compared to the previous event.
>> +  
>> +  
>> +  
>> +  
>> +
>> +
>> +
>> +  
>> + This event is sent when a multi-finger swipe gesture ceases to
>> + be valid. This may happen when one or more finger is lifted or
>> + the gesture is cancelled.
>> +
>> + When a gesture is cancelled, the client should undo state changes
>> + caused by this gesture. What causes a gesture to be cancelled is
>> + implementation-dependent.
>> +  
>> +  
>> +  
>> +  
>
> copy/paste error here (sorry, my fault)
>
>> +
>> +  
>> +
>> +  
>> +
>> +  A swipe gesture object notifies a client about a multi-finger pinch
>
> s/swipe/pinch/
>
>> +  gesture detected on an indirect input device such as a touchpad.
>> +  The gesture is usually initiated by multiple fingers moving towards
>> +  each other or away from each other, or by two or more fingers rotating
>> +  around a logical center of gravity.  The precise conditions of when
>> +  such a gesture is detected are implementation-dependent.
>> +
>> +  A gesture consists of three stages: begin, update (optional) and end.
>> +
>> +  A gesture may be cancelled by the compositor or the hardware.
>> +  Destructive actions should not be considered until the end of a
>> +  gesture has been received.
>> +
>> +
>> +
>> +  
>> +
>> +
>> +
>> +  
>> + This event is sent when a multi-finger pinch gesture is detected
>> + on the device.
>> +
>> + The gesture is assigned a unique @id. Future events from this
>> + gesture reference this ID. The ID ceases to be valid after a
>> + pointer_gesture_swipe.end and may be re-used in the future.
>
> you can drop this paragraph now. for the archives: the original version of
> this patchset had an ID for each gesture sequence similar to touches.
>
> Carlos and I agreed that this isn't really necessary - while it's
> technically possible to have two gestures on two different devices at the
> same time this is something that the compositor should suppress. If we find
> a sensible use-case for this, we can add the gesture sequence ID later.
>
> Carlos: you may want to add a paragraph explicitly stating that only one
> gesture of a type may be active at a time.
>
>> +  
>> +  
>> +  
>> +  
>> +
>> +
>> +
>> +  
>> + This event is sent when a multi-finger pinch gesture changes the
>> + position of the logical center, t

[PATCH wayland v2] protocol: Add pointer gestures (swipe/pinch) protocol

[Carlos Garnacho]

The lifetime and progress of gestures is maintained by the separate
wl_pointer_gesture_pinch and wl_pointer_gesture_swipe interfaces,
each of these has begin/update(optional)/end phases, as transmitted
by their events.

The gesture interfaces can be obtained from the wl_pointer, and
must be interpreted on the last surface entered by the pointer,
starting from the pointer coordinates.

Signed-off-by: Carlos Garnacho 
Reviewed-by: Peter Hutterer 
---
 protocol/wayland.xml | 153 ++-
 1 file changed, 151 insertions(+), 2 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 42c9309..e122841 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1329,7 +1329,7 @@
 

 
-  
+  
 
   A seat is a group of keyboards, pointer and touch devices. This
   object is published as a global during start up, or when such a
@@ -1402,7 +1402,139 @@
 
   
 
-  
+  
+
+  A swipe gesture object notifies a client about a multi-finger swipe
+  gesture detected on an indirect input device such as a touchpad.
+  The gesture is usually initiated by multiple fingers moving in the
+  same direction but once initiated the direction may change.
+  The precise conditions of when such a gesture is detected are
+  implementation-dependent.
+
+  A gesture consists of three stages: begin, update (optional) and end.
+  There cannot be multiple simultaneous pinch or swipe gestures, how
+  compositors prevent these situations is implementation-dependent.
+
+  A gesture may be cancelled by the compositor or the hardware.
+  Destructive actions should not be considered until the end of a
+  gesture has been received.
+
+
+
+  
+
+
+
+  
+   This event is sent when a multi-finger swipe gesture is detected
+   on the device.
+  
+  
+  
+  
+
+
+
+  
+   This event is sent when a multi-finger swipe gesture changes the
+   position of the logical center.
+
+   The dx and dy coordinates are relative coordinates of the logical
+   center of the gesture compared to the previous event.
+  
+  
+  
+  
+
+
+
+  
+   This event is sent when a multi-finger swipe gesture ceases to
+   be valid. This may happen when one or more finger is lifted or
+   the gesture is cancelled.
+
+   When a gesture is cancelled, the client should undo state changes
+   caused by this gesture. What causes a gesture to be cancelled is
+   implementation-dependent.
+  
+  
+  
+  
+
+  
+
+  
+
+  A pinch gesture object notifies a client about a multi-finger pinch
+  gesture detected on an indirect input device such as a touchpad.
+  The gesture is usually initiated by multiple fingers moving towards
+  each other or away from each other, or by two or more fingers rotating
+  around a logical center of gravity.  The precise conditions of when
+  such a gesture is detected are implementation-dependent.
+
+  A gesture consists of three stages: begin, update (optional) and end.
+  There cannot be multiple simultaneous pinch or swipe gestures, how
+  compositors prevent these situations is implementation-dependent.
+
+  A gesture may be cancelled by the compositor or the hardware.
+  Destructive actions should not be considered until the end of a
+  gesture has been received.
+
+
+
+  
+
+
+
+  
+   This event is sent when a multi-finger pinch gesture is detected
+   on the device.
+  
+  
+  
+  
+
+
+
+  
+   This event is sent when a multi-finger pinch gesture changes the
+   position of the logical center, the rotation or the relative scale.
+
+   The dx and dy coordinates are relative coordinates in the
+   surface coordinate space of the logical center of the gesture.
+
+   The scale factor is an absolute scale compared to the
+   pointer_gesture_pinch.begin event, e.g. a scale of 2 means the fingers
+   are now twice as far apart as on pointer_gesture_pinch.begin.
+
+   The rotation is the relative angle in degrees clockwise compared to the 
previous
+   pointer_gesture_pinch.begin or pointer_gesture_pinch.update event.
+  
+  
+  
+  
+  
+  
+
+
+
+  
+   This event is sent when a multi-finger pinch gesture ceases to
+   be valid. This may happen when one or more finger is lifted or
+   the gesture is cancelled.
+
+   When a gesture is cancelled, the client should undo state changes
+   caused by this gesture. What causes a gesture to be cancelled is
+   implementation-dependent.
+  
+  
+  
+  
+
+
+  
+
+  
 
   The wl_pointer interface represents one or more input devices,
   such as mice, which control the pointer location and pointer_focus

Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs

[Jasper St. Pierre]

If the client still has key focus, then it should get the key release.
That sounds like a compositor bug to me.

On Thu, Jul 16, 2015 at 10:28 AM, Arnaud Vrac  wrote:
> On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre 
> wrote:
>
>> On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho 
>> wrote:
>> > On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote:
>> >> What is the value of clients having this information?
>> >
>> > The same there is in having wl_touch.cancelled. See the cases in the
>> > original email in the thread.
>> >
>> >> I think we've
>> >> tried to hide grab semantics from the point of view of the client and
>> >> simply say "we can revoke input at any time, including in response to
>> >> a request you make", which gives us, the compositor, a lot more
>> >> leeway
>> >> with future possibilities.
>> >
>> > Sure, I'm all for that. What I'd really want is having a way to tell
>> > clients we do so. I'm totally fine with documenting the places where
>> > this potentially happens on a per-case basis, even if the final wording
>> > is "compositor dependent", same as for seat.release_input emission.
>> >
>> > That said, toolkits/clients will surely expect some consistence across
>> > compositors, so the leeway is relative.
>> >
>> >>
>> >> Grabs were a major pain point in X11 since they were overspecified,
>> >> so
>> >> we're trying to not fall into that same trap again.
>> >
>> > I'm sure there is a lot of ground between "let's not overspecify" and
>> > "let's go shopping".
>> >
>> > It would be convenient first to identify what are the sore points with
>> > X grabs. AFAICT, most of these come from grabs not being easily
>> > transferred, and the WM/screensaver/etc not being more of a client to
>> > revoke/break grabs. On wayland the compositor is completely free to do
>> > as it pleases, with and without this change I'm proposing.
>>
>> Yeah, transferring grabs race-free, a lack of being able to override
>> or revoke grabs are the top two. But focus management + grabs in X11
>> is tricksy and sort of awkward: if I take a keyboard grab, key focus
>> can still navigate around as usual, we'll just get NotifyWhileGrabbed
>> as our detail.
>>
>> > However, one thing that X did well is defining a consistent event
>> > delivery model when grabs were being taken (well, except for touch
>> > events...), so both the grabbing and the pre-grab windows are well
>> > aware of what's going on, I think one is due in wayland, at least face
>> > to clients.
>>
>> Did it? I don't know of any model that lets me know when a client has
>> taken a grab or ungrabs their existing grab. The exception is that I
>> believe if I'm the key or pointer focus, I'll get a FocusOut / Leave
>> event with the "NotifyGrabbed" detail, and when the grab is dropped
>> (and I am still the key focus / pointer focus, which is not
>> guaranteed!), we'll get the reverse event with "NotifyUngrabbed".
>>
>> And in X11, this is actually good, because such an event would be
>> racy: some other client might have taken a grab in such a time. And it
>> happens all the time because of passive grabs, including X11's own
>> implicit passive grab on the pointer.
>>
>> Anyway, this model matches well with wl_keyboard.leave /
>> wl_pointer.leave being sent at the start of device grabs.
>>
>> >>
>> >> For instance, if the user is in a game that has a keyboard grab and
>> >> presses Alt-Tab to switch out, the client should just have its
>> >> keyboard grab revoked without having to have that as a possibility in
>> >> the protocol spec. Same thing with tray icon behavior, etc.
>> >
>> > sure, in that case you'd still get wl_keyboard.leave and the client can
>> > properly undo the key press / mods. But notice there is always a need
>> > to know when to undo (eg. in your example above, the game might have
>> > bound Alt to "release flares", if you first press Alt and then Tab, and
>> > the client doesn't get the Alt key release, you don't want to leave
>> > that stuck when you focus back)
>>
>> The client gets a wl_keyboard.leave. Is that not good enough? What use
>> cases does this new event solve?
>
>
> There's a case where that doesn't happen: if the key press triggers the
> activation of an input method, which grabs the keyboard. The client still
> keeps the focus and has no way to know if has to stop generating key repeats
> for the key that triggered the activation.
>
> I'm getting exactly this issue, the keyboard grab is needed in the virtual
> keyboard to be usable with the arrow keys.
>
>>
>>
>> >> Clients need to cope with losing mouse and keyboard focus at any
>> >> time,
>> >> and with seats going away at any time. It's just how it is.
>> >
>> > Toolkits are nothing else than giant state machines, they rely on a
>> > meaningful event order, or some proper notification when things go
>> > south. If you mess with that, you'll get clients in inconsistent
>> > states, including:
>> >
>> > - stuck buttons
>> > - gestures listening to vanished tou

Re: [PATCH weston v3 0/5] Fast repaint loop start on DRM

[Mario Kleiner]

On 07/16/2015 01:30 PM, Pekka Paalanen wrote:

On Tue,  7 Jul 2015 12:53:09 +0300
Pekka Paalanen  wrote:


From: Pekka Paalanen 

Hi,

as promised in
http://lists.freedesktop.org/archives/wayland-devel/2015-July/023192.html here
are the patches. The above-mentioned email contains an analysis of the effects
of these patches.

My modifications are mostly stylish and code re-use. millihz_to_nsec() was
suggested by Daniel Stone.

This series supersedes the patches 7, 8, and 9 of
http://lists.freedesktop.org/archives/wayland-devel/2015-June/022785.html

Mario Kleiner (3):
   presentation-shm: Allow setting of delay before surface.commit
   compositor-drm: Allow instant start of repaint loop. (v3)
   compositor: Respect repaint-window when restarting repaint loop.

Pekka Paalanen (2):
   shared: introduce timespec-util.h
   compositor,shared: add millihz_to_nsec()

  Makefile.am|  2 ++
  clients/presentation-shm.c | 48 -
  shared/timespec-util.h | 75 ++
  src/compositor-drm.c   | 39 +++-
  src/compositor.c   | 30 ++-
  5 files changed, 165 insertions(+), 29 deletions(-)
  create mode 100644 shared/timespec-util.h



Hi,

since no-one has commented anything and I'm confident with these
patches, I have pushed them:
2abe445..b7df04e  master -> master


Thanks,
pq



Hi Pekka,

yes, they all look good and hereby get my post-push reviewed-by :). I 
reviewed them yesterday before going to sleep, but was then too tired to 
also retest them and write a reply. Thanks for catching my pico second 
conversion error in the 2nd patch!


thanks,
-mario

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

Re: [PATCH wayland] protocol: define further the behavior of input on the presence of grabs

[Arnaud Vrac]

On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre 
wrote:

> On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho 
> wrote:
> > On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote:
> >> What is the value of clients having this information?
> >
> > The same there is in having wl_touch.cancelled. See the cases in the
> > original email in the thread.
> >
> >> I think we've
> >> tried to hide grab semantics from the point of view of the client and
> >> simply say "we can revoke input at any time, including in response to
> >> a request you make", which gives us, the compositor, a lot more
> >> leeway
> >> with future possibilities.
> >
> > Sure, I'm all for that. What I'd really want is having a way to tell
> > clients we do so. I'm totally fine with documenting the places where
> > this potentially happens on a per-case basis, even if the final wording
> > is "compositor dependent", same as for seat.release_input emission.
> >
> > That said, toolkits/clients will surely expect some consistence across
> > compositors, so the leeway is relative.
> >
> >>
> >> Grabs were a major pain point in X11 since they were overspecified,
> >> so
> >> we're trying to not fall into that same trap again.
> >
> > I'm sure there is a lot of ground between "let's not overspecify" and
> > "let's go shopping".
> >
> > It would be convenient first to identify what are the sore points with
> > X grabs. AFAICT, most of these come from grabs not being easily
> > transferred, and the WM/screensaver/etc not being more of a client to
> > revoke/break grabs. On wayland the compositor is completely free to do
> > as it pleases, with and without this change I'm proposing.
>
> Yeah, transferring grabs race-free, a lack of being able to override
> or revoke grabs are the top two. But focus management + grabs in X11
> is tricksy and sort of awkward: if I take a keyboard grab, key focus
> can still navigate around as usual, we'll just get NotifyWhileGrabbed
> as our detail.
>
> > However, one thing that X did well is defining a consistent event
> > delivery model when grabs were being taken (well, except for touch
> > events...), so both the grabbing and the pre-grab windows are well
> > aware of what's going on, I think one is due in wayland, at least face
> > to clients.
>
> Did it? I don't know of any model that lets me know when a client has
> taken a grab or ungrabs their existing grab. The exception is that I
> believe if I'm the key or pointer focus, I'll get a FocusOut / Leave
> event with the "NotifyGrabbed" detail, and when the grab is dropped
> (and I am still the key focus / pointer focus, which is not
> guaranteed!), we'll get the reverse event with "NotifyUngrabbed".
>
> And in X11, this is actually good, because such an event would be
> racy: some other client might have taken a grab in such a time. And it
> happens all the time because of passive grabs, including X11's own
> implicit passive grab on the pointer.
>
> Anyway, this model matches well with wl_keyboard.leave /
> wl_pointer.leave being sent at the start of device grabs.
>
> >>
> >> For instance, if the user is in a game that has a keyboard grab and
> >> presses Alt-Tab to switch out, the client should just have its
> >> keyboard grab revoked without having to have that as a possibility in
> >> the protocol spec. Same thing with tray icon behavior, etc.
> >
> > sure, in that case you'd still get wl_keyboard.leave and the client can
> > properly undo the key press / mods. But notice there is always a need
> > to know when to undo (eg. in your example above, the game might have
> > bound Alt to "release flares", if you first press Alt and then Tab, and
> > the client doesn't get the Alt key release, you don't want to leave
> > that stuck when you focus back)
>
> The client gets a wl_keyboard.leave. Is that not good enough? What use
> cases does this new event solve?
>

There's a case where that doesn't happen: if the key press triggers the
activation of an input method, which grabs the keyboard. The client still
keeps the focus and has no way to know if has to stop generating key
repeats for the key that triggered the activation.

I'm getting exactly this issue, the keyboard grab is needed in the virtual
keyboard to be usable with the arrow keys.


>
> >> Clients need to cope with losing mouse and keyboard focus at any
> >> time,
> >> and with seats going away at any time. It's just how it is.
> >
> > Toolkits are nothing else than giant state machines, they rely on a
> > meaningful event order, or some proper notification when things go
> > south. If you mess with that, you'll get clients in inconsistent
> > states, including:
> >
> > - stuck buttons
> > - gestures listening to vanished touch sequences, unable to trigger
> > anymore
> > - stuck repeat keys


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

Re: [PATCH v2 weston 00/16] Atomic modesetting support

[Daniel Stone]

Hi,

On 11 July 2015 at 02:05, Bryce Harrington  wrote:
> On Fri, Jun 26, 2015 at 02:16:55PM -0500, Derek Foreman wrote:
>> On 22/06/15 11:25 AM, Daniel Stone wrote:
>> > Hi,
>> > Thanks to everyone who reviewed the previous series. This new series
>> > cleans up the previous patches, introduces a few fixes (e.g. not relying
>> > on a repaint to pull us out of DPMS), and crucially adds support for the
>> > libdrm TEST_ONLY interface (allowing us to check before we commit, e.g.
>> > that a particular plane combination is workable), using the new cursor
>> > API from libdrm.
>>
>> Everything up to and including 8/16 seems like beneficial clean-up or
>> bug fix that could land independently of later bits?
>>
>> For that half,
>> Reviewed-By: Derek Foreman 
>>
>> (The rest I haven't had a chance to look at yet)
>
> At least for patches 1-6 I tend to agree; they're good cleanup or
> refactoring, and no reason not to just get them landed.  Patch 7 started
> to look a bit more ambitious to me so I stopped there.  But with 1-6,
> might save time having to rebase them.  Unfortunately they already don't
> apply, but if you can split them out from the remainder of the patchset,
> I'd be +1 for just landing them immediately.

Thanks for this. I've rebased the first six across the libweston
divide and pushed those now. I think 7-10 should be very uninvasive
once rebased as well; it's only where we get to 11 and upwards that it
starts getting a bit hairy.

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

Re: [PATCH v2 weston 04/16] compositor-drm: Record current DPMS level

[Daniel Stone]

Hi,

On 11 July 2015 at 01:58, Bryce Harrington  wrote:
> On Mon, Jun 22, 2015 at 05:25:09PM +0100, Daniel Stone wrote:
>> + ret = drmModeConnectorSetProperty(c->drm.fd, output->connector_id,
>> +   output->dpms_prop->prop_id, level);
>> + if (ret) {
>
> Just a nitpick, but we don't actually use ret for anything other than
> this test.  Maybe save the variable and just do "if
> (drmModeConnectorSetProperty(..." ?

I'd actually prefer not to, just for readability/consistency's sake.
Thanks though. :)

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

Re: [PATCH v3 weston] Introduce wl_relative_pointer interface

[Benjamin Tissoires]

On Thu, Jul 16, 2015 at 3:37 AM, Peter Hutterer
 wrote:
> On Thu, Jul 16, 2015 at 03:23:20PM +0800, Jonas Ådahl wrote:
>> On Thu, Jul 16, 2015 at 03:37:30PM +0900, x414e54 wrote:
>> > On Wed, Jul 15, 2015 at 11:55 AM, Peter Hutterer
>> >  wrote:
>> > > On Wed, Jul 15, 2015 at 08:23:09AM +0900, x414e54 wrote:
>> > >> Hi,
>> > >>
>> > >> Just a quick questions:
>> > >>
>> > >> 1) Is there any way to un-normalize the values?
>> > >
>> > > not at this point, no.
>> > > fwiw as of libinput 0.19 the normalization only applies to the 
>> > > accelerated
>> > > delta, the unaccelerated one is generally in device-specific units. 
>> > > Except
>> > > on touchpads, where we still normalize it to a 1000dpi mouse, we may 
>> > > review
>> > > that at some point. but since the normalization is "magic", you can't
>> > > unnormalize them.
>> >
>> > Unaccelerated un-normalzied is fine. But it would be nice to have this
>> > reflected in the wayland spec just to make sure it is consistent
>> > between window managers.
>>
>> I have no objections to removing the note about the compositor having
>> applied the normalizations, partly because it is not correct when
>> running on libinput anymore, but also because it might not be a good
>> idea to be to specific about how they look as at some backends we might
>> not be able to provide exactly that type of information (remote desktop
>> for example).
>>
>> >
>> > >
>> > >> 2) What happens with >1000hz gaming mice for example which need
>> > >> microsecond granularity timestamps?
>> > >
>> > > naïve question: do people notice the difference between 1000Hz and 
>> > > 2000Hz?
>> >
>> > You could probably say the same for 500hz and 1000hz mice. I do not
>> > think it is your/our place to say if someone would notice or not, some
>> > people may some people might not.
>> >
>> > Not necessarily mice but definitely when using head tracking and eye
>> > tracking it is noticeable. Also it helps you to create more accurate
>> > prediction and allows you to render frames ahead.
>> >
>> > Considering the original events are reported in nanoseconds/ktime if
>> > it came from evdev? (I may be wrong). It does not seem like too much
>> > trouble just to pass the original nanosecond time along even if it is
>> > in two 32 bit integers sec and nsec.
>>
>> Libinput exposes the time value as a uint32_t in milleseconds. It gets
>> the timestamp from a 'struct timeval' which is in microseconds. In other
>> words, we'd need to expose the lost time data via additional API in
>> libinput. I'm no input device expert so I'm not going to have any strong
>> objections to adding more information, unless someone have an objective
>> objection to it.
>>
>> How correct are the timestamps from the kernel for such devices?
>
> honestly not sure, but even if they're not as precise now any increase in
> precision would automatically feed through to everything else in the stack
> if we expose the time in finer-grained units. so adding a get_time_usec()
> for all the events seems sensible. not sure about nsec being worthwhile
> though.
> Benjamin, what's the precision in HID?
>

There is no formal rule for HID. It depends on the USB connection and speed.
For most of generic unifying Logitech devices they are reporting one
report every 8 ms (125Hz). But Logitech had to develop special
receivers for their gaming mice to be able to report 1000Hz. And those
1000Hz mice are still using HID.
So I believe if the hardware makers were capable of reporting 100K Hz,
they would do it :)

Cheers,
Benjamin

> Cheers,
>Peter
>
>> > There is one mouse available called the Asus ROG Gladius. So there are
>> > definitely people using it now.
>> >
>> > >
>> > > Cheers,
>> > >Peter
>> > >
>> > >> On Mon, Jun 29, 2015 at 3:54 PM, Peter Hutterer
>> > >>  wrote:
>> > >> > On Fri, Jun 26, 2015 at 12:38:01PM +0800, Jonas Ådahl wrote:
>> > >> >> A wl_relative_pointer object is an extension to the wl_pointer 
>> > >> >> interface
>> > >> >> only used for emitting relative pointer events. It will only emit 
>> > >> >> events
>> > >> >> when the parent pointer has focus.
>> > >> >>
>> > >> >> To get a relative pointer object, use the get_relative_pointer 
>> > >> >> request
>> > >> >> of the global wl_relative_pointer_manager object. When stabilizing it
>> > >> >> might make more sense to just add it to wl_seat instead of having a
>> > >> >> single use global interface.
>> > >> >>
>> > >> >> All interface names are currently prefixed with underscore in order 
>> > >> >> to
>> > >> >> avoid any future conflicts with stable protocol.
>> > >> >>
>> > >> >> Signed-off-by: Jonas Ådahl 
>> > >> >> ---
>> > >> >>
>> > >> >> Changes since v2:
>> > >> >>
>> > >> >>  * Updated copyright.
>> > >> >>  * Updated the license text to corrected one.
>> > >> >>  * Clarified that relative motion events are unaffected by clamping.
>> > >> >>  * Clarified that pointer acceleration behaviour is device specific.
>> > >> >>  * Clarified that the order of relati

Re: weston-desktop-shell

[Pekka Paalanen]

On Thu, 16 Jul 2015 11:06:38 +
Nancy Zou  wrote:

> Hi pekka
> 
> >>Btw. even the 3 seconds sounds awfully long. What platform is this
> >>and which backend/renderer?
> Fbdev backend, gl renderer

Ah, the unholy combination.

> >>Did you pass some --with-cairo= option to Weston's configure?
> --With-cairo=image

Good.

> >>Does the desktop fade in from black, or does it just jump out after
> >>3 seconds?
>  No black screen with Weston-desktop-shell. But if use other clients,
> there is black screen first.  
> 
> The Weston-desktop-shell start need about 1.5s. After start
> Weston-desktop-shell, then start my own launcher need about 3s. I
> used to start my launcher instead of Weston-desktop-shell, it need to
> cost 15s.
> 
> Part of my Weston.ini
> [core]
> shell=/usr/lib/weston/desktop-shell.so
> backend=/usr/lib/weston/fbdev-backend.so
> 
> [shell]
> background-color=0xff002244
> background-type=tile
> panel-color=0x90ff
> locking=true
> animation=zoom
> startup-animation=fade
> #client=/usr/bin/launcher
> client=/usr/lib/weston/weston-desktop-shell

Odd. You definitely should be getting first a black screen which then
fades to the desktop once weston-desktop-shell signals ready, because
you have startup-animation=fade.

> >>The 16 seconds delay happens because the application you replaced
> >>weston-desktop-shell with does not do the job of
> >>weston-desktop-shell. There is a 15 second timeout to show the
> >>desktop in case weston-desktop-shell fails to signal ready.
> 
> Thank you for your details. Does it means the desktop shell need to
> check the signal or the compositor?

It's the "desktop_ready" request in desktop-shell.xml.

But really, that is just one of the many things a weston-desktop-shell
replacement needs to handle. You can't plug a random app there.

Weston currently does not have a feature to start arbitrary clients on
start-up. It has been discussed but not implemented yet.


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

[PATCH wayland 1/2] scanner: refactor creating objects and get rid of leaks

[Marek Chalupa]

Create functions for structures allocation (instead of inlining it into
the code) and free the objects after we don't use them anymore.

Signed-off-by: Marek Chalupa 
---
 src/scanner.c | 266 +-
 1 file changed, 209 insertions(+), 57 deletions(-)

diff --git a/src/scanner.c b/src/scanner.c
index 7d8cfb9..c652612 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1,6 +1,7 @@
 /*
  * Copyright © 2008-2011 Kristian Høgsberg
  * Copyright © 2011 Intel Corporation
+ * Copyright © 2015 Red Hat, Inc.
  *
  * Permission is hereby granted, free of charge, to any person obtaining
  * a copy of this software and associated documentation files (the
@@ -316,6 +317,185 @@ is_nullable_type(struct arg *arg)
 }
 
 static void
+free_description(struct description *desc)
+{
+   free(desc->summary);
+   free(desc->text);
+
+   free(desc);
+}
+
+static struct message *
+create_message(struct location loc, const char *name)
+{
+   struct message *message;
+
+   message = xmalloc(sizeof *message);
+   message->loc = loc;
+   message->name = xstrdup(name);
+   message->uppercase_name = uppercase_dup(name);
+   wl_list_init(&message->arg_list);
+   message->arg_count = 0;
+   message->new_id_count = 0;
+   message->description = NULL;
+
+   return message;
+}
+
+static struct arg *
+create_arg(const char *name, const char *type)
+{
+   struct arg *arg;
+
+   arg = xmalloc(sizeof *arg);
+   arg->name = xstrdup(name);
+   arg->summary = NULL;
+   arg->interface_name = NULL;
+
+   if (strcmp(type, "int") == 0)
+   arg->type = INT;
+   else if (strcmp(type, "uint") == 0)
+   arg->type = UNSIGNED;
+   else if (strcmp(type, "fixed") == 0)
+   arg->type = FIXED;
+   else if (strcmp(type, "string") == 0)
+   arg->type = STRING;
+   else if (strcmp(type, "array") == 0)
+   arg->type = ARRAY;
+   else if (strcmp(type, "fd") == 0)
+   arg->type = FD;
+   else if (strcmp(type, "new_id") == 0)
+   arg->type = NEW_ID;
+   else if (strcmp(type, "object") == 0)
+   arg->type = OBJECT;
+   else
+   return NULL;
+
+   return arg;
+}
+
+static void
+free_arg(struct arg *arg)
+{
+   free(arg->name);
+   free(arg->interface_name);
+   free(arg->summary);
+   free(arg);
+}
+
+static void
+free_message(struct message *message)
+{
+   struct arg *a, *a_next;
+
+   free(message->name);
+   free(message->uppercase_name);
+   if (message->description)
+   free_description(message->description);
+
+   wl_list_for_each_safe(a, a_next, &message->arg_list, link)
+   free_arg(a);
+
+   free(message);
+}
+
+static struct enumeration *
+create_enumeration(const char *name)
+{
+   struct enumeration *enumeration;
+
+   enumeration = xmalloc(sizeof *enumeration);
+   enumeration->name = xstrdup(name);
+   enumeration->uppercase_name = uppercase_dup(name);
+   enumeration->description = NULL;
+
+   wl_list_init(&enumeration->entry_list);
+
+   return enumeration;
+}
+
+static struct entry *
+create_entry(const char *name, const char *value)
+{
+   struct entry *entry;
+
+   entry = xmalloc(sizeof *entry);
+   entry->name = xstrdup(name);
+   entry->uppercase_name = uppercase_dup(name);
+   entry->value = xstrdup(value);
+
+   return entry;
+}
+
+static void
+free_entry(struct entry *entry)
+{
+   free(entry->name);
+   free(entry->uppercase_name);
+   free(entry->value);
+   free(entry->summary);
+
+   free(entry);
+}
+
+static void
+free_enumeration(struct enumeration *enumeration)
+{
+   struct entry *e, *e_next;
+
+   free(enumeration->name);
+   free(enumeration->uppercase_name);
+
+   if (enumeration->description)
+   free_description(enumeration->description);
+
+   wl_list_for_each_safe(e, e_next, &enumeration->entry_list, link)
+   free_entry(e);
+
+   free(enumeration);
+}
+
+static struct interface *
+create_interface(struct location loc, const char *name, int version)
+{
+   struct interface *interface;
+
+   interface = xmalloc(sizeof *interface);
+   interface->loc = loc;
+   interface->name = xstrdup(name);
+   interface->uppercase_name = uppercase_dup(name);
+   interface->version = version;
+   interface->description = NULL;
+   interface->since = 1;
+   wl_list_init(&interface->request_list);
+   wl_list_init(&interface->event_list);
+   wl_list_init(&interface->enumeration_list);
+
+   return interface;
+}
+
+static void
+free_interface(struct interface *interface)
+{
+   struct message *m, *next_m;
+   struct enumeration *e, *next_e;
+
+   free(interface->name);
+   free(interface->uppercase_name);
+   if (interface->description)

[PATCH wayland 2/2] scanner: wrap few long lines

[Marek Chalupa]

Wrap few long lines to the length around 80 chars

Signed-off-by: Marek Chalupa 
---
 src/scanner.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/scanner.c b/src/scanner.c
index c652612..ac511f1 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -597,7 +597,8 @@ start_element(void *data, const char *element_name, const 
char **atts)
message->since = version;
 
if (strcmp(name, "destroy") == 0 && !message->destructor)
-   fail(&ctx->loc, "destroy request should be destructor 
type");
+   fail(&ctx->loc,
+"destroy request should be destructor type");
 
ctx->message = message;
} else if (strcmp(element_name, "arg") == 0) {
@@ -620,7 +621,9 @@ start_element(void *data, const char *element_name, const 
char **atts)
break;
default:
if (interface_name != NULL)
-   fail(&ctx->loc, "interface attribute not 
allowed for type %s", type);
+   fail(&ctx->loc,
+"interface attribute not allowed for type"
+" %s", type);
break;
}
 
@@ -629,10 +632,14 @@ start_element(void *data, const char *element_name, const 
char **atts)
else if (strcmp(allow_null, "true") == 0)
arg->nullable = 1;
else
-   fail(&ctx->loc, "invalid value for allow-null attribute 
(%s)", allow_null);
+   fail(&ctx->loc,
+"invalid value for allow-null attribute (%s)",
+allow_null);
 
if (allow_null != NULL && !is_nullable_type(arg))
-   fail(&ctx->loc, "allow-null is only valid for objects, 
strings, and arrays");
+   fail(&ctx->loc,
+"allow-null is only valid for objects, strings,"
+" and arrays");
 
if (summary)
arg->summary = xstrdup(summary);
-- 
2.4.3

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

Re: [PATCH weston v3 0/5] Fast repaint loop start on DRM

[Pekka Paalanen]

On Tue,  7 Jul 2015 12:53:09 +0300
Pekka Paalanen  wrote:

> From: Pekka Paalanen 
> 
> Hi,
> 
> as promised in
> http://lists.freedesktop.org/archives/wayland-devel/2015-July/023192.html here
> are the patches. The above-mentioned email contains an analysis of the effects
> of these patches.
> 
> My modifications are mostly stylish and code re-use. millihz_to_nsec() was
> suggested by Daniel Stone.
> 
> This series supersedes the patches 7, 8, and 9 of
> http://lists.freedesktop.org/archives/wayland-devel/2015-June/022785.html
> 
> Mario Kleiner (3):
>   presentation-shm: Allow setting of delay before surface.commit
>   compositor-drm: Allow instant start of repaint loop. (v3)
>   compositor: Respect repaint-window when restarting repaint loop.
> 
> Pekka Paalanen (2):
>   shared: introduce timespec-util.h
>   compositor,shared: add millihz_to_nsec()
> 
>  Makefile.am|  2 ++
>  clients/presentation-shm.c | 48 -
>  shared/timespec-util.h | 75 
> ++
>  src/compositor-drm.c   | 39 +++-
>  src/compositor.c   | 30 ++-
>  5 files changed, 165 insertions(+), 29 deletions(-)
>  create mode 100644 shared/timespec-util.h
> 

Hi,

since no-one has commented anything and I'm confident with these
patches, I have pushed them:
   2abe445..b7df04e  master -> master


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

RE: weston-desktop-shell

[Nancy Zou]

Hi pekka

>>Btw. even the 3 seconds sounds awfully long. What platform is this and which 
>>backend/renderer?
Fbdev backend, gl renderer

>>Did you pass some --with-cairo= option to Weston's configure?
--With-cairo=image

>>Does the desktop fade in from black, or does it just jump out after 3 seconds?
 No black screen with Weston-desktop-shell. But if use other clients, there is 
black screen first.  

The Weston-desktop-shell start need about 1.5s. After start 
Weston-desktop-shell, then start my own launcher need about 3s. I used to start 
my launcher instead of Weston-desktop-shell, it need to cost 15s.

Part of my Weston.ini
[core]
shell=/usr/lib/weston/desktop-shell.so
backend=/usr/lib/weston/fbdev-backend.so

[shell]
background-color=0xff002244
background-type=tile
panel-color=0x90ff
locking=true
animation=zoom
startup-animation=fade
#client=/usr/bin/launcher
client=/usr/lib/weston/weston-desktop-shell



>>The 16 seconds delay happens because the application you replaced 
>>weston-desktop-shell with does not do the job of weston-desktop-shell.
>>There is a 15 second timeout to show the desktop in case weston-desktop-shell 
>>fails to signal ready.

Thank you for your details. Does it means the desktop shell need to check the 
signal or the compositor?


Best Regards
Nancy






Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our 
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, 
www.youtube.com/user/CSRplc, Facebook, 
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at 
www.twitter.com/CSR_plc.
You can now access the wide range of products powered by aptX at www.aptx.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: weston-desktop-shell

[Pekka Paalanen]

On Thu, 16 Jul 2015 12:18:03 +0300
Pekka Paalanen  wrote:

> On Thu, 16 Jul 2015 08:17:58 +
> Nancy Zou  wrote:
> 
> > Dear all:
> > 
> > When I set other Weston clients in the Weston.ini instead of
> > Weston-deskto-shell, then start Weston is very slow. It cost about
> > 16s. The Weston-desk-shell only cost 3s. Does there any big
> > difference between Weston-desktop-shell and other Weston client
> > examples(for example, Weston-fullscreen)?
> > 
> > It is really puzzle me, could anyone can give me some hints. Thank
> > you.
> 
> I don't know about the slowness, but you are not meant to put random
> Wayland apps in place of weston-desktop-shell.
> 
> Weston-desktop-shell is a special helper client to the desktop shell
> plugin of Weston, and it has special responsibilities and privileges.
> If a client running in its stead does not implement those
> responsibilities, the desktop does not work as expected.

Btw. even the 3 seconds sounds awfully long. What platform is this and
which backend/renderer?

Did you pass some --with-cairo= option to Weston's configure?

Does the desktop fade in from black, or does it just jump out after 3
seconds?

Does it make a difference if you put

[shell]
startup-animation=none

in your weston.ini?

The 16 seconds delay happens because the application you replaced
weston-desktop-shell with does not do the job of weston-desktop-shell.
There is a 15 second timeout to show the desktop in case
weston-desktop-shell fails to signal ready.


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

Re: [PATCH weston] README: introduce libweston

[Pekka Paalanen]

On Wed, 15 Jul 2015 07:36:50 -0700
"Jon A. Cruz"  wrote:

> Factoring in the comments by Bryce, this looks good to me.
> 
> Acked-by: Jon A. Cruz 
> 
> On 07/14/2015 03:07 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > What is libweston and where do we intend to go with it.
> > 
> > Cc: Giulio Camuffo 
> > Signed-off-by: Pekka Paalanen 
> > ---
> >  README | 139 
> > -
> >  1 file changed, 138 insertions(+), 1 deletion(-)

Thank you for the acks, all. I did the changes Bryce suggested, almost
verbatim, and pushed:
   21deb28..2abe445  master -> master


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

Re: weston-desktop-shell

[Pekka Paalanen]

On Thu, 16 Jul 2015 08:17:58 +
Nancy Zou  wrote:

> Dear all:
> 
> When I set other Weston clients in the Weston.ini instead of
> Weston-deskto-shell, then start Weston is very slow. It cost about
> 16s. The Weston-desk-shell only cost 3s. Does there any big
> difference between Weston-desktop-shell and other Weston client
> examples(for example, Weston-fullscreen)?
> 
> It is really puzzle me, could anyone can give me some hints. Thank
> you.

I don't know about the slowness, but you are not meant to put random
Wayland apps in place of weston-desktop-shell.

Weston-desktop-shell is a special helper client to the desktop shell
plugin of Weston, and it has special responsibilities and privileges.
If a client running in its stead does not implement those
responsibilities, the desktop does not work as expected.


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

Re: [PATCH weston 0/2] transform refactoring in ivi-shell

[Pekka Paalanen]

On Wed, 15 Jul 2015 14:03:01 +0900
Nobuhiko Tanibata  wrote:

> Hi,
> 
> Current code in ivi-shell to transform a surface to global_matrix is not 
> readable very much. This patch set improves it. This consists of two 
> patches,
> 
> - remove transform part once to add transform logic from scratch.
> - add transform logic as more readable way.

Hi Tanibata-san,

these two and "ivi-shell: remove one indent level from update_prop()"
pushed:
   8c7287f..21deb28  master -> master


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

weston-desktop-shell

[Nancy Zou]

Dear all:

When I set other Weston clients in the Weston.ini instead of 
Weston-deskto-shell, then start Weston is very slow. It cost about 16s. The 
Weston-desk-shell only cost 3s.
Does there any big difference between Weston-desktop-shell and other Weston 
client examples(for example, Weston-fullscreen)?

It is really puzzle me, could anyone can give me some hints. Thank you.

Best Regards
Nancy



Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our 
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, 
www.youtube.com/user/CSRplc, Facebook, 
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at 
www.twitter.com/CSR_plc.
You can now access the wide range of products powered by aptX at www.aptx.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] README: introduce libweston

[Pekka Paalanen]

On Wed, 15 Jul 2015 09:52:38 -0700
Bryce Harrington  wrote:

> On Wed, Jul 15, 2015 at 01:03:24PM +0100, Daniel Stone wrote:
> > Hi,
> > 
> > On 14 July 2015 at 11:07, Pekka Paalanen  wrote:
> > > From: Pekka Paalanen 
> > >
> > > What is libweston and where do we intend to go with it.
> > 
> > Sounds good to me, although the bit about always using
> > --with-cairo=image just makes me lean even more towards removing the
> > other options.
> 
> What exactly does that affect inside Weston?  Is it just some of the
> example clients, or does it affect stuff that actual users would care
> about?

It mainly affects the toytoolkit, which flavour of Cairo it will use
for everything. It doesn't affect the compositor as such, but as it
affects all demo clients which includes weston-desktop-shell, it will
impact all users.

Until we actually fix that, I recommend people to build with the
default flavour "image".

A quick fix would be to have a runtime switch in toytoolkit to ask for
cairo-egl, and default to cairo-image. This way we'd limit the
cairo-egl impact to just the demos that actually ask for it.

A more involved fix would be to get rid of cairo-egl completely, and
remove the support from toytoolkit. Then demos that depended on it
would need to get their decorations drawn with cairo-image, copied into
textures, and blitted in GL to the surface.


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

Re: [PATCH wayland] protocol: Add pointer gestures (swipe/pinch) protocol

[Pekka Paalanen]

On Wed, 15 Jul 2015 20:02:10 +0200
Carlos Garnacho  wrote:

> The lifetime and progress of gestures is maintained by the separate
> wl_pointer_gesture_pinch and wl_pointer_gesture_swipe interfaces,
> each of these has begin/update(optional)/end phases, as transmitted
> by their events.
> 
> The gesture interfaces can be obtained from the wl_pointer, and
> must be interpreted on the last surface entered by the pointer,
> starting from the pointer coordinates.
> 
> Signed-off-by: Carlos Garnacho 
> ---
>  protocol/wayland.xml | 153 
> ++-
>  1 file changed, 151 insertions(+), 2 deletions(-)

Hi,

just two drive-by comments:

> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 42c9309..51effad 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1329,7 +1329,7 @@
>  
> 
>  
> -  
> +  
>  
>A seat is a group of keyboards, pointer and touch devices. This
>object is published as a global during start up, or when such a
> @@ -1402,7 +1402,139 @@
>  
>
>  
> -  
> +  
> +
> +  A swipe gesture object notifies a client about a multi-finger swipe
> +  gesture detected on an indirect input device such as a touchpad.
> +  The gesture is usually initiated by multiple fingers moving in the
> +  same direction but once initiated the direction may change.
> +  The precise conditions of when such a gesture is detected are
> +  implementation-dependent.
> +
> +  A gesture consists of three stages: begin, update (optional) and end.
> +
> +  A gesture may be cancelled by the compositor or the hardware.
> +  Destructive actions should not be considered until the end of a
> +  gesture has been received.
> +
> +
> +

Name this "destroy". Then it will match wl_blah_destroy() so we get
both destruction request and wl_proxy freeing with the same call and
there won't be a misleading wl_blah_destroy() function defined that
won't send the request. Also mark it as a destructor.

The old wl_pointer etc. interfaces only have a "release" request,
because they did not define destructor protocol at all when first
introduced (a mistake), and adding it later is not possible. So the
"release" request is a workaround for a server-side object leak (that
gets cleaned up only when the whole client disconnects).

wayland-scanner will always generate a wl_blah_destroy() function that
will free the proxy. Making it also send a request is up to the protocol
spec.

See e.g. wl_region for an example of a destructor.

> +  
> +

> +  
> +
> +  A swipe gesture object notifies a client about a multi-finger pinch
> +  gesture detected on an indirect input device such as a touchpad.
> +  The gesture is usually initiated by multiple fingers moving towards
> +  each other or away from each other, or by two or more fingers rotating
> +  around a logical center of gravity.  The precise conditions of when
> +  such a gesture is detected are implementation-dependent.
> +
> +  A gesture consists of three stages: begin, update (optional) and end.
> +
> +  A gesture may be cancelled by the compositor or the hardware.
> +  Destructive actions should not be considered until the end of a
> +  gesture has been received.
> +
> +
> +

Here too.


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

Re: [PATCH wayland 3/3] shm: wl_shm_buffer_get_data() requires a valid pool.

[Hardening]

Le 01/07/2015 12:52, Marek Chalupa a écrit :
> 
> 
> On Wed, Jul 1, 2015 at 11:25 AM, Marek Chalupa  > wrote:
> 
> 
> 
> On Fri, Jun 26, 2015 at 6:35 PM, Derek Foreman
> mailto:der...@osg.samsung.com>> wrote:
> 
> There's no situation where a shm buffer without a pool makes sense,
> so we enforce the pool's existence a little more rigidly.
> 
> Signed-off-by: Derek Foreman  >
> ---
>  src/wayland-shm.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
> index da11743..79b3886 100644
> --- a/src/wayland-shm.c
> +++ b/src/wayland-shm.c
> @@ -353,10 +353,12 @@ wl_shm_buffer_get_stride(struct
> wl_shm_buffer *buffer)
>  WL_EXPORT void *
>  wl_shm_buffer_get_data(struct wl_shm_buffer *buffer)
>  {
> -   if (buffer->pool)
> -   return buffer->pool->data + buffer->offset;
> -   else
> -   return buffer + 1;
> +   assert(buffer->pool);
> +
> +   if (!buffer->pool)
> +   return NULL;
> 
> 
> This condition is never true if the assert passed
> 
>  
> Yeah, but in non-debug build we do not have the assert, so it may make
> sense to have this doubled. Ok.
>  

I find it a little strange, that something that abort() in debug mode,
just "silently" return NULL in production mode...

Checking with the Eclipse "Call hierarchy" tool, none of the callers of
wl_shm_buffer_get_data() check the return value, so we may detect the
bug quite far from the real source.

So my suggestion is either wl_shm_buffer_get_data is a "succeed or kill
program" function (like xyzalloc functions), or the callers have to be
updated if we can live with buffer->pool == NULL.

Best regards.
-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH wayland] shm: add getters for the fd and offset

[Hardening]

Le 01/07/2015 10:25, Giulio Camuffo a écrit :
> This allows to share the buffer data by mmapping the fd again.
> ---
>  src/wayland-server-core.h |  6 ++
>  src/wayland-shm.c | 16 +++-
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 

Reviewed-by: David FORT 

> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
> index 7d03789..938cdf7 100644
> --- a/src/wayland-server-core.h
> +++ b/src/wayland-server-core.h
> @@ -396,6 +396,12 @@ wl_shm_buffer_create(struct wl_client *client,
>uint32_t id, int32_t width, int32_t height,
>int32_t stride, uint32_t format);
>  
> +int
> +wl_shm_buffer_get_offset(struct wl_shm_buffer *buffer);
> +
> +int
> +wl_shm_buffer_get_fd(struct wl_shm_buffer *buffer);
> +
>  void wl_log_set_handler_server(wl_log_func_t handler);
>  
>  #ifdef  __cplusplus
> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
> index b6b31d6..c85e839 100644
> --- a/src/wayland-shm.c
> +++ b/src/wayland-shm.c
> @@ -52,6 +52,7 @@ struct wl_shm_pool {
>   int refcount;
>   char *data;
>   int32_t size;
> + int fd;
>  };
>  
>  struct wl_shm_buffer {
> @@ -77,6 +78,7 @@ shm_pool_unref(struct wl_shm_pool *pool)
>   return;
>  
>   munmap(pool->data, pool->size);
> + close(pool->fd);
>   free(pool);
>  }
>  
> @@ -250,7 +252,7 @@ shm_create_pool(struct wl_client *client, struct 
> wl_resource *resource,
>  "failed mmap fd %d", fd);
>   goto err_close;
>   }
> - close(fd);
> + pool->fd = fd;
>  
>   pool->resource =
>   wl_resource_create(client, &wl_shm_pool_interface, 1, id);
> @@ -409,6 +411,18 @@ wl_shm_buffer_get_height(struct wl_shm_buffer *buffer)
>   return buffer->height;
>  }
>  
> +WL_EXPORT int
> +wl_shm_buffer_get_offset(struct wl_shm_buffer *buffer)
> +{
> + return buffer->offset;
> +}
> +
> +WL_EXPORT int
> +wl_shm_buffer_get_fd(struct wl_shm_buffer *buffer)
> +{
> + return buffer->pool->fd;
> +}
> +
>  static void
>  reraise_sigbus(void)
>  {
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH v3 weston] Introduce wl_relative_pointer interface

[Peter Hutterer]

On Thu, Jul 16, 2015 at 03:23:20PM +0800, Jonas Ådahl wrote:
> On Thu, Jul 16, 2015 at 03:37:30PM +0900, x414e54 wrote:
> > On Wed, Jul 15, 2015 at 11:55 AM, Peter Hutterer
> >  wrote:
> > > On Wed, Jul 15, 2015 at 08:23:09AM +0900, x414e54 wrote:
> > >> Hi,
> > >>
> > >> Just a quick questions:
> > >>
> > >> 1) Is there any way to un-normalize the values?
> > >
> > > not at this point, no.
> > > fwiw as of libinput 0.19 the normalization only applies to the accelerated
> > > delta, the unaccelerated one is generally in device-specific units. Except
> > > on touchpads, where we still normalize it to a 1000dpi mouse, we may 
> > > review
> > > that at some point. but since the normalization is "magic", you can't
> > > unnormalize them.
> > 
> > Unaccelerated un-normalzied is fine. But it would be nice to have this
> > reflected in the wayland spec just to make sure it is consistent
> > between window managers.
> 
> I have no objections to removing the note about the compositor having
> applied the normalizations, partly because it is not correct when
> running on libinput anymore, but also because it might not be a good
> idea to be to specific about how they look as at some backends we might
> not be able to provide exactly that type of information (remote desktop
> for example).
> 
> > 
> > >
> > >> 2) What happens with >1000hz gaming mice for example which need
> > >> microsecond granularity timestamps?
> > >
> > > naïve question: do people notice the difference between 1000Hz and 2000Hz?
> > 
> > You could probably say the same for 500hz and 1000hz mice. I do not
> > think it is your/our place to say if someone would notice or not, some
> > people may some people might not.
> > 
> > Not necessarily mice but definitely when using head tracking and eye
> > tracking it is noticeable. Also it helps you to create more accurate
> > prediction and allows you to render frames ahead.
> > 
> > Considering the original events are reported in nanoseconds/ktime if
> > it came from evdev? (I may be wrong). It does not seem like too much
> > trouble just to pass the original nanosecond time along even if it is
> > in two 32 bit integers sec and nsec.
> 
> Libinput exposes the time value as a uint32_t in milleseconds. It gets
> the timestamp from a 'struct timeval' which is in microseconds. In other
> words, we'd need to expose the lost time data via additional API in
> libinput. I'm no input device expert so I'm not going to have any strong
> objections to adding more information, unless someone have an objective
> objection to it.
> 
> How correct are the timestamps from the kernel for such devices?

honestly not sure, but even if they're not as precise now any increase in
precision would automatically feed through to everything else in the stack
if we expose the time in finer-grained units. so adding a get_time_usec()
for all the events seems sensible. not sure about nsec being worthwhile
though.
Benjamin, what's the precision in HID?

Cheers,
   Peter

> > There is one mouse available called the Asus ROG Gladius. So there are
> > definitely people using it now.
> > 
> > >
> > > Cheers,
> > >Peter
> > >
> > >> On Mon, Jun 29, 2015 at 3:54 PM, Peter Hutterer
> > >>  wrote:
> > >> > On Fri, Jun 26, 2015 at 12:38:01PM +0800, Jonas Ådahl wrote:
> > >> >> A wl_relative_pointer object is an extension to the wl_pointer 
> > >> >> interface
> > >> >> only used for emitting relative pointer events. It will only emit 
> > >> >> events
> > >> >> when the parent pointer has focus.
> > >> >>
> > >> >> To get a relative pointer object, use the get_relative_pointer request
> > >> >> of the global wl_relative_pointer_manager object. When stabilizing it
> > >> >> might make more sense to just add it to wl_seat instead of having a
> > >> >> single use global interface.
> > >> >>
> > >> >> All interface names are currently prefixed with underscore in order to
> > >> >> avoid any future conflicts with stable protocol.
> > >> >>
> > >> >> Signed-off-by: Jonas Ådahl 
> > >> >> ---
> > >> >>
> > >> >> Changes since v2:
> > >> >>
> > >> >>  * Updated copyright.
> > >> >>  * Updated the license text to corrected one.
> > >> >>  * Clarified that relative motion events are unaffected by clamping.
> > >> >>  * Clarified that pointer acceleration behaviour is device specific.
> > >> >>  * Clarified that the order of relative_motion and motion is not
> > >> >>guaranteed.
> > >> >>  * Explained that button events etc are to be fetched from the
> > >> >>corresponding wl_pointer object.
> > >> >>  * Clarified that relative motion events are in x/y coordinate space.
> > >> >>  * Added an 'unstable protocol' warning explaining compatibility etc.
> > >> >>
> > >> >>
> > >> >>  Makefile.am   |   7 +-
> > >> >>  protocol/relative-pointer.xml | 127 
> > >> >>  src/compositor.c  |   3 +
> > >> >>  src/compositor.h  |   5 ++
> > >> >>  src/input.c   | 186 
> > >

Re: [PATCH] wayland-server: Fix null pointer dereferencing

[Marek Chalupa]

On 07/16/2015 09:27 AM, Marek Chalupa wrote:

Nice catch (some static analysis tool? :).

I'm not sure if this is the right way to fix it, though. If somebody
calls wl_resource_post_error with NULL resource, it is his fault and
program should crash to reveal this error. So the right fix in this case
would be to delete wl_client_post_no_memory() on line 783 in bind_display.
Can wl_resource_post_error be called on some other place with NULL?
The only thing I can make up is when destroying client - resources are
being destroyed and the first is destroyed display_resource, thus if
any destroy handler after that calls wl_client_post_no_memory, we get
wl_resource_post_error(NULL, ...).

So the fix is correct in the sense that there are paths with resource =
NULL. On the other hand, we'd like to discover cases where programmer
passes NULL. Hmm, maybe something like client->destroying + NULL checks
could solve this. Or we'll just go with this patch - since the NULL
paths are (I hope :) only on client destruction, this should be ok.


Or we could add check to wl_client_post_no_memory(). That would solve 
the problem when client is being destroyed and wl_resource_post_error 
would be untouched and passing NULL would crash the program as "desired".


Hmm.. Still keep the though with client->destroying. If we did:

wl_client_post_no_memory(client)
{
if (client->destroying)
return;

wl_resource_post_error(...);
}

Then all the programming errors would go through, reveling error in 
program, yet calling this on client destruction would be safe.

(We still need to fix bind_display with this approach)

Cheers,
Marek



On 07/16/2015 08:27 AM, Ashim wrote:

Initialising 'wl_client *client = NULL' and checking 'resource' for
NULL and returning if found.
This patch will avoid dereferencing of 'resource' if NULL

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91356

Signed-off-by: Ashim 
---
  src/wayland-server.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index 0f04f66..2a0d19c 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -207,7 +207,7 @@ WL_EXPORT void
  wl_resource_post_error(struct wl_resource *resource,
 uint32_t code, const char *msg, ...)
  {
-struct wl_client *client = resource->client;
+struct wl_client *client = NULL;
  char buffer[128];
  va_list ap;

@@ -215,6 +215,11 @@ wl_resource_post_error(struct wl_resource *resource,
  vsnprintf(buffer, sizeof buffer, msg, ap);
  va_end(ap);

+if (resource == NULL)
+return;
+else
+client = resource->client;
+
  client->error = 1;

  /*


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

Re: [PATCH] wayland-server: Fix null pointer dereferencing

[Marek Chalupa]

On 07/16/2015 09:22 AM, Giulio Camuffo wrote:

2015-07-16 9:27 GMT+03:00 Ashim :

Initialising 'wl_client *client = NULL' and checking 'resource' for NULL and 
returning if found.
This patch will avoid dereferencing of 'resource' if NULL


I think in this case passing a NULL resource to
wl_resource_post_error() is a programming mistake, and it should
crash. If there is the possibility somewhere that the resource is null
it should be checked before calling wl_resource_post_error(), imho.


Yep, agree. But in wayland-server.c on line 783 it is programming 
mistake that should be fixed :)



--
Giulio



Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91356

Signed-off-by: Ashim 
---
  src/wayland-server.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index 0f04f66..2a0d19c 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -207,7 +207,7 @@ WL_EXPORT void
  wl_resource_post_error(struct wl_resource *resource,
uint32_t code, const char *msg, ...)
  {
-   struct wl_client *client = resource->client;
+   struct wl_client *client = NULL;
 char buffer[128];
 va_list ap;

@@ -215,6 +215,11 @@ wl_resource_post_error(struct wl_resource *resource,
 vsnprintf(buffer, sizeof buffer, msg, ap);
 va_end(ap);

+   if (resource == NULL)
+   return;
+   else
+   client = resource->client;
+
 client->error = 1;

 /*
--
1.7.9.5

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

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


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

Re: [PATCH] wayland-server: Fix null pointer dereferencing

[Marek Chalupa]

Nice catch (some static analysis tool? :).

I'm not sure if this is the right way to fix it, though. If somebody 
calls wl_resource_post_error with NULL resource, it is his fault and 
program should crash to reveal this error. So the right fix in this case 
would be to delete wl_client_post_no_memory() on line 783 in bind_display.

Can wl_resource_post_error be called on some other place with NULL?
The only thing I can make up is when destroying client - resources are
being destroyed and the first is destroyed display_resource, thus if
any destroy handler after that calls wl_client_post_no_memory, we get
wl_resource_post_error(NULL, ...).

So the fix is correct in the sense that there are paths with resource = 
NULL. On the other hand, we'd like to discover cases where programmer
passes NULL. Hmm, maybe something like client->destroying + NULL checks 
could solve this. Or we'll just go with this patch - since the NULL 
paths are (I hope :) only on client destruction, this should be ok.


On 07/16/2015 08:27 AM, Ashim wrote:

Initialising 'wl_client *client = NULL' and checking 'resource' for NULL and 
returning if found.
This patch will avoid dereferencing of 'resource' if NULL

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91356

Signed-off-by: Ashim 
---
  src/wayland-server.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index 0f04f66..2a0d19c 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -207,7 +207,7 @@ WL_EXPORT void
  wl_resource_post_error(struct wl_resource *resource,
   uint32_t code, const char *msg, ...)
  {
-   struct wl_client *client = resource->client;
+   struct wl_client *client = NULL;
char buffer[128];
va_list ap;

@@ -215,6 +215,11 @@ wl_resource_post_error(struct wl_resource *resource,
vsnprintf(buffer, sizeof buffer, msg, ap);
va_end(ap);

+   if (resource == NULL)
+   return;
+   else
+   client = resource->client;
+   
client->error = 1;

/*


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

Re: [PATCH v3 weston] Introduce wl_relative_pointer interface

[Jonas Ådahl]

On Thu, Jul 16, 2015 at 03:37:30PM +0900, x414e54 wrote:
> On Wed, Jul 15, 2015 at 11:55 AM, Peter Hutterer
>  wrote:
> > On Wed, Jul 15, 2015 at 08:23:09AM +0900, x414e54 wrote:
> >> Hi,
> >>
> >> Just a quick questions:
> >>
> >> 1) Is there any way to un-normalize the values?
> >
> > not at this point, no.
> > fwiw as of libinput 0.19 the normalization only applies to the accelerated
> > delta, the unaccelerated one is generally in device-specific units. Except
> > on touchpads, where we still normalize it to a 1000dpi mouse, we may review
> > that at some point. but since the normalization is "magic", you can't
> > unnormalize them.
> 
> Unaccelerated un-normalzied is fine. But it would be nice to have this
> reflected in the wayland spec just to make sure it is consistent
> between window managers.

I have no objections to removing the note about the compositor having
applied the normalizations, partly because it is not correct when
running on libinput anymore, but also because it might not be a good
idea to be to specific about how they look as at some backends we might
not be able to provide exactly that type of information (remote desktop
for example).

> 
> >
> >> 2) What happens with >1000hz gaming mice for example which need
> >> microsecond granularity timestamps?
> >
> > naïve question: do people notice the difference between 1000Hz and 2000Hz?
> 
> You could probably say the same for 500hz and 1000hz mice. I do not
> think it is your/our place to say if someone would notice or not, some
> people may some people might not.
> 
> Not necessarily mice but definitely when using head tracking and eye
> tracking it is noticeable. Also it helps you to create more accurate
> prediction and allows you to render frames ahead.
> 
> Considering the original events are reported in nanoseconds/ktime if
> it came from evdev? (I may be wrong). It does not seem like too much
> trouble just to pass the original nanosecond time along even if it is
> in two 32 bit integers sec and nsec.

Libinput exposes the time value as a uint32_t in milleseconds. It gets
the timestamp from a 'struct timeval' which is in microseconds. In other
words, we'd need to expose the lost time data via additional API in
libinput. I'm no input device expert so I'm not going to have any strong
objections to adding more information, unless someone have an objective
objection to it.

How correct are the timestamps from the kernel for such devices?


Jonas

> 
> There is one mouse available called the Asus ROG Gladius. So there are
> definitely people using it now.
> 
> >
> > Cheers,
> >Peter
> >
> >> On Mon, Jun 29, 2015 at 3:54 PM, Peter Hutterer
> >>  wrote:
> >> > On Fri, Jun 26, 2015 at 12:38:01PM +0800, Jonas Ådahl wrote:
> >> >> A wl_relative_pointer object is an extension to the wl_pointer interface
> >> >> only used for emitting relative pointer events. It will only emit events
> >> >> when the parent pointer has focus.
> >> >>
> >> >> To get a relative pointer object, use the get_relative_pointer request
> >> >> of the global wl_relative_pointer_manager object. When stabilizing it
> >> >> might make more sense to just add it to wl_seat instead of having a
> >> >> single use global interface.
> >> >>
> >> >> All interface names are currently prefixed with underscore in order to
> >> >> avoid any future conflicts with stable protocol.
> >> >>
> >> >> Signed-off-by: Jonas Ådahl 
> >> >> ---
> >> >>
> >> >> Changes since v2:
> >> >>
> >> >>  * Updated copyright.
> >> >>  * Updated the license text to corrected one.
> >> >>  * Clarified that relative motion events are unaffected by clamping.
> >> >>  * Clarified that pointer acceleration behaviour is device specific.
> >> >>  * Clarified that the order of relative_motion and motion is not
> >> >>guaranteed.
> >> >>  * Explained that button events etc are to be fetched from the
> >> >>corresponding wl_pointer object.
> >> >>  * Clarified that relative motion events are in x/y coordinate space.
> >> >>  * Added an 'unstable protocol' warning explaining compatibility etc.
> >> >>
> >> >>
> >> >>  Makefile.am   |   7 +-
> >> >>  protocol/relative-pointer.xml | 127 
> >> >>  src/compositor.c  |   3 +
> >> >>  src/compositor.h  |   5 ++
> >> >>  src/input.c   | 186 
> >> >> ++
> >> >>  5 files changed, 309 insertions(+), 19 deletions(-)
> >> >>  create mode 100644 protocol/relative-pointer.xml
> >> >>
> >> >> diff --git a/Makefile.am b/Makefile.am
> >> >> index 0a30cb4..70c436f 100644
> >> >> --- a/Makefile.am
> >> >> +++ b/Makefile.am
> >> >> @@ -105,7 +105,9 @@ nodist_weston_SOURCES = 
> >> >>   \
> >> >>   protocol/presentation_timing-protocol.c \
> >> >>   protocol/presentation_timing-server-protocol.h  \
> >> >>   protocol/scaler-protocol.c  \
> >> >> - protocol/scaler-server-prot

Re: [PATCH] wayland-server: Fix null pointer dereferencing

[Giulio Camuffo]

2015-07-16 9:27 GMT+03:00 Ashim :
> Initialising 'wl_client *client = NULL' and checking 'resource' for NULL and 
> returning if found.
> This patch will avoid dereferencing of 'resource' if NULL

I think in this case passing a NULL resource to
wl_resource_post_error() is a programming mistake, and it should
crash. If there is the possibility somewhere that the resource is null
it should be checked before calling wl_resource_post_error(), imho.

--
Giulio

>
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91356
>
> Signed-off-by: Ashim 
> ---
>  src/wayland-server.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 0f04f66..2a0d19c 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -207,7 +207,7 @@ WL_EXPORT void
>  wl_resource_post_error(struct wl_resource *resource,
>uint32_t code, const char *msg, ...)
>  {
> -   struct wl_client *client = resource->client;
> +   struct wl_client *client = NULL;
> char buffer[128];
> va_list ap;
>
> @@ -215,6 +215,11 @@ wl_resource_post_error(struct wl_resource *resource,
> vsnprintf(buffer, sizeof buffer, msg, ap);
> va_end(ap);
>
> +   if (resource == NULL)
> +   return;
> +   else
> +   client = resource->client;
> +
> client->error = 1;
>
> /*
> --
> 1.7.9.5
>
> ___
> 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