[PATCH libinput 5/5] Add meson.build file
Signed-off-by: Peter Hutterer
---
meson.build | 596 ++
meson_options.txt | 16 ++
2 files changed, 612 insertions(+)
create mode 100644 meson.build
create mode 100644 meson_options.txt
diff --git a/meson.build b/meson.build
new file mode 100644
index 000..a6cbb81
--- /dev/null
+++ b/meson.build
@@ -0,0 +1,596 @@
+project('libinput', 'c', 'cpp',
+ version : '1.7.0',
+ license: 'MIT/Expat',
+ default_options : [ 'c_std=gnu99' ],
+ meson_version : '>= 0.38.0')
+
+libinput_version = meson.project_version().split('.')
+
+# We use libtool-version numbers because it's easier to understand.
+# Before making a release, the libinput_so_*
+# numbers should be modified. The components are of the form C:R:A.
+# a) If binary compatibility has been broken (eg removed or changed interfaces)
+#change to C+1:0:0.
+# b) If interfaces have been changed or added, but binary compatibility has
+#been preserved, change to C+1:0:A+1
+# c) If the interface is the same as the previous version, change to C:R+1:A
+libinput_lt_c=22
+libinput_lt_r=2
+libinput_lt_a=12
+
+# convert to soname
+libinput_so_version = '@0@.@1@.@2@'.format((libinput_lt_c - libinput_lt_a),
+libinput_lt_a, libinput_lt_r)
+
+# Compiler setup
+cc = meson.get_compiler('c')
+cppflags = ['-Wall', '-Wextra', '-Wno-unused-parameter', '-g',
'-fvisibility=hidden']
+cflags = cppflags + ['-Wmissing-prototypes', '-Wstrict-prototypes']
+add_global_arguments(cflags, language: 'c')
+add_global_arguments(cppflags, language: 'cpp')
+
+config_h = configuration_data()
+config_h.set('_GNU_SOURCE', '1')
+
+code = '''
+#define _GNU_SOURCE
+#include
+static_assert(1 == 1, "msg");
+'''
+if not cc.compiles(code,
+ name : 'static_assert check',
+ args : [ '-Werror' ])
+ config_h.set('static_assert(...)', '/* */')
+endif
+
+# Dependencies
+pkgconfig = import('pkgconfig')
+dep_udev = dependency('libudev')
+dep_mtdev = dependency('mtdev', version: '>= 1.1.0')
+dep_libevdev = dependency('libevdev', version: '>= 0.4')
+dep_lm = cc.find_library('m')
+dep_rt = cc.find_library('rt')
+
+ libwacom configuration
+
+if get_option('libwacom')
+ dep_libwacom = dependency('libwacom', version : '>= 0.20')
+
+ code = '''
+ #include
+ int main(void) { libwacom_get_paired_device(NULL); }
+ '''
+ result = cc.links(code,
+ args : '-lwacom',
+ name : 'libwacom_get_paired_device check',
+ dependencies : dep_libwacom)
+ if result
+ config_h.set('HAVE_LIBWACOM_GET_PAIRED_DEVICE', '1')
+ endif
+endif
+
+ udev bits
+
+udev_dir = get_option('udev-dir')
+if udev_dir == ''
+ udev_dir = '@0@/lib/udev'.format(get_option('prefix'))
+endif
+udev_rules_dir = '@0@/rules.d'.format(udev_dir)
+udev_hwdb_dir = '@0@/hwdb.d'.format(udev_dir)
+
+executable('libinput-device-group',
+ 'udev/libinput-device-group.c',
+ dependencies : [dep_udev, dep_libwacom],
+ include_directories : include_directories('src'),
+ install : true,
+ install_dir : udev_dir)
+executable('libinput-model-quirks',
+ 'udev/libinput-model-quirks.c',
+ dependencies : dep_udev,
+ include_directories : include_directories('src'),
+ install : true,
+ install_dir : udev_dir)
+
+model_quirks = 'udev/90-libinput-model-quirks.hwdb'
+install_data(model_quirks,
+install_dir : udev_hwdb_dir)
+
+parse_hwdb_py = find_program('udev/parse_hwdb.py')
+test('parse-hwdb',
+ parse_hwdb_py,
+ args : ['@0@/@1@'.format(meson.source_root(), model_quirks)])
+
+udev_rules_config = configuration_data()
+udev_rules_config.set('UDEV_TEST_PATH', '')
+configure_file(input : 'udev/80-libinput-device-groups.rules.in',
+ output : '80-libinput-device-groups.rules',
+ install : true,
+ install_dir : udev_rules_dir,
+ configuration : udev_rules_config)
+configure_file(input : 'udev/90-libinput-model-quirks.rules.in',
+ output : '90-libinput-model-quirks.rules',
+ install : true,
+ install_dir : udev_rules_dir,
+ configuration : udev_rules_config)
+
+litest_udev_rules_config = configuration_data()
+litest_udev_rules_config.set('UDEV_TEST_PATH', meson.build_root())
+litest_groups_rules_file = configure_file(input :
'udev/80-libinput-device-groups.rules.in',
+ output : '80-libinput-device-groups-litest.rules',
+ install : false,
+ configuration : litest_udev_rules_config)
+litest_model_quirks_file = configure_file(input :
'udev/90-libinput-model-quirks.rules.in',
+ output : '90-libinput-model-quirks-litest.rules',
+ install : false,
+ conf
[PATCH libinput 1/5] Rename man pages to .1 suffix for meson's benefit
Signed-off-by: Peter Hutterer
---
tools/Makefile.am| 4 ++--
tools/{libinput-debug-events.man => libinput-debug-events.1} | 0
tools/{libinput-list-devices.man => libinput-list-devices.1} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename tools/{libinput-debug-events.man => libinput-debug-events.1} (100%)
rename tools/{libinput-list-devices.man => libinput-list-devices.1} (100%)
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 60a68c6..4fc1046 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -26,12 +26,12 @@ 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)
-dist_man1_MANS = libinput-list-devices.man
+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)
-dist_man1_MANS += libinput-debug-events.man
+dist_man1_MANS += libinput-debug-events.1
if BUILD_EVENTGUI
noinst_PROGRAMS += event-gui
diff --git a/tools/libinput-debug-events.man b/tools/libinput-debug-events.1
similarity index 100%
rename from tools/libinput-debug-events.man
rename to tools/libinput-debug-events.1
diff --git a/tools/libinput-list-devices.man b/tools/libinput-list-devices.1
similarity index 100%
rename from tools/libinput-list-devices.man
rename to tools/libinput-list-devices.1
--
2.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 2/5] doc: drop the explicit input from the doxygen.in
We pass in the input via the commandline, so having the files here is misleading. Replace it with an @INPUT@ - in autotools that one is ignored but it'll help meson. Signed-off-by: Peter Hutterer --- doc/libinput.doxygen.in | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/doc/libinput.doxygen.in b/doc/libinput.doxygen.in index 3dd4101..e3c3d34 100644 --- a/doc/libinput.doxygen.in +++ b/doc/libinput.doxygen.in @@ -8,8 +8,7 @@ EXTRACT_ALL= YES EXTRACT_STATIC = YES MAX_INITIALIZER_LINES = 0 QUIET = YES -INPUT = @top_srcdir@/src/libinput.h \ -@top_srcdir@/README.md +INPUT = @INPUT@ IMAGE_PATH = @top_srcdir@/doc/svg \ @top_srcdir@/doc/dot GENERATE_HTML = YES -- 2.9.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 3/5] test: allow running the symbols-leak-test.in script directly
With autotools, we replace the @top_srcdir@ during configure and then run teh resulting scripts. With meson, it's easier to just pass top-srcdir it in as argument. Signed-off-by: Peter Hutterer --- test/symbols-leak-test.in | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/test/symbols-leak-test.in b/test/symbols-leak-test.in index 448ef2f..69861c9 100755 --- a/test/symbols-leak-test.in +++ b/test/symbols-leak-test.in @@ -2,6 +2,13 @@ ### simple check for exported symbols +# Allow running this after the configure.ac replacement or directly with an +# argument for the top_srcdir +TOP_SRCDIR="@top_srcdir@" +if [ "$TOP_SRCDIR" = "@top_srcdir@" ]; then + TOP_SRCDIR="$1" +fi + # make bash exit if any command will exit with non-0 return value set -e @@ -9,9 +16,9 @@ set -e cd `dirname $0` diff -a -u \ - <(cat @top_srcdir@/src/libinput.sym | \ + <(cat "$TOP_SRCDIR"/src/libinput.sym | \ grep '^\s\+libinput_.*' | \ sed -e 's/^\s\+\(.*\);/\1/' | sort) \ - <(cat @top_srcdir@/src/*.c | \ + <(cat "$TOP_SRCDIR"/src/*.c | \ grep LIBINPUT_EXPORT -A 1 | grep '^libinput_.*' | \ sed -e 's/(.*//' | sort) -- 2.9.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 4/5] configure.ac: drop checks for a few flags
These were added in 2013 for old enterprise distributions (centos 5.5, see fdo
bz 63360), it's now 4 years later and these checks seems a bit superfluous.
If those bits are missing, compilation will fail anyway.
Signed-off-by: Peter Hutterer
---
configure.ac | 9 -
1 file changed, 9 deletions(-)
diff --git a/configure.ac b/configure.ac
index 8b838fd..338d385 100644
--- a/configure.ac
+++ b/configure.ac
@@ -55,15 +55,6 @@ AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != :])
LT_PREREQ([2.2])
LT_INIT
-AC_CHECK_DECL(EPOLL_CLOEXEC, [],
- [AC_MSG_ERROR("EPOLL_CLOEXEC is needed to compile libinput")],
- [[#include ]])
-AC_CHECK_DECL(TFD_CLOEXEC,[],
- [AC_MSG_ERROR("TFD_CLOEXEC is needed to compile libinput")],
- [[#include ]])
-AC_CHECK_DECL(CLOCK_MONOTONIC,[],
- [AC_MSG_ERROR("CLOCK_MONOTONIC is needed to compile libinput")],
- [[#include ]])
AC_CHECK_DECL(static_assert, [],
[AC_DEFINE(static_assert(...), [/* */], [noop static_assert()
replacement]),
AC_MSG_RESULT([no])],
--
2.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 0/5] Enable meson as build system
This adds meson as a build system, for now in parallel to autotools but if everything goes well expect autotools to be removed in a future release. So better get on the meson bandwagon. There are a couple of minor differences, the biggest is probably that the test run doesn't automatically run valgrind anymore. gcov is provided natively through meson (though I haven't tested this yet), so that bit goes away. The rest is pretty much straightforward. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v2 wayland-protocols] inputfd - direct input access protocol
On Tue, Apr 25, 2017 at 11:34:06AM +0200, Bastien Nocera wrote:
> On Sun, 2017-04-23 at 09:47 -0700, Roderick Colenbrander wrote:
> >
>
> > We originally discussed maybe using pipes and now more unix domain
> > sockets for 'non kernel evdev fds'. As part of the discussion we
> > realized ioctls wouldn't be available. Thinking about it some more, I
> > think the lack of ioctl support is problematic. Sure we can use fds
> > to
> > send 'struct input_event' over, but EVIOCGABS is critical for
> > determining capabilties and value ranges. Many others are useful too
> > like the revoke ones. How should this be dealt with?
>
> To be honest, I expected the single file descriptor to work both ways,
> and with ioctls, but that's obviously not possible when the ioctl might
> be blocking.
>
> I've looked through SDL, and it only uses ioctl()s for this initial
> state and for force feedback ("haptic"). A separate API for that looks
> unfortunately in order.
fwiw, the kernel has SYN_CONFIG but it's not well defined (or defined at
all) so right now the kernel pretty much guarantees that a device never
changes. And even if it didn't, too much of the userspace already relies on
that so it cannot be changed. Hence the ioctls only being used during
initialisation.
Cheers,
Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v2 wayland-protocols] inputfd - direct input access protocol
On Tue, Apr 25, 2017 at 11:16:24AM +0200, Bastien Nocera wrote: > On Tue, 2017-04-25 at 10:20 +1000, Peter Hutterer wrote: > > On Mon, Apr 24, 2017 at 02:19:45PM +1000, Peter Hutterer wrote: > > > On Sun, Apr 23, 2017 at 09:47:20AM -0700, Roderick Colenbrander > > > wrote: > > > > On Mon, Apr 17, 2017 at 9:05 PM, Peter Hutterer > > > > wrote: > > > > > > > > > > On Fri, Apr 07, 2017 at 01:43:57PM +0300, Pekka Paalanen wrote: > > > > > > On Fri, 7 Apr 2017 14:04:40 +1000 > > > > > > Peter Hutterer wrote: > > > > > > > > > > > > > For the initial patchset, see > > > > > > > https://lists.freedesktop.org/archives/wayland-devel/2017-M > > > > > > > arch/033626.html > > > > > > > For a high-level description, see > > > > > > > http://who-t.blogspot.com.au/2017/04/inputfd-protocol-for-d > > > > > > > irect-access-to.html > > > > > > > > > > > > > > This is a relatively unexciting update, the notable bits > > > > > > > are: > > > > > > > * instead of having a per-device type get_seat_* request, > > > > > > > we now have just a > > > > > > > basic get_seat() request that returns all inputfd-capable > > > > > > > devices. This > > > > > > > allows for mice, keyboards, etc as well without having > > > > > > > more requests > > > > > > > * the property description has a link to the github repo i > > > > > > > started for the > > > > > > > dictionary > > > > > > > * the fd was split into a read/write fd to allow for pipes, > > > > > > > the type was > > > > > > > extended for an evdev-protocol-carrying pipe. (I'm not > > > > > > > convinced this > > > > > > > is good enough yet, just as a note) > > > > > > > > > > > > Hi, > > > > > > > > > > > > I don't understand the need for two fds. Yes, pipes are > > > > > > one-directional, but one could use a AF_UNIX socket for > > > > > > bidirectional > > > > > > comms (socketpair(2)). Having a second pipe fd for writing > > > > > > does not > > > > > > allow for a synchronous command a la ioctl() anyway. > > > > > > > > > > > > You have read and write fds in the same event. Wayland is > > > > > > incapable of sending an argument of type fd that is not > > > > > > actually a real > > > > > > open file descriptor. This means that if the write fd is not > > > > > > needed, > > > > > > one still needs to create a valid open fd, send it, and close > > > > > > it. > > > > > > > > > > > > Even if you send the same fd in both arguments, the receiver > > > > > > will > > > > > > receive two different valued fds. Determining if they are the > > > > > > same > > > > > > underlying "file" is... I don't actually know how to do that. > > > > > > Something > > > > > > about comparing fstat(2) information. > > > > > > > > > > > > We had the problem with the linux_dmabuf protocol, where one > > > > > > needs > > > > > > to send a variable number of fds. We solved it by sending one > > > > > > event per > > > > > > fd. > > > > > > > > > > > > > > > > ftr, I've reverted this locally again, so we're back down to > > > > > one fd, thanks. > > > > > > > > > > Cheers, > > > > > Peter > > > > > > > > > > > > > We originally discussed maybe using pipes and now more unix > > > > domain > > > > sockets for 'non kernel evdev fds'. As part of the discussion we > > > > realized ioctls wouldn't be available. Thinking about it some > > > > more, I > > > > think the lack of ioctl support is problematic. Sure we can use > > > > fds to > > > > send 'struct input_event' over, but EVIOCGABS is critical for > > > > determining capabilties and value ranges. Many others are useful > > > > too > > > > like the revoke ones. How should this be dealt with? > > > > > > there are two parts to that question. The first one is effectively > > > "how to > > > deal with device capabilities", i.e. EVIOCGABS and friends. Those > > > can be > > > handled on a side-channel, either through the IFDA properties or as > > > real > > > events on the wayland protocol. (ioctl is a side-channel too, so > > > it's not > > > even that different). Obviously, as events on the wayland protocol > > > we could > > > guarantee things like event ordering and only send them on the > > > first focus > > > in, etc. IFDA properties give us the extensibility advantages, > > > so... *shrug* :) > > > > > > Something like this should get you most of the way there? > > Why bother with this when you could export the same data via the more > generic properties? It's not like this event is formatted like an ioctl > answer, so if we need to demarshal/parse anyway... That was my first attempt, but tbh, it doesn't look pretty: diff --git a/README.md b/README.md index 2f611c5..95e9d9b 100644 --- a/README.md +++ b/README.md @@ -62,6 +62,27 @@ In alphabetical order. The bus type of this device. Permitted values are * **```bluetooth```** * **```usb```** +* **```IFDA_CAPABILITY_EVDEV_EV_ABS```**: + A device capability denoting the EV_ABS capability on an evdev-like file + descriptor. The value is a sequence of six hexad
Return values in Wayland XML specification
How are return values specified in the Wayland XML specification? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] doc: compact installation instructions
On Tue, Apr 25, 2017 at 11:29:07AM +0200, Jan Engelhardt wrote:
> * Drop version-specific SO version from source-install command where
> this is not needed.
> * Less typing for the user: use zypper short forms.
> * Less typing for the user: libtool implies automake implies
> autoconf, so trim the install command.
is anyone actually typing this? or do they just copy-paste anyway? I suspect
the latter, so I much prefer clarity over shortness.
> * Just specify the requirement for a root shell instead of lengthily
> prefixing everything with one specific tool.
> (People might be using, for example, kdesu/gksu.)
> ---
> doc/building.dox | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/doc/building.dox b/doc/building.dox
> index 9bafa32..53829eb 100644
> --- a/doc/building.dox
> +++ b/doc/building.dox
> @@ -59,15 +59,15 @@ $> sudo make uninstall
> @endcode
>
> The following commands reinstall the current system package for libinput,
> -overwriting manually installed files.
> +overwriting manually installed files. As root, issue:
nope to this, I prefer sudo because it's a lot more explicit than an
almost-hidden "as root". and yes, I still get occasional complaints of users
that don't know they need to be root to install. And I suspect that if
you're using kdesu/gksu then you're more likely to know to leave sudo off
(or leave it in, doesn't matter).
>
> -Debian/Ubuntu based distributions: ```sudo apt-get install
> +Debian/Ubuntu based distributions: ```apt-get install
> --reinstall libinput```
> -Fedora 22 and later: ```sudo dnf reinstall libinput```
> -RHEL/CentOS/Fedora 21 and earlier: ```sudo yum reinstall
> libinput```
> -openSUSE: ```sudo zypper install --force libinput10```
> -Arch: ```sudo packman -S libinput```
> +Fedora 22 and later: ```dnf reinstall libinput```
> +RHEL/CentOS/Fedora 21 and earlier: ```yum reinstall
> libinput```
> +openSUSE: ```zypper in -f libinput10```
tbh, this doesn't really help. yes, it may be a short form, but
"install --force" is a lot more readable and obvious if something goes
wrong.
> +Arch: ```pacman -S libinput```
>
>
> @subsection building_dependencies Build dependencies
> @@ -75,19 +75,19 @@ overwriting manually installed files.
> libinput has a few build-time dependencies that must be installed prior to
> running configure. In most cases, it is sufficient to install the
> dependencies that your distribution uses to build the libinput package.
> -These can be installed with one of the following commands:
> +These can be installed with one of the following commands in a root shell:
>
>
> -Debian/Ubuntu based distributions: ```sudo apt-get build-dep
> +Debian/Ubuntu based distributions: ```apt-get build-dep
> libinput```
> -Fedora 22 and later: ```sudo dnf builddep libinput```
> -RHEL/CentOS/Fedora 21 and earlier: ```sudo yum-builddep
> libinput```
> +Fedora 22 and later: ```dnf builddep libinput```
> +RHEL/CentOS/Fedora 21 and earlier: ```yum-builddep
> libinput```
> openSUSE:
>
> -$> sudo zypper modifyrepo --enable `zypper repos | grep source | awk '{print
> $5}'`
> -$> sudo zypper source-install -d libinput10
> -$> sudo zypper install autoconf automake libtool
> -$> sudo zypper modifyrepo --disable `zypper repos | grep source | awk
> '{print $5}'`
> +# zypper modifyrepo --enable `zypper repos | grep source | awk '{print $5}'`
> +# zypper si -d libinput
> +# zypper in libtool
> +# zypper modifyrepo --disable `zypper repos | grep source | awk '{print $5}'`
any particular reason why to use # here?
Cheers,
Peter
>
>
> Arch:
> --
> 2.12.0
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] doc: compact installation instructions
* Drop version-specific SO version from source-install command where
this is not needed.
* Less typing for the user: use zypper short forms.
* Less typing for the user: libtool implies automake implies
autoconf, so trim the install command.
* Just specify the requirement for a root shell instead of lengthily
prefixing everything with one specific tool.
(People might be using, for example, kdesu/gksu.)
---
doc/building.dox | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/doc/building.dox b/doc/building.dox
index 9bafa32..53829eb 100644
--- a/doc/building.dox
+++ b/doc/building.dox
@@ -59,15 +59,15 @@ $> sudo make uninstall
@endcode
The following commands reinstall the current system package for libinput,
-overwriting manually installed files.
+overwriting manually installed files. As root, issue:
-Debian/Ubuntu based distributions: ```sudo apt-get install
+Debian/Ubuntu based distributions: ```apt-get install
--reinstall libinput```
-Fedora 22 and later: ```sudo dnf reinstall libinput```
-RHEL/CentOS/Fedora 21 and earlier: ```sudo yum reinstall
libinput```
-openSUSE: ```sudo zypper install --force libinput10```
-Arch: ```sudo packman -S libinput```
+Fedora 22 and later: ```dnf reinstall libinput```
+RHEL/CentOS/Fedora 21 and earlier: ```yum reinstall libinput```
+openSUSE: ```zypper in -f libinput10```
+Arch: ```pacman -S libinput```
@subsection building_dependencies Build dependencies
@@ -75,19 +75,19 @@ overwriting manually installed files.
libinput has a few build-time dependencies that must be installed prior to
running configure. In most cases, it is sufficient to install the
dependencies that your distribution uses to build the libinput package.
-These can be installed with one of the following commands:
+These can be installed with one of the following commands in a root shell:
-Debian/Ubuntu based distributions: ```sudo apt-get build-dep
+Debian/Ubuntu based distributions: ```apt-get build-dep
libinput```
-Fedora 22 and later: ```sudo dnf builddep libinput```
-RHEL/CentOS/Fedora 21 and earlier: ```sudo yum-builddep
libinput```
+Fedora 22 and later: ```dnf builddep libinput```
+RHEL/CentOS/Fedora 21 and earlier: ```yum-builddep libinput```
openSUSE:
-$> sudo zypper modifyrepo --enable `zypper repos | grep source | awk '{print
$5}'`
-$> sudo zypper source-install -d libinput10
-$> sudo zypper install autoconf automake libtool
-$> sudo zypper modifyrepo --disable `zypper repos | grep source | awk '{print
$5}'`
+# zypper modifyrepo --enable `zypper repos | grep source | awk '{print $5}'`
+# zypper si -d libinput
+# zypper in libtool
+# zypper modifyrepo --disable `zypper repos | grep source | awk '{print $5}'`
Arch:
--
2.12.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v2 wayland-protocols] inputfd - direct input access protocol
On Sun, 2017-04-23 at 09:47 -0700, Roderick Colenbrander wrote:
>
> We originally discussed maybe using pipes and now more unix domain
> sockets for 'non kernel evdev fds'. As part of the discussion we
> realized ioctls wouldn't be available. Thinking about it some more, I
> think the lack of ioctl support is problematic. Sure we can use fds
> to
> send 'struct input_event' over, but EVIOCGABS is critical for
> determining capabilties and value ranges. Many others are useful too
> like the revoke ones. How should this be dealt with?
To be honest, I expected the single file descriptor to work both ways,
and with ioctls, but that's obviously not possible when the ioctl might
be blocking.
I've looked through SDL, and it only uses ioctl()s for this initial
state and for force feedback ("haptic"). A separate API for that looks
unfortunately in order.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v2 wayland-protocols] inputfd - direct input access protocol
On Tue, 2017-04-25 at 10:20 +1000, Peter Hutterer wrote: > On Mon, Apr 24, 2017 at 02:19:45PM +1000, Peter Hutterer wrote: > > On Sun, Apr 23, 2017 at 09:47:20AM -0700, Roderick Colenbrander > > wrote: > > > On Mon, Apr 17, 2017 at 9:05 PM, Peter Hutterer > > > wrote: > > > > > > > > On Fri, Apr 07, 2017 at 01:43:57PM +0300, Pekka Paalanen wrote: > > > > > On Fri, 7 Apr 2017 14:04:40 +1000 > > > > > Peter Hutterer wrote: > > > > > > > > > > > For the initial patchset, see > > > > > > https://lists.freedesktop.org/archives/wayland-devel/2017-M > > > > > > arch/033626.html > > > > > > For a high-level description, see > > > > > > http://who-t.blogspot.com.au/2017/04/inputfd-protocol-for-d > > > > > > irect-access-to.html > > > > > > > > > > > > This is a relatively unexciting update, the notable bits > > > > > > are: > > > > > > * instead of having a per-device type get_seat_* request, > > > > > > we now have just a > > > > > > basic get_seat() request that returns all inputfd-capable > > > > > > devices. This > > > > > > allows for mice, keyboards, etc as well without having > > > > > > more requests > > > > > > * the property description has a link to the github repo i > > > > > > started for the > > > > > > dictionary > > > > > > * the fd was split into a read/write fd to allow for pipes, > > > > > > the type was > > > > > > extended for an evdev-protocol-carrying pipe. (I'm not > > > > > > convinced this > > > > > > is good enough yet, just as a note) > > > > > > > > > > Hi, > > > > > > > > > > I don't understand the need for two fds. Yes, pipes are > > > > > one-directional, but one could use a AF_UNIX socket for > > > > > bidirectional > > > > > comms (socketpair(2)). Having a second pipe fd for writing > > > > > does not > > > > > allow for a synchronous command a la ioctl() anyway. > > > > > > > > > > You have read and write fds in the same event. Wayland is > > > > > incapable of sending an argument of type fd that is not > > > > > actually a real > > > > > open file descriptor. This means that if the write fd is not > > > > > needed, > > > > > one still needs to create a valid open fd, send it, and close > > > > > it. > > > > > > > > > > Even if you send the same fd in both arguments, the receiver > > > > > will > > > > > receive two different valued fds. Determining if they are the > > > > > same > > > > > underlying "file" is... I don't actually know how to do that. > > > > > Something > > > > > about comparing fstat(2) information. > > > > > > > > > > We had the problem with the linux_dmabuf protocol, where one > > > > > needs > > > > > to send a variable number of fds. We solved it by sending one > > > > > event per > > > > > fd. > > > > > > > > > > > > > ftr, I've reverted this locally again, so we're back down to > > > > one fd, thanks. > > > > > > > > Cheers, > > > > Peter > > > > > > > > > > We originally discussed maybe using pipes and now more unix > > > domain > > > sockets for 'non kernel evdev fds'. As part of the discussion we > > > realized ioctls wouldn't be available. Thinking about it some > > > more, I > > > think the lack of ioctl support is problematic. Sure we can use > > > fds to > > > send 'struct input_event' over, but EVIOCGABS is critical for > > > determining capabilties and value ranges. Many others are useful > > > too > > > like the revoke ones. How should this be dealt with? > > > > there are two parts to that question. The first one is effectively > > "how to > > deal with device capabilities", i.e. EVIOCGABS and friends. Those > > can be > > handled on a side-channel, either through the IFDA properties or as > > real > > events on the wayland protocol. (ioctl is a side-channel too, so > > it's not > > even that different). Obviously, as events on the wayland protocol > > we could > > guarantee things like event ordering and only send them on the > > first focus > > in, etc. IFDA properties give us the extensibility advantages, > > so... *shrug* :) > > > Something like this should get you most of the way there? Why bother with this when you could export the same data via the more generic properties? It's not like this event is formatted like an ioctl answer, so if we need to demarshal/parse anyway... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
