[PATCH libinput] Revert "Expose a custom acceleration profile"

2018-05-20 Thread Peter Hutterer 
This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.

Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.

This reverts commit d8bd650540e68e8b648e76180c5eee0f19a3b893.

Signed-off-by: Peter Hutterer 
---
Just sending this to the list in case anyone noticed the original patch set
and so that the reason for the revert shows up more publicly.

 doc/pointer-acceleration.dox   |  66 -
 doc/svg/ptraccel-curve-example.svg | 290 -
 meson.build|   1 -
 src/evdev.c|  29 +---
 src/filter-custom.c| 216 ---
 src/filter-private.h   |   2 -
 src/filter.c   |   9 --
 src/filter.h   |  12 --
 src/libinput-private.h |   2 -
 src/libinput.c |  14 --
 src/libinput.h |  56 ---
 src/libinput.sym   |   1 -
 tools/libinput-debug-events.man|  10 +-
 tools/libinput-list-devices.c  |   6 +-
 tools/ptraccel-debug.c |  29 +---
 tools/shared.c |  21 ---
 tools/shared.h |   7 +-
 17 files changed, 9 insertions(+), 762 deletions(-)
 delete mode 100644 doc/svg/ptraccel-curve-example.svg
 delete mode 100644 src/filter-custom.c

diff --git a/doc/pointer-acceleration.dox b/doc/pointer-acceleration.dox
index 5e300998..652c72c6 100644
--- a/doc/pointer-acceleration.dox
+++ b/doc/pointer-acceleration.dox
@@ -153,70 +153,4 @@ Pointer acceleration for relative motion on tablet devices 
is a flat
 acceleration, with the speed setting slowing down or speeding up the pointer
 motion by a constant factor. Tablets do not allow for switchable profiles.
 
-@section ptraccel-device-speed Speed-dependent acceleration curve
-
-When the @ref LIBINPUT_CONFIG_ACCEL_PROFILE_DEVICE_SPEED_CURVE profile is
-selected, it is the caller's responsibility to load an acceleration profile
-into the device that maps the device's movement into an accelerated
-movement.
-
-This profile maps input speed in **device units** to an acceleration
-factor. libinput calculates the device's speed based on the deltas and their
-timestamps and applies the factor provided by the acceleration profile to
-the current delta.
-
-@note This profile uses data in device units, an acceleration curve loaded
-by the caller only applies to that device and will not behave the same way
-for other devices.
-
-@dot
-digraph
-{
-   rankdir="LR";
-   node [shape="box";]
-   subgraph cluster0 {
-   history[shape=record,label=" delta(t-1)| 
delta(t-2)| delta(t-3)|  ..."];
-   label = "motion history";
-   }
-   delta[label="delta"];
-   velocity[shape="ellipse"];
-   factor[shape="ellipse"];
-   accel[label="accelerated delta"];
-   curve[label="acceleration curve"];
-
-   delta->velocity;
-   delta->factor;
-   factor->accel;
-   history->velocity;
-
-   velocity->curve;
-   curve->factor;
-}
-@enddot
-
-For example, assume the current delta is (2, 4) which maps to a current
-movement velocity of 10 units per microsecond. libinput looks up the custom
-acceleration function for 10 which may return 3. The accelerated delta thus
-becomes (6, 12).
-
-The profile itself is a curve defined by a number of points on the curve
-mapping speed to an acceleration factor. Between each two curve points,
-libinput provides linear interpolation, most acceleration profiles will thus
-only need to provide a handful of curve points. The following illustration
-shows the acceleration curve defined for the points (10, 0.25), (20, 0.4)
-and (35, 3.0).
-
-@image html ptraccel-curve-example.svg "Interpolation of the acceleration 
curve for three defined points"
-
-As seen in the picture above: given an acceleration factor f(x) and a curve
-defined by the caller for the points
-a, b, and c where a < b < c:
-- if x <= a, f(x) == f(a)
-- if x >= c, f(x) == f(c)
-- if a < x < b: f(x) == the the linear interpolation value between f(a) and 
f(b)
-- if b < x < c: f(x) == the the linear interpolation value between f(b) and 
f(c)
-
-The behavior of a a curve is implementation-defined until the caller sets
-curve points.
-
 */
diff --git a/doc/svg/ptraccel-curve-example.svg 
b/doc/svg/ptraccel-curve-example.svg
deleted file mode 100644
index b098e142..
--- a/doc/svg/ptraccel-curve-example.svg
+++ /dev/null
@@ -1,290 +0,0 @@
-
-http://www.w3.org/2000/svg;
- xmlns:xlink="http://www.w3.org/1999/xlink;
->
-
-Gnuplot
-Produced by GNUPLOT 5.0 patchlevel 6 
-
-
-
-

Re: [PATCH v3 1/2] weston-info: Add support for tablet-unstable-v2

2018-05-20 Thread Peter Hutterer 
On Mon, Apr 30, 2018 at 11:35:49AM +0200, w...@ongy.net wrote:
> From: Markus Ongyerth 
> 
> This now prints each tablet seat with at least one tablet/pad/tool
> attached.
> For each tablet seat, each tablet, pad and tool is printed with as much
> detail about the device as the protocol provides.
> Seat info is stored to be referenced, because the protocol requires to
> request a tablet_seat for each wl_seat and it's not guaranteed that the
> tablet_v2_manager is available when seats are advertised.
> 
> Signed-off-by: Markus Ongyerth 
> Acked-by: Pekka Paalanen 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  Makefile.am   |  14 +-
>  clients/weston-info.c | 845 ++
>  2 files changed, 854 insertions(+), 5 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 69ca6cba..ac0f5471 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -824,11 +824,13 @@ weston_simple_im_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  weston_info_SOURCES =\
>   clients/weston-info.c   \
>   shared/helpers.h
> -nodist_weston_info_SOURCES = \
> - protocol/presentation-time-protocol.c   \
> - protocol/presentation-time-client-protocol.h\
> - protocol/linux-dmabuf-unstable-v1-protocol.c\
> - protocol/linux-dmabuf-unstable-v1-client-protocol.h
> +nodist_weston_info_SOURCES = \
> + protocol/presentation-time-protocol.c   \
> + protocol/presentation-time-client-protocol.h\
> + protocol/linux-dmabuf-unstable-v1-protocol.c\
> + protocol/linux-dmabuf-unstable-v1-client-protocol.h \
> + protocol/tablet-unstable-v2-protocol.c  \
> + protocol/tablet-unstable-v2-client-protocol.h
>  weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la
>  weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  
> @@ -888,6 +890,8 @@ BUILT_SOURCES +=  \
>   protocol/ivi-application-client-protocol.h  \
>   protocol/linux-dmabuf-unstable-v1-protocol.c\
>   protocol/linux-dmabuf-unstable-v1-client-protocol.h \
> + protocol/tablet-unstable-v2-protocol.c  \
> + protocol/tablet-unstable-v2-client-protocol.h   \
>   protocol/input-timestamps-unstable-v1-protocol.c\
>   protocol/input-timestamps-unstable-v1-client-protocol.h
>  
> diff --git a/clients/weston-info.c b/clients/weston-info.c
> index 386bd412..6606117a 100644
> --- a/clients/weston-info.c
> +++ b/clients/weston-info.c
> @@ -41,6 +41,7 @@
>  #include "shared/zalloc.h"
>  #include "presentation-time-client-protocol.h"
>  #include "linux-dmabuf-unstable-v1-client-protocol.h"
> +#include "tablet-unstable-v2-client-protocol.h"
>  
>  typedef void (*print_info_t)(void *info);
>  typedef void (*destroy_info_t)(void *info);
> @@ -113,6 +114,7 @@ struct linux_dmabuf_info {
>  
>  struct seat_info {
>   struct global_info global;
> + struct wl_list global_link;
>   struct wl_seat *seat;
>   struct weston_info *info;
>  
> @@ -123,6 +125,75 @@ struct seat_info {
>   int32_t repeat_delay;
>  };
>  
> +struct tablet_v2_path {
> + struct wl_list link;
> + char *path;
> +};
> +
> +struct tablet_tool_info {
> + struct wl_list link;
> + struct zwp_tablet_tool_v2 *tool;
> +
> + uint64_t hardware_serial;
> + uint64_t hardware_id_wacom;
> + enum zwp_tablet_tool_v2_type type;
> + 
> + bool has_tilt;
> + bool has_pressure;
> + bool has_distance;
> + bool has_rotation;
> + bool has_slider;
> + bool has_wheel;
> +};
> +
> +struct tablet_pad_group_info {
> + struct wl_list link;
> + struct zwp_tablet_pad_group_v2 *group;
> +
> + uint32_t modes;
> + size_t button_count;
> + int *buttons;
> + size_t strips;
> + size_t rings;
> +};
> +
> +struct tablet_pad_info {
> + struct wl_list link;
> + struct zwp_tablet_pad_v2 *pad;
> +
> + uint32_t buttons;
> + struct wl_list paths;
> + struct wl_list groups;
> +};
> +
> +struct tablet_info {
> + struct wl_list link;
> + struct zwp_tablet_v2 *tablet;
> +
> + char *name;
> + uint32_t vid, pid;
> + struct wl_list paths;
> +};
> +
> +struct tablet_seat_info {
> + struct wl_list link;
> +
> + struct zwp_tablet_seat_v2 *seat;
> + struct seat_info *seat_info;
> +
> + struct wl_list tablets;
> + struct wl_list tools;
> + struct wl_list pads;
> +};
> +
> +struct tablet_v2_info {
> + struct global_info global;
> + struct zwp_tablet_manager_v2 *manager;
> + struct weston_info *info;
> +
> + struct wl_list seats;
> +};
> +
>  struct presentation_info {
>   struct global_info global;
>   struct wp_presentation

Re: [PATCH v3 2/2] weston-info: destroy wl_keyboard

2018-05-20 Thread Peter Hutterer 
On Mon, Apr 30, 2018 at 11:35:50AM +0200, w...@ongy.net wrote:
> From: Markus Ongyerth 
> 
> Fixes a memory leak by calling wl_keyboard_destroy on a any keyboard

already has my rev-by anyway, but "on a any" seems overly excessive here ;)

Cheers,
   Peter

> that was used to listen for events.
> 
> Signed-off-by: Markus Ongyerth 
> Acked-by: Pekka Paalanen 
> Reviewed-by: Peter Hutterer 
> ---
>  clients/weston-info.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/clients/weston-info.c b/clients/weston-info.c
> index 6606117a..609e270a 100644
> --- a/clients/weston-info.c
> +++ b/clients/weston-info.c
> @@ -118,6 +118,7 @@ struct seat_info {
>   struct wl_seat *seat;
>   struct weston_info *info;
>  
> + struct wl_keyboard *keyboard;
>   uint32_t capabilities;
>   char *name;
>  
> @@ -498,10 +499,8 @@ seat_handle_capabilities(void *data, struct wl_seat 
> *wl_seat,
>   return;
>  
>   if (caps & WL_SEAT_CAPABILITY_KEYBOARD) {
> - struct wl_keyboard *keyboard;
> -
> - keyboard = wl_seat_get_keyboard(seat->seat);
> - wl_keyboard_add_listener(keyboard, _listener,
> + seat->keyboard = wl_seat_get_keyboard(seat->seat);
> + wl_keyboard_add_listener(seat->keyboard, _listener,
>seat);
>  
>   seat->info->roundtrip_needed = true;
> @@ -531,6 +530,9 @@ destroy_seat_info(void *data)
>   if (seat->name != NULL)
>   free(seat->name);
>  
> + if (seat->keyboard)
> + wl_keyboard_destroy(seat->keyboard);
> +
>   wl_list_remove(>global_link);
>  }
>  
> -- 
> 2.17.0
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] virtual-keyboard: Add new virtual keyboard protocol

2018-05-20 Thread Dorota Czaplejewicz 
On Thu, 17 May 2018 18:53:10 +0200
Dorota Czaplejewicz  wrote:

> Provides the ability to emulate keyboards by applications. Complementary to 
> input-method protocol.
> 
> The interface is a mirror copy of wl_keyboard, with removed serials, and 
> added seat binding.
> ---
> 
> This proposal is another one needed by Purism to support on screen keyboards 
> on a phone screen.
> 
> Virtual-keyboard is a protocol to let applications send arbitrary keyboard 
> events. The need for this protocol comes from the fact that the input-method 
> protocol combines two separate input responsibilities. It currently deals 
> both with text input and raw keyboard events. I hope to split input-method 
> along this line into virtual-keyboard and the rest of input-method. I'm going 
> to submit the updated input-method for review soon.
> 
> Applications should be able to control both interfaces at the same time. A 
> screen keyboard supporting autocorrect (input-method) still wants to send 
> arrow keys (vityual-keyboard) correctly. Because of this, both kinds of 
> events at minimum must be sent to the same seat. I made the seat binding 
> explicitly done by the application, taking inspiration from text-input 
> protocol, which assumes per-seat binding as well.
> 
> Input welcome.
> 
> Cheers,
> Dorota


Apart from the typo that Silvan spotted, I have also encountered the issue 
where the .c/.h generator complained about undefined key_state and 
keymap_format enums which are defined in wayland.xml. I'm not sure what the 
correct way to solve this - should they be copied into this protocol?

Cheers,
Dorota


pgpWUjf6GNGOd.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v5] compositor-drm: Add aspect-ratio parsing support

2018-05-20 Thread Nautiyal, Ankit K 
From: Ankit Nautiyal 

The flag bits 19-22 of the connector modes, provide the aspect-ratio
information. This information can be stored in flags bits of the
weston mode structure, so that it can used for setting a mode with a
particular aspect-ratio.
Currently, DRM layer supports aspect-ratio with atomic-modesetting by
default. For legacy modeset path, the user-space needs to set the
drm client cap for aspect-ratio, if it wants aspect-ratio information
in modes.

This patch:
- preserves aspect-ratio flags from kernel video modes and
  accommodates it in wayland mode.
- uses aspect-ratio to pick the appropriate mode during modeset.
- changes the mode format in configuration file weston.ini to
  accommodate aspect-ratio information as:
  WIDTHxHEIGHT at REFRESH-RATE ASPECT-RATIO
  The aspect-ratio should be given as .
- modifies the man pages to explain the usage of different mode format
  configurations in weston.ini.

v2: As per recommendation from Pekka Paalanen, Quentin Glidic,
Daniel Stone, dropped the aspect-ratio info from wayland protocol,
thereby avoiding exposure of aspect-ratio to the client.

v3: As suggested by Pekka Paalanen, added aspect_ratio field to store
aspect-ratio information from the drm. Also added drm client
capability for aspect-ratio, as recommended by Daniel Vetter.

v4: Minor modifications and fixes as suggested by Pekka Paalanen.

v5: Rebased, fixed some styling issues, and added aspect-ratio
information while printing weston_modes.
Signed-off-by: Ankit Nautiyal 

Acked-by: Pekka Paalanen  (v4)
---
 libweston/compositor-drm.c | 115 +
 libweston/compositor-drm.h |  21 +++
 libweston/compositor.h |   1 +
 man/weston.ini.man |  13 +++--
 4 files changed, 136 insertions(+), 14 deletions(-)

diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 287431eb..e1d79e49 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -73,6 +73,10 @@
 #define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2
 #endif
 
+#ifndef DRM_CLIENT_CAP_ASPECT_RATIO
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+#endif
+
 #ifndef DRM_CAP_CURSOR_WIDTH
 #define DRM_CAP_CURSOR_WIDTH 0x8
 #endif
@@ -272,6 +276,8 @@ struct drm_backend {
uint32_t pageflip_timeout;
 
bool shutting_down;
+
+   bool aspect_ratio_supported;
 };
 
 struct drm_mode {
@@ -3049,6 +3055,19 @@ err:
drmModeSetCursor(b->drm.fd, output->crtc_id, 0, 0, 0);
 }
 
+/*
+ * Get the aspect-ratio from drmModeModeInfo mode flags.
+ *
+ * @param drm_mode_flags- flags from drmModeModeInfo structure.
+ * @returns aspect-ratio as encoded in enum 'weston_mode_aspect_ratio'.
+ */
+static uint8_t
+drm_to_weston_mode_aspect_ratio(uint32_t drm_mode_flags)
+{
+   return (drm_mode_flags & DRM_MODE_FLAG_PIC_AR_MASK) >>
+   DRM_MODE_FLAG_PIC_AR_BITS_POS;
+}
+
 static void
 drm_assign_planes(struct weston_output *output_base, void *repaint_data)
 {
@@ -3179,25 +3198,44 @@ drm_assign_planes(struct weston_output *output_base, 
void *repaint_data)
 static struct drm_mode *
 choose_mode (struct drm_output *output, struct weston_mode *target_mode)
 {
-   struct drm_mode *tmp_mode = NULL, *mode;
+   struct drm_mode *tmp_mode = NULL, *mode_fall_back = NULL, *mode;
+   uint8_t src_aspect = 0;
+   uint8_t target_aspect = 0;
+   struct drm_backend *b;
 
+   b = to_drm_backend(output->base.compositor);
+   target_aspect = target_mode->aspect_ratio;
+   src_aspect = output->base.current_mode->aspect_ratio;
if (output->base.current_mode->width == target_mode->width &&
output->base.current_mode->height == target_mode->height &&
(output->base.current_mode->refresh == target_mode->refresh ||
-target_mode->refresh == 0))
-   return to_drm_mode(output->base.current_mode);
+target_mode->refresh == 0)) {
+   if (!b->aspect_ratio_supported || src_aspect == target_aspect)
+   return (struct drm_mode *)output->base.current_mode;
+   }
 
wl_list_for_each(mode, >base.mode_list, base.link) {
+   uint32_t flags = mode->mode_info.flags;
+
+   src_aspect = drm_to_weston_mode_aspect_ratio(flags);
if (mode->mode_info.hdisplay == target_mode->width &&
mode->mode_info.vdisplay == target_mode->height) {
if (mode->base.refresh == target_mode->refresh ||
target_mode->refresh == 0) {
-   return mode;
-   } else if (!tmp_mode)
+   if (!b->aspect_ratio_supported ||
+   src_aspect == target_aspect)
+   return mode;
+   else if (!mode_fall_back)
+

[PATCH wayland-protocols v6] unstable: add xdg-decoration protocol

2018-05-20 Thread Simon Ser 
This adds a new protocol to negotiate server-side rendering of window
decorations for xdg-toplevels. This allows compositors that want to draw
decorations themselves to send their preference to clients, and clients that
prefer server-side decorations to request them.

This is inspired by a protocol from KDE [1] which has been implemented in
KDE and Sway and was submitted for consideration in 2017 [2]. This patch
provides an updated protocol with those concerns taken into account.

Signed-off-by: Simon Ser 

[1] 
https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
[2] 
https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
---

This was iterated on privately between representatives of Sway and wlroots
(Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and
Mir (Alan Griffiths).

A proof-of-concept of a client and server implementation is available at [1].

Changes from v5 to v6:
- Add back the set_mode request, add a new unset_mode request

This version fixes the race condition Jonas pointed out in his v4 review.

I believe there were two client use-cases for the set_mode request in v4:
- Request a specific preferred mode, and ignore the compositor preference. This
  is still possible since the set_mode request is back.
- Use the compositor's preference, as the client doesn't have one. In v4 this
  was achieved by sending a set_mode request with the mode received in the
  preferred_mode event. In this version this is achieved by not unsetting the
  mode (either by not sending any set_mode request, or by sending an unset_mode
  request).

The race condition could happen in v4 if the compositor sent a preferred_mode
event and couldn't decide if the client would want to keep its current mode or
change it (ie. should the compositor wait for a set_mode request or not?). This
new design doesn't let the client know the compositor's preferred mode. When the
compositor changes its preferred mode, it already knows if the client prefers to
use it or to use its own - and thus can directly send a configure event if
necessary.

I believe this lso simplifies the protocol and makes it easier to understand. I
don't think there are any regressions due to the fact that the client doesn't
know anymore the compositor's preferred mode.

[1] https://github.com/swaywm/wlroots/pull/638

 Makefile.am   |   1 +
 unstable/xdg-decoration/README|   4 +
 .../xdg-decoration-unstable-v1.xml| 145 ++
 3 files changed, 150 insertions(+)
 create mode 100644 unstable/xdg-decoration/README
 create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..71909d8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -17,6 +17,7 @@ unstable_protocols =  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
+   unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README
new file mode 100644
index 000..73f0c52
--- /dev/null
+++ b/unstable/xdg-decoration/README
@@ -0,0 +1,4 @@
+xdg_decoration protocol
+
+Maintainers:
+Simon Ser 
diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml 
b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
new file mode 100644
index 000..cf8cbdb
--- /dev/null
+++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
@@ -0,0 +1,145 @@
+
+
+  
+Copyright © 2018 Simon Ser
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN