date:20170516

Re: [PATCH libinput] util: harmonize container_of() definition with linux kernel one

2017-05-16 Thread Peter Hutterer

On Mon, May 15, 2017 at 01:08:17PM +0200, Gabriel Laskar wrote:
> commit 3925936 introduced changes to container_of, this is hopefully the
> last part of it.
> 
> In the linux kernel, container_of() takes a type name, and not a
> variable. Without this, in some cases it is needed to declare an unused
> variable in order to call container_of().
> 
> example:
> 
>   return container_of(dispatch, struct fallback_dispatch, base);
> 
> instead of:
> 
>   struct fallback_dispatch *p;
>   return container_of(dispatch, p, base);
> 
> This introduce also list_first_entry(), a simple wrapper around
> container_of() to retrieve the first element of a non empty list. It
> allows to simplify list_for_each() and list_for_each_safe().
> 
> Signed-off-by: Gabriel Laskar 
> ---
> 
> As they were no documentation for all the list functions/macros I did not add
> one for list_first_entry(), if it is necessary, I will add them.

thanks, much appreciated

   cef2a095..20f5f2d9  master -> master

If you want to write the documentation for the list functions, I'll merge
them. I have also had a long-standing task of separating out a lot of the
helpers into their own files where possible and just #including them from
libinput-util.h. Makes it easier to re-use those in other projects.

Cheers,
   Peter

> 
>  src/evdev-lid.c |  4 +---
>  src/evdev-mt-touchpad.h |  4 +---
>  src/evdev-tablet-pad.h  |  4 +---
>  src/evdev-tablet.h  |  4 +---
>  src/evdev.h |  8 ++--
>  src/libinput-util.h | 19 +++
>  6 files changed, 17 insertions(+), 26 deletions(-)
> 
> diff --git a/src/evdev-lid.c b/src/evdev-lid.c
> index baf7185..9e694ba 100644
> --- a/src/evdev-lid.c
> +++ b/src/evdev-lid.c
> @@ -44,11 +44,9 @@ struct lid_switch_dispatch {
>  static inline struct lid_switch_dispatch*
>  lid_dispatch(struct evdev_dispatch *dispatch)
>  {
> - struct lid_switch_dispatch *l;
> -
>   evdev_verify_dispatch_type(dispatch, DISPATCH_LID_SWITCH);
>  
> - return container_of(dispatch, l, base);
> + return container_of(dispatch, struct lid_switch_dispatch, base);
>  }
>  
>  static void
> diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
> index 304e92f..ef0171d 100644
> --- a/src/evdev-mt-touchpad.h
> +++ b/src/evdev-mt-touchpad.h
> @@ -391,11 +391,9 @@ struct tp_dispatch {
>  static inline struct tp_dispatch*
>  tp_dispatch(struct evdev_dispatch *dispatch)
>  {
> - struct tp_dispatch *tp;
> -
>   evdev_verify_dispatch_type(dispatch, DISPATCH_TOUCHPAD);
>  
> - return container_of(dispatch, tp, base);
> + return container_of(dispatch, struct tp_dispatch, base);
>  }
>  
>  #define tp_for_each_touch(_tp, _t) \
> diff --git a/src/evdev-tablet-pad.h b/src/evdev-tablet-pad.h
> index 5569007..c80e144 100644
> --- a/src/evdev-tablet-pad.h
> +++ b/src/evdev-tablet-pad.h
> @@ -73,11 +73,9 @@ struct pad_dispatch {
>  static inline struct pad_dispatch*
>  pad_dispatch(struct evdev_dispatch *dispatch)
>  {
> - struct pad_dispatch *p;
> -
>   evdev_verify_dispatch_type(dispatch, DISPATCH_TABLET_PAD);
>  
> - return container_of(dispatch, p, base);
> + return container_of(dispatch, struct pad_dispatch, base);
>  }
>  
>  static inline struct libinput *
> diff --git a/src/evdev-tablet.h b/src/evdev-tablet.h
> index 43ed897..7d17e36 100644
> --- a/src/evdev-tablet.h
> +++ b/src/evdev-tablet.h
> @@ -88,11 +88,9 @@ struct tablet_dispatch {
>  static inline struct tablet_dispatch*
>  tablet_dispatch(struct evdev_dispatch *dispatch)
>  {
> - struct tablet_dispatch *t;
> -
>   evdev_verify_dispatch_type(dispatch, DISPATCH_TABLET);
>  
> - return container_of(dispatch, t, base);
> + return container_of(dispatch, struct tablet_dispatch, base);
>  }
>  
>  static inline enum libinput_tablet_tool_axis
> diff --git a/src/evdev.h b/src/evdev.h
> index c9a44f8..2bd58c1 100644
> --- a/src/evdev.h
> +++ b/src/evdev.h
> @@ -247,9 +247,7 @@ struct evdev_device {
>  static inline struct evdev_device *
>  evdev_device(struct libinput_device *device)
>  {
> - struct evdev_device *d;
> -
> - return container_of(device, d, base);
> + return container_of(device, struct evdev_device, base);
>  }
>  
>  #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
> @@ -371,11 +369,9 @@ struct fallback_dispatch {
>  static inline struct fallback_dispatch*
>  fallback_dispatch(struct evdev_dispatch *dispatch)
>  {
> - struct fallback_dispatch *f;
> -
>   evdev_verify_dispatch_type(dispatch, DISPATCH_FALLBACK);
>  
> - return container_of(dispatch, f, base);
> + return container_of(dispatch, struct fallback_dispatch, base);
>  }
>  
>  struct evdev_device *
> diff --git a/src/libinput-util.h b/src/libinput-util.h
> index 6d9bbe2..e34a500 100644
> --- a/src/libinput-util.h
> +++ b/src/libinput-util.h
> @@ -86,22 +86,25 @@ void list_insert(struct list *list, struct list *elm);
>  void list_remove(struct list *elm);

[PATCH libinput] Add support for SW_TABLET_MODE

2017-05-16 Thread Peter Hutterer

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

Signed-off-by: Peter Hutterer 
---
This builds on top of the patch series here
https://lists.freedesktop.org/archives/wayland-devel/2017-April/033942.html
since rebased and available here:
https://github.com/whot/libinput/tree/wip/sw-tablet-mode

 src/evdev.c| 48 ---
 src/evdev.h|  1 +
 src/libinput.h | 16 +
 test/litest-device-thinkpad-extrabuttons.c |  1 +
 test/litest.c  |  3 +
 test/test-switch.c | 95 +++---
 6 files changed, 108 insertions(+), 56 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 1b4ec934..8cc8a2cc 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -958,6 +958,20 @@ fallback_process_switch(struct fallback_dispatch *dispatch,
 LIBINPUT_SWITCH_RF_DISABLED,
 state);
break;
+   case SW_TABLET_MODE:
+   if (dispatch->sw.tablet_mode_state == e->value)
+   return;
+
+   dispatch->sw.tablet_mode_state = e->value;
+   if (e->value)
+   state = LIBINPUT_SWITCH_STATE_ON;
+   else
+   state = LIBINPUT_SWITCH_STATE_OFF;
+   switch_notify_toggle(>base,
+time,
+LIBINPUT_SWITCH_TABLET_MODE,
+state);
+   break;
}
 }
 
@@ -1288,14 +1302,21 @@ fallback_sync_initial_state(struct evdev_device *device,
struct evdev_dispatch *evdev_dispatch)
 {
struct fallback_dispatch *dispatch = fallback_dispatch(evdev_dispatch);
+   uint64_t time = libinput_now(evdev_libinput_context(device));
 
if (dispatch->sw.rfkill_all_state) {
-   uint64_t time = libinput_now(evdev_libinput_context(device));
switch_notify_toggle(>base,
 time,
 LIBINPUT_SWITCH_RF_DISABLED,
 LIBINPUT_SWITCH_STATE_ON);
}
+
+   if (dispatch->sw.tablet_mode_state) {
+   switch_notify_toggle(>base,
+time,
+LIBINPUT_SWITCH_TABLET_MODE,
+LIBINPUT_SWITCH_STATE_ON);
+   }
 }
 
 static void
@@ -1845,13 +1866,23 @@ static inline void
 fallback_dispatch_init_switch(struct fallback_dispatch *dispatch,
  struct evdev_device *device)
 {
-   if (!libevdev_has_event_code(device->evdev, EV_SW, SW_RFKILL_ALL))
-   return;
+   int val;
 
-   dispatch->sw.rfkill_all_state = libevdev_get_event_value(device->evdev,
-EV_SW,
-SW_RFKILL_ALL);
-   device->seat_caps |= EVDEV_DEVICE_SWITCH;
+   if (libevdev_has_event_code(device->evdev, EV_SW, SW_RFKILL_ALL)) {
+   val = libevdev_get_event_value(device->evdev,
+  EV_SW,
+  SW_RFKILL_ALL);
+   dispatch->sw.rfkill_all_state = val;
+   device->seat_caps |= EVDEV_DEVICE_SWITCH;
+   }
+
+   if (libevdev_has_event_code(device->evdev, EV_SW, SW_TABLET_MODE)) {
+   val = libevdev_get_event_value(device->evdev,
+  EV_SW,
+  SW_TABLET_MODE);
+   dispatch->sw.tablet_mode_state = val;
+   device->seat_caps |= EVDEV_DEVICE_SWITCH;
+   }
 }
 
 static struct evdev_dispatch *
@@ -3214,6 +3245,9 @@ evdev_device_has_switch(struct evdev_device *device,
case LIBINPUT_SWITCH_RF_DISABLED:
code = SW_RFKILL_ALL;
break;
+   case LIBINPUT_SWITCH_TABLET_MODE:
+   code = SW_TABLET_MODE;
+   break;
default:
return -1;
}
diff --git a/src/evdev.h b/src/evdev.h
index 02c14e65..0587740d 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -359,6 +359,7 @@ struct fallback_dispatch {
 
struct {
int rfkill_all_state;
+   int tablet_mode_state;
} sw;
 
/* Bitmask of pressed keys used to ignore initial release events from
diff --git a/src/libinput.h b/src/libinput.h
index 38abae8e..316f210a 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -639,6 +639,22 @@ enum libinput_switch {
 * c) toggle the state to match the switch state (if required)
 */
LIBINPUT_SWITCH_RF_DISABLED,
+
+   /**
+* This switch indicates whether the device is in

[PATCH libinput 1/4] tools: drop libshared.la

2017-05-16 Thread Peter Hutterer

Include the source files directly, we'll need per-target compiler flags that
affect different tools differently in the future.

Signed-off-by: Peter Hutterer 
---
 tools/Makefile.am | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/tools/Makefile.am b/tools/Makefile.am
index 4fc1046e..79352b72 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -1,6 +1,5 @@
 noinst_PROGRAMS = event-debug ptraccel-debug
 bin_PROGRAMS = libinput-list-devices libinput-debug-events
-noinst_LTLIBRARIES = libshared.la
 
 AM_CPPFLAGS = -I$(top_srcdir)/include \
   -I$(top_srcdir)/src \
@@ -8,14 +7,12 @@ AM_CPPFLAGS = -I$(top_srcdir)/include \
 AM_CFLAGS = $(GCC_CFLAGS)
 AM_CXXFLAGS = $(GCC_CXXFLAGS)
 
-libshared_la_SOURCES = \
-  shared.c \
-  shared.h
-libshared_la_CFLAGS = $(AM_CFLAGS) $(LIBEVDEV_CFLAGS)
-libshared_la_LIBADD = $(LIBEVDEV_LIBS)
+shared_sources = \
+shared.c \
+shared.h
 
-event_debug_SOURCES = event-debug.c
-event_debug_LDADD = ../src/libinput.la libshared.la $(LIBUDEV_LIBS) 
$(LIBEVDEV_LIBS)
+event_debug_SOURCES = event-debug.c $(shared_sources)
+event_debug_LDADD = ../src/libinput.la $(LIBUDEV_LIBS) $(LIBEVDEV_LIBS)
 event_debug_LDFLAGS = -no-install
 event_debug_CFLAGS = $(AM_CFLAGS) $(LIBUDEV_CFLAGS) $(LIBEVDEV_CFLAGS)
 
@@ -23,9 +20,9 @@ ptraccel_debug_SOURCES = ptraccel-debug.c
 ptraccel_debug_LDADD = ../src/libfilter.la ../src/libinput.la
 ptraccel_debug_LDFLAGS = -no-install
 
-libinput_list_devices_SOURCES = libinput-list-devices.c
-libinput_list_devices_LDADD = ../src/libinput.la libshared.la $(LIBUDEV_LIBS)
-libinput_list_devices_CFLAGS = $(AM_CFLAGS) $(LIBUDEV_CFLAGS)
+libinput_list_devices_SOURCES = libinput-list-devices.c $(shared_sources)
+libinput_list_devices_LDADD = ../src/libinput.la $(LIBUDEV_LIBS) 
$(LIBEVDEV_LIBS)
+libinput_list_devices_CFLAGS = $(AM_CFLAGS) $(LIBUDEV_CFLAGS) 
$(LIBEVDEV_CFLAGS)
 dist_man1_MANS = libinput-list-devices.1
 
 libinput_debug_events_SOURCES = $(event_debug_SOURCES)
@@ -36,9 +33,11 @@ dist_man1_MANS += libinput-debug-events.1
 if BUILD_EVENTGUI
 noinst_PROGRAMS += event-gui
 
-event_gui_SOURCES = event-gui.c
-event_gui_LDADD = ../src/libinput.la libshared.la $(CAIRO_LIBS) $(GTK_LIBS) 
$(LIBUDEV_LIBS)
-event_gui_CFLAGS = $(CAIRO_CFLAGS) $(GTK_CFLAGS) $(LIBUDEV_CFLAGS) $(AM_CFLAGS)
+event_gui_SOURCES = event-gui.c $(shared_sources)
+event_gui_LDADD = ../src/libinput.la $(CAIRO_LIBS) $(GTK_LIBS) \
+ $(LIBUDEV_LIBS) $(LIBEVDEV_LIBS)
+event_gui_CFLAGS = $(CAIRO_CFLAGS) $(GTK_CFLAGS) \
+  $(LIBUDEV_CFLAGS) $(LIBEVDEV_CFLAGS) $(AM_CFLAGS)
 event_gui_LDFLAGS = -no-install
 endif
 
-- 
2.12.2

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

[PATCH libinput 0/4] tools: provide a single 'libinput' tool (á la git)

2017-05-16 Thread Peter Hutterer


We currently have two tools that we install - libinput-list-devices and
libinput-debug-events. There's a bunch of things we need to do for debugging
that is different enough that different tools are warranted for. Instead of
messing up /usr/bin with a swath of libinput-foo tools, let's switch to a
single 'libinput' tool and take commands instead, i.e. just like git does.
This patch set adds 'libinput list-devices' and 'libinput debug-events' but 
more tools will be incoming.

A nice side-effect of that is that we now have a 'libinput' man page too,
just in case somebody accidentally tries to read documentation before wildy
trying random commands in hope of success.

The old tools are still around, they'll remain for this release and then get
deprecated and eventually removed. Hence the #ifdefs sprinkled across, if
they're to be removed anyway I won't spend too much time polishing these.

Note that the GUI debugger is still currently a separate tool, not 100% sure
whether to merge it.

Cheers,
  Peter

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

[PATCH libinput 4/4] tools: hook libinput-debug-events into the libinput tool

2017-05-16 Thread Peter Hutterer

Signed-off-by: Peter Hutterer 
---
 meson.build   |  7 +++--
 tools/Makefile.am |  8 --
 tools/libinput-debug-events.c | 15 +--
 tools/libinput-tool.c |  8 ++
 tools/libinput-tool.h |  1 +
 tools/libinput.1  | 60 ++-
 tools/shared.c| 36 ++
 tools/shared.h|  5 ++--
 8 files changed, 121 insertions(+), 19 deletions(-)

diff --git a/meson.build b/meson.build
index 090536b5..1606401c 100644
--- a/meson.build
+++ b/meson.build
@@ -344,6 +344,7 @@ executable('event-debug',
   event_debug_sources,
   dependencies : dep_libinput,
   include_directories : include_directories('src'),
+  c_args : [ '-DTOOLS_BUILD_STANDALONE=1' ],
   install : false
   )
 
@@ -352,6 +353,7 @@ executable('libinput-debug-events',
   libinput_debug_events_sources,
   dependencies : dep_libinput,
   include_directories : include_directories('src'),
+  c_args : [ '-DTOOLS_BUILD_STANDALONE=1' ],
   install : true
   )
 
@@ -360,11 +362,12 @@ executable('libinput-list-devices',
   libinput_list_devices_sources,
   dependencies : [ dep_libinput ],
   include_directories : include_directories('src'),
-  c_args : [ '-DTOOLS_BUILD_STANDALONE=1' ]
+  c_args : [ '-DTOOLS_BUILD_STANDALONE=1' ],
   install : true,
   )
 
-libinput_sources = [ 'tools/libinput-tool.c' ] + libinput_list_devices_sources
+libinput_sources = [ 'tools/libinput-tool.c' ] + libinput_list_devices_sources 
+ libinput_debug_events_sources
+
 executable('libinput',
   libinput_sources,
   dependencies : dep_libinput,
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 94765ced..77b4e74c 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -11,10 +11,12 @@ shared_sources = \
 shared.c \
 shared.h
 
+event_debug_sources = libinput-debug-events.c $(shared_sources)
 event_debug_SOURCES = libinput-debug-events.c $(shared_sources)
 event_debug_LDADD = ../src/libinput.la $(LIBUDEV_LIBS) $(LIBEVDEV_LIBS)
 event_debug_LDFLAGS = -no-install
-event_debug_CFLAGS = $(AM_CFLAGS) $(LIBUDEV_CFLAGS) $(LIBEVDEV_CFLAGS)
+event_debug_CFLAGS = $(AM_CFLAGS) $(LIBUDEV_CFLAGS) $(LIBEVDEV_CFLAGS) \
+-DTOOLS_BUILD_STANDALONE=1
 
 ptraccel_debug_SOURCES = ptraccel-debug.c
 ptraccel_debug_LDADD = ../src/libfilter.la ../src/libinput.la
@@ -28,12 +30,14 @@ dist_man1_MANS = libinput-list-devices.1
 
 libinput_debug_events_SOURCES = $(event_debug_SOURCES)
 libinput_debug_events_LDADD = $(event_debug_LDADD)
-libinput_debug_events_CFLAGS = $(AM_CFLAGS) $(event_debug_CFLAGS)
+libinput_debug_events_CFLAGS = $(AM_CFLAGS) $(event_debug_CFLAGS) \
+  -DTOOLS_BUILD_STANDALONE=1
 dist_man1_MANS += libinput-debug-events.1
 
 libinput_SOURCES = \
   libinput-tool.c \
   libinput-tool.h \
+  libinput-debug-events.c \
   libinput-list-devices.c \
   $(shared_sources)
 libinput_LDADD = ../src/libinput.la $(LIBUDEV_LIBS) $(LIBEVDEV_LIBS)
diff --git a/tools/libinput-debug-events.c b/tools/libinput-debug-events.c
index 574fa9ed..f64708d0 100644
--- a/tools/libinput-debug-events.c
+++ b/tools/libinput-debug-events.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 
+#include "libinput-tool.h"
 #include "shared.h"
 
 uint32_t start_time;
@@ -896,7 +897,7 @@ mainloop(struct libinput *li)
 }
 
 int
-main(int argc, char **argv)
+libinput_debug_events(struct global_options *opts, int argc, char **argv)
 {
struct libinput *li;
struct timespec tp;
@@ -909,7 +910,7 @@ main(int argc, char **argv)
if (tools_parse_args(argc, argv, ))
return 1;
 
-   be_quiet = context.options.quiet;
+   be_quiet = context.options.global_options.quiet;
 
li = tools_open_backend();
if (!li)
@@ -921,3 +922,13 @@ main(int argc, char **argv)
 
return 0;
 }
+
+#if TOOLS_BUILD_STANDALONE
+int
+main(int argc, char **argv)
+{
+   struct global_options opts = {0};
+
+   return libinput_debug_events(, argc, argv);
+}
+#endif
diff --git a/tools/libinput-tool.c b/tools/libinput-tool.c
index b20ed0f3..12204abd 100644
--- a/tools/libinput-tool.c
+++ b/tools/libinput-tool.c
@@ -57,12 +57,16 @@ libinput_tool_usage(void)
   "Commands:\n"
   "  list-devices\n"
   "List all devices with their default configuration 
options\n"
+  "\n"
+  "  debug-events\n"
+  "Print events to stdout\n"
   "\n");
 }
 
 enum command {
COMMAND_NONE,
COMMAND_LIST_DEVICES,
+   COMMAND_DEBUG_EVENTS,
 };
 
 enum global_opts {
@@ -84,6 +88,8 @@ parse_args_cmd(enum command cmd,

[PATCH libinput 3/4] tools: add a 'libinput' tool

2017-05-16 Thread Peter Hutterer

This tool will eventually replace the different libinput tools we ship atm
with the various functionalities being commands to the single tool, rather
than multiple tools.

Right now, we still build both tools separately.

Signed-off-by: Peter Hutterer 
---
 meson.build   |  10 +++
 tools/Makefile.am |  14 +++-
 tools/libinput-list-devices.c |  56 +++-
 tools/libinput-tool.c | 153 ++
 tools/libinput-tool.h |  39 +++
 tools/libinput.1  |  76 +
 6 files changed, 330 insertions(+), 18 deletions(-)
 create mode 100644 tools/libinput-tool.c
 create mode 100644 tools/libinput-tool.h
 create mode 100644 tools/libinput.1

diff --git a/meson.build b/meson.build
index 6cd48d6c..090536b5 100644
--- a/meson.build
+++ b/meson.build
@@ -360,8 +360,18 @@ executable('libinput-list-devices',
   libinput_list_devices_sources,
   dependencies : [ dep_libinput ],
   include_directories : include_directories('src'),
+  c_args : [ '-DTOOLS_BUILD_STANDALONE=1' ]
+  install : true,
+  )
+
+libinput_sources = [ 'tools/libinput-tool.c' ] + libinput_list_devices_sources
+executable('libinput',
+  libinput_sources,
+  dependencies : dep_libinput,
+  include_directories : include_directories ('src'),
   install : true
   )
+install_man('tools/libinput.1')
 
 ptraccel_debug_sources = [ 'tools/ptraccel-debug.c' ]
 executable('ptraccel-debug',
diff --git a/tools/Makefile.am b/tools/Makefile.am
index e4443ffc..94765ced 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -1,5 +1,5 @@
 noinst_PROGRAMS = event-debug ptraccel-debug
-bin_PROGRAMS = libinput-list-devices libinput-debug-events
+bin_PROGRAMS = libinput-list-devices libinput-debug-events libinput
 
 AM_CPPFLAGS = -I$(top_srcdir)/include \
   -I$(top_srcdir)/src \
@@ -22,7 +22,8 @@ ptraccel_debug_LDFLAGS = -no-install
 
 libinput_list_devices_SOURCES = libinput-list-devices.c $(shared_sources)
 libinput_list_devices_LDADD = ../src/libinput.la $(LIBUDEV_LIBS) 
$(LIBEVDEV_LIBS)
-libinput_list_devices_CFLAGS = $(AM_CFLAGS) $(LIBUDEV_CFLAGS) 
$(LIBEVDEV_CFLAGS)
+libinput_list_devices_CFLAGS = $(AM_CFLAGS) $(LIBUDEV_CFLAGS) 
$(LIBEVDEV_CFLAGS) \
+  -DTOOLS_BUILD_STANDALONE=1
 dist_man1_MANS = libinput-list-devices.1
 
 libinput_debug_events_SOURCES = $(event_debug_SOURCES)
@@ -30,6 +31,15 @@ libinput_debug_events_LDADD = $(event_debug_LDADD)
 libinput_debug_events_CFLAGS = $(AM_CFLAGS) $(event_debug_CFLAGS)
 dist_man1_MANS += libinput-debug-events.1
 
+libinput_SOURCES = \
+  libinput-tool.c \
+  libinput-tool.h \
+  libinput-list-devices.c \
+  $(shared_sources)
+libinput_LDADD = ../src/libinput.la $(LIBUDEV_LIBS) $(LIBEVDEV_LIBS)
+libinput_CFLAGS = $(AM_CFLAGS) $(LIBUDEV_CFLAGS) $(LIBEVDEV_CFLAGS)
+dist_man1_MANS += libinput.1
+
 if BUILD_EVENTGUI
 noinst_PROGRAMS += event-gui
 
diff --git a/tools/libinput-list-devices.c b/tools/libinput-list-devices.c
index aad605a4..a0154d36 100644
--- a/tools/libinput-list-devices.c
+++ b/tools/libinput-list-devices.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 
+#include "libinput-tool.h"
 #include "shared.h"
 
 static const char *
@@ -354,39 +355,38 @@ print_device_notify(struct libinput_event *ev)
 static inline void
 usage(void)
 {
-   printf("Usage: %s [--help|--version]\n"
-  "\n"
+#if TOOLS_BUILD_STANDALONE
+   printf("Usage: %s [--help|--version]\n", program_invocation_short_name);
+#else
+   printf("Usage: libinput list-devices [--help]\n");
+#endif
+   printf("\n"
   "This tool creates a libinput context on the default seat 
\"seat0\"\n"
   "and lists all devices recognized by libinput and the 
configuration options.\n"
   "Where multiple options are possible, the default is prefixed 
with \"*\".\n"
   "\n"
   "Options:\n"
   "--help .. show this help\n"
+#if TOOLS_BUILD_STANDALONE
   "--version ... show version information\n"
+#endif
   "\n"
-  "This tool requires access to the /dev/input/eventX nodes.\n",
-  program_invocation_short_name);
+  "This tool requires access to the /dev/input/eventX nodes.\n");
 }
 
 int
-main(int argc, char **argv)
+libinput_list_devices(struct global_options *opts, int argc, char **argv)
 {
struct libinput *li;
struct tools_context context;
struct libinput_event *ev;
 
+#if !TOOLS_BUILD_STANDALONE
if (argc > 1) {
-   if (streq(argv[1], "--help")) {
-   usage();
-   return 0;
-   } else if (streq(argv[1], "--version")) {
-   printf("%s\n", LIBINPUT_VERSION);
-

[PATCH libinput 2/4] tools: rename a source file to match the future common file name paradigm

2017-05-16 Thread Peter Hutterer

Signed-off-by: Peter Hutterer 
---
 meson.build  | 2 +-
 tools/Makefile.am| 2 +-
 tools/{event-debug.c => libinput-debug-events.c} | 0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename tools/{event-debug.c => libinput-debug-events.c} (100%)

diff --git a/meson.build b/meson.build
index e1ea40cb..6cd48d6c 100644
--- a/meson.build
+++ b/meson.build
@@ -339,7 +339,7 @@ endif
  tools 
 tools_shared_sources = [ 'tools/shared.c',
 'tools/shared.h' ]
-event_debug_sources = [ 'tools/event-debug.c' ] + tools_shared_sources
+event_debug_sources = [ 'tools/libinput-debug-events.c' ] + 
tools_shared_sources
 executable('event-debug',
   event_debug_sources,
   dependencies : dep_libinput,
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 79352b72..e4443ffc 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -11,7 +11,7 @@ shared_sources = \
 shared.c \
 shared.h
 
-event_debug_SOURCES = event-debug.c $(shared_sources)
+event_debug_SOURCES = libinput-debug-events.c $(shared_sources)
 event_debug_LDADD = ../src/libinput.la $(LIBUDEV_LIBS) $(LIBEVDEV_LIBS)
 event_debug_LDFLAGS = -no-install
 event_debug_CFLAGS = $(AM_CFLAGS) $(LIBUDEV_CFLAGS) $(LIBEVDEV_CFLAGS)
diff --git a/tools/event-debug.c b/tools/libinput-debug-events.c
similarity index 100%
rename from tools/event-debug.c
rename to tools/libinput-debug-events.c
-- 
2.12.2

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

[PATCH libinput] touchpad: fix clickfinger behavior with a thumb being present

2017-05-16 Thread Friedrich Schöller

With a thumb on the touchpad, a two-finger click was incorrectly
treated as a middle-click. This patch takes the thumb into account and
treats the click as a right-click.
---
 src/evdev-mt-touchpad-buttons.c | 44 ++---
 1 file changed, 19 insertions(+), 25 deletions(-)

diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index 895cf0e..ffb6a58 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -981,23 +981,24 @@ out:
 static uint32_t
 tp_clickfinger_set_button(struct tp_dispatch *tp)
 {
-   uint32_t button;
+   bool thumb_detected = false;
unsigned int nfingers = tp->nfingers_down;
struct tp_touch *t;
struct tp_touch *first = NULL,
*second = NULL;
 
-   if (nfingers != 2)
-   goto out;
+   if (nfingers < 2)
+   return BTN_LEFT;
 
-   /* two fingers down on the touchpad. Check for distance
-* between the fingers. */
tp_for_each_touch(tp, t) {
if (t->state != TOUCH_BEGIN && t->state != TOUCH_UPDATE)
continue;
 
-   if (t->thumb.state == THUMB_STATE_YES)
+   if (t->thumb.state == THUMB_STATE_YES) {
+   thumb_detected = true;
+   nfingers--;
continue;
+   }
 
if (!first)
first = t;
@@ -1005,27 +1006,20 @@ tp_clickfinger_set_button(struct tp_dispatch *tp)
second = t;
}
 
-   if (!first || !second) {
-   nfingers = 1;
-   goto out;
-   }
+   if (nfingers < 2)
+   return BTN_LEFT;
+   else if (nfingers > 2)
+   return BTN_MIDDLE;
 
-   if (tp_clickfinger_within_distance(tp, first, second))
-   nfingers = 2;
+   /* Two fingers (not counting thumbs) are on the touchpad. If no
+* additional thumb was detected, we check the distance between the
+* touches. Some touchpads can not report more than two finger positions
+* so we do not check the distance if an additional thumb was detected.
+*/
+   if (thumb_detected || tp_clickfinger_within_distance(tp, first, second))
+   return BTN_RIGHT;
else
-   nfingers = 1;
-
-out:
-   switch (nfingers) {
-   case 0:
-   case 1: button = BTN_LEFT; break;
-   case 2: button = BTN_RIGHT; break;
-   default:
-   button = BTN_MIDDLE; break;
-   break;
-   }
-
-   return button;
+   return BTN_LEFT;
 }
 
 static int
-- 
2.9.4

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

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

2017-05-16 Thread Pekka Paalanen

On Mon, 15 May 2017 17:31:57 +0200
Philipp Kerling  wrote:

> Thanks for your answers! See reply below.
> 
> 2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました:
> > On Sun, 14 May 2017 14:43:44 +0200
> > Philipp Kerling  wrote:  
> > > To start off:
> > >  * Kodi should offer the user the opportunity to select inside the
> > >    application on which monitor he/she wants to have Kodi displayed
> > > on
> > >    when in full-screen mode. Now I see that I can do this with
> > > either
> > >    wl_shell_surface::set_fullscreen and
> > > zxdg_toplevel::set_fullscreen,
> > >    which expect a wl_output to display the window on. But I am not
> > > sure
> > >    how I should match the wl_output instance I get from Wayland
> > > with
> > >    the monitor that the user selected. As far as I can see, I can
> > > only
> > >    identify the monitor by way of "make" and "model". This seems
> > >    reasonable enough at first glance, but I think that in multi-
> > > monitor 
> > >    configurations it is not so uncommon to buy the same monitor
> > > model
> > >    multiple times - I personally have done this. Naturally, the
> > > "make"
> > >    and "model" of both monitors are identical, so I cannot discern
> > >    which is which by looking at the wl_output metadata. Am I
> > > missing
> > >    something here?  
> > 
> > That is all true, you are not missing anything.
> > 
> > It is a missing piece of protocol - I believe no-one has had both the
> > need and the time to work on getting anything better yet.
> >   
> > > Why isn't e.g. the connector the output is connected
> > >    to exported?  
> > 
> > Because connector names are specific to DRM while Wayland (core
> > protocol at least) is not.  
> I'm not sure I agree. See further below.
> 
> > Also, would you not want to identify the
> > monitor rather than which connector it happens to be plugged in?   
> I think that it's not quite decided yet what we want the user
> experience to be on the Kodi side, i.e. do we want to bind output to
> the physical monitor (however it is identified) or the GPU connector?
> You can probably find use cases for both, so it's not an easy decision
> to make. With X11 it was limited to the latter, so my first approach
> was to mimic that. Ideally, both would be possible with Wayland and the
> application can decide what is best for its specific use case. I
> realize that this might be too much to ask for all at once, so I'll
> talk to my mentor to decide which case we want to focus on for Kodi.
> There are also two different points involved in this discussion:
>I. How the *user* identifies which output/monitor the fullscreen
>   display should be on (e.g. with make+model+connector name, or by
>   compositor-specific numbering).
>   II. How *Kodi* or any other application then stores this, re-identifies
>   this output/monitor and maps it to a wl_output on application start
>   and hotplug. Possiblities include saving information pertaining to
>   the output, the connector, the physical device, or any combination.

Hi,

very much agreed.

> > Would
> > a user even know which connector name matches to which monitor?  
> Yes, I also thought about this. Tech-savvy users might actually be able
> to identify the connector name, but you are absolutely right that
> usually users should not be expected to. In fact, having make and model
> available actually is an improvement in that regard (on X11, Kodi
> *only* displays connector since that is what's available via RANDR).
> So: How do you suggest to identify a particular monitor then? As I
> said, make and model are not sufficient - but serial number will not
> help the user in identification. If there are multiple monitors of the
> same model, I do not think that they (i.e. the physical devices) can be
> reasonably discerned in a way that is transparent to the user. That's
> why I suggested the connector name.

One idea coming to mind is that in the DE's (compositor's) display
configuration dialog, the user would be allowed to identify monitors by
visual clues, and would be given the opportunity to give the monitors
(or connectors!) custom names. An application could then show all the
information plus the custom names so that the user can pick the one he
wants.

> > To expose such a name in the protocol, we should define the space or
> > meaning of the names. Human-readable? That's not the connector name,
> > IMHO. Machine-parseable? Needs a very strict definition to work.
> > Both?  
> RANDR output names (which are somewhat close to what I refer to as
> connector names - it's a matter of debate whether output or connector
> name would be more fitting for the Kodi use case) are specifically
> meant to be "presented to the user", but I can see your point. I think
> that machine-parseable is doable, also considering that RANDR did have
> a "ConnectorType" property which is probably part of what we'd want
> here. 

I think

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

2017-05-16 Thread Philipp Kerling

Hi,

Am Dienstag, den 16.05.2017, 11:30 +0300 schrieb Pekka Paalanen:
> On Mon, 15 May 2017 17:51:16 +0200
> Philipp Kerling  wrote:
> 
> > 2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました:
> > > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:  
> > > > On Sun, 14 May 2017 14:43:44 +0200
> > > > Philipp Kerling  wrote:  
> > > > >  * Am I correct in that if I use zxdg_toplevel (i.e. give
> > > > > this
> > > > > role to
> > > > >a surface), I cannot also use wl_shell_surface? If so,
> > > > > this
> > > > > would be  
> > > > 
> > > > Yes. wl_shell and xdg_shell suites of protocol extensions are
> > > > mutually
> > > > exclusive, you cannot use both for the same wl_surface.
> > > > wl_shell is
> > > > the
> > > > deprecated one, and xdg_shell suite is the replacement waiting
> > > > to
> > > > be
> > > > decleared stable.
> > > >   
> > > > >quite a problem. I can see that zxdg_toplevel
> > > > > functionality is
> > > > >mostly superior to that of wl_shell_surface, but it has
> > > > > one
> > > > > omission
> > > > >that is crucial for Kodi: the ability to request a
> > > > > specific
> > > > > refresh
> > > > >rate for fullscreen display. This is needed for closely
> > > > > matching the
> > > > >display and video FPS so duplicated and skipped frames are
> > > > > kept to a
> > > > >minimum. Is this an intentional omission and/or is there
> > > > > anything
> > > > >that provides this functionality?  
> > > > 
> > > > Hopefully the xdg_shell designers would answer that, but I
> > > > believe
> > > > it
> > > > has been omitted for now to make it easier to declare the first
> > > > fundamental parts of xdg_shell stable. It is missing a lot, but
> > > > the
> > > > foundation must agreed upon first before building more on
> > > > top.  
> > > 
> > > Rather than combining the FPS request with fullscreening,
> > > wouldn't it
> > > be
> > > better to let applications set FPS as a property of the surface?
> > > 
> > > That way the client would make a promise that is is going to
> > > update
> > > surface contents with periodic commits of the specified rate,
> > > completely
> > > independent of the actual output hardware or fullscreen state.
> > > 
> > > The server could use that information to choose the best display
> > > refresh
> > > rate even if not in fullscreen mode.  
> > 
> > I would not want my compositor to do that, since changing the
> > refresh
> > rate means that the monitor will go blank for a while while
> > resyncing
> > on most hardware.
> 
> Hi,
> 
> I get the feeling that you are assuming the server would always obey
> the
> client refresh rate. The protocol should not be designed like that.
I actually don't and I think I explicitly stated that in an earlier
email. I know that Wayland has nothing like RANDR (i.e. where every
application can mess around with the output modes as it pleases) on
purpose. Sorry if I gave the impression that this or something similar
is what I'd want.

> Wayland protocol design principle for the desktops is that clients
> describe what they would want to do (and why), and the server
> implements the policy on when and how that actually happens - if at
> all. This is very much the opposite from X11. A typical example is
> input grabs: a client has to provide both the reason (the input event
> they are acting on) and the context (the surface a grab will be tied
> to). The server decides if it grants a grab or not, and if yes, it
> can
> also revoke the grab at any time.
> 
> The reason the framerate was in the fullscreen request in wl_shell is
> that fullscreen offers fairly clear conditions on when the server
> should or could switch the video mode:
> - when the fullscreen window becomes top-most and active, switch
> video
>   mode to the client requested one
> - when the fullscreen window becomes inactive, is hidden, or some
> other
>   top-level window comes on top of it; a condition that is not just
>   transient; switch video mode back to the default one
> - do not switch back to default one for insignificant actions, e.g. a
>   notification window appearing, window switcher starter but not yet
>   chosen the next active window
> 
> If a custom video mode request can be made on any kind of window, it
> becomes more hard to figure out the right situations when to switch -
> if switching at all. The server always has to have the choice to not
> switch at all, ever, e.g. if the hardware is incapable, would make
> the
> screen blank for too long that it's annoying, or simply a policy set
> by
> the user.
That's perfectly OK. I don't think it necessarily becomes more
difficult by attaching the information to all surfaces as opposed to
only full-screen surfaces though. As you said, the compositor should
not be obligated to do anything at all and the arguably most common use
case which is the old set_fullscreen behaviour that only considers
fullscreen surfaces is still possible

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

2017-05-16 Thread Philipp Zabel

On Mon, 2017-05-15 at 17:51 +0200, Philipp Kerling wrote:
> 2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました:
> > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:
> > > On Sun, 14 May 2017 14:43:44 +0200
> > > Philipp Kerling  wrote:
> > > >  * Am I correct in that if I use zxdg_toplevel (i.e. give this
> > > > role to
> > > >a surface), I cannot also use wl_shell_surface? If so, this
> > > > would be
> > > 
> > > Yes. wl_shell and xdg_shell suites of protocol extensions are
> > > mutually
> > > exclusive, you cannot use both for the same wl_surface. wl_shell is
> > > the
> > > deprecated one, and xdg_shell suite is the replacement waiting to
> > > be
> > > decleared stable.
> > > 
> > > >quite a problem. I can see that zxdg_toplevel functionality is
> > > >mostly superior to that of wl_shell_surface, but it has one
> > > > omission
> > > >that is crucial for Kodi: the ability to request a specific
> > > > refresh
> > > >rate for fullscreen display. This is needed for closely
> > > > matching the
> > > >display and video FPS so duplicated and skipped frames are
> > > > kept to a
> > > >minimum. Is this an intentional omission and/or is there
> > > > anything
> > > >that provides this functionality?
> > > 
> > > Hopefully the xdg_shell designers would answer that, but I believe
> > > it
> > > has been omitted for now to make it easier to declare the first
> > > fundamental parts of xdg_shell stable. It is missing a lot, but the
> > > foundation must agreed upon first before building more on top.
> > 
> > Rather than combining the FPS request with fullscreening, wouldn't it
> > be
> > better to let applications set FPS as a property of the surface?
> > 
> > That way the client would make a promise that is is going to update
> > surface contents with periodic commits of the specified rate,
> > completely
> > independent of the actual output hardware or fullscreen state.
> > 
> > The server could use that information to choose the best display
> > refresh
> > rate even if not in fullscreen mode.
> I would not want my compositor to do that, since changing the refresh
> rate means that the monitor will go blank for a while while resyncing
> on most hardware. Doing this on a regular basis would be very
> disturbing.

I agree, non-fullscreen vrefresh rate changes would only be useful for
outputs that are known to change modes quickly without blanking.
For generic desktop compositors this probably should be limited to
fullscreen surfaces. However, there may be other things that could be
done with this information, like using it for compositing decisions, if
it is known in advance that the application will not change buffer until
the next screen update. Or for changing encoder parameters for outputs
that end up being encoded and streamed.

regards
Philipp

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

Re: [PATCH] doc: be explicit about requests not returning a value

2017-05-16 Thread Pekka Paalanen

On Tue, 16 May 2017 11:23:55 +0530
Varad Gautam  wrote:

> From: Varad Gautam 
> 
> document how the asynchronous model works for requests and events to avoid
> any confusion.
> 
> Signed-off-by: Varad Gautam 
> Suggested-by: Pekka Paalanen 
> ---
>  doc/publican/sources/Protocol.xml | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/publican/sources/Protocol.xml 
> b/doc/publican/sources/Protocol.xml
> index ba6b5f1..b8c30fe 100644
> --- a/doc/publican/sources/Protocol.xml
> +++ b/doc/publican/sources/Protocol.xml
> @@ -52,7 +52,12 @@
>object ID and the event opcode, from which the client can determine
>the type of event.  Events are generated both in response to requests
>(in which case the request and the event constitutes a round trip) or
> -  spontaneously when the server state changes.
> +  spontaneously when the server state changes.  As the Wayland protocol
> +  follows an asynchronous request model, there is no concept of
> +  'return value' for requests.  A client can only receive information 
> from
> +  the server in the form of events.  Hence, if a client cannot proceed
> +  without getting some information from the server, it must invoke a
> +  round trip by issuing a wl_display_roundtrip call.
>  
>  
>

Hi Varad,

I had to read this a couple of times before I could understand what you
are after. That's probably not a good sign, considering I recently
explained the same thing on the mailing list. ;-)

How about a new paragraph instead, with a more verbose and explicit
description?

- there is no concept of return value; why; do not be fooled by the C
  API
- what do you need to do instead if you need one: explicitly define a
  reply event in the protocol
- if one needs to block waiting for the reply, how
- how to coalesce several request-reply pairs into one roundtrip
- prefer protocol designs where there is no need to block waiting
- the inverse: server needing info from client; the server must never
  block waiting

Maybe it'd need a sub-heading even?


Thanks,
pq


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

Re: [PATCH libinput] util: harmonize container_of() definition with linux kernel one

[PATCH libinput] Add support for SW_TABLET_MODE

[PATCH libinput 1/4] tools: drop libshared.la

[PATCH libinput 0/4] tools: provide a single 'libinput' tool (á la git)

[PATCH libinput 4/4] tools: hook libinput-debug-events into the libinput tool

[PATCH libinput 3/4] tools: add a 'libinput' tool

[PATCH libinput 2/4] tools: rename a source file to match the future common file name paradigm

[PATCH libinput] touchpad: fix clickfinger behavior with a thumb being present

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

Re: [PATCH] doc: be explicit about requests not returning a value

12 matches

Site Navigation

Mail list logo

Footer information