[ANNOUNCE] libei 1.2.1
libei 1.2.1 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/1.2.1 Only one fix in liboeffis: previously using OEFFIS_DEVICE_ALL_DEVICES in oeffis_create_session() would result in the portal selecting no devices instead of all. That's obviously not what's desired. Peter Hutterer (7): ci: bump to use F39 CI: drop the git depth for the ABI check job CI: fix a hardcoded fedora and replace it with the jinja var CI: move the minium meson version job to debian test: yield the proxy, not the subprocess for the liboeffis fixtures oeffis: OEFFIS_DEVICE_ALL_DEVICES should translate to "all" libei 1.2.1 signature.asc Description: PGP signature
[ANNOUNCE] libei 1.2.0
libei 1.2.0 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/1.2.0 Notable fixes in this release include better handling of various protocol errors and less log spam: - if the write buffer is full, outgoing messages are now cached instead of returning EAGAIN. - if a message send fails, stop trying to send more messages which will do nothing but spam the log with more errors - if we get disconnected by the server, stop trying to send things to the server (and spam the log on error) - use EINTR checks instead of blocking SIGALRM - keep a cache of defunct objects to avoid spamming the log when there are in-flight messages arriving after destroy No change in the API Alban Browaeys (1): Fix duplicate negation in log message Peter Hutterer (33): ei: improve a debug message, the number we print is the serial util: fix clobbered errno in sink_add_source util: allow sources to have write notifications ei: queue unsent messages for later delivery if our buffer is full Add a static assertion that EAGAIN == EWOULDBLOCK tools: add a --interval option to the demo server and client util: block SIGALRM during posix_fallocate CI: add a separate job for the documentation build doc/protocol: fix some hugo warnings doc: use a specific revision of the hugo template CI: add missing dependencies line ei: if sending a message fails, don't send any more ei: remove the source if we get disconnected tools: add an --iterations argument to ei-demo-client util: replace most of SIGALRM blocks with EINTR checks util: don't check for EINTR on close() util: retry posix_fallocate() if it fails util: add helper macros for the ELF section handling util: add a global setup option to our munit wrapper test: set up a timer to trigger SIGALRM doc: drop the git depth from the hugo theme test: expand log messages to accommodate for 4-digit line numbers test: make peck_dispatch_until_stable() print more useful debug info test: fix a test missing frame events eis: only queue a seat bind event if the caps change eis: fix a typo test: hack a peck_debug() function test: make bug logs fatal by default test: add the ability to add offsets to ei_now() ei: keep a cache of defunct objects to avoid spamming the log ei: improve debug messages for keymap failures pre-commit: autoupdate and add two more useful checkers libei 1.2.0 signature.asc Description: PGP signature
Re: Re: 回复: Re: get input device in wayland
On Fri, Nov 24, 2023 at 11:00:34AM +0800, weinan wang wrote: > Thank you, I think I understand why the wayland-protocol is designed > the way it is. > Finally, I would like to ask if there is a input mapping protocol upstream is > considering to add like "xinput map-to-output". > Tablet, touch screen, and other absolute device mapping functions > are currently implemented separately in different compositors, > such as kwin has added related functions in dbus there is no protocol planned or at least I'm not aware of it, it will be a compositor-specific configuration only. It all requires a bit of a mindshift - think of Wayland like HTTP. You don't configure your browser via HTTP requests from the websites, that is done through other channels, for a whole bunch of reasons. Cheers, Peter > At 2023-11-24 09:11:34, "Peter Hutterer" wrote: > >On Wed, Nov 22, 2023 at 06:52:47PM +0800, WeiWei wrote: > >> Thank you very much, I will discuss this idea with the designer. > >> > >> I'd like to ask, why the underlying device is not exposed in > >> current wayland-protocols, what are the benefits of doing this. > > > >The overwhelmingly vast majority of applications don't need to know > >about the specifics of the device, so exposing it is both not necessary > >and may also lead to interference if the applications try to do things > >based on assumptions that a compositor may not meet. > > > >X did expose the devices and in addition to making it a nightmare to > >maintain it is also effectively unused. Plus there's a whole can of > >niche bugs that can get exposed that way - e.g. if you're listening for > >button events on a specific device you can get out of sync with what the > >compositor treats as logical button state. > > > >> With keyboard and pointer, we don't usually care about > >> physical device, but for touch devices, each touch device > >> will work independently and need input mapping and calibration, > >> is it possible to consider adding some device information > >> in wl_touch in the future. > > > >The general consensus is that touch mapping and calibration should be > >part of the compositor and/or a side-channel to the compositor if the > >calibration needs to be done in an external application. > > > >Cheers, > > Peter > > > >> > >> > >> 从 Windows 版邮件发送 > >> > >> 发件人: Peter Hutterer > >> 发送时间: 2023年11月22日 14:45 > >> 收件人: weinan wang > >> 抄送: wayland-devel@lists.freedesktop.org > >> 主题: Re: Re: get input device in wayland > >> > >> On Wed, Nov 22, 2023 at 09:22:56AM +0800, weinan wang wrote: > >> > Thanks for reply, > >> > We want to achieve an application for touch input map, > >> > it will map touch input to a output device when we have multi-screen. > >> > > >> > The input map need provide a input device and a output device, > >> > in our design, we will traversal all screen to ask user "is this screen > >> > you > >> > want to map", and user choice a touch device by tap on a touch device, > >> > just like "touch config" feature in Windows11. > >> > > >> > All in all, we want to achieve an application for touch input map, if > >> > have a batter > >> > design, i will discuss it with the designer. > >> > >> There is no absolutely surefire way to do this as a pure Wayland > >> application but one possible UI flow would be: > >> > >> - getting the list of touchscreens from udev [1] > >> - printing something like "Mapping screen 'Foo Vendor Touchscreen'" > >> - display on output A with icons "this one", "nah, next one please" > >> - rotate through outputs until "this one" is clicked > >> > >> You don't need to care whether the confirmation even comes from the > >> touchscreen. > >> > >> Alternatively you can display on all screens simultaneously and assume > >> the button + screen that receives the "Yes" click are the one that want > >> the touchscreen. > >> > >> Cheers, > >> Peter > >> > >> [1] slightly unreliable since there's no guarantee they're all handled > >> but most likely good enough > >> > >> > At 2023-11-22 06:31:07, "Peter Hutterer" > >> > wrote: > >> > >On Tue, Nov 21, 2023 at 04:20:10PM +0800, weinan wang wrote: > >> > >>
Re: 回复: Re: get input device in wayland
On Wed, Nov 22, 2023 at 06:52:47PM +0800, WeiWei wrote: > Thank you very much, I will discuss this idea with the designer. > > I'd like to ask, why the underlying device is not exposed in > current wayland-protocols, what are the benefits of doing this. The overwhelmingly vast majority of applications don't need to know about the specifics of the device, so exposing it is both not necessary and may also lead to interference if the applications try to do things based on assumptions that a compositor may not meet. X did expose the devices and in addition to making it a nightmare to maintain it is also effectively unused. Plus there's a whole can of niche bugs that can get exposed that way - e.g. if you're listening for button events on a specific device you can get out of sync with what the compositor treats as logical button state. > With keyboard and pointer, we don't usually care about > physical device, but for touch devices, each touch device > will work independently and need input mapping and calibration, > is it possible to consider adding some device information > in wl_touch in the future. The general consensus is that touch mapping and calibration should be part of the compositor and/or a side-channel to the compositor if the calibration needs to be done in an external application. Cheers, Peter > > > 从 Windows 版邮件发送 > > 发件人: Peter Hutterer > 发送时间: 2023年11月22日 14:45 > 收件人: weinan wang > 抄送: wayland-devel@lists.freedesktop.org > 主题: Re: Re: get input device in wayland > > On Wed, Nov 22, 2023 at 09:22:56AM +0800, weinan wang wrote: > > Thanks for reply, > > We want to achieve an application for touch input map, > > it will map touch input to a output device when we have multi-screen. > > > > The input map need provide a input device and a output device, > > in our design, we will traversal all screen to ask user "is this screen you > > want to map", and user choice a touch device by tap on a touch device, > > just like "touch config" feature in Windows11. > > > > All in all, we want to achieve an application for touch input map, if have > > a batter > > design, i will discuss it with the designer. > > There is no absolutely surefire way to do this as a pure Wayland > application but one possible UI flow would be: > > - getting the list of touchscreens from udev [1] > - printing something like "Mapping screen 'Foo Vendor Touchscreen'" > - display on output A with icons "this one", "nah, next one please" > - rotate through outputs until "this one" is clicked > > You don't need to care whether the confirmation even comes from the > touchscreen. > > Alternatively you can display on all screens simultaneously and assume > the button + screen that receives the "Yes" click are the one that want > the touchscreen. > > Cheers, > Peter > > [1] slightly unreliable since there's no guarantee they're all handled > but most likely good enough > > > At 2023-11-22 06:31:07, "Peter Hutterer" wrote: > > >On Tue, Nov 21, 2023 at 04:20:10PM +0800, weinan wang wrote: > > >> Hey Guys, > > >> We have an application that needs to get the touch device > > >> corresponding to the touch event, and on X11, we can get the device ID > > >> that sends this event according to the XI_Touch events, and then find > > >> the device we want according to this ID. But on Wayland, it seems > > >> that neither wl_seat nor wl_touch can get device-related information, > > >> this application is a user permission, so we can't use libinput to get > > >> more low-level events. > > >> Please ask if there is any other way to get the device that sends the > > >> event? > > > > > >This is not possible in wayland, physical devices are abstracted into > > >wl_pointer/wl_keyboard/wl_touch and the underlying device is not exposed > > >anywhere through wayland or even current wayland-protocols. > > > > > >The sole exception is the wl_tablet protocol which is per physical > > >device but that's due to how tablets are being used. > > > > > >You don't usually have access to the libinput context inside the > > >compositor either (because Wayland itself doesn't require libinput, it's > > >an implementation detail). > > > > > >The question here is: what are you trying to achieve? maybe there's a > > >different way to do it than having access to the specific physical > > >device. > > > > > >Cheers, > > > Peter >
Re: Re: get input device in wayland
On Wed, Nov 22, 2023 at 09:22:56AM +0800, weinan wang wrote: > Thanks for reply, > We want to achieve an application for touch input map, > it will map touch input to a output device when we have multi-screen. > > The input map need provide a input device and a output device, > in our design, we will traversal all screen to ask user "is this screen you > want to map", and user choice a touch device by tap on a touch device, > just like "touch config" feature in Windows11. > > All in all, we want to achieve an application for touch input map, if have a > batter > design, i will discuss it with the designer. There is no absolutely surefire way to do this as a pure Wayland application but one possible UI flow would be: - getting the list of touchscreens from udev [1] - printing something like "Mapping screen 'Foo Vendor Touchscreen'" - display on output A with icons "this one", "nah, next one please" - rotate through outputs until "this one" is clicked You don't need to care whether the confirmation even comes from the touchscreen. Alternatively you can display on all screens simultaneously and assume the button + screen that receives the "Yes" click are the one that want the touchscreen. Cheers, Peter [1] slightly unreliable since there's no guarantee they're all handled but most likely good enough > At 2023-11-22 06:31:07, "Peter Hutterer" wrote: > >On Tue, Nov 21, 2023 at 04:20:10PM +0800, weinan wang wrote: > >> Hey Guys, > >> We have an application that needs to get the touch device > >> corresponding to the touch event, and on X11, we can get the device ID > >> that sends this event according to the XI_Touch events, and then find > >> the device we want according to this ID. But on Wayland, it seems > >> that neither wl_seat nor wl_touch can get device-related information, > >> this application is a user permission, so we can't use libinput to get > >> more low-level events. > >> Please ask if there is any other way to get the device that sends the > >> event? > > > >This is not possible in wayland, physical devices are abstracted into > >wl_pointer/wl_keyboard/wl_touch and the underlying device is not exposed > >anywhere through wayland or even current wayland-protocols. > > > >The sole exception is the wl_tablet protocol which is per physical > >device but that's due to how tablets are being used. > > > >You don't usually have access to the libinput context inside the > >compositor either (because Wayland itself doesn't require libinput, it's > >an implementation detail). > > > >The question here is: what are you trying to achieve? maybe there's a > >different way to do it than having access to the specific physical > >device. > > > >Cheers, > > Peter
Re: get input device in wayland
On Tue, Nov 21, 2023 at 04:20:10PM +0800, weinan wang wrote: > Hey Guys, > We have an application that needs to get the touch device > corresponding to the touch event, and on X11, we can get the device ID > that sends this event according to the XI_Touch events, and then find > the device we want according to this ID. But on Wayland, it seems > that neither wl_seat nor wl_touch can get device-related information, > this application is a user permission, so we can't use libinput to get > more low-level events. > Please ask if there is any other way to get the device that sends the > event? This is not possible in wayland, physical devices are abstracted into wl_pointer/wl_keyboard/wl_touch and the underlying device is not exposed anywhere through wayland or even current wayland-protocols. The sole exception is the wl_tablet protocol which is per physical device but that's due to how tablets are being used. You don't usually have access to the libinput context inside the compositor either (because Wayland itself doesn't require libinput, it's an implementation detail). The question here is: what are you trying to achieve? maybe there's a different way to do it than having access to the specific physical device. Cheers, Peter
Re: using libinput with glib's signal_timeout
On Fri, Nov 03, 2023 at 11:12:27AM +0100, kyomawolf wrote: > Hey Guys, > currently I'm trying to use a libinput's eventloop. It used to work as a > standalone, but when I tried to put it into Glib::signal_timeout it seems to > not receive any events anymore. Do you know more about why this is happening? > I put a simple example of what I mean in the attachment. > Greetings Kyomawolf > rough guess: you're not calling libinput_dispatch() when there's data on the libinput_get_fd(). libinput doesn't work in a thread, it only does things when you call libinput_dispatch() and that again may (or may not) result in events being available. IOW, unless you call libinput_dispatch(), nothing happens. also - if in doubt enable debug logging so you can see what libinput does during dispatch, that might provide some info too. Cheers, Peter
[ANNOUNCE] libei 1.1.0
libei 1.1.0 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/1.1.1 Only a few minor fixes to the tools and one documentation fix since the RC1. Jason Gerecke (1): Correct documentation for ei_touch_(get|set)_user_data Peter Hutterer (4): tools: start ei-debug-events for the fd we get from the oeffis demo tool tools: fix an indentation issue tools/debug-events: print the region mapping id libei 1.1.0 signature.asc Description: PGP signature
[ANNOUNCE] libei 1.1.0 RC1
libei 1.1.0 RC1 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/1.0.901 Notable fixes in this release include: - ei_device_get_region_at() and its libeis equivalent was added as a helper to obtain a device's region at a given point. this is a library-only change. - ei_region_get_mapping_id() returns the mapping id previously set by the EIS implementation via eis_region_set_mapping_id(). This mapping id can be used to identify external resources that have a relationship with this region, e.g. a pipewire stream that uses the same mapping id. This is a protocol addition and bumps the ei_device protocol to version 2. Note that libei(s) was accidentally leaking some symbols from internal utility functions due to a missing compiler flag. These symbols are no longer there but ABI checkers will complain when updating to this version - those errors can be ignored. The ei-scanner protocol parser now requires Python 3.9. It did already anyway, but now it'll actually fail during meson setup instead of just blowing up with Python exceptions during build. Other than that, a bunch of fixes and tidies, in particular the s390x builds and test runs should now work correctly. Not planning on another RC - unless something major comes up expect 1.1.0 next week somewhen. Peter Hutterer (20): meson.build: bump to use gnu11 over gnu99 Add ei_device_get_region_at() to obtain a region for a point util: fix iobuf_take_fd invalid memmove for multiple fds util: fix iobuf_append_fd OOB when we have too many fds Add a mapping_id to the regions proto: require Python 3.9 test: rework the oeffis dbus tests to be pytest-compatible test: close the sockets on exit util: add a strv_from_mem() helper function test: log the buffers after reading from them test: ensure munit debug messages are visible on failure meson: build libutil with hidden symbols visibility CI: update the commit for the last ABI break test: rename a variable to avoid clashes brei: avoid pointer casts for 32/64 bit values util: switch iobuf to uint8_t to avoid sign issues brei: copy protocol strings out of the protocol buffers test: use munit_assert_uint64 for 64-bit values test: fix 64-bit pointer access for the object ids libei 1.1.0rc1 signature.asc Description: PGP signature
[ANNOUNCE] libinput 1.24.0
libinput 1.24.0 is now available. It's been a while since the last release so let's flush out what's on our branch. Only three notable topics: On Apple touchpads, natural scrolling is now enabled by default and palm detection is disabled - the touchpads are good enough that they don't need our help. Built-in tablet devices now always have touch arbitration enabled, so we no longer need to add a quirk for each of them. And speaking of tablets: the pressure offset limit for worn-out devices is now at 50% of the range. Modern pens have a precise enough range that even worn out pen can still provide satisfactory pressure sensitivity. This pressure offset is now detected on worn-out pens that do not support distance. Finally, where a relative device's rotation is 180 degrees (e.g. a trackball used upside-down) we now flip the scroll wheel direction as well. The rest of the changes is the usual mix of janitorial patches and device-specific quirks. As usual, the git shortlog is below. Bjørn Forsman (2): tablet: increase pressure offset limit from 20% to 50% quirks: Add Wacom Bamboo Fun Pen Hector Martin (2): evdev: Enable natural scrolling by default on Apple touchpad: Disable edge palm detection Apple touchpads José Expósito (3): doc: document libinput_device_tablet_pad_get_* error case quirks: AddHP Spectre x360 15 ModelTabletModeNoSuspend keyboard quirk quirks: Add Lenovo Legion 7i 4090 keyboard quirks Llerraf Gnem (1): docs: fix "See also" link in libinput_config_accel_profile Peter Hutterer (45): test: minor cleanups CI: bump to latest ci-templates for a new ci-fairy fallback: don't double-map if any left-handed buttons are down test: move arbitration test into a helper function tablet: split out arbitration/rotation handling assignment tablet: always enable touch arbitration with touchscreens/ext. touchpads doc/user: the CI uses FEDORA_PACKAGES, not FEDORA_RPMS CI: remove unused meson-prep.sh and meson-test.sh scripts quirks: sort the razer entries by PID tools: add a tool to update our Razer quirks for internal keyboards doc/user: fix documentation for rotation doc/user: add a section on natural scrolling CI: fix the rpm build job's Fedora version tools: fix a few scan-build dead store warnings tools/debug-gui: fix a deprecated warning CI: update to use Fedora 38 test: carry the step as argument for arg testing tools: add rotation support to debug-events and debug-gui fallback: remove write-only rotation.is_enabled variable evdev: if a device's rotation is around 180 degrees, flip the wheel CI: add a comment to the meson build helper test: change tablet coords to doubles and pass the pointer through test: add an extra override hook for tablet motion test: add a pre-calibrated flag and exclude the tests as necessary test: add a calibrated (swapped) tablet device man: hide debug-gui from the libinput.man page if disabled CODING_STYLE: drop the unintended real name policy doc/user: move ignoring devices to separate page test: remove a confusing comment test: check the tablet pressure values with a helper function test: check that the pressure offset is reduced during motion events too doc/user: update the udev rule to handle bind/unbind events tablet: move setting the pressure offset into a helper function tablet: split detecting and updating the pressure offset tablet: split proximity and axis update handling tablet: apply pressure offset handling for non-distance tablets doc/user: quirks are available, not supported Add triage policies for merge requests Add a triage policy for kernel bugs test: expand the tablet mode switch test to check for fake key releases Fix a gcc analyzer complaint Fix a few gcc analyzer complaints in util-strings.* Drop the Signed-off-by requirement quirks: add quirk for the RazerBlade152023 keyboard libinput 1.24.0 Robert Glossop (1): Disregard touchless clicks on flaky devices Simon Ser (1): doc/user/timestamps: document which clock is used Yinon Burgansky (1): docs: improve custom pointer acceleration documentation. signature.asc Description: PGP signature
[ANNOUNCE] libei 1.0.0
libei 1.0.0 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/1.0.0 # Changes: Note that there is one minor protocol change (`ei_connection.sync`) and one ABI (not API) change in libeis since the RC2 despite previous statements that the protocol and API are stable. In both cases it was better to do it now while every user of libei(s) is still in draft than having to special-case those instances for the next 10 years. An rebuild will take care of of the ABI change, making sure libei and libeis are both on 1.0.0 will take care of the protocol change. Notable changes since RC2: - meson requirements dropped back to 0.56 to allow for building on older distros - Protocol - ei_connection.sync now takes a version argument to allow for future updates of the ei_callback interface. This is a protocol change. - the ei-scanner now exposes interface_arg + interface_arg_for and version_arg + version_arg_for to allow for better handling of arguments that refer to interfaces or versions, respectively - Library: - The enum eis_event_type was synced with libei so identical events (e.g. EI_EVENT_FRAME and EIS_EVENT_FRAME) have the same enum value in both libraries. This fixes commit e6954b76d. This is an ABI break, a rebuild will take care of it. - sending an ei_device_scroll_discrete event with value 1 now logs a bug. This typically indicates a bug in the caller and the value should be a fraction or multiple of 120 instead. - a few missing functions are now public: eis_region_contains(), eis_region_get_physical_scale(), eis_device_get_context(), eis_seat_get_context(), eis_device_get_width() and eis_device_get_height() - libeis *for now* sends all negotiated interface versions back to the client during the initial handshake. This isn't required by the protocol but it ensures those parts of any new client are working correctly. Please see the documentation here: https://libinput.pages.freedesktop.org/libei/ The git shortlog is below Ian Douglas Scott (2): ei-scanner: Fix `--jinja-extra-data-file`, and make `mypy` check pass ei-scanner: Expose `interface_arg`, and also provide `interface_arg_for` Peter Hutterer (39): meson.build: drop requirements back to 0.56 CI: add a build test for our minimum meson version scanner: rework the main() function into something easier to test scanner: add tests for the extra data arguments ei-scanner: expose `version_arg` and `version_arg_for` proto: add a version argument to ei_connection.sync libei: check incoming objects' version for correctness libeis: check incoming objects' version for correctness log: remove trailing linebreaks from log messages Log a bug if a client tries to send a discrete value 1 CI: add a comment to the meson build helper Remove unimplemented ei_device_get_keymap() ei: ei_device_get_width/height need to be public APIs doc: change the doxygen oeffis group to liboeffis tools: make the demo client send the correct discrete events eis: expose eis_device_get_context() and eis_seat_get_context() test: use the callback's version instead of hardcoding it a second time Correct a meaningless comment eis: sync event codes with libei CI: use meson setup in the abi check job CI: fix the ABI check job, it was using the wrong HEAD eis: add eis_region_get_physical_scale eis: expose eis_region_contains ei: more docs that data is in pixels or mm test: drop ifdef'd out test test: add tests for the eis region getters CI: remove a copy/pasted MESON_ARGS from the abicheck job ci: add a check that our event values cannot diverge test: check that the width/height are set for physical devices ei: remove unused ei_pingpong_new() tests: add tests for button events ei: removed unused ei_callback_new_for_id eis: send all our interface versions to the client test: add a unit test for ei_region_convert_point ei: fix a whitespace error test: don't over-ref the button/scroll devices test: add test for correct ei_device_close behavior test: ensure all returned interface versions are 1 libei 1.0.0 signature.asc Description: PGP signature
[ANNOUNCE] libei 1.0.0RC2
libei 1.0.0 RC2 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/0.99.2 There were more commits than expected since RC1, so let's do another RC, just in case. Notable things in this RC: - libei should build now on BSDs - the library providing sd-bus can be selected with a meson option - ei-scanner supports Interface.plainname (the interface name without an "ei_" or "eis_" prefix) - ei(s)_event_type_to_string() returns the name of the event type enum. This is for debugging and to avoid callers having to implement that particular function themselves. Please see the documentation here: https://libinput.pages.freedesktop.org/libei/ The git shortlog is below: Ian Douglas Scott (2): doc/protcol: Change references of `ei_device.keymap` to `ei_keyboard` tools: Consistently refer to `$XDG_RUNTIME_DIR` Jan Beich (8): meson: depend on math library for BSDs meson: depend on epoll-shim for BSDs meson: depend on elogind or basu if systemd is missing liboeffis: expand sd_bus_close_unref for basu compatibility util: avoid /proc on BSDs (but keep for tests) meson: allow selecting sd-bus library via option brei: silence warnings on 32-bit architectures util: silence warnings when memfd_create is missing Peter Hutterer (15): CI: install meson and ninja from pip CI: move the pip package list into the config.yml file as well brei: move the object_id_t typedefs to the brei-proto.h header Drop a few unused unref functions CI: bump to use F38 eis: drop declaration for eis_client_has_capability() CI: add an abidiff job pre-commit: add a hook to generate the CI templates CI: clone the upstream repo for the abidiff job Log a connection error before disconnecting eis: don't log a warning for a disconnecting client that's disconnected scanner: add the Interface.plainname property test: add some tests for the ei-scanner itself Export the event names through helper functions libei 1.0.0rc2 signature.asc Description: PGP signature
[ANNOUNCE] libei 1.0.0
libei 1.0.0 RC1 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/0.99.1 This release marks the C API and the protocol stable. 1.0 is expected very soon unless someone finds some serious issues with the current code that warrants another RC. Notable changes since 0.5: - the protocol no longer has a fixed capability enum, the bitmask is based on the available interfaces. See the ei_seat.capability event in the protocol documentation - new interfaces for button and scroll - these were split out from the previously merged pointer/pointer_absolute interfaces. Clients need to bind to those in addition to binding to pointer and/or pointer_absolute. EIS implementations need to provide those separately in addition to pointer/pointer_absolute. - a number of APIs have been renamed to adjust for this, e.g. ei_event_pointer_get_scroll_x() is now ei_event_scroll_get_dx() - ei_seat_bind_capability() was removed, use ei_seat_bind_capabilities() instead - the pkgconfig files are now libei-1.0.pc, libeis-1.0.pc, liboeffis-1.0.pc - enabling tests are now a meson feature, i.e. use -Dtests=enabled All of the above are largely search/replace. Don't forget to bind to the new button/scroll capabilities. Please see the documentation here: https://libinput.pages.freedesktop.org/libei/ The git shortlog is below: Peter Hutterer (48): ei: fix ei_seat_unbind_capabilities ei: de-duplicate ei_seat_unbind_capability test: cast the varargs to the right data size meson: require the python modules that the scanner requires doc: fix two obsolete API comments doc: move the sentinel attribute to unconfuse doxygen test: fix a debug log typo Rename an internal struct to scroll_state Split the ei_pointer interface up into its components protocol: replace the capabilities enum with an interface list Purge the pseudo-code examples doc: point to the main branch, not the master branch ei: change the API to match the protocol interfaces closer eis: change the API to match the protocol interfaces closer doc: rename the mainpage sections to get @ref ei to work Add a few more doxygen comments doc: some minor doxygen updates doc: split the libei doxygen API into multiple submodules ei: tighten the event type checks eis: remove a misleading paragraph from the docs eis: split up the API docs into smaller categories eis: drop the vestiges of client restrictions tools/demo-server: only print now if we actually have events tools/demo-server: check if we have a touch before sending one tools: ei-demo-client needs to bind to the new button/scroll caps ei: fix capability checks for sending events tools: ei-demo-client should bind all caps at once tools: make the button/scroll caps available on demo-server seats meson.build: install our headers into a versioned subfolder doc/protocol: fix the link to the C libraries section doc/protocol: fix link to the liboeffis API docs meson.build: add soname versions to the generated libraries doc/api: add liboeffis to the various sections doc/api: add the unicode icons for a splash of color doc/api: add some more high-level overview to the libei page test: fix the oeffis pytest meson.build: list if oeffis is built in the summary meson.build: change the test builds to be a feature tools: bind to the new capabilities in ei-debug-events test: add the new caps to the bind-all-caps test test: switch to use ei_seat_bind_capabilities() ei: drop ei_seat_bind_capability() and the unbind equivalent ei: drop unused ei_insert_device_removed_event() proto: document the callback-data for pingpong/callback better protocol: widen the callback_data arg for ping/sync to 64bit proto: fix a typo README: fix the paragraph talking about the protocol libei 1.0.0rc1 signature.asc Description: PGP signature
[ANNOUNCE] libei 0.5
libei 0.5 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/0.5 Notable changes since 0.4.1: - the previously protobuf-based ad-hoc protocol has changed to custom format defined in the protocol.xml file. This protocol is heavily influenced by the Wayland protocol but not binary compatible. The protocol is not yet stable. - new and prettier documentation, primarily aimed at the protocol. See https://libinput.pages.freedesktop.org/libei/ - ei_get_version() has been removed, with the protocol having per-interface versions this is no longer useful - ei_device_start_emulating() now takes a sequence number - Support for properties has been removed. The use-case for these was a bit unclear anyway and the few things they could have been used for are catered for by the portal. - libreis has been removed. The use-case for this was a bit unclear and it didn't provide anything the portals can't do. This is a development snapshot and neither API nor ABI should be considered stable. Anyone using libei or libeis must keep both in sync, there are no accommodations made for libei/libeis from different versions and the wire protocol may break at any time. Please see the documentation here: https://libinput.pages.freedesktop.org/libei/ The git shortlog is below: Jonas Ådahl (4): protocol: Make integer explicitly sized demos: Print timestamp protocol: Add support for 64 bit integers on the wire protocol: Make timestamps a single 64 bit argument Peter Hutterer (273): meson.build: add override_dependencies for all our libraries gitlab CI: drop the reference to the forced container rebuild gitlab CI: drop the container clean stage gitlab CI: compress the file inclusion a bit gitlab CI: switch the ci-fairy job to the fdo ci-fairy image gitlab CI: move default_artefacts to the default build template gitlab CI: replace meson-build.sh with a more generic one gitlab-ci: add one more explanatory comment Format python files with black util-time: fix the us2ms function ei: re-order a few arguments to match the order in the protocol Add a gitignore file for the subprojects directory ei: fix a typo test: fix a test case's behavior eis: don't allow connecting a disconnected client test: fix compiler warning about possible loss of precision meson.build: switch the source file lists to use files() meson.build: switch the src include dir to the proper meson way meson.build: use proper include handling for the proto dir brei: drop the explicit src in a #include statement meson.build: move tests to test/meson.build proto: drop the varint values, replace with fixed size ones proto: drop the Packet message, replace with 4 byte prefix Purge libreis from the repo Purge the properties from the protocol Add a sequence number to START_EMULATING test: fix pytest loading liboeffis.so tools: add a comment to the demo server tools: cleanup our clients in the eis demo server tools: whitespace fix in the demo server util: add a object getter helper for fields as refs util: add macros to declare getters and setters util: undo accidental rename from source->is_active to is_sender meson.build: alphabetical sort of the source files Remove the public API to query the client version number Add some extra getters for the context and the eis_client ei: divide the headers up across multiple files eis: divide the headers up across multiple files eis: don't send stop_emulating for a sender device test: drop a bunch of unused imports CI: move the package list to the config.yml file CI: the check-commit and check-merge-request should use the ci-fairy image CI: use the ci-fairy image and a venv for the black job CI: add a python linter job with Ruff CI: fix typo in the package list util: rename xvasprintf to xvaprintf ei: implement ei_device_get_width/height test: set the minimum bits for our test devices eis: don't EINVAL if a coordinate is outside the region util: add msleep() tools: copy the default log handler to the eis demo server libeis: make eis_client_get_context() part of the public API eis: use eis_client_get_context instead of parent util: add some mask helpers util: mmap with MAP_PRIVATE instead of MAP_SHARED ei: rename ei_set_connection to ei_set_socket Add ei/eis getters for the device id ei-device: use the setter declaration macros util-io: add a few helper functions to iobuf Drop protobuf in favour of a custom proto
[ANNOUNCE] libinput 1.22.1
libinput 1.22.1 is available! This version includes quirks for laptops from Apple and Dell, as well as for the Glorious Model 0 mouse. It also backports a meson fix for use of libinput as subproject and a fix for libinput debug-events not flushing the output, resulting in truncated information. Finally, the tablet touch arbitration rectangle was increased by 50mm in both directions to reduce the number of misdetected touches. Charles Wang (1): quirks: add quirks for Dell Precision5680 Touchpad Hector Martin (1): quirks: Add Apple MTP touchpad quirk José Expósito (2): tablet: increase touch arbitration rectangle height quirks: add quirk for Dell Latitude 5290 2-in-1 Peter Hutterer (2): tools: fflush the output in debug-events after each set of events libinput 1.22.1 Samuel Reddy (1): quirks: add quirks for Glorious Model O mouse Simon Ser (1): build: override dependency for use as subproject signature.asc Description: PGP signature
[ANNOUNCE] libei 0.4.1
libei 0.4.1 is now available. This time with the tag pointing to the right commit. See below for the 0.4 announcement below which has all the interesting bits. On Fri, Dec 09, 2022 at 03:15:30PM +1000, Peter Hutterer wrote: > libei 0.4 is now available. libei is a library to send > Emulated Input (EI) to a matching Emulated Input Server (EIS) which can > receive those events with libeis, also part of this project. > > libei uses GitLab releases, for tarballs please see: > https://gitlab.freedesktop.org/libinput/libei/-/releases/0.4.1 > > Notable changes since 0.3: > - ei_setup_backend_portal() was removed. The portal it connected to never > really existed and all the efforts since have gone into supporting libei > connections through the RemoteDesktop and the InputCapture portals. Note > that these changes are not yet merged into upstream xdg-desktop-portal. > - a new library "liboeffis" takes the place of the above. It is a helper > library to connect to the RemoteDesktop portal via DBus with a minimal API > and retrieve the EIS socket. > This library is intended to be used by tools that cannot easily talk DBus > themselves (this includes Xwayland). > - the libei/libeis log handlers have a new API which makes handling log > messages a bit simpler. > - version exchange between client/server make it possible (in the future) to > have multiple supported protocol versions. > > This is a development snapshot and neither API nor ABI should be considered > stable. Anyone using libei or libeis must keep both in sync, there are no > accommodations made for libei/libeis from different versions and the wire > protocol may break at any time. > > Please see the API documentation here: > https://libinput.pages.freedesktop.org/libei/ > > The git shortlog is below: > > Olivier Fourdan (7): > README: Xwayland is a Wayland client > Fix absolute events filtering > util: Add block/release signals API > util: Protect system calls against signals > util: Add a wrapper for dup() and pipe2() > ei: Use the signal protected wrappers > liboeffis: protect from interrupted system calls > > Peter Hutterer (44): > Add a comment that reserved properties cannot be set by the API > reis: fix return code handling in allow_capabilities > reis: drop unnecessary variable rc > proto: reformat according to the Google Style Guide > proto: specify that Configure messages must be sent before connection > eis: capabilities can only be reduced > proto: document ConfigureCapabilities > proto: split the Configure messages out a bit > proto: document that only one ConfigureName is possible > Remove a double semicolon > util: only do flag_* operations if the bit fits > test: rename the ei AUTOCONNECT behavior to HANDLE_CONNECT > test: set up libreis support in eierpecken > eis: send out the list of existing properties on connect > eis: add eis_client_has_capability > test: add a few tests for reis > eis: default the client to only the capabilities we know about > tools/demo-client: stop means stop sending events > tools/demo-client: keep a ref to the ptr/kbd/abs devices > tools: print property values in the demo client and server > proto: split the client's SetProperty from the server event > log: allocate the log message on demand > log: enforce single logical messages only > Drop the trailing newline from the log messages > log: abstract the auxiliary information into a log message context > tools: drop help for obsolete --sender option from the eis-demo-server > Add a version macro for grepable version numbers > proto: add a version exchange prior to connect > proto: allow the client to set the protocol version > proto: add versioned Configure transactions > Fix some logging linebreak issues > proto: separate pre-connection properties into ConfigureProperty > doc: fix two references to function calls > doc: fix a doxygen warning about a wrong parameter name > doc: fix a comment in util-mem.h > meson.build: fix an indentation issue > CI: purge all references to the master branch > CI: bump to Fedora 37 > CI: bump to latest ci-templates > README: swap to RemoteDesktop over the nonexistent EmulatedInput portal > Purge the portal code > liboeffis is a wrapper library for the RemoteDesktop communication > util: change the signal handler to a context-manager like macro > libei 0.4 > > signature.asc Description: PGP signature
[ANNOUNCE] libei 0.4
libei 0.4 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/0.4 Notable changes since 0.3: - ei_setup_backend_portal() was removed. The portal it connected to never really existed and all the efforts since have gone into supporting libei connections through the RemoteDesktop and the InputCapture portals. Note that these changes are not yet merged into upstream xdg-desktop-portal. - a new library "liboeffis" takes the place of the above. It is a helper library to connect to the RemoteDesktop portal via DBus with a minimal API and retrieve the EIS socket. This library is intended to be used by tools that cannot easily talk DBus themselves (this includes Xwayland). - the libei/libeis log handlers have a new API which makes handling log messages a bit simpler. - version exchange between client/server make it possible (in the future) to have multiple supported protocol versions. This is a development snapshot and neither API nor ABI should be considered stable. Anyone using libei or libeis must keep both in sync, there are no accommodations made for libei/libeis from different versions and the wire protocol may break at any time. Please see the API documentation here: https://libinput.pages.freedesktop.org/libei/ The git shortlog is below: Olivier Fourdan (7): README: Xwayland is a Wayland client Fix absolute events filtering util: Add block/release signals API util: Protect system calls against signals util: Add a wrapper for dup() and pipe2() ei: Use the signal protected wrappers liboeffis: protect from interrupted system calls Peter Hutterer (44): Add a comment that reserved properties cannot be set by the API reis: fix return code handling in allow_capabilities reis: drop unnecessary variable rc proto: reformat according to the Google Style Guide proto: specify that Configure messages must be sent before connection eis: capabilities can only be reduced proto: document ConfigureCapabilities proto: split the Configure messages out a bit proto: document that only one ConfigureName is possible Remove a double semicolon util: only do flag_* operations if the bit fits test: rename the ei AUTOCONNECT behavior to HANDLE_CONNECT test: set up libreis support in eierpecken eis: send out the list of existing properties on connect eis: add eis_client_has_capability test: add a few tests for reis eis: default the client to only the capabilities we know about tools/demo-client: stop means stop sending events tools/demo-client: keep a ref to the ptr/kbd/abs devices tools: print property values in the demo client and server proto: split the client's SetProperty from the server event log: allocate the log message on demand log: enforce single logical messages only Drop the trailing newline from the log messages log: abstract the auxiliary information into a log message context tools: drop help for obsolete --sender option from the eis-demo-server Add a version macro for grepable version numbers proto: add a version exchange prior to connect proto: allow the client to set the protocol version proto: add versioned Configure transactions Fix some logging linebreak issues proto: separate pre-connection properties into ConfigureProperty doc: fix two references to function calls doc: fix a doxygen warning about a wrong parameter name doc: fix a comment in util-mem.h meson.build: fix an indentation issue CI: purge all references to the master branch CI: bump to Fedora 37 CI: bump to latest ci-templates README: swap to RemoteDesktop over the nonexistent EmulatedInput portal Purge the portal code liboeffis is a wrapper library for the RemoteDesktop communication util: change the signal handler to a context-manager like macro libei 0.4 signature.asc Description: PGP signature
[ANNOUNCE] libei 0.3
libei 0.3 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/0.3 Notable changes since 0.2: - libei now supports the concept of sender/receiver contexts. A libei context in sender mode can send events to the (EIS-created) devices, a libei context in receiver mode can receive events from the (EIS-created) devices. This allows for libei to be used as a transport layer for captured input events (the synergy server use-case). - a libei context can bind/unbind to seat capabilities individually at any time - frame events now carry a timestamp - a helper tool ei-debug-events is now available, this tool can be used in e.g. portal implementation to show the events being sent. This is a development snapshot and neither API nor ABI should be considered stable. Anyone using libei or libeis must keep both in sync, there are no accommodations made for libei/libeis from different versions and the wire protocol may break at any time. Please see the API documentation here: https://libinput.pages.freedesktop.org/libei/ The git shortlog is below: David Redondo (1): Some doc fixes relating to keymaps Jonas Ådahl (7): libei: Clarify whether a context owns a passed fd eis: Clarify mmap restrictions on keymap eis: Fix a couple of coding style issues eis: Add API to add client getting an fd eirpecken: Use the new eis_backend_fd_add_client() eis: Remove eis_backend_fd_add_fd() Only auto-stop emulating if sender Peter Hutterer (64): Fix a typo in the docs Documentation updates meson.build: don't pass werror through to munit gitlab CI: move the pages job configuration to config.yml gitlab CI: add a -Werror job (allowed to fail) gitlab CI: drop the requirement for Signed-off-by Add SPDX identifiers to all source files gitlab CI: fail the CI early if the fork is private util: add a helper for fetching the cmdline. eis: add the functions to fetch a region back from the device test: localize a coordinate set a bit better test: add a helper function to mark test progress test: aded a test for key events util-object: split macro to generate unref into one two test: define peck_unrefp in the header file doc: document the events a little doc: fix the documentation for the eis capabilities doc: updates all over the place eis: don't allow for region changes once the region was added Add concept of active/passive libei contexts tools: add active/passive mode to the demo server and client test: add test cases for eis -> ei events ei: require the client to confirm capabilities rather than drop them eis: remove eis_device_set_name(), use eis_device_configure_name() eis: after the client binds the seat, drop the capabilities meson.build: fix a deprecation warning Fix a comment referring to an old implementation Remove a stray uint32_t from the documentation Correct two comments regarding active vs passive context Add ei_is_active() eis: the EIS context does not have a is_active setting Change to allow dynamic binding of capabilities Differentiate between physical and virtual devices Rename ei active/passive to sender/receiver tools: print the returned negative errno on failure tools: fix a few issues in the demo server tools: add ei-debug-events Whitespace fix Improve the "message type" debug output a bit Better touch debugging messages test: make the dispatch looping easier to understand in the debug logs test: use the helper functions to enable the default behaviors test: handle frame events in passive ei contexts by default ei: frame events must be sent on state emulating, not resumed test: add a few missing frame events Only send touch up events on destroy if the touch is down Enforce a frame after ei_touch_destroy() Filter empty frame events test: ensure we only get frame events after device events Add a bunch of warnings when sending events outside of emulating Warn if the touch isn't down for a touch motion Flush the frame event before a stop_emulating Assert on start_emulating if we're left with a pending frame event Add a filter for empty frames on the receiver side ei: add receiver handling for empty/flushing frame events Remove an outdated comment Print the strerror too if a message fails Add timestamps to frame events util: add the macros to run through a list backwards ei: expose ei_event_get_context() internally Add a pending event queue for incoming
[ANNOUNCE] libinput 1.20.1
libinput 1.20.1 is now available One single patch only, for a format string vulnerability, assigned CVE-2020-1215. See https://gitlab.freedesktop.org/libinput/libinput/-/issues/752 for details When a device is detected by libinput, libinput logs several messages through log handlers set up by the callers. These log handlers usually eventually result in a printf call. Logging happens with the privileges of the caller, in the case of Xorg this may be root. The device name ends up as part of the format string and a kernel device with printf-style format string placeholders in the device name can enable an attacker to run malicious code. An exploit is possible through any device where the attacker controls the device name, e.g. /dev/uinput or Bluetooth devices. Many thanks to Albin Eldstål-Ahrens and Benjamin Svensson from Assured AB for their discovery and responsible reporting of this issue. This issue was independently discovered by Lukas Lamster. Many thanks for their discovery and responsible reporting. The release is available via gitlab from https://gitlab.freedesktop.org/libinput/libinput/-/releases/1.20.1 -- Peter Hutterer (2): evdev: strip the device name of format directives libinput 1.20.1 signature.asc Description: PGP signature
[ANNOUNCE] libinput 1.18.2
libinput 1.18.2 is now available. This release includes a fix for CVE-2022-1215, a format string vulnerabilty in the evdev device handling. For details, see https://gitlab.freedesktop.org/libinput/libinput/-/issues/752 Peter Hutterer (2): evdev: strip the device name of format directives libinput 1.18.2 git tag: 1.18.2 https://www.freedesktop.org/software/libinput/libinput-1.18.2.tar.xz SHA256: be63f923b868c9287be2879c3df3129d8e8d36a8dec9b8ad1cf161eead82aea4 libinput-1.18.2.tar.xz SHA512: 39e7fed19c31c54e85d1c778b31224449310372c04c1255ea47496b5365e750232b1586c0c6adb3033b8d524c8bbc210b5bb5ed0dcc4a78e82e65acbf4669b22 libinput-1.18.2.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.18.2.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] libinput 1.19.4
libinput 1.19.4 is now available. This release includes a fix for CVE-2022-1215, a format string vulnerabilty in the evdev device handling. For details, see https://gitlab.freedesktop.org/libinput/libinput/-/issues/752 Peter Hutterer (2): evdev: strip the device name of format directives libinput 1.19.4 git tag: 1.19.4 https://www.freedesktop.org/software/libinput/libinput-1.19.4.tar.xz SHA256: ff33a570b5a936c81e6c08389a8581c2665311d026ce3d225c88d09c49f9b440 libinput-1.19.4.tar.xz SHA512: 3a046a1719747c04f59d48608c438399631c25d0ed0643ca0370206bb67c6da2ea06978ea8cec0feff2bc61d63a9045519c961c5fd8fd46814b571468174 libinput-1.19.4.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.19.4.tar.xz.sig signature.asc Description: PGP signature
Re: Touchscreen calibration matrix changes
On Wed, Apr 06, 2022 at 06:02:22AM +0300, Teemu K wrote:
> On Tue, Apr 5, 2022 at 5:21 PM Pekka Paalanen wrote:
> >
> > On Tue, 29 Mar 2022 15:31:59 +0300
> > Teemu K wrote:
> >
> > > Hi,
> > >
> > > I'm trying to get touch calibration working on Wayland/Weston for
> > > resistive touch. I can get the calibration points and calculate
> > > calibration matrix values, but when I call
> > > libinput_device_config_calibration_set_matrix and then read it back it
> > > would seem that the matrix is changed, but the actual touchscreen does
> > > not indicate so. Ie. if I calibrate the touch clearly wrong it still
> > > behaves like it would have been calibrated perfectly.
> >
> > Hi,
> >
> > what exactly do you mean by "when I call
> > libinput_device_config_calibration_set_matrix", what is "I" there?
> By "I" I mean the application.
>
> > > If I set the same values to udev rule like this:
> > > ATTRS{name}=="tsc2007", ENV{LIBINPUT_CALIBRATION_MATRIX}="1.29342,
> > > -0.0223598, -0.135092, -0.0272545, -1.11435, 1.04368"
> > >
> > > They get taken in use and I can read those values as default values
> > > with libinput_device_config_calibration_get_default_matrix - function.
> >
> > That's right.
> >
> > > Is there something else that needs to be done to get the updated
> > > matrix taken in use or is there known issue with Wayland/Weston given
> > > that it is quite old version Wayland 1.17.0/Weston 6.0.1.
> > > Unfortunately I'm stuck with those versions for now.
> >
> > I'm not sure what problem you have. The udev rule works, right?
> Yeah, but the problem was replacing those defaults with the calibrated
> values with that ibinput_device_config_calibration_set_matrix -
> function.
>
> > Or do you mean updating the calibration matrix while Weston is already
> > running?
> >
> > Did you write a new program that simply calls
> > libinput_device_config_calibration_set_matrix() and then expect Weston
> > to pick that up when you run it?
> Weston is already running and I'm trying to set a new matrix in use
> for Weston. Is that not what the
> ibinput_device_config_calibration_set_matrix - function is meant for?
>
> > If so, then libinput just does not work that way. There is no persistent
> > configuration in libinput, and any setting you make is local in the
> > in-memory libinput data structure. The udev rules are the persistent
> > configuration. That's why e.g. calibration_helper option exists in
> > weston.ini, so that you could have your own way of storing the
> > calibration in udev rules.
> This is not the issue. I'm very well aware that there is no persistent
> storage in libinput and I'm not trying to use it as such. I'm trying
> to set a new matrix when Weston is already running.
The issue here is less whether libinput has persistent storage, the issue is
that you do not have access to the libinput context that the compositor uses.
https://wayland.freedesktop.org/libinput/doc/latest/faqs.html#can-i-write-a-program-to-make-libinput-do-foo
The only way around this is to use compositor-provided knobs that *the
compositor* then converts into libinput configuration calls. Like the weston
touch protocol that you have found now.
Cheers,
Peter
>
> But I ended up copying the implementation from weston-touch-calibrator
> as you mentioned instead and it worked so this issue is solved.
>
> Thanks.
>
> -TeemuK
>
> > It looks like clients/touch-calibrator.c existed already in Weston
> > 6.0.0. It's a ready-made calibration tool that computes
> > LIBINPUT_CALIBRATION_MATRIX values, and uploads those to Weston. You
> > need weston.ini option touchscreen_calibrator=true to make it work, and
> > the calibration_helper option to save the calibration persistent. These
> > are described in the weston.ini man page, and there is an example
> > script at
> > https://gitlab.freedesktop.org/wayland/weston/-/blob/main/doc/scripts/calibration-helper.bash
> >
> > The option touchscreen_calibrator=true exposes a Wayland extension that
> > allows both getting raw touch coordinates and uploading a new
> > calibration matrix to Weston. This is the only way to update the matrix
> > without restarting Weston.
> >
> >
> > Thanks,
> > pq
[ANNOUNCE] libei 0.2
libei 0.2 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/0.2 This is a development snapshot and neither API nor ABI should be considered stable. Anyone using libei or libeis must keep both in sync, there are no accommodations made for libei/libeis from different versions and the wire protocol may break at any time. Please see the API documentation here: https://libinput.pages.freedesktop.org/libei/ The git shortlog is below: David Edmundson (1): tools/demo-server: create a seat in uinput mode David Redondo (3): Implement support for scroll events Allow compiling against newer protobuf-c Free lockfile path Olivier Fourdan (1): libei: Do not abort if LIBEI_SOCKET is not set Peter Hutterer (429): Initial commit libei: change the device creation API a bit libei: make the pointer/touch ranges constant and client-determined libeis: caps shouldn't be a bitmask Simplify the suspend/resume behavior Update keymap handling examples: update for the latest API changes Drop the _ctx suffix to the main structs libei: add a HELLO message on connect libeis: add the init bits for a new libeis context for unix sockets libeis: declare a few extra functions that will be useful Add the minimal implementation for a UNIX socket libeis server libeis: remove existing devices before disconnecting the client libeis: avoid a cleanup double-free client: handle the case of zero data bytes tools: handle device removal tools: handle multiple events after a single dispatch() libeis: whitespace fix libeis: fix wrong message field assignment libeis: only log client state transitions if they changed Add the minimal implementation for a UNIX socket libei client tools: terminate the example server correctly on SIGINT meson: fix header installation and pkgconfig libraries tools: make the socket server example take a socket path README: add some clarification for why libei libei: add a hook to configure the client name libei: take the LIBEI_SOCKET variable if the socket path is NULL libeis: remove the socket on exit tools: default to the LIBEI_SOCKET if present Send the trailing null byte for composed string messages utils: update the buffer length when appending data util: remove the source from the removed_list on destroy libeis: only remove the source on disconnect, don't destroy it meson.build: drop spaces before colon util: fix the fd reading util: add some documentation for the iobuf helpers test: add a test for the util-io helpers Replace the custom message parsing with protobuf README: make a note about the Xwayland PoC and short-lived apps Process multiple messages in one dispatch Use send() instead of write() to prevent SIGPIPE Add a missing empty line utils: Rename OBJECT_DECLARE... to OBJECT_IMPLEMENT proto: add a protocol specification proto: add a fixed-length frame message Implement pointer button and keyboard key events tools: add key events to the example client Make the button events carry event codes, not indices libei: switch to passive naming for accepted/removed messages libei: implement a few missing functions libei: add a few comments and extra checks libei: documentation updates test: add some internal unit-tests to libei test: remove an unnecssary arg for the iotest libei: switch to a single ei_new() function libei: rename to ei_setup_backend_socket() libei: don't ref the event on return libeis: handle other events during unref libeis: don't ref the event on return tools: stop immediately on a disconnect event libei: add a backend to work off a single fd libeis: switch to a single eis_new() function libei: remove unused connection field libei: fix source removal on ei_disconnect utils: rename the sources close behavior for extra clarity tools: fix a few memleaks on errors libeis: rename to eis_setup_backend_socket() libei: implement device_get_name() libei: implement ei_peek_event() util: add flag_set and flag_clear helpers eis: implement eis_peek_event() and eis_next_event_type() util: fix the example for DEFINE_TRIVIAL_CLEANUP_FUNC eis: implement an fd backend libei: fix the source ref handling util: add a tristate helper Add a test suite Fix the sources ref handling again util: add a realloc helper test: add a test for the sources utility functions libei: rename _NEW state
Re: button remapping and drag lock?
On Thu, Dec 23, 2021 at 10:30:50AM -0500, Tom Horsley wrote: > Here is a bit of shell script which makes it possible to use my > Kensington Expert Wireless Trackball Mouse under X11: > > xinput --set-button-map "$nm" 1 8 3 4 5 6 7 2 > xinput --set-prop --type=int --format=8 "$nm" \ > 'libinput Drag Lock Buttons' 2 1 > > The trackball is large, it sits in one place, and unless I > can make one of the buttons be a drag lock button, it is > almost impossible to use, needing to cross over both hands > or play twister with my fingers :-). (If I can use drag > lock, it is the best mouse I've ever had). > > Is there any way at all to do this in wayland? I recently > tried wayland on an ubuntu 20.04 system, and could not find > anything like it. > > I'd be happy to buy a couple of trackballs for wayland developers > if they'd promise to support drag lock :-). > > Alternatively, perhaps you could tell me where such support > would best be implemented and I could see about implementing > it myself. Shouldn't take me more than a year to come up to speed > on the software :-). I'd argue that the best place to implement this is in the compositor [1] since it allows for better discoverability and more flexible configuration - it is an accessibility interface after all. But right now, it isn't (afaict) currently implemented in any compositor. Cheers, Peter [1] hence why in X it's implemented in the driver which is the closest thing to the compositor for these use-cases
[ANNOUNCE] libinput 1.19.3
libinput 1.19.3 is now available. The usual low-risk device-specific fixes and one fix for hold gestures when a thumb is detected. Alexander Radovich (1): quirks: add ModelBouncingKeys for A4Tech X-710BK Mouse Gary Wolfe (1): quirks: Dell 15R touchpad settings for firmware v3 Joaquin Gonzalez (1): quirks: changes touchpad pressure Lenovo Yoga 2 Pro José Expósito (3): doc/user: fix broken link to systemd 60-evdev.hwdb gestures: cancel hold gestures on thumb detection doc/user: fix broken link to "Observations on trackpoint input data" Peter Hutterer (1): libinput 1.19.3 git tag: 1.19.3 https://www.freedesktop.org/software/libinput/libinput-1.19.3.tar.xz SHA256: 3cae78ccde19d7d0f387e58bc734d4d17ab5f6426f54a9e8b728c90b17baa068 libinput-1.19.3.tar.xz SHA512: f4b776d0da78c687ba21b430a04941ac6b43f68970c82ec9f7360358fdea5ed6a873948ce66a25bcdd64d4b95fa4bf705cc24dbc25c7c0f5fd2d0efbd763f298 libinput-1.19.3.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.19.3.tar.xz.sig signature.asc Description: PGP signature
Re: xkbcommon: Converting keysym to keycode
On Sat, Dec 04, 2021 at 08:34:49AM +, adlo wrote: > Basically the program I’m working on was originally designed for X11, and I’m > trying to adapt it to Wayland. I’m trying to find an equivalent to > XKeysymToKeycode(). > > > it doesn't, but if you look at xkbcli how-to-type and it's source > > (tools/how-to-type.c) that's the closest approximation. > > What does this program do? Does it iterate through all possible keycodes and > lookup the keysym for them? please look at the source, it's not a huge program. > > > > Main reason is that the keycode->keysym conversion is one-way only and it's > > not 100% reliable to go back. e.g. if a modifier is locked/latched you > > cannot > > access certain keysyms without unlocking that modifier, etc. > > How would I deal with capital letters with regards to getting a keycode from > a keysym? there's no such thing as a capital letter with keycodes, keycodes are really just "this physical key has been pressed". so capital letters usually resolve to a sequence - shift down, keycode, shift up. That is where the difficult bits start. > > > KEY_TAB is defined in linux/input-event-codes.h. XKB uses those keycodes + 8 > > for the evdev ruleset (see /usr/share/X11/xkb/keycodes/evdev for the > > mapping) > > and it goes from there. If you're using a different ruleset you're going to > > get interesting results but evdev is effectively hardcoded everywhere > > anyway, > > so you won't. > > Is linux/input-event-codes.h keycodes or keysyms? keycodes, but they have semantic naming for easier association. Cheers, Peter
Re: xkbcommon: Converting keysym to keycode
On Wed, Dec 01, 2021 at 02:31:38PM +, adlo wrote: > Does xkbcommon have a function to convert a keysym to a keycode? it doesn't, but if you look at xkbcli how-to-type and it's source (tools/how-to-type.c) that's the closest approximation. Main reason is that the keycode->keysym conversion is one-way only and it's not 100% reliable to go back. e.g. if a modifier is locked/latched you cannot access certain keysyms without unlocking that modifier, etc. > Also, what keycodes does Weston use? It seems that in libweston, KEY_TAB is > assigned the number 15. Is this a real keycode? Is this a standard keycode? > Is it used in xkbcommon or anything like that? KEY_TAB is defined in linux/input-event-codes.h. XKB uses those keycodes + 8 for the evdev ruleset (see /usr/share/X11/xkb/keycodes/evdev for the mapping) and it goes from there. If you're using a different ruleset you're going to get interesting results but evdev is effectively hardcoded everywhere anyway, so you won't. And note, it's a keycode with a semantic naming after the US layout. Those names are just easier to identify than XKB's naming scheme, e.g. KEY_C is a lot easier to understand than AB03 (alphabetic keys, second row from botton, third from left). This goes doubly for high keycodes, KEY_MICMUTE is a lot easier to associate than I256 (Internet key 256) [1] It's effectively standard everywhere in Wayland, including things like BTN_LEFT instead of numerical buttons. Cheers, Peter [1] because the internet was totally the future when that naming scheme was invented.
[ANNOUNCE] libinput 1.19.2
libinput 1.19.2 is now available. The usual set of device-specific quirks and one behavioural change: if the configured scroll button is button 6 or higher, we no longer use a delay before scrolling triggers. A-w-x (1): quirks: add quirk for GPD Win Max Eduardo de Souza Cruz (2): evdev: disable button scroll timeout for extra mouse buttons evdev: avoid usage of bogus BTN_FORWARD name José Expósito (1): gestures: avoid processing the last hold and motion event twice Peter Hutterer (2): test: use a plain libinput context for the log priority check libinput 1.19.2 Sean Rhodes (2): quirks: Add quirk for StarLabs clickpads with two phyisical buttons quirks: Update dmi for StarBook Mk V Travis Wrightsman (1): quirks: relax DMI modalias match for Purism Librem 14v1 git tag: 1.19.2 https://www.freedesktop.org/software/libinput/libinput-1.19.2.tar.xz SHA256: 0fc39f0af3ee1a77c60c34bc45391a4d0879169f7c0f7bbbeb5eef590b98b883 libinput-1.19.2.tar.xz SHA512: fc5244dc90ceb710f7b5bb76a3cafc7dd5a8d5fa05c51122412615bfc3a99435d6a1017b79c3ce73561139fc2f5959acaf16cb9500796ea2f3eb6cb95d1a1acb libinput-1.19.2.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.19.2.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] libinput 1.19.1
libinput 1.19.1 is now available. A new feature is detecting (and working around) buggy devices that claim to have a high-resolution scroll wheel but don't actually send events. This shouldn't happen too often with real hardware but will be quite common with uinput devices. We now assume any non-bluetooth touchpad is internal. Previously USB touchpads were sometimes internal, sometimes external - we now default to internal except for a few well-known external ones. This should make DWT work a bit better on affected devices. Finally, the jumping cursor warning has been reduced once again. In the vast majority of cases this isn't something the user can do anything about, and the libinput papering over the jump is correct behaviour. That means we don't need to annoy the user with frequent warnings. José Expósito (5): doc: guarantee end sequence for continuous scroll evdev: v120 scroll: invert horizontal scrolling quirk libinput: add hold to get base event test: add kernel bugs to log handler fallback: hires scroll heuristics for buggy devices Peter Hutterer (7): touchpad: fix leak when the touchpad is removed before the dwt keyboard touchpad: reduce the jumping cursor warnings to 5 per day touchpad: use the model flags to determine internal vs external touchpad: mark USB touchpads as internal by default quirks: add quirk for the Prestigio Smartbook 141 C2 touchpad quirks: update the Dell N5110 touchpad quirk libinput 1.19.1 git tag: 1.19.1 https://www.freedesktop.org/software/libinput/libinput-1.19.1.tar.xz SHA256: 0bdcf5b1783b737854b7af1ca22df67bc36a6fe7c9cfa71f01e9149f9220446d libinput-1.19.1.tar.xz SHA512: 63084f5e081ee4918fee8584d99e6feb84ce9b771015c556c930843e0097abb9b93b6f9731c488b8493eac18fa4086f4822a2ed00f3cb3258346341ad0061c36 libinput-1.19.1.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.19.1.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] libinput 1.19.0
libinput 1.19.0 is now available. Only three device-specific quirks since the RC so let's call this release done, push it out and the world becomes a slightly better, or at least different, place. Since there's nothing too noteworthy, here's the text from the RC explaining the new features. This release brings two new features and the corresponding API additions: hold gestures and high-resolution wheel scrolling (which changes the scroll APIs). Hold gestures are a new type of gestures that are triggered by holding one or more fingers on a touchpad without significant movement. They add to the existing pinch and swipe gestures and allow for the implementation of hold-to-click. Where callers implement kinetic scrolling, hold gestures can be used to stop scrolling - since the gesture is triggered on a finger(s) down after a scroll motion, that event can be used to stop scrolling. Many thanks to José Expósito for the new gestures. High-resolution wheel scrolling has been long in the making and the solution ends up replacing the existing pointer axis API. Three new events are available: LIBINPUT_EVENT_POINTER_SCROLL_WHEEL, LIBINPUT_EVENT_POINTER_SCROLL_FINGER, and LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS. These events **replace** the existing LIBINPUT_EVENT_POINTER_AXIS events, i.e. if you are processing the new events simply discard the old events. The FINGER and CONTINUOUS events are very similar to the previous event, the WHEEL event supporst a new API: libinput_event_pointer_get_scroll_value_v120(). That function returns the value of a scroll movement in multiples or fractions of 120. For example, a high-resolution scroll event that triggers 4 events instead of just 1 per 15 degree rotation will generate 4 events with a value of 30 each. Many thanks to José Expósito for taking those patches and pushing them over the line so they could be merged. The documentation has been updated for the new APIs, please see https://wayland.freedesktop.org/libinput/doc/latest/. The rest of the changes is the usual mix of janitorial patches and device-specific quirks. As usual, the git shortlog is below. Clayton Craft (1): quirks: Pine64 PineBook Pro keyboard José Expósito (4): doc: add missing literal blocks in contributing quirks: Microsoft Surface Pro 3 Cover util: add a function to parse bool properties quirks: no button debouncing on generic emulated mouse Peter Hutterer (1): libinput 1.19.0 weizhixiang (1): use ARRAY_FOR_EACH when traverse array git tag: 1.19.0 https://www.freedesktop.org/software/libinput/libinput-1.19.0.tar.xz SHA256: 3d3a2f12b4a65cd82684121ae4b33cdc3ad541c761a55e8eb73a8e5e443cccbb libinput-1.19.0.tar.xz SHA512: daf42ce797f2b5aef8d6f7a5c0d967590581e6ac12c26fa6bde5fbc619d75319e39ca55d65d5347e554dd6a48b91f5fed4d3167eabef8ad1ebc43bc0c3e8e220 libinput-1.19.0.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.19.0.tar.xz.sig
[ANNOUNCE] libinput 1.18.901
libinput 1.18rc1 is now available. This release brings two new features and the correspoding API additions: hold gestures and high-resolution wheel scrolling (which changes the scroll APIs). Hold gestures are a new type of gestures that are triggered by holding one or more fingers on a touchpad without significant movement. They add to the existing pinch and swipe gestures and allow for the implementation of hold-to-click. Where callers implement kinetic scrolling, hold gestures can be used to stop scrolling - since the gesture is triggered on a finger(s) down after a scroll motion, that event can be used to stop scrolling. Many thanks to José Expósito for the new gestures. High-resolution wheel scrolling has been long in the making and the solution ends up replacing the existing pointer axis API. Three new events are available: LIBINPUT_EVENT_POINTER_SCROLL_WHEEL, LIBINPUT_EVENT_POINTER_SCROLL_FINGER, and LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS. These events **replace** the existing LIBINPUT_EVENT_POINTER_AXIS events, i.e. if you are processing the new events simply discard the old events. The FINGER and CONTINUOUS events are very similar to the previous event, the WHEEL event supporst a new API: libinput_event_pointer_get_scroll_value_v120(). That function returns the value of a scroll movement in multiples or fractions of 120. For example, a high-resolution scroll event that triggers 4 events instead of just 1 per 15 degree rotation will generate 4 events with a value of 30 each. Many thanks to José Expósito for taking those patches and pushing them over the line so they could be merged. The documentation has been updated for the new APIs, please see https://wayland.freedesktop.org/libinput/doc/latest/. The rest of the changes is the usual mix of janitorial patches and device-specific quirks. As usual, the git shortlog is below. Andrea Ippolito (1): doc/user: make "verifying install" command portable Dmitry Maluka (1): quirks: Thinkpad T470 trackpoint multiplier José Expósito (29): gestures: add a function to know if there is pending pointer motion gestures: refactor gesture enabled gestures: handle pointer motion as an extra state gestures: use events to change between states gestures: filter motion inside the gesture state machine libinput: add hold gesture public API and tool support gesutures: allow to configure hold gestures gestures: add hold gesture implementation tests: move existing gesture tests to functions to be able to reuse them tests: optionally hold in gesture test functions tests: add hold gesture tests gestures: add quick hold implementation doc: add touchpad gestures state machine diagram doc: update draw.io URL gestures: always save touch information gestures: move first_moved and first_mm up gestures: improve one finger hold detection doc: add common failed pipeline errors tools/debug-gui: move gtk_main_quit to a function tools/debug-gui: use GMainLoop instead of gtk_main tools/debug-gui: refactor UI element placement debug-gui: migrate to GTK4 debug-gui: pointer locking on Wayland debug-gui: pointer locking on X11 ci: update to GTK 4 when available meson.build: use the / operator instead of join_paths editorconfig: add settings for meson files quirks: Lenovo Trackpoint Keyboard II test: refactor litest_assert_event_type logic Kevin Anderson (1): quirks: add Framework Touchpad Quirk Mohamed Elsharnouby (1): quirks: add pressure range for Dell Latitude 7480 Peter Hutterer (27): doc: note that gestures may be cancelled doc: add docs for hold gestures meson.build: bump to 1.18.900 gitlab CI: add a comment to explain how to actually edit the CI quirks: add a quirk for the Huawei Matebook 2020 touchpad quirks: add a quirk for the X61 bezel buttons util-list: restore list_for_each_safe() to be a single statement Replace fallthrough comments with __attribute__((fallthrough)) Silence compiler warnings for -Wformat-nonliteral Disable -Wmissing-field-initializers Mark some functions as printf-like to silence some compiler warnings touchpad: remove two unused functions doc/user: fix the line alignments for the hold gesture tables doc/user: move the hold gesture section up to the others gitlab CI: name the qemu tags per distribution gitlab CI: split the qemu meson build parts out as separate template gitlab CI: update to latest ci-templates gitlab CI: move the SUITES handling to the template where it matters gitlab CI: use the ci-templates FreeBSD templates Define the versionsort overrides as inlines gitlab CI: debug the meson_build script gitlab CI: drop dependencies between jobs meson.build: disable documentation by default
[ANNOUNCE] libinput 1.18.1
libinput 1.18.1 is now available. This release only adds device-specific quirks, no other changes to the library. Kevin Anderson (1): quirks: add Framework Touchpad Quirk Mohamed Elsharnouby (1): quirks: add pressure range for Dell Latitude 7480 Peter Hutterer (3): quirks: add a quirk for the Huawei Matebook 2020 touchpad quirks: add a quirk for the X61 bezel buttons libinput 1.18.1 Quytelda Kahja (2): quirks: Add tablet smoothing attribute. Add section for Lenovo Yoga C930 tablet in 50-system-lenovo.quirks. Sanjiv (1): Update quirks/50-system-chuwi.quirks The_Observer (1): quirks: add a quirk for the Purism Librem 14v1 Thomas Stenhouse-Pyne (1): quirks: add volume rocker quirk for Lenovo Duet 7i satrmb (1): quirks: Chuwi AeroBook Plus has a clickpad falsely claiming to have BTN_RIGHT git tag: 1.18.1 https://www.freedesktop.org/software/libinput/libinput-1.18.1.tar.xz SHA256: 9ca14021fbc2523bc0610582c51f368321592040b6ca63becc2fa1ea11f1a7cb libinput-1.18.1.tar.xz SHA512: 450e38c0f8245aa0165a8047d25aebee646332f0f2ed442bb2d1bd3e723c2082b6d00d6e3bda308981ece8e29b5cddbd56eab900d2b7497705a45fc27b281828 libinput-1.18.1.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.18.1.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] libinput 1.18.0
libinput 1.18.0 is now available. Only one device-specific quirk since the RC1 so here's the usual copy/paste from the RC announcement with the changes since 1.17.0: No big new features, just general fixes and polishing everywhere. This is mostly just flushing the main branch out. Some of the user-visibile changes are: - Gestures' unaccelerated motion now matches the accelerated motion (without accel, obviously). A bug caused these to be in different scales which didn't work overly well for obvious reasons. - Better gesture detection should reduce the amount of pinch gestures detected as two-finger scrolling. - Pressing the wheel button down now suppresses accidental scroll wheel events. - Reworked clickpad detection means we should be more robust for devices with broken firmware. As usual, please see the git shortlog for details. Neev Parikh (1): Update 50-system-asus.quirks to include Asus G15 Zephyrus quirk. Peter Hutterer (1): libinput 1.18.0 git tag: 1.18.0 https://www.freedesktop.org/software/libinput/libinput-1.18.0.tar.xz SHA256: 18c6a286583268d39841348e561fbb4713bde0c643b360f5d8a3f27800afdb9a libinput-1.18.0.tar.xz SHA512: 9a834f075d7a1f892416bb6b241eb052f749d3aa883c4b39c0f1c9616c115d6b9a541b587508646fddaf0d3fe57af92fe4629b522d1d51196499e7b523e0aa90 libinput-1.18.0.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.18.0.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.17.901
libinput 1.18 RC1 is now available. No big new features, just general fixes and polishing everywhere. This is mostly just flushing the main branch out. I don't expect the need for a second RC. Some of the user-visibile changes are: - Gestures' unaccelerated motion now matches the accelerated motion (without accel, obviously). A bug caused these to be in different scales which didn't work overly well for obvious reasons. - Better gesture detection should reduce the amount of pinch gestures detected as two-finger scrolling. - Pressing the wheel button down now suppresses accidental scroll wheel events. - Reworked clickpad detection means we should be more robust for devices with broken firmware. As usual, please see the git shortlog for details. Alexander Mikhaylenko (1): gestures: Filter unaccelerated deltas for gestures Ben Weston (1): quirk: fix sensitivity for Dell Latitude 7490 pointing-stick Chris Dickson (1): quirks: mark the 0x252 razer keyboard as internal Greg V (4): quirks: recognize SPI bus quirks: add quirks for Apple SPI input devices quirks: implement DMI support on FreeBSD quirks: add wildcard to HID-over-I2C names (for FreeBSD) Hans Gaiser (1): Add quirk for Lenovo Legion 5 Pro. Jonas Ådahl (1): tablet-pad-leds: Open led file with O_NONBLOCK | O_CLOEXEC JoseExposito (9): fallback: replace fallback_dispatch->wheel with an anonymous struct fallback: disable mouse scroll wheel while middle button is pressed tools/code-formatting: Add EditorConfig file touchpad/clickfinger: limit middle click to 3 fingers libinput: change gesture notify cancel parameter from int to bool gestures: rename int filter_motion to bool ignore_motion gestures: move the code to get raw pointer motion to its own function gestures: move up some functions to use them later gestures: move the logic to detect gestures to its own function José Expósito (1): test: cleanup: remove fallthrough followed by break Konstantin Kharlamov (2): util-list.h: simplify code by removing an excess initialization treewide: get rid of `tmp` argument in list_for_each_safe Nicolas Fella (1): doc/user: Add instructions for using with CMake Pedro Ribeiro (1): Add Lenovo Legion 5 keyboard to 50-system-lenovo.quirks Peter Hutterer (55): completion: add missing libinput analyze subtools to the zsh completions tools/per-slot-delta: print the button state too while analyzing tools/per-slot-delta: handle KeyboardInterrupts nicely util: document our list interface tools/debug-gui: start the unaccelerated motion deltas in the screen center tools/debug-gui: move the pointer position into a struct point tools/debug-gui: move the abs pointer position into a struct point tools/debug-gui: draw a sprite for the unaccelerated pointer as well test: fix two inadvertent pointer jumps in a test test: add a comment to the thumb speed test touchpad: always push a touch's current point to the motion history test: localize a few variables test: update a few tests for more modern helpers filter: correct comments about the threshold's unit doc/user: explain why we are doing motion normalization test: fix debugging messages for gesture begin event test: simplify the helper for moving three touches at the same time test: push/pop event frames around three-touch movements tests: add a gesture test to ensure our unaccel deltas are in a sane range tools/record: factor out the output file collection tools/record: de-duplicate an error message tools/record: localize a variable tools/record: free the namelist when we're done tools/record: deduplicate the device opening logic tools/record: switch the output file from an fd to a FILE* tools/record: mark the iprintf function as printf tools/record: get rid of indent push/pop, replace with fixed indents tools/record: append the devices in-order tools/record: remember the first device in the context tools/record: rename the output file handling tools/record: rework the event printing tools/record: line up the "neutral state" message evdev: don't check the event time if it's higher than the dispatch time evdev: don't truncate event time to 32 bits quirks: add palm size quirk for the Gigabyte Aero 15 touchpad: factor out clickpad assignment to a helper touchpad: use some helper variables to make the code easier to read touchpad: a touchpad with only one button is a clickpad touchpad: if we have a right button, let's assume it's not a clickpad gitlab CI: switch to Ubuntu 21.04 doc/user: fix a link to the system hwdb file Change various references to the master branch to main tools/record: fix a strlen assumptio
[ANNOUNCE] libinput 1.17.3
libinput 1.17.3 is now available. The device specific quirks listed below add the necesssary keyboard integration quirk to get palm rejection to work correctly. Hans Gaiser (1): Add quirk for Lenovo Legion 5 Pro. Peter Hutterer (2): gitlab CI: bump from Fedora 32 to 34 libinput 1.17.3 dan g (1): quirks: add palm rejection support for all Razer Blade models git tag: 1.17.3 https://www.freedesktop.org/software/libinput/libinput-1.17.3.tar.xz SHA256: 0d010e0bf601b5d3a06b3c4d77d67751cf554f3e6448e57aa046ea9ee8f818ac libinput-1.17.3.tar.xz SHA512: 3d1ab4362ede886996795d700a938d20e04cd922e8f9598fe9346f9f93e149119526fb324a096787b4b8a47bf3e5613130bcd874f10df86761031710d2acc792 libinput-1.17.3.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.17.3.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Dell Totem support / libinput bug: Event for missing capability CAP_POINTER on device "Advanced Silicon S.A. CoolTouch® System System Multi Axis"
On Mon, May 17, 2021 at 11:00:15AM +0200, Max Maischein wrote: > Hi Peter, > > best to file an issue against libinput, debugging over email is pretty > > terrible. > > Filed as https://gitlab.freedesktop.org/libinput/libinput/-/issues/614 thanks, I already replied there but for the list archives: you are on libinput 1.12, totem support was added in 1.14 which is as good a reason as any why it doesn't quite work perfectly ;) Cheers, Peter > > >> Is there anything more I can do to help? I'd really like to use the > >> totem as a secondary mouse/tool, but so far, it "only" gets detected as > >> a primary mouse (without configuration or anything, so that's really > >> great already). > > > > fwiw, if the device is indeed detected as totem, then you can't do... > > anything. The totem is a tablet tool and exposed as such - without > > client-side support to map that tool into something else you cannot use it > > for anything (that would require compositor, wayland and toolkit support). > > And the amount of effort required to add bimanual interaction to > > applications is, let's just say "nontrivial" :) > > > > This is mostly as a toy, so I'll play around with writing my own client, > but if there is anything I can do to test etc., just tell me - I'm happy > to do (bi-)manual testing :) > > -max ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Dell Totem support / libinput bug: Event for missing capability CAP_POINTER on device "Advanced Silicon S.A. CoolTouch® System System Multi Axis"
On Mon, May 10, 2021 at 09:05:55AM +0200, Max Maischein wrote: > Hi all, > > I got a Dell Canvas+Totem widget (on clearance, they are discontinued), > and got the following error message when running `libinput debug-events`: > > libinput bug: Event for missing capability CAP_POINTER on device > "Advanced Silicon S.A. CoolTouch® System System Multi Axis" > > The recorded sequence is "drop the totem on the screen, click it (this > is where the error shows up), lift it again", recorded using > > libinput record /dev/input/event9 -o dell-totem-drop-click-lift-20210510.yml > > Is there anything more I can do to help? I'd really like to use the > totem as a secondary mouse/tool, but so far, it "only" gets detected as > a primary mouse (without configuration or anything, so that's really > great already). best to file an issue against libinput, debugging over email is pretty terrible. > Is there anything more I can do to help? I'd really like to use the > totem as a secondary mouse/tool, but so far, it "only" gets detected as > a primary mouse (without configuration or anything, so that's really > great already). fwiw, if the device is indeed detected as totem, then you can't do... anything. The totem is a tablet tool and exposed as such - without client-side support to map that tool into something else you cannot use it for anything (that would require compositor, wayland and toolkit support). And the amount of effort required to add bimanual interaction to applications is, let's just say "nontrivial" :) That's the main reason totem support never got past the libinput API, the number of people using them is so close to zero that it just wasn't worth the effort. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Help writing a virtual touchpad
On Tue, May 11, 2021 at 10:15:39AM +0200, Andrea Somaini wrote: > Thanks a lot for your detailed response, that blog post was amazing and it > made some things much more clearer. > > At the end, I managed to write a kernel driver that receives input through > a character device and sends raw input events, without ever knowing the > existence of evdev. It still need a lot of tweaking regarding resolution > and which events I should send and which not. (e.g. should I communicate > the pressure if my data does not contain information about it? What about > tool_width/major-axis and such?) The only thing pressure is used for atm is for palm and thumb detection. Given you're writing a virtual touchpad, you shouldn't need either. Same for major/minor. Tool width is unused in libinput so I wouldn't bother with it either. > Anyway, with some trial and error the driver kinda works and I got to see > 1:1 multitouch gesture on GNOME 40 :) > > Regarding performance: I use a userspace process to write to a character > device which talks to my kernelspace code, maybe using evdev directly > avoids some layers of abstraction? And in this way I don’t have to write > any kernelspace code right? correct, uinput is a module supported everywhere and would not require a custom kernel module. Using it removes one moving part, you only need the userspace process because everything else is already there (and well-tested :) Cheers, Peter > > Repo with my code: https://github.com/thegoldgoat/toccami_driver > > Thank you so much, > Andrea > Il 11 mag 2021, 03:09 +0200, Peter Hutterer , ha > scritto: > > On Sat, May 08, 2021 at 12:45:24PM +0200, Andrea Somaini wrote: > > > Hello, > > > I was thinking about creating a virtual touchpad device for Linux > > > I never worked on such low level software, so I feel kinda lost > > > Can someone please point me where should I start? > > > > The best option you have at this point is to emulate an evdev node that > > behaves like a touchpad. That's both straightforward and complicated at the > > same time. The code itself is trivial (use python-libevdev, check the > > examples directory) but getting touchpads right in evdev can be a bit > > tricky - you really need to know the details of the evdev protocol. > > > > If you look at the libinput test devices (e.g. > > test/litest-device-synaptics-rmi4.c) you get a **rough** idea of the events > > you need to send for a finger down event and a finger move event. > > You still need to handle BTN_TOOL_DOUBLETAP, etc. > > What I recommend is: use libinput record to record 1, 2, 3... finger > > interactions on your normal touchpad to get the set of data sent, then > > emulate that device. Axis ranges and coordinates can generally be changed > > at-will, but the set of events within each frame has to be correct (or > > correct enough) to be processed as expected. > > > > https://who-t.blogspot.com/2016/09/understanding-evdev.html has some > > explanations too. > > > > Cheers, > > Peter > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Help writing a virtual touchpad
On Sat, May 08, 2021 at 12:45:24PM +0200, Andrea Somaini wrote: > Hello, > I was thinking about creating a virtual touchpad device for Linux > I never worked on such low level software, so I feel kinda lost > Can someone please point me where should I start? The best option you have at this point is to emulate an evdev node that behaves like a touchpad. That's both straightforward and complicated at the same time. The code itself is trivial (use python-libevdev, check the examples directory) but getting touchpads right in evdev can be a bit tricky - you really need to know the details of the evdev protocol. If you look at the libinput test devices (e.g. test/litest-device-synaptics-rmi4.c) you get a **rough** idea of the events you need to send for a finger down event and a finger move event. You still need to handle BTN_TOOL_DOUBLETAP, etc. What I recommend is: use libinput record to record 1, 2, 3... finger interactions on your normal touchpad to get the set of data sent, then emulate that device. Axis ranges and coordinates can generally be changed at-will, but the set of events within each frame has to be correct (or correct enough) to be processed as expected. https://who-t.blogspot.com/2016/09/understanding-evdev.html has some explanations too. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.17.2
libinput 1.17.2 is now available. This release fixes an overeager "system is too slow" log message and adds a few more quirks for specific devices. Ben Weston (1): quirk: fix sensitivity for Dell Latitude 7490 pointing-stick Chris Dickson (1): quirks: mark the 0x252 razer keyboard as internal Jonas Ådahl (1): tablet-pad-leds: Open led file with O_NONBLOCK | O_CLOEXEC Peter Hutterer (4): evdev: don't check the event time if it's higher than the dispatch time evdev: don't truncate event time to 32 bits quirks: add palm size quirk for the Gigabyte Aero 15 libinput 1.17.2 Udo Rader (1): quirks: add quirk for Lenovo Yoga Slim 9 Touchpad git tag: 1.17.2 https://www.freedesktop.org/software/libinput/libinput-1.17.2.tar.xz SHA256: b822263086b6588b9a9a153be97dea409f63927fb67b9a241748e76f222a5be1 libinput-1.17.2.tar.xz SHA512: b8953ad483648d5629d56c4dc226d4906693b15da5ba4027627a51ec35ea65b0603c09056b52ed2025df1f7a877669a5b7482c025e0b37003fc676563bd05263 libinput-1.17.2.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.17.2.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
libinput default git branch changed to 'main'
Following the Wayland repository changes, libinput has now changed to use "main" as the default branch. All open merge requests have been changed over. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.17.1
libinput 1.17.1 is now available. Several device-specific quirks and a fix to the zsh completion files. Nothing exciting, nothing risky. Greg V (4): quirks: recognize SPI bus quirks: add quirks for Apple SPI input devices quirks: implement DMI support on FreeBSD quirks: add wildcard to HID-over-I2C names (for FreeBSD) Pedro Ribeiro (1): Add Lenovo Legion 5 keyboard to 50-system-lenovo.quirks Peter Hutterer (3): completion: add missing libinput analyze subtools to the zsh completions doc/user: explain why we are doing motion normalization libinput 1.17.1 git tag: 1.17.1 https://www.freedesktop.org/software/libinput/libinput-1.17.1.tar.xz SHA256: e51c50f3ce253961bed452d9f93102cc26128406975ab88ff9ec9e6c3b875137 libinput-1.17.1.tar.xz SHA512: 2e7baa198fed9c673d28453efb066f9371f2b575a844e41cde455c636bbe1cc68faae7129026944a502cd5d7bfcc72272066b9e3cda5c959f7b464483f9dd860 libinput-1.17.1.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.17.1.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.16.5
libinput 1.16.5 is now available. This will be the last 1.16.x release now that 1.17.0 is out. The usual collection of device-specific quirks to (primarily) adjust pressure threshods on various touchpads. Please see the git shortlog for details. Blaž Hrastnik (1): Match all Surface (Pro/Laptop/Book) devices. Gablegritule (1): quirks: add pressure ranges for the Dell Latitude E5510 TouchPad Gary Wolfe (1): Dell touchpad was too sensitive with default settings Jef Driesen (1): quirks: add quirk for Dell XPS 15 9500 touchpad Peter Hutterer (3): quirks: disable pressure on the Lenovo Yoga 9i touchpad gitlab CI: run the scan-build analysis jobs in script libinput 1.16.5 git tag: 1.16.5 https://www.freedesktop.org/software/libinput/libinput-1.16.5.tar.xz SHA256: 42d404af037a0dcc9dee7a1ab0a8e53cec0b62902fc4a262e5be9d2b7452c214 libinput-1.16.5.tar.xz SHA512: b2fdd87375cbd5b212f76cefedfaa146966dde1d5e5d566beadd3167749dc3667214946178b157fa4b44360dc6b86a25ffb0356049cdf5a57d0fa2b8e3fcb1e9 libinput-1.16.5.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.16.5.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.16.902
libinput 1.17rc2 is now available. One (anticipated) change to the new tapping code: 2/3 finger tap-and-drag requires that the actual drag operation is done with one finger only. So in the default config, a 2 finger tap followed by a 1 finger drag produces a right-click drag. The documentation now has the set of distribution-specific build dependencies, see https://wayland.freedesktop.org/libinput/doc/latest/building.html This has been requested many times but now that it's generated from our CI config we can do without having to worry about it going stale. Other than that, not a lot of changes that stick out, the usual pre-release doc fixes, test suite cleanups/fixes, and device-specific quirks. I expect this to be the last RC before the 1.17 release. As usual, see the git shortlog for details. Gablegritule (1): quirks: add pressure ranges for the Dell Latitude E5510 TouchPad Peter Hutterer (28): quirks: improve the README doc/user: some whitespace fixes doc/user: expand the explanations on how to submit a merge request quirks: reword the requirements section in the quirks README test: don't require root to list tests touchpad: disable the pressure axes wherever the resolution is nonzero Create /etc/libinput on install gitlab CI: rename the VM stage "test-suite" test: don't set the log handler 10 times tests: drop the duplicate test for pointer event conversion tools/record: add some curly braces test: init an array to zero to silence scan-build tools/record: remove a useless assignment gitlab CI: run the scan-build analysis jobs in script test: move a helper function close to its caller test: wrap the litest user data into a struct test: use motion events to check the "system is too slow" message gitlab CI: make the test suite names a list utils: add a trunkname() function to extract the trunk of a filename test: drop the custom group names gitlab CI: add a job to make sure we're running all test suites doc/user: generate the required package list for the CI distributions gitlab CI: move the no-libwacom test suite into its own stage doc: update the docs with a note regarding multifinger dragging test: print the event type on mismatch test: drop the needless base event conversion test: add test cases for 2/3 finger movement after tap libinput 1.16.902 satrmb (3): touchpad: stretch the tap-and-drag timeout a bit depending on finger count touchpad: permit only one finger on the touchpad at the start of a tap-drag test: fix a few missing or wrong drag-lock timeouts наб (2): totem: fix suspension-as-addition and resumption-as-removal in interface totem: separate X/Y resolution from touch size in discriminator git tag: 1.16.902 https://www.freedesktop.org/software/libinput/libinput-1.16.902.tar.xz SHA256: 16931b5425180a9b9730bbe97d52a4823cd6682a8718f9745642c3e0cce79563 libinput-1.16.902.tar.xz SHA512: 2610b49a4d7ef796e0947f344a462e52a49f72c22b4088a43c3e9ad9810ea3ebd0f329da90b804f2d3f635b488eac73fcfd16fa8a3383de77ffb7b3ae3716771 libinput-1.16.902.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.16.902.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.16.901
libinput 1.17rc1 is now available. This has been a long release cycle, primarily because ETIME on my side. Still, quite a few patches have accumulated, most of the quirks and hw-specific ones have found their way into the 1.16 branch already. The big new feature is tap-and-drag with two and three fingers. Previously, tap-and-drag could only be used to left-click and drag, it is now possible to right/middle-click and drag using two or three fingers. Wacom's AES tablets no longer have smoothing enabled, it looks like those devices don't need it. This should make the tablets more responsive and accurate. The quirks system has a few new attributes that make it easier to quirk broken devices without recompiling. As you've seen on the 1.16.x releases, the "your system is too slow" is now ratelimited to merely 5 an hour. There's nothing a user can usually do about this anyway, so not spamming the logs seems a bit more user-friendly. A new debugging tool: libinput analyze touch-down-state This tool visualises the touch state over time (using a libinput record log as input), making it easier to debug stuck touches or hw issues where ghost touches are detected. Other than that, the fixes are all over the place and it's hard to narrow it down to useful groups. Please see the git shortlog below for details. Many thanks to all contributors! Alyssa Ross (1): quirks: add Google Pixelbook (eve) Blaž Hrastnik (1): Match all Surface (Pro/Laptop/Book) devices. Davide Depau (1): quirks: fix force-press on Apple Magic Trackpad 2 Gary Wolfe (1): Dell touchpad was too sensitive with default settings Jef Driesen (1): quirks: add quirk for Dell XPS 15 9500 touchpad Jonas Ådahl (1): doc: fix IRC channel name Kai-Chuan Hsieh (1): quirks: Customize ALPS i2c touchpad palm detect pressure threshold Peter Hutterer (85): gitlab CI: drop Fedora 30 tools: fix a replay exception when a recording has an empty quirks list doc: fix a wrongly named parameter touchpad: ignore the ALPS jump to 4095/0 meson.build: bump to 1.16.900 meson.build: drop a meson < 0.43 condition meson.build: we no longer install a hwdb file, so drop the directory define Drop the trailing slash from the HTTP_DOC_LINK meson.build: update libwacom dependency to 0.27 or newer doc/api: drop the doxygen/graphviz version checks meson.build: bump minimum version to 0.47 meson.build: drop the separate cpp flags quirks: fix a logical error checking for A..Z timer: fix a logic error checking the list node meson.build: add a few compiler warnings and make them compiler-conditional tools/replay: check the recorded udev properties against the local properties tools/record: add --grab option tools/record: prefix the device list with a # character tools/record: compress a set of printfs into one tablet: group the pressure related bit into a substruct test: remove duplicate tool type test: don't run the tool switch test on tablets that require forced prox out tablet: split a ternary condition into a normal if else for readability test: auto-assign the tool type for tablet tests test: move the x/y coords a bit when testing tool type switches test: set the elan test device to always double up on tool bits doc/api: fix the doxygen output handling tools: only call libinput_dispatch() once per poll tools: print the libinput_dispatch() counter for debugging messages tools: color-group the debugging messages gitlab CI: add git depth to the coverity job and save the artifacts fallback: expand the range of valid keys test: fix the tablet relative calibration test test: fix the tip one axis test Print the event name when using an invalid event type tools/debug-events: rework touch event printing evdev: quirks_get_tuples can deal with a NULL quirks evdev: localize two variables during quirks handling quirks: add AttrEventCodeEnable as counterpoint to the disable one quirks: add AttrInputPropEnable and Disable quirks: switch the models with missing buttonpad to use the new attr evdev: reduce the "your system is slow" warning to 5 per hour doc/user: update the timer offset warning for the new "too slow" message gitlab CI: trigger the wayland website pipeline directly gitlab CI: remove a now-unused VERSION variable gitlab CI: update to latest ci-templates gitlab CI: update the comments Fix the termination of the readlink result Fix a few coverity complaints tools: print the AttrEventCodeEnable and AttrInputPropEnable/Disable quirks gitlab CI: pass MESON_ARGS down to the wayland-web job gitlab CI: switch to the vmctl script gitlab CI: use a template for the various ci-fairy jobs gitl
[ANNOUNCE] libinput 1.16.4
libinput 1.16.4 is now available. This release provides updated udev rules for compatibility with systemd 247, see the systemd announcement for details https://lists.freedesktop.org/archives/systemd-devel/2020-November/045646.html If you are planning to update to systemd 247, you should update to this libinput version. Peter Hutterer (4): Fix the termination of the readlink result Fix a few coverity complaints udev: update rules to handle bind/unbind events libinput 1.16.4 git tag: 1.16.4 https://www.freedesktop.org/software/libinput/libinput-1.16.4.tar.xz SHA256: 65923a06d5a8970e4a999c4668797b9b689614b62b1d44432ab1c87b65e39e29 libinput-1.16.4.tar.xz SHA512: a95a3bcf58a9298946d15f4f2fd93dc5807d3042f8797950a1ffd96d3c979b55a764f035a9f7680d0ea400b033698c322eb61a4387dbc280db6110ffd3e137ee libinput-1.16.4.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.16.4.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.16.3
libinput 1.16.3 is now available. Only one real change, the "your system is slow" warning is rate-limited to 5 per hour now to avoid spamming the logs. Peter Hutterer (3): evdev: reduce the "your system is slow" warning to 5 per hour doc/user: update the timer offset warning for the new "too slow" message libinput 1.16.3 git tag: 1.16.3 https://www.freedesktop.org/software/libinput/libinput-1.16.3.tar.xz MD5: 562614e91c10c75ab1c2b71e5d27f076 libinput-1.16.3.tar.xz SHA1: ee1e93ee647bdd4598a5910eb654592563657d66 libinput-1.16.3.tar.xz SHA256: dc5e1ae51ec1cc635ca96f61118b0f07dfea783cab0747a60f3555068bb077e4 libinput-1.16.3.tar.xz SHA512: cdf87988b24dc0a44b7b6ed3e15e70c7702bf65f1cfe257924967677c7a1f1485011a9e30254ba8962c83885de78f824e7955cedb07322676332d42532ec4a39 libinput-1.16.3.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.16.3.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.16.2
libinput 1.16.2 is now available. A few device-specific fixes for the Google Pixelbook, Apple Magic Trackpad 2, some ALPS i2c touchpads and a jumping cursor fix for ALPS DoalPoint touchpads. Alyssa Ross (1): quirks: add Google Pixelbook (eve) Davide Depau (1): quirks: fix force-press on Apple Magic Trackpad 2 Kai-Chuan Hsieh (1): quirks: Customize ALPS i2c touchpad palm detect pressure threshold Peter Hutterer (5): gitlab CI: drop Fedora 30 tools: fix a replay exception when a recording has an empty quirks list touchpad: ignore the ALPS jump to 4095/0 fallback: expand the range of valid keys libinput 1.16.2 git tag: 1.16.2 https://www.freedesktop.org/software/libinput/libinput-1.16.2.tar.xz MD5: 7c0aca7bba3e8559a869ed15b2173b2e libinput-1.16.2.tar.xz SHA1: bff5e91ea0ea45509532aaa3e1a876d476e3e82e libinput-1.16.2.tar.xz SHA256: fc3d8c50fe7abc4dc4406bc01262a3f8149864557f87279adcf300e523c160a9 libinput-1.16.2.tar.xz SHA512: 3394faeb0cdb0a543624e150f04a98f3bce8d67438e47455808bde8eec8ea9cdafb86056e5f8d3431352ae33714e490c55edeb51e0af1972c68fca07c1ef1daa libinput-1.16.2.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.16.2.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.16.1
libinput 1.16.1 is now available. This release fixes a regression introduced in 1.16.0 where we fixed a bug that caused some joysticks to be added by libinput. Unfortunately, there are keyboards out there that claim to have seemingly random event codes, some of which cause those keyboards to be labelled as ID_INPUT_JOYSTICK by udev. Those keyboards stopped working with 1.16. Revert back to the old behaviour until we can figure out a better way to deal with this. See https://gitlab.freedesktop.org/libinput/libinput/-/issues/517 for that particular issue. Peter Hutterer (5): Revert "evdev: fix the check for tablet vs joystick" evdev: remove now-misleading comment include: update event codes to v5.8 test: add two test devices for the false joystick labelling libinput 1.16.1 haarp (1): Add original MX Master to inverted-horizontal-wheel-having mice. git tag: 1.16.1 https://www.freedesktop.org/software/libinput/libinput-1.16.1.tar.xz MD5: 51454993fcc576f4480aba8c1c3232ac libinput-1.16.1.tar.xz SHA1: 7f5df6d17e9a06b6a28ce9eea0a11cf8555b63dd libinput-1.16.1.tar.xz SHA256: 7ba7d1aeedd15168bb21d17e9e628aa1c27957963a423a3fea3938a501758539 libinput-1.16.1.tar.xz SHA512: 86b2d563c2cff2b3d3cae3acdd399030cc785cc9859a06357a99565ef51f95122a8427c8c0883121fb0760613460a29c8cd8c7a7e3ac68115c10330b3b75cbe0 libinput-1.16.1.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.16.1.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC: libei - emulated input in Wayland compositors
An update to the work that's been happening here. libei now has some xdg-desktop-portal support. It will ping the portal, get the fd back and then go on from there. For Xwayland switching to use the a portal is a one-line change, so a sandboxed X application now has XTEST requests go through the portal. The portal implementation is currently very simple and for initial negotiation only, once the fd has been exchanged, the portal has no further say in the matter. I suspect that's likely to change one way or another. Olivier has been working on the Xwayland support, after some initial testing we figured it's *not* possible to have libei support batch requests directly. This is required for xdotool which fires off all requests and exits immediately. Olivier has added event buffering so we can replay the events once the device negotiation is done. He's also added the bits so we can "identify" clients based on their X client name. There's a new part to manage Restrictions for EIS, libreis. The portal can use that on the fd to limit what the client will be able to do later. Right now the portal sets the client's name to the app-id (and that name cannot be changed by the client, this also applies to Xwayland). It's early stages otherwise, lock down of capabilities (e.g. deny keyboard caps) is mostly just sketched out, not tested. I've been filling in the libei/libeis pieces though a lot of it is still in the proof-of-concept stage. Do not run your nuclear fusion plant on this. Either way, I reckon the whole thing looks promising. Combination of branches for portal support is outlined here: https://gitlab.freedesktop.org/whot/libei/-/issues/1 Comes with free occasional crashes. Cheers, Peter On Fri, Jul 31, 2020 at 03:13:50PM +1000, Peter Hutterer wrote: > I've been working on a new approach for allowing emulated input devices in > Wayland. Or in short - how can we make xdotool and synergy work? And > eventually replace them. > > The proposal I have is a library for Emulated Input, in short libei. > https://gitlab.freedesktop.org/whot/libei/ > > libei has two parts, the client side (libei) for applications and > a server side (libeis) for the compositor. The two libraries communicate > with each other (how? doesn't matter, it's an implementation detail) to > negotiate input devices. > > The process is roughly: > - the libei client connects and says "I am org.freedesktop.SomeApplication > and I want a pointer and a keyboard device" > - the libeis server says "ok, you can have a pointer device and a keyboard > device" > - the libei client says 'move the pointer by 1/1', etc. and the server does > just that. or not, depending on context. > > There are more details, see the README in the repo and the libei.h and > libeis.h header files that describe the API. > > The sticking point here is: emulated input comes via a separate channel. > The server a) knows it's emulated input, b) knows who it is coming from and > c) has complete control over the input. > > a) is interesting because you can differ between the events internally. The > API right now is very similar to libinput's events so integrating it into a > compositor should be trivial. > > b) is somewhat handwavy if an application runs outside a sandbox - any > information will be unreliable. Flatpak gives you an app-id though and > with that we can (eventually) do things like storing the allow/deny > decisions of the user in the portal implementation. > > c) allows you to e.g. suspend the client when convenient or just ignore > certain sequences altogether. The two made-up examples are: suspend EI > during a password prompt, or allow EI from the software yubikey *only* > during a password prompt. > > Now, the next question is: how do they *start* talking to each other? > libei provides multiple backends for the initial connection negotiation. My > goal is to have this work with flatpak portals so an application running > within the sandbox can be restricted accordingly. Alternatives to this could > be public DBus interfaces, simple fd passing or (as is implemented right > now) a named unix socket. > > The aim is that a client can simply iterate through all of the options until > finds a connection. Once that's found, the actual code for emulating input is > always the same so it's trivial to implement a client that works on any > compositor that supports some backend of libeis. > The server part only needs to care about the negotiation mechanisms it > allows, i.e. GNOME will only have dbus/portal, sway will only have... dunno, > fd exchange maybe? > > Next: because we have a separate channel for emulated input we can hook up > XTEST to use libei to talk to a compositor. I have a PoC implementation for > weston and Xwayland: &g
[ANNOUNCE] libinput 1.16.0
libinput 1.16.0 is now available. No significant changes since the second RC, so here's slightly polished RC1 announcement text. This has been a long cycle, mostly because there weren't any huge changes on the main development branch and a lot of the minor annoyances have found their way into the 1.15.x releases anyway. libinput now monitors timestamps of the events vs the current time when libinput_dispatch() is called by the compositor. Where the difference *may* result in issues, a (rate-limited) warning is printed to the log. So you may see messages popping up in the form of "event processing lagging behind by XYZms, your system is too slow" This is a warning only and has no immediate effect. Previously we would only notice (and warn about) this when it affected an internal timer. Note that these warnings do not show an issue with libinput, it shows that the the compositor is not calling libinput_dispatch() quick enough. The wheel tilt axis source was deprecated. No device ever had the required udev properties set so we should stop pretending we support this. Touchpads now support the "flat" acceleration profile. The default remains unchanged and this needs to be selected in the configuration interface. The "flat" profile applies a constant factor to movement deltas (1.0 for the default speed setting). Events from lid or tablet-mode switches that are known to libinput as being unreliable are now filtered and no longer passed to the caller. This prevents callers from receiving those known-bogus events and having to replicate the same heuristics to identify unreliable devices that libinput employs internally. A new "libinput analyze" debugging tool is the entry tool for analysing various aspects of devices. Right now the only tool is "libinput analyze per-slot-delta" which can be used to detect pointer jumps in a libiput record output. This tool used to live elsewhere, it was moved to libinput so that reporters can easier run this tool, reducing the load on the maintainers. The tools have seen a few minor improvements, e.g. - "libinput record touchpad.yml" does the right thing, no explicit --output argument required - libinput measure touchpad-pressure has been revamped to be a bit more obvious - libinput measure touchpad-size has been added (as replacement for the touchpad-edge-detector tool) - libinput measure fuzz has been fixed to work (again and) slightly more reliable The libinput test suite has been fixed to avoid interference with the currently running session. Previously it was virtually impossible to work while the test suite is running - multiple windows would pop up, the screen would blank regularly, etc. And of course a collection of fixes, quirks and new bugs. As usual, see the git shortlog for details. Diego Abad A (1): FIX: typo on building documentation Peter Hutterer (2): test: semi-fix the switch_suspend_with_touchpad test libinput 1.16.0 git tag: 1.16.0 https://www.freedesktop.org/software/libinput/libinput-1.16.0.tar.xz MD5: b518dae7f603040872739216971ee97b libinput-1.16.0.tar.xz SHA1: e9216dcc3e3d87d37371335380d15d2dc333e157 libinput-1.16.0.tar.xz SHA256: 83f6d0c94e5e0dd87094ce73f0edb631919617d24a60ee0ab9bd9197411d76e8 libinput-1.16.0.tar.xz SHA512: 0c932a88f2a1d23ebef0d58c0cdbfb558e9e3d990fca15b21f5b9011bdd1bc2da81aad374fcdb8f4590f6ee2fc45e668e0583371ceb354437e585240e687aac6 libinput-1.16.0.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.16.0.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC: libei - emulated input in Wayland compositors
On Sat, Aug 01, 2020 at 01:42:16PM +0200, Roman Gilg wrote: > > > > 1) It exports a set of APIs under org.freedesktop.portal.* that all > > sandboxed applications can access. > > > > In contrast to explicitly allowed APIs (i.e. build time configured list > > of API to be exposed directly to inside an application sandbox by > > default), a portal APIs allows for applications to dynamically request > > access to privileged functionality, for example access to arbitrary > > file system locations, cameras, geo location, or screen casting. > > That's quite a long sentence. Let me dissect it a bit. What kind of > API are we talking about? The xdg-portal-desktop one? Who defines the > "build time configured list of API"? Are we talking about the "build" > of the Flatpak? Is it the Manifest's "finish-args" as described this > way in the Flatpak documentation? [1] sort-of, there's a confusion of terms. "API" stands primarily for a DBus API but you'll probably think of X11 and Wayland as sockets. for the purpose here you can consider them as APIs as well. When you build a flatpak application, you specify what that application can access outside the sandbox, that's your [1] link. by default, a sandboxed application does not have X11 or Wayland access. you can allow access to those or any API at build time, e.g. --talk-name=org.freedesktop.EI would allow the application to talk to a EIS server directly without the portal in between. These permissions are compiled in and listed by the flatpak itself - they're not dynamic like the portal. Problem with any build-time permissions is the portal has no control over it. This particularly shows the issue with sockets which are a complete side-channel. A DBus API will be called every time it's needed - that allows for a gatekeeper in between. A socket, once established, is largely outside the control of such a gatekeeper. XTEST for example floats along on the rest of X, you cannot allow an application to use X for display but disallow XTEST in a portal, support for this would have to be implemented in X itself. The same would be true for a Wayland virtual input protocol. EI is (will be) a combination of API + socket, similar to screencasting - negotiation is handled by the portal but once the connection is established the data is outside the portal's control. We could make the communication fully dbus-y so we can filter at any point but I don't think that would provide a lot of benefit. The socket approach here is acceptable because it's very *specific* for what it does. It only does emulated input, so giving permission to that implies you want that to happen. Giving permission for X (or Wayland) does not by default mean you want emulated input to happen through those protocols. > > 2) It provides, using backends, methods for implementing user > > interactive permission management. For arbitrary file system access, > > this may involve e.g. opening a file using a file selection dialog, or > > for screen casting this may mean actively choosing what part of your > > screen should be shared. > > Right, what the basic idea of the portals is, is pretty clear to me. > Basically it pipes requests of sandboxed apps through an > authentication and permission system in case they want to interact > with outside their sandbox. It's more about the cases where they > don't. A Wayland client in a sandbox interacts via Wayland protocol > with the outside of their sandbox, but that's not going through > xdg-portals, or is there a permission to block it from that? For flatpak at least, you need to explicity allow wayland access (--socket=wayland) at which point it's basically a wayland-sized hole in the sandbox. > > 3) It manages remembered access, using a common permission store[0]. For > > example if an application was permanently denied camera access, the > > portal will know about this and not query the portal backend. > > Yea, I quickly did an online search for a GUI to it and found [2] > which looks awesome. Also answers my question above: there exist > permissions to block a sandboxed app from Wayland or X11. But I assume > a user won't be asked for every new GUI app he installs if it is > allowed to show some pixels and instead the permission is by default > set to allowed. Looking back at it the GUI app should set this as a > permission in their Manifest file, which is like a default on install. It does indeed ask, or at least tell you: $ flatpak install --user org.gimp.GIMP Looking for matches… Found similar ref(s) for ‘org.gimp.GIMP’ in remote ‘flathub’ (user). Use this remote? [Y/n]: y org.gimp.GIMP permissions: ipc network x11 file access [1] dbus access [2] tags [3] [1] /tmp, host, xdg-config/GIMP, xdg-config/gtk-3.0, xdg-run/gvfs [2] org.freedesktop.FileManager1, org.gtk.vfs, org.gtk.vfs.* [3] stable ... Proceed with these changes to the user installation? [Y/n]: So the built-in permissions for gimp include x11 and
Re: RFC: libei - emulated input in Wayland compositors
On Fri, Jul 31, 2020 at 08:49:41PM +0200, Roman Gilg wrote: > On Fri, Jul 31, 2020 at 7:13 AM Peter Hutterer > wrote: > > > > I've been working on a new approach for allowing emulated input devices in > > Wayland. Or in short - how can we make xdotool and synergy work? And > > eventually replace them. > > > > The proposal I have is a library for Emulated Input, in short libei. > > https://gitlab.freedesktop.org/whot/libei/ > > We talked about it already yesterday but thanks again for this great > project. I decided to directly write some experimental integration > code based on your Weston branch for the server library in KWinFT [1] > in order to try this out as a solution for my Steam Controller issue > [2] that - I assume - motivated the creation of this library to some > extent. > > And yes, it works. :) I can move the cursor with the Steam controller > as in "Steam client -> XTEST -> patched Xwayland -> libei -> libeis -> > KWinFT" just fine. > > Am I right in assuming that the button-press event is not yet done in > libei or in the patched Xwayland version you linked? When it's > available let me know and I'll add the necessary logic for that too. I've implemented buttons and keys now but note it's an optimistic implemention. i.e. not a lot of error checking and failure handling. It'll be good enough for a PoC implementation though. As before, the two examples in tools/ show what's supported and I've updated the xwayland and weston branches too (xdotool type 'hello world' works now, imagine the possibilities!). Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC: libei - emulated input in Wayland compositors
On Fri, Jul 31, 2020 at 12:16:55PM +0300, Pekka Paalanen wrote: > On Fri, 31 Jul 2020 15:13:50 +1000 > Peter Hutterer wrote: > > > I've been working on a new approach for allowing emulated input devices in > > Wayland. Or in short - how can we make xdotool and synergy work? And > > eventually replace them. > > > > The proposal I have is a library for Emulated Input, in short libei. > > https://gitlab.freedesktop.org/whot/libei/ > > > > libei has two parts, the client side (libei) for applications and > > a server side (libeis) for the compositor. The two libraries communicate > > with each other (how? doesn't matter, it's an implementation detail) to > > negotiate input devices. > > > > The process is roughly: > > - the libei client connects and says "I am org.freedesktop.SomeApplication > > and I want a pointer and a keyboard device" > > - the libeis server says "ok, you can have a pointer device and a keyboard > > device" > > - the libei client says 'move the pointer by 1/1', etc. and the server does > > just that. or not, depending on context. > > > > There are more details, see the README in the repo and the libei.h and > > libeis.h header files that describe the API. > > > > The sticking point here is: emulated input comes via a separate channel. > > The server a) knows it's emulated input, b) knows who it is coming from and > > c) has complete control over the input. > > > > a) is interesting because you can differ between the events internally. The > > API right now is very similar to libinput's events so integrating it into a > > compositor should be trivial. > > > > b) is somewhat handwavy if an application runs outside a sandbox - any > > information will be unreliable. Flatpak gives you an app-id though and > > with that we can (eventually) do things like storing the allow/deny > > decisions of the user in the portal implementation. > > > > c) allows you to e.g. suspend the client when convenient or just ignore > > certain sequences altogether. The two made-up examples are: suspend EI > > during a password prompt, or allow EI from the software yubikey *only* > > during a password prompt. > > > > Now, the next question is: how do they *start* talking to each other? > > libei provides multiple backends for the initial connection negotiation. My > > goal is to have this work with flatpak portals so an application running > > within the sandbox can be restricted accordingly. Alternatives to this could > > be public DBus interfaces, simple fd passing or (as is implemented right > > now) a named unix socket. > > > > The aim is that a client can simply iterate through all of the options until > > finds a connection. Once that's found, the actual code for emulating input > > is > > always the same so it's trivial to implement a client that works on any > > compositor that supports some backend of libeis. > > The server part only needs to care about the negotiation mechanisms it > > allows, i.e. GNOME will only have dbus/portal, sway will only have... dunno, > > fd exchange maybe? > > > > Next: because we have a separate channel for emulated input we can hook up > > XTEST to use libei to talk to a compositor. I have a PoC implementation for > > weston and Xwayland: > > https://gitlab.freedesktop.org/whot/weston/-/commits/wip/eis > > https://gitlab.freedesktop.org/whot/xserver/-/commits/wip/xwayland-eis > > With that xdotool can move the pointer. Note this is truly the most minimal > > code just to illustrate the point but you can fill in the blanks and do > > things like the compositor preventing XTEST or not, etc. > > > > This is all in very early stages with very little error checking so things > > will probably crash or disconnect unexpectedly. I've tried to document the > > API to make the intentions clear but there are still some very handwavy > > bits. > > > > Do let me know if you have any questions or suggestions please though. > > Hi Peter, > > this seems like a very well thought out proposal. I like it. > Particularly the "how do you connect and get authorised" is a good > compromise since there is no one solution fitting all. Thanks! > When an ei client creates a new emulated input device, how should > Wayland compositors handle that wrt. wl_seats? Add it into the main > wl_seat? Create a new wl_seat for each ei client? Is there enough > information for a compositor to decide? I think you should treat them like a physical input device, except that you know they're e
Re: RFC: libei - emulated input in Wayland compositors
On Fri, Jul 31, 2020 at 11:00:53AM +0300, Vlad Zahorodnii wrote: > > c) allows you to e.g. suspend the client when convenient or just ignore > > certain sequences altogether. The two made-up examples are: suspend EI > > during a password prompt, or allow EI from the software yubikey *only* > > during a password prompt. > > We don't want any application be able to inject input events. How should > a program such as synergy authenticate itself? or is it completely up to > the compositor to decide what the authentication process looks like? yes...ish. there are two kinds of applications, the ones that run in a trusted sandbox (flatpak) and the ones that don't. For the ones outside the sandbox you can provide some information and even auto-fill it, but in the end the information is going to be untrustworthy. libei could (and probably should) pack the protocol with things like /proc/$pid/commandline but in the end you can't verify any of this. X, which basically always runs outside the sandbox could add _NET_WM_NAME but that's a voluntary property. So my current expectation is that we'll have *some* API in libei that provides for a key-value store and we'll likely agree on some keys that should go in there and classifies as untrusted but still usable data. e.g. "proxy=xwayland" or something. For flatpaks we have the app-id which is, AIUI, somewhat unfakable [1] and the portal can pass that to the libeis backend. And, again AIUI, the portal implementations already have some mechanisms to remember decisions, so once you allow com.whatever.synergy, it'll always be permitted. But either way, we're not adding anything new to that part of the process. In the end, the *decision* what's being accepted and what isn't is still outside, I think we can only provide data here. The backends will be different enough that I'm not sure we can provide some common thing here but I'm happy to be convinced otherwise. Cheers, Peter [1] installing applications that misidentify themselves is out of scope here ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RFC: libei - emulated input in Wayland compositors
I've been working on a new approach for allowing emulated input devices in Wayland. Or in short - how can we make xdotool and synergy work? And eventually replace them. The proposal I have is a library for Emulated Input, in short libei. https://gitlab.freedesktop.org/whot/libei/ libei has two parts, the client side (libei) for applications and a server side (libeis) for the compositor. The two libraries communicate with each other (how? doesn't matter, it's an implementation detail) to negotiate input devices. The process is roughly: - the libei client connects and says "I am org.freedesktop.SomeApplication and I want a pointer and a keyboard device" - the libeis server says "ok, you can have a pointer device and a keyboard device" - the libei client says 'move the pointer by 1/1', etc. and the server does just that. or not, depending on context. There are more details, see the README in the repo and the libei.h and libeis.h header files that describe the API. The sticking point here is: emulated input comes via a separate channel. The server a) knows it's emulated input, b) knows who it is coming from and c) has complete control over the input. a) is interesting because you can differ between the events internally. The API right now is very similar to libinput's events so integrating it into a compositor should be trivial. b) is somewhat handwavy if an application runs outside a sandbox - any information will be unreliable. Flatpak gives you an app-id though and with that we can (eventually) do things like storing the allow/deny decisions of the user in the portal implementation. c) allows you to e.g. suspend the client when convenient or just ignore certain sequences altogether. The two made-up examples are: suspend EI during a password prompt, or allow EI from the software yubikey *only* during a password prompt. Now, the next question is: how do they *start* talking to each other? libei provides multiple backends for the initial connection negotiation. My goal is to have this work with flatpak portals so an application running within the sandbox can be restricted accordingly. Alternatives to this could be public DBus interfaces, simple fd passing or (as is implemented right now) a named unix socket. The aim is that a client can simply iterate through all of the options until finds a connection. Once that's found, the actual code for emulating input is always the same so it's trivial to implement a client that works on any compositor that supports some backend of libeis. The server part only needs to care about the negotiation mechanisms it allows, i.e. GNOME will only have dbus/portal, sway will only have... dunno, fd exchange maybe? Next: because we have a separate channel for emulated input we can hook up XTEST to use libei to talk to a compositor. I have a PoC implementation for weston and Xwayland: https://gitlab.freedesktop.org/whot/weston/-/commits/wip/eis https://gitlab.freedesktop.org/whot/xserver/-/commits/wip/xwayland-eis With that xdotool can move the pointer. Note this is truly the most minimal code just to illustrate the point but you can fill in the blanks and do things like the compositor preventing XTEST or not, etc. This is all in very early stages with very little error checking so things will probably crash or disconnect unexpectedly. I've tried to document the API to make the intentions clear but there are still some very handwavy bits. Do let me know if you have any questions or suggestions please though. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.15.902
libinput 1.16 RC2 is now available. A device-specific quirk for the Lenovo X1 Gen6 touchpad and a change in the udev property handling to be more restrictive when rejecting joystick devices. This should be it for this cycle, unless someone finds a build error or serious crasher expect expect the 1.16 release within a few days. Peter Hutterer (7): evdev: fix the check for tablet vs joystick evdev: drop the check for tablet vs joystick quirks: correct modalias for the Lenovo X1 Gen6 touchpad: disable jump detection on the Lenovo X1 Gen6 touchpad gitlab CI: remove a bunch of trailing spaces gitlab CI: build an rpm package to verify the installed file list libinput 1.15.902 git tag: 1.15.902 https://www.freedesktop.org/software/libinput/libinput-1.15.902.tar.xz MD5: 259e7fe7fae7168920a3ed88346db9ce libinput-1.15.902.tar.xz SHA1: 0bf93514f2b62f4fd105fd63e6e5289f531c72f2 libinput-1.15.902.tar.xz SHA256: 866a92093e98b4f487508a067969c0c627e480419a67311bf26f0fab72cd3b57 libinput-1.15.902.tar.xz SHA512: b0e597f36809cf3f9109fa75aee7fbe224b411a807d568eac6e5e1743e41c21d86b60ed2e66a7281d13217c3a774f8e859663c9569e92efdca6784717b663266 libinput-1.15.902.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.15.902.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.15.901
libinput 1.16 RC1 is now available. This has been a long cycle, mostly because there weren't any huge changes on the main development branch and a lot of the minor annoyances have found their way into the 1.15.x releases anyway. I expect at least one or two more RCs, there are some MRs that look promising and they may just find their way into 1.16. libinput now monitors timestamps of the events vs the current time when libinput_dispatch() is called by the compositor. Where the difference *may* result in issues, a (rate-limited) warning is printed to the log. So you may see messages popping up in the form of "event processing lagging behind by XYZms, your system is too slow" This is a warning only and has no immediate effect. Previously we would only notice (and warn about) this when it affected an internal timer. The wheel tilt axis source was deprecated. No device ever had the required udev properties set so we should stop pretending we support this. Touchpads now support the "flat" acceleration profile. Unreliable lid or tablet-mode switches are now filtered by libinput, i.e. if libinput knows the device is unreliable, no switch event is passed to the caller. This prevents callers from receiving those known-bogus events and having to replicate the same heuristics that libinput employs. A new "libinput analyze" debugging tool is the entry tool for analysing various aspects of devices. Right now the only tool is "libinput analyze per-slot-delta" which can be used to detect pointer jumps in a libiput record output. This tool used to live elsewhere, it was moved to libinput so that reporters can easier run this tool, reducing the load on the maintainers. The tools have seen a few minor improvements, e.g. - "libinput record touchpad.yml" does the right thing, no explicit --output argument required - libinput measure touchpad-pressure has been revamped to be a bit more obvious - libinput measure touchpad-size has been added (as replacement for the touchpad-edge-detector tool) - libinput measure fuzz has been fixed to work (again and) slightly more reliable The libinput test suite has been fixed to avoid interference with the currently running session. Previously it was virtually impossible to work while the test suite is running - multiple windows would pop up, the screen would blank regularly, etc. And of course a collection of fixes, quirks and new bugs. As usual, see the git shortlog for details. Benjamin Tissoires (4): ci: use latest templates, and API ci: use the ci fairy to delete unwanted tags ci: use ci-fairy to generate the template, not a custom script ci: move the ci template to the expected file for ci-fairy Evan Goode (1): Allow the flat acceleration profile for touchpads Hans de Goede (1): quirks: Add HP stream x360 11 ModelTabletModeNoSuspend keyboard quirk John Rodriguez (1): Add quirks file for Sony Vaio Laptop Loïc Yhuel (1): quirks: correctly print boolean values Martin Cihlář (1): add trust mouse quirk #455 Matt Mayfield (1): touchpad: restore thumb detection while keeping fixes from !292 Peter Hutterer (90): tools: record: fix dmi recording tools: fix a typo in a man page tools: add a libinput analyze command with the per-slot-delta subcommand gitlab: revamp the bug template a bit tools: record: allow for an output file without --o tools: record: use the right exit code when the output file is missing tools: switch tool option parsing test to use pytest man: install the analyze per-slot-delta man page tools: if pytest fails to import, skip the tool option parsing test tools: record: drop quotes from os-release information doc/api: remove invalid doxygen option pad: fix a compiler warning touchpad: ratelimit the touch jump tests doc: update the jumping cursor docs evdev: print a human time for ratelimit tests util: fix a scan-build warning (value set but not read) test: fix a scan-build warning (value set but not read) meson.build: bump to 1.15.900 gitlab issue templates: remove the checkmarks gitlab CI: update the various build tests to F32 gitlab CI: switch the 'needs' tags to a dashed list gitlab CI: invert the ci-templates check gitlab CI: autogenerate the qemu tests for the last version of a distribution gitlab CI: generate the jobs for the custom builds from the config.yaml doc/user: add a mini-blurb for the new libinput analyze tool completion: add libinput analyze to zsh completions tools: add libinput analyze to the libinput tool help output udev: don't use IMPORT+= Fix race condition causing duplicate devices in udev seats tools: revamp the touchpad-pressure measuring tool tools: make the thumb threshold configurable while measuring pressure tools:
Re: weston-info as a standalone utility
On Thu, Jul 09, 2020 at 05:14:32PM +0200, Olivier Fourdan wrote: > Hey, > > On Thu, 9 Jul 2020 at 16:41, Daniel Stone wrote: > > > > On Thu, 9 Jul 2020 at 15:38, Pekka Paalanen wrote: > > > +1 for having this under the wayland organization in Gitlab. > > > +1 for deleting weston-info from Weston repository. > > > > > > Shall we keep the new repository only for "info" tools, or should > > > it contain more, like Weston's simple-shm, simple-egl, and a > > > rewrite of weston-eventdemo that doesn't use toytoolkit? > > > > > > I would be fine with moving all "simple" clients from Weston > > > repository to there if that's appropriate. > > > > +1 to all of the above. I'd be happy to see it in a utils and examples > > repo, with at least the ones you mentioned here. I don't think > > toytoolkit should ever be pushed in there, because then we run the > > danger of people thinking it might be a good idea. > > Thanks for your support! > > Having another "utils and example" repo is a good idea, but I think > weston-info stands apart from the other programs you mentioned, > simple-shm, simple-egl or eventdemo are more testing or debugging > tools, I reckon. > > I mean weston-info is simple and generic enough that it deserves a > repo of its own. Besides, having it in its own repo would allow for > new releases whenever we see fit, i.e. when we want to add more > information for new protocols, without having to deal with other > unrelated tools. I agree with olivier here, wayland-info should always work, against any compositor and just list the basic information about the protocols - and all of them, ideally. No interactivity, no toolkits, no debugging beyond the most basic grep. Any other tools can well go into a wayland-utils repo but they're different to wayland-info. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.15.6
libinput 1.15.6 is now available. A set of device-specific quirks, nothing major. If you don't have any of the devices listed in the shortlog below, nothing will change. Hans de Goede (1): quirks: Add HP stream x360 11 ModelTabletModeNoSuspend keyboard quirk John Rodriguez (1): Add quirks file for Sony Vaio Laptop Loïc Yhuel (1): quirks: correctly print boolean values Martin Cihlář (1): add trust mouse quirk #455 Peter Hutterer (4): tablet: use the AttrPressureRange quirk for tablets too quirks: mark the 0x233 razer keyboard as internal gitlab CI: alpine needs pip explicitly installed now libinput 1.15.6 Troels Blicher Petersen (1): Lenovo X201 Tablet: Added bezel buttons support in tablet mode Yariv Barkan (1): quirks: fix Apple external trackpad v2 thresholds git tag: 1.15.6 https://www.freedesktop.org/software/libinput/libinput-1.15.6.tar.xz MD5: b2388a1d6f0dcc944b49bc7239a53be8 libinput-1.15.6.tar.xz SHA1: 3313a4d76df51e62dfd3cf84918352faa0cf21de libinput-1.15.6.tar.xz SHA256: aeedea216a6317ddc6e27c3d54f26b987078780db6a8320cc09e19c25b307f1c libinput-1.15.6.tar.xz SHA512: 90459e5a1f22fd42ffcbab157b461e4514c30803bcebdaced76c65c05cccfa6f259640a50497055fe7ed0b376a6979f6d1d01227ae447fe60ba88fa81142b969 libinput-1.15.6.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.15.6.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Missing Protocols ir-keytable Ubuntu 20.04
On Tue, Jun 02, 2020 at 05:08:10PM +0100, Sean Young wrote: > Hi, > > On Wed, May 06, 2020 at 02:35:32PM +0200, Ralf Schmidt wrote: > > On more thing: because off the removed -d parameter, Remotes like the > > Technisat TTS35AI are no longer supported, such Type of Remotes are not > > recognized in /sys/class/rc/. > > So I'm now the proud owner of this device. > > This device is a usb dongle which is an IR receiver, but self-describes > as a usb hid keyboard device. It comes with a remote. > > As far as I can figure out, there is no way to reprogram it. > > So users have been re-mapping scancodes to different keycodes using: > > ir-keytable -d /dev/input/eventN -c -k 0x12:KEY_F1 > > However, ir-keytable was designed load keymaps for rc devices, not hid > devices. This functionality was intentionally removed, as it was buggy > in many ways. ir-keytable does not exist for remapping usb hid keyboards. > > This has left some users like Ralf in a situation where they can no longer > change the key mappings for their remote. > > ir-keytable is probably not the right way to do this; it has no rules to > do this from udev, for example. What tooling is there for doing this > and what is the recommended way to do this? remapping the keys through the udev builtins maybe? see /usr/lib/udev/hwdb.d/60-keyboard.hwdb Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: (2) Question about Linux MT Protocol B type
gt;│ > │ event2 TOUCH_DOWN +39.078s 1 (0) 87.22/85.86 (628.00/1099.00mm) >│ > │ event2 TOUCH_FRAME +39.078s >│ > │ event2 TOUCH_UP +39.122s >│ > │ event2 TOUCH_FRAME +39.122s >│ > └┘ > > So I looks like 1st finger down -> 1st finger up -> 2nd finger down -> 2nd > finger up > > I interpret it: 2nd finger down can come first than 1st finger, after all > fingers are released. the TOUCH_FRAME is the key here - anything within the frame is considered the same hardware event. So in the list above, you have 3 events: - touch 0 down - touch 0 up and touch 1 down - touch 1 up The order within a frame must not matter to a client (evdev clients and libinput client, for that matter). > I have thought that first touch down's index is always 0. the touch index value is an implementation detail. the only guarantee is that any given index refers to the same touch until the touch up event. It may get reused after that. (iirc) libinput increases them, but not always just by 1 due to implementation details. So right now the first index is zero but if I'm bored tomorrow I could change this to 42 and no client should break :) hth Cheers, Peter > But following in this case, second or third touch down can come fater than > first touch down. > > So I ask it to you that second finger down came fisrt situation is normal > situation or not.. > > I'll waiting for your reply. > > If you reply about this, it helps me a lot. > > > > Thanks and regards, > > JeongHyun Kang. > > > > - Original Message - > > Sender : Peter Hutterer > > Date : 2020-05-22 12:32 (GMT+9) > > Title : Re: Question about Linux MT Protocol B type > > > > On Thu, May 21, 2020 at 07:42:33PM +0900, 강정현 wrote: > > Dear all, > > > > I have an one question about Linux MT Protocol B type. > > > > Asume that press touch screen using first finger. > > > > And release fisrt finger and press second finger toghether. > > > > > > > > In that case, which procotol is correct? > > > > ┌───┐ > > │ ABS_MT_SLOT 0 > > │ > > │ > > │ > > │ ABS_MT_TRACKING_ID 1 > > │ > > │ > > │ > > │ ABS_MT_POSITION_X 10 > > │ > > │ > > │ > > │ ABS_MT_POSITION_Y 5 > > │ > > │ > > │ > > │ ABS_MT_SYNC <-- first finger press > > │ > > └───┘ > > There's no such thing as ABS_MT_SYNC, use SYN_REPORT here. > > > first case > > > > ┌───┐ > > │ ABS_MT_TRACKING_ID -1 > > │ > > │ > > │ > > │ ABS_MT_TRACKING_ID 2 > > │ > > │ > >
Re: Question about Linux MT Protocol B type
On Thu, May 21, 2020 at 07:42:33PM +0900, 강정현 wrote: > Dear all, > > I have an one question about Linux MT Protocol B type. > > Asume that press touch screen using first finger. > > And release fisrt finger and press second finger toghether. > > > > In that case, which procotol is correct? > > ┌───┐ > │ ABS_MT_SLOT 0 > │ > │ > │ > │ ABS_MT_TRACKING_ID 1 > │ > │ > │ > │ ABS_MT_POSITION_X 10 > │ > │ > │ > │ ABS_MT_POSITION_Y 5 > │ > │ > │ > │ ABS_MT_SYNC <-- first finger press > │ > └───┘ There's no such thing as ABS_MT_SYNC, use SYN_REPORT here. > first case > > ┌───┐ > │ ABS_MT_TRACKING_ID -1 > │ > │ > │ > │ ABS_MT_TRACKING_ID 2 > │ > │ > │ > │ ABS_MT_POSITION_X 15 > │ > │ > │ > │ ABS_MT_POSITION_Y 10 > │ > │ > │ > │ ABS_MT_SYNC <-- first finger release and first finger press is generated > │ > └───┘ Nope, that's wrong. You could skip the tracking ID -1 event and switch directly to ID 2. This is technically allowed by the protocol but a lot of userspace (anything Xorg and libinput) will struggle with it for historical reasons. Where you are re-using the same slot, you should always stop a touch and start the next touch in a separate frame. Direct switching also introduces some ambiguity because it merely means "kernel lost tracking of touch point", so userspace now has to decide whether it's the same touch or a new touch. > > second case > > ┌┐ > │ ABS_MT_TRACKING_ID -1 >│ > │ >│ > │ ABS_MT_SLOT 1 >│ > │ >│ > │ ABS_MT_TRACKING_ID 2 >│ > │ >│ > │ ABS_MT_POSITION_X 15 >│ > │ >│ > │ ABS_MT_POSITION_Y 10 >│ > │
Re: Issue with setting calibration matrix on imx6 platform.
On Mon, May 11, 2020 at 09:17:16AM +0530, poornachandrasekhar.alama...@india.horner-apg.com wrote: > Hi, > > > > We are trying to set calibration matrix on imx6 platfrom. > > We are able to set the touch calibration matrix using udev (static) on imx6 > platform. > > > > Our requirement is to set the calibration matrix dynamically during the run > time from the application. > > Libinput provides api's for setting the calibration matrix, so using them. I > tried setting, but the touch changes does not get reflected. think of libinput like a "grep" process. the normal instance runs within your compositor. your code below is equivalent to starting a new grep on the same file but with different options - this does not affect the instance already running in the compositors. If you want to change calibration at runtime, you need to talk to the compositor to get it to apply those options to the real libinput instance. Cheers, Peter > I am using following api > > 1. libinput_path_create_context() > > 2. libinput_path_add_device() > > 3. libinput_device_config_calibration_has_matrix() > > 4. libinput_device_config_calibration_get_matrix() > > 5. libinput_device_config_calibration_set_matrix() > > > > I have attached the c file used for touch calibration for your reference, > > where TouchCalibrationMatrix() is performing all operations. > > > > After setting the new calibration and reading back the calibration, I can > see that calibration matrix is set, but it is not getting reflected in the > touch. > > > > Can you please let me know where I am going wrong. > > > > Thanks & Regards, > > Poorna Chandra Sekhar Alamanda. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol backwards compatibility requirements?
On Tue, Apr 21, 2020 at 11:50:27AM +0300, Pekka Paalanen wrote: [...] > > > If you're asking if the implementation for version < N could be > > > deleted or avoided, then I'd say no. Definitely no for desktop > > > compositors, probably no for anything else public. > > > > The sub-interfaces are inseparable from the seats, that's set in stone. The > > question here is less about mixing versions within the seat but more > > about skipping versions without harm. Let's say wl_pointer version 9 > > introduces wl_pointer.pressure, something independent of anything else > > else in the wl_pointer interface. Qt (iirc) never implemented axis_discrete > > handling but it let's say it wants support for pressure. > > > > Guaranteed backwards compatibility means Qt can bump to version 9, implement > > noop functions for axis_source and axis_discrete and done. > > > > Allowing events to change between versions means that Qt now also needs to > > update its handling of whatever changed between those versions, e.g. > > wl_pointer.axis. A direct jump past versions you don't care about isn't > > possible. > > I would say that the direct jump past versions is never possible. Like > you said, Qt still needs to implement the noop functions. If it > doesn't, it will crash when those events get sent. The fact that making > those new functions noop is ok is just a detail, an accident of design. > Qt must come with a valid implementation - what a valid and workable > implementation is, is just a detail. > > > Also, having written the patches to change wl_pointer.axis_discrete to a 120 > > base value there's another issue: no auto-generated FOO_SINCE_VERSION > > because this doesn't show up in the protocol itself. So this really flies > > under the radar and you just have to know about it by reading the > > documentation. > > Was that one of the breaking changes already done in the past? so, checking the two examples Simon mentioned: - wl_data_offer.accept: semantics changed from "yes, I can receive this type" to "I have received and processed this type and I'm done now". - xdg_output.description: event was only sent once, changed to sent multiple times. Notable: xdg_output is still officially unstable anyway. So a change in message semantics and how often a message can be received but not in the actual data delivered. Not directly comparable to a potential change in the value ranges of an event. > Sounds to me like it's just one more reason to not change existing > message semantics, and add new messages instead. > > Maybe one possibility with e.g. wl_pointer, if you actually want to > shed the old cruft, is to create interface wl_pointer2 and add > get_pointer2 request to wl_seat. We will never be able to get rid of > the original wl_pointer interface or its implementations, but at least > it would be clearly separate. Good point, but I don't think it's worth it. For something that's moving more frequently this may help, but I don't anticipate a lot of wl_pointer changes. So this would require double the boilerplate everywhere whith very little benefit. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol backwards compatibility requirements?
On Mon, Apr 20, 2020 at 03:05:32PM +0300, Pekka Paalanen wrote: > On Thu, 16 Apr 2020 17:47:56 +1000 > Christopher James Halse Rogers wrote: > > > On Wed, Apr 15, 2020 at 14:27, Simon Ser wrote: > > > Hi, > > > > > > On Monday, April 13, 2020 1:59 AM, Peter Hutterer > > > wrote: > > >> Hi all, > > >> > > >> This is request for comments on the exact requirements for protocol > > >> backwards compatibility for clients binding to new versions of an > > >> interface. > > >> Reason for this are the high-resolution wheel scrolling patches: > > >> https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 > > >> > > >> Specifically, the question is: do we **change** protocol elements or > > >> behaviour as the interface versions increase? A few random examples: > > > > > > What we can't do is: > > > > > > - Change existing messages' signature > > > - Completely remove a message > > Indeed. > > > > > It should be relatively easy to modify wayland-scanner to support both > > of these things, *if* we decide that it's a reasonable thing to do. > > (You'd do something like add support for > removed_in="5"/> and the like) > > How would that work, given the version is negotiated at runtime? > > The message signature structs are now ABI as well, and we have no room > for alternate signatures, do we? > > > > > > >> - event wl_foo.bar introduced in version N sends a wl_fixed in > > >>surface coordinates. version N+1 changes this to a normalized > > >>[-1, +1] range. > > > > > > Argument types can't be changed. This would be a breaking change for > > > the > > > generated code, we can't do that. > > > > But this isn't changing the argument type; it's changing the > > interpretation of the argument. > > In both cases the type is wl_fixed; in the first you interpret this > > wl_fixed as being in surface coordinates, in the second you interpret > > it differently. > > > > This doesn't require any changes to code generation; I don't think this > > is (in principle) any more disruptive than changing “wl_foo.baz is > > sent exactly once” to “wl_foo.baz is sent zero or more times”, > > which you're happy with. > > Something we rarely consider is if you pass Wayland protocol objects > into a library without negotiating the object version with the library > first. For example, we pass wl_surface into the EGL Wayland wrapper > library. If wl_surface would get a version bump breaking backwards > compatibility, meaning that version N+1 changes something that existed > in version N, the library handling only version N would fall apart. ftr, this seems like something that should be noted in the protocol's xml directly to avoid future accidents. > I sincerely hope this is the only case of a library taking a ready-made > Wayland object in. Getting the version negotiation right needs > inconvenient additions to the library API that I don't think many would > bother or even realize it's needed. > > You can query the version of a wl_proxy, sure, but that does not help > you if it returns a number larger than what your code knows about. > > Btw. this is also a problem in the opposite direction. Let's say you > use a toolkit and the toolkit allows you access to the Wayland protocol > objects. Then the toolkit gains support for new interface versions and > uses them, but your app code is not updated. If the protocol change is > backwards incompatible, your app code may break even if only behaviour > changes and not signatures. > > > >> - request wl_foo.bar introduced in version N takes an int. version > > >> N+1 > > >>changes wl_foo.bar to take a wl_fixed and an enum. > > > > > > Ditto. > > > > > >> - request wl_foo.bar introduced in version N guaranteed to generate > > >> a single > > >>event wl_foo.baz. if the client binds to version N+1 that event > > >> may be > > >>sent zero, one or multiple times. > > > > > > This is fine. > > > > > >> I think these examples cover a wide-enough range of the possible > > >> changes. > > >> > > >> My assumption was that we only ever add new requests/events but > > >> never change > > >> existing behaviour. So wl_foo.bar introduced in version N will > > >> always have
Re: Protocol backwards compatibility requirements?
On Thu, Apr 16, 2020 at 05:47:56PM +1000, Christopher James Halse Rogers wrote: > > > On Wed, Apr 15, 2020 at 14:27, Simon Ser wrote: > > Hi, > > > > On Monday, April 13, 2020 1:59 AM, Peter Hutterer > > wrote: > > > Hi all, > > > > > > This is request for comments on the exact requirements for protocol > > > backwards compatibility for clients binding to new versions of an > > > interface. > > > Reason for this are the high-resolution wheel scrolling patches: > > > https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 > > > > > > Specifically, the question is: do we **change** protocol elements or > > > behaviour as the interface versions increase? A few random examples: > > > > What we can't do is: > > > > - Change existing messages' signature > > - Completely remove a message > > It should be relatively easy to modify wayland-scanner to support both of > these things, *if* we decide that it's a reasonable thing to do. (You'd do > something like add support for and the > like) > > > > > > - event wl_foo.bar introduced in version N sends a wl_fixed in > > >surface coordinates. version N+1 changes this to a normalized > > >[-1, +1] range. > > > > Argument types can't be changed. This would be a breaking change for the > > generated code, we can't do that. > > But this isn't changing the argument type; it's changing the interpretation > of the argument. > In both cases the type is wl_fixed; in the first you interpret this wl_fixed > as being in surface coordinates, in the second you interpret it differently. > > This doesn't require any changes to code generation; I don't think this is > (in principle) any more disruptive than changing “wl_foo.baz is sent exactly > once” to “wl_foo.baz is sent zero or more times”, which you're happy with. > > > > > > - request wl_foo.bar introduced in version N takes an int. version > > > N+1 > > >changes wl_foo.bar to take a wl_fixed and an enum. > > > > Ditto. > > > > > - request wl_foo.bar introduced in version N guaranteed to generate > > > a single > > >event wl_foo.baz. if the client binds to version N+1 that event > > > may be > > >sent zero, one or multiple times. > > > > This is fine. > > > > > I think these examples cover a wide-enough range of the possible > > > changes. > > > > > > My assumption was that we only ever add new requests/events but > > > never change > > > existing behaviour. So wl_foo.bar introduced in version N will > > > always have > > > the same behaviour for any interface N+m. > > > > We can change existing requests' behaviour. This has already been done a > > number of times, see e.g. wl_data_offer.accept or > > xdg_output.description. > > > > Clients should always have a max-version, ie. they should never blindly > > bind > > to the compositor's version. > > > > What is also fine is marking a message as "deprecated from version N". > > Such a > > message wouldn't be sent anymore starting from this version. > > > > > I've seen some pushback for above linked patchset because it gets > > > complicated and suggestions to just change the current interface. > > > The obvious advantage is being able to clean up any mess in the > > > protocol. > > > > > > The disadvantages are the breakage of backwards compatibility with > > > older > > > versions. You're effectively forcing every compositor/client to > > > change the > > > code based on the version number, even where it's not actually > > > needed. Or, > > > IOW, a client may want a new feature in N+2 but now needs to > > > implement all > > > changes from N+1 since they may change the behaviour significantly. > > > > This is the meat of the question - all of the changes described are > technically fairly simple to implement. yes, I agree, this is more a "political" choice or as you say, a question of what do we limit ourselves to. > To some extent this is a question of self-limitations. As has been > mentioned, protocols have *already* been deliberately broken in this way, > and people are happy enough with that. As long as we're mindful of the cost > such changes impose, I think that having the technical capability to make > such changes is of benefit - for example, rather than marking a message as > “deprecated from
Protocol backwards compatibility requirements?
Hi all, This is request for comments on the exact requirements for protocol backwards compatibility for clients binding to new versions of an interface. Reason for this are the high-resolution wheel scrolling patches: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 Specifically, the question is: do we **change** protocol elements or behaviour as the interface versions increase? A few random examples: - event wl_foo.bar introduced in version N sends a wl_fixed in surface coordinates. version N+1 changes this to a normalized [-1, +1] range. - request wl_foo.bar introduced in version N takes an int. version N+1 changes wl_foo.bar to take a wl_fixed and an enum. - request wl_foo.bar introduced in version N guaranteed to generate a single event wl_foo.baz. if the client binds to version N+1 that event may be sent zero, one or multiple times. I think these examples cover a wide-enough range of the possible changes. My assumption was that we only ever add new requests/events but never change existing behaviour. So wl_foo.bar introduced in version N will always have the same behaviour for any interface N+m. I've seen some pushback for above linked patchset because it gets complicated and suggestions to just change the current interface. The obvious advantage is being able to clean up any mess in the protocol. The disadvantages are the breakage of backwards compatibility with older versions. You're effectively forcing every compositor/client to change the code based on the version number, even where it's not actually needed. Or, IOW, a client may want a new feature in N+2 but now needs to implement all changes from N+1 since they may change the behaviour significantly. So... what's our official stance on protocol backwards compatibility requirements for clients binding to new versions? The last bit is important, this is not a discussion about an changing existing version, merely about future ones and binding to newer versions is opt-in for both compositor and client. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.15.5
libinput 1.15.5 is now available. A few minor changes, specifically in the udev rules and the doxygen generation to avoid warnings. The warnings about touch jumps on touchpads are now ratelimited - it's been quite a while since we could do anything about those anyway and in almost all cases libinput appears to do the right thing so it's not necessary to log every single jump and spam the logs. The docs have been updated accordingly too. Finally, another fix for a libinput record regression. Please do update so I don't have to deal with broken recordings. Peter Hutterer (6): tools: record: drop quotes from os-release information touchpad: ratelimit the touch jump tests doc: update the jumping cursor docs udev: don't use IMPORT+= doc/api: remove invalid doxygen option libinput 1.15.5 git tag: 1.15.5 https://www.freedesktop.org/software/libinput/libinput-1.15.5.tar.xz MD5: c9a1b15bb932eaf22f840efe4c3f84eb libinput-1.15.5.tar.xz SHA1: 644b1c6936cfff8a4547da71fbcd7ebd28618426 libinput-1.15.5.tar.xz SHA256: a90efc8f423c3094f2f9f372fb92381b2f3aad62e8b5882a8abe333aa8249c97 libinput-1.15.5.tar.xz SHA512: a0a3a325048841fc017e19d3bc5f5490605972ab9e2730dc5678bda7efb7a5b1fa6f531f3c8abd8393899ec383d8d2bcfd586eacee04fc1fbda0e02ba2af956a libinput-1.15.5.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.15.5.tar.xz.sig ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, Apr 04, 2020 at 11:16:08AM -0700, Rob Clark wrote: > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > > strictly > > > > > pre-merge CI. > > > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > > > > > > > I wouldn't mind manually triggering pipelines, but unless there is > > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > > click first the container jobs.. then wait.. then the build jobs.. > > > then wait some more.. and then finally the actual runners. That would > > > be a real step back in terms of usefulness of CI.. one might call it a > > > regression :-( > > > > On GStreamer side we have moved some existing pipeline to manual mode. > > As we use needs: between jobs, we could simply set the first job to > > manual (in our case it's a single job called manifest in your case it > > would be the N container jobs). This way you can have a manual pipeline > > that is triggered in single (or fewer) clicks. Here's an example: > > > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 > > > > That our post-merge pipelines, we only trigger then if we suspect a > > problem. > > > > I'm not sure that would work for mesa since the hierarchy of jobs > branches out pretty far.. ie. if I just clicked the arm64 build + test > container jobs, and everything else ran automatically after that, it > would end up running all the CI jobs for all the arm devices (or at > least all the 64b ones) generate your gitlab-ci from a template so each pipeline has its own job dependency. The duplication won't hurt you if it's expanded through templating and it gives you fine-grained running of the manual jobs. We're using this in ci-templates/libevdev/libinput for the various distributions and their versions so each distribution+version is effectively its own pipeline. But we only need to maintain one job in the actual template file. https://freedesktop.pages.freedesktop.org/ci-templates/ci-fairy.html#templating-gitlab-ci-yml Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, Apr 04, 2020 at 08:11:23AM -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( I *think* this should work though if you set up the right job dependencies. very simple example: https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128601 job1 is "when:manual", job2 has "needs: job1", job3 has "needs: job2". Nothing runs at first, if you trigger job1 it'll cascade down to job 2 and 3. The main limit you have here are the stages - where a job is part of a stage but does not have an explicit "needs:" it will wait for the previous stage to complete. That will never happen if one job in that stage has a manual dependency. See this pipeline as an example: https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128605 So basically: if you set up all your jobs with the correct "needs" you could even have a noop stage for user interface purposes. Here's an example: https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128606 It has a UI stage with "test-arm" and "test-x86" manual jobs. It has other stages with dependent jobs on those (cascading down) but it also has a set of autorun jobs that run independent of the manual triggers. When you push, the autorun jobs run. When you trigger "test-arm" manually, it triggers the various dependent jobs. So I think what you want to do is possible, it just requires some tweaking of the "needs" entries. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.15.4
libinput 1.15.4 is now available. Only one patch to the libinput record tool to fix the dmi modalias recording. Since this tool is used by every bug reporter and the library itself has no changes please do update to this one, you'll save a lot of my time... Peter Hutterer (2): tools: record: fix dmi recording libinput 1.15.4 git tag: 1.15.4 https://www.freedesktop.org/software/libinput/libinput-1.15.4.tar.xz MD5: 76c5cb1a55f5098ed353ae7d4e054c50 libinput-1.15.4.tar.xz SHA1: 43740a5fec3f6d474906173cc01ff3d73d935d2f libinput-1.15.4.tar.xz SHA256: 9c8b6846d94e374ee4bdb32634e4ac4aa318afc31f9a58fcb545cd3095c745c1 libinput-1.15.4.tar.xz SHA512: 4659818952dc729cd5bdb78ebe21edbbacbf8a66a592b13ba30f3bb4c4e264208ec94440a253cfa4edc8b2ef904954eecea6be0f8d63cf239e3858d3abb64a80 libinput-1.15.4.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.15.4.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.15.3
libinput 1.15.3 is now available. The main change here is an end to the regressions we've seen since 1.15.1 caused by the code to adjust the slot count. This code had side-effects on multiple devices (including identifying an issue in libevdev) but since it's only needed on serial ALPS devices, it is now restricted to ALPS devices only. Two coverity fixes, some minor fixes with libinput record/replay and a fix for the test suite. Everything else is CI-related. Peter Hutterer (27): gitlab CI: whitespace fixes for better visual alignments gitlab CI: add a comment to explain one of the jobs gitlab CI: generate the CI script from a template gitlab CI: generate the VM tests through the templates as well gitlab CI: generate the various default-builds through templating gitlab CI: don't hard-code the arch/alpine versions gitlab CI: use a separate variable for the template list gitlab CI: rename the custom build jobs tools: record: fix fallback os-release file handling tools: replay: mkdir /etc/libinput if it doesn't exist yet gitlab CI: don't push to wayland web on scheduled jobs test: remove double-assignment to a variable tools: constify the optarg handling of seats gitlab CI: don't run meson test on the scan-build job gitlab CI: mark the template file as yaml file for vim gitlab CI: pass the MESON_ARGS through to the VM as well test: disable a bunch of tests relying on libwacom gitlab CI: run the kvm test suite without libwacom gitlab CI: update to latest ci-templates gitlab CI: drop the distro name from the VM jobs gitlab CI: split the task to run on a VM out from the host system gitlab CI: drop the distribution "flavor" in favor of using the name test: fix a coverity complaint touchpad: add a note to the synaptics touch restore feature quirks: rename the alps touchpad quirk to note it's a serial TP quirk touchpad: only reduce the slot count for ALPS serial touchpads libinput 1.15.3 git tag: 1.15.3 https://www.freedesktop.org/software/libinput/libinput-1.15.3.tar.xz MD5: 6fbea8d51d9194d7ba33f96d7c4cee56 libinput-1.15.3.tar.xz SHA1: 101fd149b851c197323129efcdfe5c1c6c940b43 libinput-1.15.3.tar.xz SHA256: 5b12427dd50489c2b41b04ae2ca54e31a112a33cb861f00ccd15a2ad7a88694d libinput-1.15.3.tar.xz SHA512: 6636fd618e2b9cfa5ee44701207dc98f2639adc53eb3ef135509d936fb19b2cedf5184eab58e887798d9cf8ee65f35bc9062f7e3630080bcbe45a90a8b631ef2 libinput-1.15.3.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.15.3.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: GSoC | Support for pressure-only bluetooth styli
On Tue, Feb 25, 2020 at 05:36:17PM +0530, zubin choudhary wrote: > Hello Everyone. > > I am interested in working with X.org on *Support for pressure-only > bluetooth styli.* > I am willing to buy a stylus for this project. > I'm using a dell inspiron 7373 as my primary device. can anyone please > suggest me which stylus to buy. > also, I'm not very familiar with libinput but I'm willing to take this > learning opportunity. > till I get the stylus is there any task I can do? IIRC the dell active pen (if it's still sold) should do but fwiw, I won't have the time to do any mentoring so this may not be the best project to pick. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.15.2
libinput 1.15.2 is now available. This is a recommended update to 1.15.1 to fix three regressions. The code intoduced in 1.15.1 to deal with the ALPS kernel driver hardcoding the slot number had a side-effect - where a user lifts and restarts a touch during SYN_DROPPED (kernel dropping events because userspace isn't reading them fast enough), the slot count can reduce to 0. This caused libinput to ignore all touches. There's a workaround for this in place but this is a libevdev bug, so keep an eye out for libevdev 1.9.0. See https://gitlab.freedesktop.org/libinput/libinput/issues/422 for more info. Second, an assertion also introduced by the above code was triggered where a user had one or more finger on the touchpad when libinput starts up. This was due to a wrong touch count which has been fixed now. See https://gitlab.freedesktop.org/libinput/libinput/issues/429 for more info. Finally, a regression outside libinput: the new udev rules introduced in 1.15.0 (see e7a9c07ffe) inadvertently removed other udev callouts, causing the EVDEV_ABS overrides as defined in 60-evdev.hwdb to be ignored. If your touchpad started moving differently in 1.15, that was probably the reason. On the new feature front: we don't force a proximity out on a tablet pen while a button is held down. libinput record now includes distro name and version from /etc/os-release because it's sometimes handy to know that and not always obvious from the kernel version. Other than that, a few fixes and one quirk: for the MadCatz RAT7 mouse which is a bit too creative with the keycodes it sends. Peter Hutterer (16): tools: record: record the EVDEV_ABS properties correctly udev: *add* the fuzz-to-zero program to the udev RUN list, don't overwrite udev: directly import the device groups test: drop the #define for the litest device rules test: add a test case for checking EVDEV_ABS overrides test: mark the tablets that require forced prox out as such test: fix a duplicate button down where we want a button press + release test: drop a wait in favor of direct event processing tablet: don't force a proximity out while buttons are down touchpad: never reduce the slot count to 0 touchpad: sync the initial tracking id state to the touchpad gitlab CI: print a warning when our VM startup fails gitlab CI: handling killing the qemu process better tools: record: rename a variable to just buf tools: record: record basic os-release information as well libinput 1.15.2 Victor Brekenfeld (1): quirks: Add quirk for MadCatz RAT7 mouse git tag: 1.15.2 https://www.freedesktop.org/software/libinput/libinput-1.15.2.tar.xz MD5: eb6bd2907ad33d53954d70dfb881a643 libinput-1.15.2.tar.xz SHA1: 2a0c4ce80ee43a9a1b274bfe40ca638037716584 libinput-1.15.2.tar.xz SHA256: 971c3fbfb624f95c911adeb2803c372e4e3647d1b98f278f660051f834597747 libinput-1.15.2.tar.xz SHA512: f6b50dbdf6ee6b65f88e020c4292c94c3178125d58629f27c2e52f92b658ccd67e0c5604fbf0b303621ff0386637ce1e291daaa991761d4145e8bcda4dd128a2 libinput-1.15.2.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.15.2.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.15.1
libinput 1.15.1 is now available. No large changes here, some improvements to the documentation and the debugging/recording tools. In terms of user-visible fixes: a specific event sequence involving proximity timeouts and eraser buttons could previously trigger invalid proximity in/out sequences, leading to a crash in the clients. This is fixed now. And ALPS touchpads now automatically reduce the slot-count based on the number of actually provided fingers. The kernel hardcodes 5 but we don't always get 5 finger locations, so now we adjust this down to match. A. Wilcox (1): evdev-fallback: Use input_event_init for fallback Jacob Kauffmann (1): doc/user: Fix grammar. Michael Forney (1): litest: Fix warnings about discarded qualifiers with check-0.13.0 Peter Hutterer (22): test: fix some wrong touchpad slot range checks test: simplify a slot count check test: switch from counting slot max to num_slots tools: fix abort caused by the pointing stick integration quirk doc/user: expand the contributing document and make it top-level gitlab CI: retry the VM jobs on script failure doc/user: some minor improvements doc/user: explain the gitlab issue tags test: wrap slot counting into a helper function test: make the custom touch override methods filter-able touchpad: correct a wrong slot count by the kernel tools: align the tool type names on proximity nicely tools: refuse to replay recordings with timestamps from the future tools: record: wrap the time offset handling into a helper function tools: record: fix broken event time stamp recording timer: make the timer offset error a bit more user-friendly tools: fix typo in debug-events man page tools: record: record the EV_ABS deltas along with the absolute value test: add a comment to a test device test: add helper functions for checking proximity events tablet: fix the handling of axis updates after a forced proximity out libinput 1.15.1 William Brown (2): Small improvements to contributing for accessibility. Improve git commit section git tag: 1.15.1 https://www.freedesktop.org/software/libinput/libinput-1.15.1.tar.xz MD5: 93850756b6c07aafb49d5226e88fdc81 libinput-1.15.1.tar.xz SHA1: 1b311c407c21210ad9d13b059e9eab4b85f19fb5 libinput-1.15.1.tar.xz SHA256: 6b2f57495c6f173ecf49ee19d3e10087d9916a52711e1b5eb01e0d9635950c16 libinput-1.15.1.tar.xz SHA512: 634810359bc4d86f2c4c75f472bee5eaed04ed93af3c91c4bc46a596402323941f9cc90173e278bfa7e5cbda6b7a20adc59bd09520dd4152fc961302b7e57904 libinput-1.15.1.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.15.1.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: About libinput license.
On Fri, Dec 20, 2019 at 12:46:00PM +0900, Yoshiaki Seko wrote: > Dear libinput Developers > > I'm Seko.I have a question. > > We want to use libinput. > I see your HP and I think libinput is MIT License. > https://wayland.freedesktop.org/libinput/doc/latest/faqs.html#is-libinput-gpl-licensed > > But I think below module is used GPL codes, because the text is described > below in the module header. > "Modelled after Linux' lib/ratelimit.c by Dave Young > , which is licensed GPLv2." > (libinput/1.8.1-r0/libinput-1.8.1/src libinput-util.c ratelimit_test()) > > So, I'm thinking that the GPL is propagating, isn't it a problem? I've looked at the referenced lib/ratelimit.c and I think we can justifiably say that "modelled after" merely means "got the inspiration from". The API differs and the implementation differs but I do not think that there is sufficient similarity to claim one is a derivative of the other. The GPL does not propagate here IMO. Cheers, Peter, not a lawyer. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.15.0
libinput 1.15 is now available. No significant changes over the RC, merely quirks for the Logitech MX Master 2S and the Madcatz R.A.T.3 mouse. Thus, to fill the void with useful stuff, let's copy-paste the RC1 announcement text here so it looks like we've been busy: A few new features, a lot of maintenance work. On the feature front we have scroll button locking and tablet pad keys support. Scroll button locking holds a scroll button logically down even when the button is physicall released. This applies to button scrolling (hold the button while moving a mouse up/down generates scroll events). Previously the button had to be physicall held down during the scroll motion which is difficult for a number of users. When the scroll button lock is enabled, the first click of the button holds it logically down, the second click releases it. This feature comes with the usual set of configuration hooks: libinput_device_config_scroll_set_button_lock() libinput_device_config_scroll_get_button_lock() libinput_device_config_scroll_get_default_button_lock() Some tablet devices have hardware buttons that are designed to map to a specific functionality (e.g. to open the OSD). These buttons are now supported through the new LIBINPUT_EVENT_TABLET_PAD_KEY event. Noteworthy here is that for those events the key code matters (unlike the tablet pad button code which is just a sequential number). See the documentation for more details. In addition to the event we have a new API to query whether a given tablet has a specific hw key: libinput_device_tablet_pad_has_key() Other than those, a whole bunch of device specific-fixes and general cleanups. Touchpad scrolling was approximately 10% faster than the nominal pointer speed, that has been adjusted now. The new libinput debug-tablet tool is useful to check whether a tablet sends the full axis values (or any, for that matter). libinput debug-events now takes multiple devices, libinput record has a better CLI for recording multiple devices simultaneously and libinput replay had simultaneous replay fixed. Tablet forced proximity out has been improved - it won't happen while the pen is down. In libinput 1.14 we disabled a direct tool switch from tablets, causing the eraser button to stop working. This was caused by some tablets that break the spec and act as if pen and eraser are both in proximity when the button is pressed. This issue is fully fixed now and the eraser button should work as expected now. And finally, lots of fixes to the CI with the massive benefit that we can actually run the test suite in the CI now. Less reliance on my little laptop is a good thing. As usual, the git shortlog is below. Anatolii Lishchynskyi (1): quirks: ignore mode switch button on Madcatz R.A.T.3 mouse Björn Daase (1): quirks: fix horizontal scrolling for Logitech MX Master 2S on bluetooth Peter Hutterer (8): gitlab CI: use a minimal alpine image for the commit checks gitlab CI: fix skopeo copy gitlab CI: update to latest ci-templates meson.build: re-add missing trailing slash to the HTTP link doc/user: fix some HTML formatting test: add the test cases to the suite in the utils tests test: indentation fix libinput 1.15.0 git tag: 1.15.0 https://www.freedesktop.org/software/libinput/libinput-1.15.0.tar.xz MD5: d5fe153c4b1d69ec35dc846588cd47ec libinput-1.15.0.tar.xz SHA1: 93dd7636b65e8cfea3a3068da5415f29195a189d libinput-1.15.0.tar.xz SHA256: bfbf1fef66bcb2be871a18783dfcfb88ecb431f496bf0a9cf6685fd29c5843e1 libinput-1.15.0.tar.xz SHA512: 5dab48e1b4c9c0deb5b01ebc3ccb4cc28d614be25d87daaf42f51fbd2d955266f3fdba73029bc0094caa55060dad8967751b72d8f45f19a40b542f0c9118c1b6 libinput-1.15.0.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.15.0.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.14.901
Apologies for the re-send but the original announcement was sent unsigned and without the actual text. The first RC for libinput 1.15 is now available. A few new features, a lot of maintenance work. On the feature front we have scroll button locking and tablet pad keys support. Scroll button locking holds a scroll button logically down even when the button is physicall released. This applies to button scrolling (hold the button while moving a mouse up/down generates scroll events). Previously the button had to be physicall held down during the scroll motion which is difficult for a number of users. When the scroll button lock is enabled, the first click of the button holds it logically down, the second click releases it. This feature comes with the usual set of configuration hooks: libinput_device_config_scroll_set_button_lock() libinput_device_config_scroll_get_button_lock() libinput_device_config_scroll_get_default_button_lock() Some tablet devices have hardware buttons that are designed to map to a specific functionality (e.g. to open the OSD). These buttons are now supported through the new LIBINPUT_EVENT_TABLET_PAD_KEY event. Noteworthy here is that for those events the key code matters (unlike the tablet pad button code which is just a sequential number). See the documentation for more details. In addition to the event we have a new API to query whether a given tablet has a specific hw key: libinput_device_tablet_pad_has_key() Other than those, a whole bunch of device specific-fixes and general cleanups. Touchpad scrolling was approximately 10% faster than the nominal pointer speed, that has been adjusted now. The new libinput debug-tablet tool is useful to check whether a tablet sends the full axis values (or any, for that matter). libinput debug-events now takes multiple devices, libinput record has a better CLI for recording multiple devices simultaneously and libinput replay had simultaneous replay fixed. Tablet forced proximity out has been improved - it won't happen while the pen is down. In libinput 1.14 we disabled a direct tool switch from tablets, causing the eraser button to stop working. This was caused by some tablets that break the spec and act as if pen and eraser are both in proximity when the button is pressed. This issue is fully fixed now and the eraser button should work as expected now. And finally, lots of fixes to the CI with the massive benefit that we can actually run the test suite in the CI now. Less reliance on my little laptop is a good thing. Many thanks to all that contributed! Aleix Pol (1): LIBINPUT_EVENT_TABLET_BUTTON doesn't exist, use LIBINPUT_EVENT_TABLET_PAD_BUTTON Balazs Endresz (1): Fix horizontal scrolling for Logitech MX Master 3 on bluetooth Benjamin Tissoires (2): gitlab-ci: use qemu to run the full test suite gitlab-ci: use one sha1 instead of duplicates Jakub Schmidtke (1): Fixed horizontal scrolling on Logitech MX Master 2S/3 John Chadwick (2): test: Make udev_properties array fixed-size. tablet: Improve forced prox out behavior. Konstantin Kharlamov (27): filter-flat.c: remove unused includes filter-low-dpi.c: remove unused includes filter-mouse.c: remove unused includes filter-touchpad.c: remove unused includes filter-touchpad-x230.c: remove unused includes filter-trackpoint.c: remove unused include evdev.c: remove unused include evdev-mt-touchpad.h: remove unused include evdev-mt-touchpad-tap.c: remove unused includes evdev-mt-touchpad-edge-scroll.c: remove unused includes evdev-mt-touchpad-gestures.c: remove unused include evdev-tablet.c: remove unused include evdev-tablet-pad-leds.c: remove unused includes timer.c: remove unused include libinput-fuzz-override.c: remove unused includes filter.h/c: remove unused includes evdev-mt-touchpad-buttons.c: remove unused includes path-seat.c: remove unused includes udev-seat.c: remove unused includes libinput-debug-events.c: remove unused includes libinput-fuzz-extract.c: remove unused includes libinput-fuzz-to-zero.c: remove unused includes quirks.c: remove unused include libinput-measure.c: remove unused includes libinput-tool.c: remove unused includes libinput-list-devices: be more explicit about only listing defaults libinput-list-devices: make paragraph about different settings terser Luflosi (1): doc: fix sentence Peter Hutterer (93): tools: factor out a sanity check in libinput-replay tools: make an infinite loop more obvious in the code tools: install local quirks during libinput replay tools: change python invocations to use /usr/bin/env python3 tools: flake8 fixes for the various python files test: do run the util tests under valgrind Split utility functions into separate source files Remove some
[ANNOUNCE] libinput 1.14.901
Aleix Pol (1): LIBINPUT_EVENT_TABLET_BUTTON doesn't exist, use LIBINPUT_EVENT_TABLET_PAD_BUTTON Balazs Endresz (1): Fix horizontal scrolling for Logitech MX Master 3 on bluetooth Benjamin Tissoires (2): gitlab-ci: use qemu to run the full test suite gitlab-ci: use one sha1 instead of duplicates Jakub Schmidtke (1): Fixed horizontal scrolling on Logitech MX Master 2S/3 John Chadwick (2): test: Make udev_properties array fixed-size. tablet: Improve forced prox out behavior. Konstantin Kharlamov (27): filter-flat.c: remove unused includes filter-low-dpi.c: remove unused includes filter-mouse.c: remove unused includes filter-touchpad.c: remove unused includes filter-touchpad-x230.c: remove unused includes filter-trackpoint.c: remove unused include evdev.c: remove unused include evdev-mt-touchpad.h: remove unused include evdev-mt-touchpad-tap.c: remove unused includes evdev-mt-touchpad-edge-scroll.c: remove unused includes evdev-mt-touchpad-gestures.c: remove unused include evdev-tablet.c: remove unused include evdev-tablet-pad-leds.c: remove unused includes timer.c: remove unused include libinput-fuzz-override.c: remove unused includes filter.h/c: remove unused includes evdev-mt-touchpad-buttons.c: remove unused includes path-seat.c: remove unused includes udev-seat.c: remove unused includes libinput-debug-events.c: remove unused includes libinput-fuzz-extract.c: remove unused includes libinput-fuzz-to-zero.c: remove unused includes quirks.c: remove unused include libinput-measure.c: remove unused includes libinput-tool.c: remove unused includes libinput-list-devices: be more explicit about only listing defaults libinput-list-devices: make paragraph about different settings terser Luflosi (1): doc: fix sentence Peter Hutterer (93): tools: factor out a sanity check in libinput-replay tools: make an infinite loop more obvious in the code tools: install local quirks during libinput replay tools: change python invocations to use /usr/bin/env python3 tools: flake8 fixes for the various python files test: do run the util tests under valgrind Split utility functions into separate source files Remove some usage of libinput-util.h udev: parse the EVDEV_ABS properties for a potential fuzz setting meson.build: bump to 1.14.900 touchpad: drop useless asserts() touchpad: only identify for pinch in a distinct pinch position gestures: rename the inner/outer thresholds to min/max_move gestures: where we have more fingers than slots, default to swipe doc: update reference to the event codes header doc/user: update copyright for the sphinx docs doc/user: drop markdown source parsers test: don't use debounced clicks for the middle button emulation click middle-button: add space to middlebutton state debug message test: fix a coverity warning about an unused value util-time: include linux/input.h touchpad: use the same speed for scrolling as the baseline of the accel curve gitlab CI: run the valgrind test suite as well CI: UI improvements fallback: don't send a single-touch motion if we just sent a begin Add a scroll button lock feature meson: move HTTP doc url generation to here doc/user: add a link to the API documentation in the TOC doc/user: actually link to the API documentation quirks: make the diff call for the meson check more portable gitlab CI: add an alpine image doc/user: reword one of the FAQ entries to no tmake it read outdated doc/user: add a faq entry about the pointer acceleration "issue" fallback: fix a coverity warning udev: fix potential memory leak for the phys string gitlab CI: switch to Fedora 31 gitlab CI: switch to Ubuntu 19.10 test: make the test jobs dependent on the number of processors tools: correct libinput measure reference to the tap man page tools: drop the specific libinput measure tools from the libinput man page test: remove some useless code triggering a coverity warning test: silence a coverity warning test: remove a useless assignment gitlab CI: fix an indentation issue gitlab CI: split the qemu test runs up into multiple jobs tools: debug-gui: show pressure/distance as vertical bar tablet: add a helper function to get the current tool tablet: handle a direct tool switch correctly gitlab CI: add diffutils to the Fedora RPMs test: drop a now-obsolete test test: remove the hardcoded four-job valgrind test run gitlab CI: allow the qemu-prep job to fail, runners are unreliable gitlab CI: work around collapsed multiline commands in the rebuild check m
[ANNOUNCE] libinput 1.14.3
libinput 1.14.3 is now available. This release changes the horizontal scroll direction of the Logitech MX Master 3 back to what users would expect (this device ships with the wheel inverted). Tablet no longer force a proximity out while the tip is logically down. Single-touch screens sent superfluous (and wrong) motion events within the same touch down - that's fixed now. Finally, touchpad scrolling now matches the 'default' speed of the cursor, previously it was 10% too fast. As usual, the git shortlog is below. Balazs Endresz (1): Fix horizontal scrolling for Logitech MX Master 3 on bluetooth John Chadwick (1): tablet: Improve forced prox out behavior. Peter Hutterer (6): touchpad: use the same speed for scrolling as the baseline of the accel curve fallback: don't send a single-touch motion if we just sent a begin doc/user: drop markdown source parsers gitlab CI: run the valgrind test suite as well CI: UI improvements libinput 1.14.3 git tag: 1.14.3 https://www.freedesktop.org/software/libinput/libinput-1.14.3.tar.xz MD5: d052faa64eb6d2e649e582cc0fcf6e32 libinput-1.14.3.tar.xz SHA1: af23a4359202c24b592033f54347719a8f44d872 libinput-1.14.3.tar.xz SHA256: 0feb3a0589709cc1032893bfaf4c49150d5360bd9782bec888f9e4dd9044c5b7 libinput-1.14.3.tar.xz SHA512: f01d1bd1b25b8060519575644597d35f0c89de5386d298441f440128ceee3e57549921a058adec31adc8b33dbdedf4c0bd12c76905a69f752859d3136e26336d libinput-1.14.3.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.14.3.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.14.2
libinput 1.14.2 is now available. The bulk of the changes here are quirks for specific devices, notably the Logitech MX Master 2S and 3, Thinkpad 13 G2, HP Elite x2 1013 G3 and the Lenovo T490s and X200. For everyone else, the thumb detection is now less aggressive, fixing a few issues seen where two-finger scrolling was misdetected as pinch gestures, etc. Benjamin Tissoires (2): gitlab-ci: use qemu to run the full test suite gitlab-ci: use one sha1 instead of duplicates Jakub Schmidtke (1): Fixed horizontal scrolling on Logitech MX Master 2S/3 John Chadwick (1): test: Make udev_properties array fixed-size. Peter Hutterer (3): touchpad: only identify for pinch in a distinct pinch position gestures: where we have more fingers than slots, default to swipe libinput 1.14.2 Richard McIntosh (1): Added magic trackpoint multiplier for Thinkpad 13 G2 RussianNeuroMancer (2): Tablet Mode Switch on HP Elite x2 1013 G3 is unreliable: Mark HP Elite x2 1013 G3 keyboard as external Serhii Chaplia (1): Touchpad fix and trackpoint speed adjustment for Lenovo T490s yy (1): Added quirk for Lenovo ThinkPad X200 Tablet. git tag: 1.14.2 https://www.freedesktop.org/software/libinput/libinput-1.14.2.tar.xz MD5: c282990973140e3fa2dd274c69ab3a57 libinput-1.14.2.tar.xz SHA1: fe3d33ec7d180df43987b23212d4bf1f69690580 libinput-1.14.2.tar.xz SHA256: 6b094669141f26c4df0d62147bbd0f76df1044333e19e6f6dc9413217c51a2c6 libinput-1.14.2.tar.xz SHA512: 932949a78bf95a7a05f50170cfc7dc109c99e1e3e70e63797566c0c3a3003632cad56e9b9ca2a180880f5e2ec1060613066d068b384096f37785fe70ac30c1eb libinput-1.14.2.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.14.2.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput drops keys from infrared remotes after changing keymap
On Tue, Oct 01, 2019 at 09:39:51AM +0100, Sean Young wrote: > Hi Hans, > > On Mon, Sep 30, 2019 at 01:29:59PM +0200, Hans de Goede wrote: > > On 30-09-2019 10:33, Sean Young wrote: > > > On Mon, Sep 30, 2019 at 11:34:04AM +1000, Peter Hutterer wrote: > > > > On Sun, Sep 29, 2019 at 08:17:38PM +0100, Sean Young wrote: > > > > > Any thoughts on this would be appreciated! > > > > > > > > libinput relies on udev, either directly or through the X server. So if > > > > you > > > > trigger your device to get removed and re-added through udev, libinput > > > > will > > > > add it and re-initialize it with whatever current bits it has. > > > > > > > > sudo udevadm trigger --action=remove /sys/class/input/event5 > > > > sudo udevadm trigger --action=add /sys/class/input/event5 > > > > > > Hmm, this is bit of an ugly workaround, even if generated them from > > > ir-keytable. > > > > > > We could change the kernel to re-create the input device when the keymap > > > changes, but this does not fit the current model very well. > > > > > > Not quite sure how to solve this yet. > > > > Just reading along here as an ex libinput contributor. I have the feeling > > that it will help if you can explain your specific use-case, because it > > sounds like you really want to change the keymap on the fly, while normally > > the keymap is something which gets setup once and the loaded by udev add > > device init time... > > You're absolutely right, that is exactly what I'm trying to do. > > > So can you please explain your specific use-case here? > > Simply loading a new keymap while logged in, or rather solve the issue of > "my remote doesn't work after loading the correct keymap". > > My longer term goal is to provide gnome-control-center plugin for > configuring IR receivers. > > So what I'm hearing is that from libinput's perspective, an input device > should not change once created. In order to support this use-case, either > ask the user to logout/login or the kernel should re-create the input > device when the keymap changes. just a late addition here: libinput devices are (currently) static too, so libinput callers don't expect them to change. this may or may not be a problem, depending on the caller. e.g. the ones calling libinput_device_keyboard_has_key() wouldn't expect that to change during the lifetime of the device. so even if we'd move the key mappings above a few layers, we'd still end up with the virtual device removal/addition. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Libinput-touch screen detection
On Thu, Oct 03, 2019 at 10:52:41AM +, sanjay anvekar wrote:
> Hi Peter, I couldn't get reason for missing ID_INPUT_TOUCHSCREEN , my
> udev rule looks as below.
> SUBSYSTEM=="input" KERNEL=="event[0-9]" ENV{ID_INPUT_TOUCHSCREEN}=="1"
> ENV{ID_SEAT}="seat1" SYMLINK+="/dev/input/event0"
you assign seat1 here but libinput by default uses seat0. so the device will
simply be ignored unless you tell libinput to listen to events from seat1.
libinput debug-events --seat seat1 should show the events, and likewise your
compositor provided it listens to the right seat.
>
> I don't have libinput record tool, instead tried with evtest and I see
> BTN_TOUCH, below is capture from evtest
> ~# evtestNo device specified, trying to scan all of
> /dev/input/event*Available devices:/dev/input/event0:
> touchscreen/dev/input/event1: Dell Dell USB Optical MouseSelect the
> device event number [0-1]: 0Input driver version is 1.0.1Input device ID: bus
> 0x18 vendor 0x0 product 0x0 version 0x0Input device name:
> "touchscreen"Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY)
> Event code 330 (BTN_TOUCH) Event type 3 (EV_ABS) Event code 48
> (ABS_MT_TOUCH_MAJOR) Value 0 Min 0 Max 600
> Event code 53 (ABS_MT_POSITION_X) Value 0 Min 168
> Max 3908 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min
> 195 Max 4045Properties:Testing ... (interrupt to exit)Event:
> time 1569995436.407176, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1Event:
> time 1569995436.407176, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value
> 96Event: time 1569995436.407176, type 3 (EV_ABS), code 53
> (ABS_MT_POSITION_X), value 630Event: time 1569995436.407176, type 3 (EV_ABS),
> code 54 (ABS_MT_POSITION_Y), value 693Event: time 1569995436.407176,
> ++ SYN_MT_REPORT Event: time 1569995436.407176,
> -- SYN_REPORT Event: time 1569995436.413546, type 3
> (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 94Event: time
> 1569995436.413546, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value
> 640Event: time 1569995436.413546, type 3 (EV_ABS), code 54
> (ABS_MT_POSITION_Y), value 705Event: time 1569995436.476318, ++
> SYN_MT_REPORT Event: time 1569995436.476318, --
> SYN_REPORT Event: time 1569995436.482637, type 3 (EV_ABS), code
> 48 (ABS_MT_TOUCH_MAJOR), value 85Event: time 1569995436.482637, type 3
> (EV_ABS), code 53 (ABS_MT_POSITION_X), value 645Event: time
> 1569995436.482637, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value
> 696Event: time 1569995436.482637, ++ SYN_MT_REPORT
> Event: time 1569995436.543353, -- SYN_REPORT
> Event: time 1569995436.549449, type 3 (EV_ABS), code 48
> (ABS_MT_TOUCH_MAJOR), value 89Event: time 1569995436.549449, type 3 (EV_ABS),
> code 53 (ABS_MT_POSITION_X), value 638Event: time 1569995436.549449, type 3
> (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 697Event: time
> 1569995436.549449, ++ SYN_MT_REPORT Event: time
> 1569995436.549449, -- SYN_REPORT Event: time
> 1569995436.27, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value
> 102Event: time 1569995436.27, type 3 (EV_ABS), code 53
> (ABS_MT_POSITION_X), value 638Event: time 1569995436.27, type 3 (EV_ABS),
> code 54 (ABS_MT_POSITION_Y), value 709Event: time 1569995436.27,
> ++ SYN_MT_REPORT Event: time 1569995436.27,
> -- SYN_REPORT Event: time 1569995436.752071, type 1
> (EV_KEY), code 330 (BTN_TOUCH), value 0Event: time 1569995436.752071, type 3
> (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 0Event: time 1569995436.752071,
> ++ SYN_MT_REPORT Event: time 1569995436.752071,
> -- SYN_REPORT
impossible to read, sorry.
Cheers,
Peter
>
> Does this indicate that Kernel driver is working fine and issue is with some
> configuration ? Please let me know.
> Thanks & Best Regards,Sanjay
>
> On Wednesday, 2 October, 2019, 07:16:32 pm GMT+1, Peter Hutterer
> wrote:
>
> On Wed, Oct 02, 2019 at 04:40:24PM +, sanjay anvekar wrote:
> > Hi Peter, Thank you for your response. I tried changing udev properties
> >but it didn't help. Here is output from udevadm command.udevadm info
> >/dev/input/event0P:
> >/devices/soc0/soc/210.aips-bus/21a4000.i2c/i2c-1/1-0048/input/input0/event0N:
> > input/event0S: input/by-path/platform-21a4000.i2c-eventE:
> >DEVLINKS=/dev/input/by-path/platform-21a4000.i2c-eventE
Re: Libinput-touch screen detection
On Wed, Oct 02, 2019 at 04:40:24PM +, sanjay anvekar wrote: > Hi Peter, Thank you for your response. I tried changing udev properties > but it didn't help. Here is output from udevadm command.udevadm info > /dev/input/event0P: > /devices/soc0/soc/210.aips-bus/21a4000.i2c/i2c-1/1-0048/input/input0/event0N: > input/event0S: input/by-path/platform-21a4000.i2c-eventE: > DEVLINKS=/dev/input/by-path/platform-21a4000.i2c-eventE: > DEVNAME=/dev/input/event0E: > DEVPATH=/devices/soc0/soc/210.aips-bus/21a4000.i2c/i2c-1/1-0048/input/input0/event0E: > ID_INPUT=1E: ID_PATH=platform-21a4000.i2cE: > ID_PATH_TAG=platform-21a4000_i2cE: MAJOR=13E: MINOR=64E: SUBSYSTEM=inputE: > USEC_INITIALIZED=2341962 > > Also tried with 'libinput-debug-events' and following is > outputlibinput-debug-events --device /dev/input/event0 --verboseinput device > 'touchscreen', /dev/input/event0 not tagged as input devicefailed to create > input device '/dev/input/event0'.Failed to initialized device > /dev/input/event0 > I tested this input device with 'evetest' application and it works, but > doesn't work with libinput. > How do I debug further and conclude that it is Kernel driver issue ? Please > let me know. > Thanks & Best Regards,Sanjay fwiw, the plain text your email client sends appears to be ... broken. you're missing ID_INPUT_TOUCHSCREEN which is probably you're missing BTN_TOUCH on the evdev node. run libinput record and that'll tell you the bits set for the device - for a touchscreen you need ABS_X/Y and BTN_TOUCH as the minimum. look for the udev-builtin-input_id.c file in the systemd git repo, that will tell you how the various ID_INPUT_FOO tags get applied. Then you need to make sure the kernel exports those. Cheers, Peter > > > > > On Wednesday, 2 October, 2019, 02:50:39 pm GMT+1, Peter Hutterer > wrote: > > On Tue, Oct 01, 2019 at 04:08:17PM +, sanjay anvekar wrote: > > Hi All, I am new to Wayland. I am using Weston 1.9.0 on imx6x board with > > touchscreen display of resolution 1024x768. I am seeing touchscreen as > > /dev/input/event0 device and it is working. I confirmed functioning of > > touchscreen using "cat /dev/input/event0" command. Unfortunately, I don't > > see touchscreen is listed by libinput application i.e. > > 'libinput-list-devices'. If I connect USB mouse then I see mouse is listed > > by 'libinput-list-devices' application, but not touchscreen. I am running > > Qt application and it is not able to detect touch inputs. Please let me > > know your inputs to resolve this problem. > > most likely the udev property ID_INPUT and/or ID_INPUT_TOUCHSCREEN is > missing for this device, libinput debug-events --verbose should print > *something* at least for the device. > > If the property is missing though that means that it doesn't export the > correct evdev bits to be picked up by the udev builtin, so most likely the > kernel driver needs to be fixed. > > Cheers, > Peter > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Libinput-touch screen detection
On Tue, Oct 01, 2019 at 04:08:17PM +, sanjay anvekar wrote: > Hi All, I am new to Wayland. I am using Weston 1.9.0 on imx6x board with > touchscreen display of resolution 1024x768. I am seeing touchscreen as > /dev/input/event0 device and it is working. I confirmed functioning of > touchscreen using "cat /dev/input/event0" command. Unfortunately, I don't > see touchscreen is listed by libinput application i.e. > 'libinput-list-devices'. If I connect USB mouse then I see mouse is listed > by 'libinput-list-devices' application, but not touchscreen. I am running > Qt application and it is not able to detect touch inputs. Please let me > know your inputs to resolve this problem. most likely the udev property ID_INPUT and/or ID_INPUT_TOUCHSCREEN is missing for this device, libinput debug-events --verbose should print *something* at least for the device. If the property is missing though that means that it doesn't export the correct evdev bits to be picked up by the udev builtin, so most likely the kernel driver needs to be fixed. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput drops keys from infrared remotes after changing keymap
On Sun, Sep 29, 2019 at 08:17:38PM +0100, Sean Young wrote: > Hi, > > When using IR receivers using libinput, key events get dropped if a new > rc keymap is loaded and the key was not in the old keymap. > > The input device keybit changes and libevdev does not notice this. Then > here we end up returning false: > > https://gitlab.freedesktop.org/libinput/libinput/blob/master/src/libinput.c#L3100 > > The event is reported via evtest but not via libinput debug-events. basic problem here: evdev isn't really designed for run-time changes of devices, so both libevdev and libinput expect the device to be static. There's SYN_CONFIG which **may** be usable for this but it's unused in the kernel and thus nothing in userspace handles it either. A discussion years ago about defining SYN_CONFIG for devices that change at runtime was put into the too-hard basket, in most cases creating a new device is more sensible. > So, for example, mceusb IR devices register with a keymap for MCE remotes. > If later a keymap for a different remote is loaded, e.g.: > > $ ir-keytable -w /lib/udev/rc_keymaps/imon_rsc.toml > > If I press any button which does not exist in the MCE remote keymap > (for example space or backspace), libinput does not report these events. > > I've tried fixing this by making the kernel input device have all the keybit > fields set, but this had to be reverted since it overflowed the size of > uevents. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=05f0edadcc5fccdfc0676825b3e70e75dc0a8a84 > > If libinput receives an EV_KEY event which is unexpected, we could go > and check if the input device and see if keybit has added. yeah, well... none of the libinput clients would know how to handle this either, so libinput would have to emulate removal and plug-in of a new device. Which of course is doable but quite a bit of work to get right. > However in a diferent sense ir-keytable changed the input device underneath > libinput; another way to fix this to add support for loading IR keymaps > to libinput and all the way up the stack. I've been wanting to do this > anyway but I have no idea if there is any interest in this. > > Any thoughts on this would be appreciated! libinput relies on udev, either directly or through the X server. So if you trigger your device to get removed and re-added through udev, libinput will add it and re-initialize it with whatever current bits it has. sudo udevadm trigger --action=remove /sys/class/input/event5 sudo udevadm trigger --action=add /sys/class/input/event5 I think this is your best bet right now, but obviously the best approach would be to set up the keymap that it can get loaded as part of the udev rules loaded during initial device plug. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Set input device to the output
On Tue, Sep 24, 2019 at 12:47:09PM +, Yavuz Selim Mutlu wrote: > Hi there, > > Our board drives two different LVDS displays, and output names are seen as > LVDS-1 and LVDS-2. > When I run the weston the touchscreen events are associated with LVDS-1. > If I touch the LVDS-2 panel which has touchscreen, the LVDS-1 panel is > responsive. > > Weston debug: "associating input device event6 with output LVDS-1 (none by > udev)" > > How can I associate this input device with the LVDS-2 output? setting WL_OUTPUT=LVDS-2 as udev property on the input device should be all that's needed here. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v6 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
On Fri, Aug 03, 2018 at 07:12:29PM +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. > --- > Hello, > > this is the change I wanted to send previously (sorry). > > Regards, > Dorota Czaplejewicz > > Makefile.am| 1 + > unstable/virtual-keyboard/README | 2 + > .../virtual-keyboard-unstable-v1.xml | 114 > + > 3 files changed, 117 insertions(+) > create mode 100644 unstable/virtual-keyboard/README > create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..d67aa1b 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -20,6 +20,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/virtual-keyboard/virtual-keyboard-unstable-v1.xml \ > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > $(NULL) > > diff --git a/unstable/virtual-keyboard/README > b/unstable/virtual-keyboard/README > new file mode 100644 > index 000..a2c646d > --- /dev/null > +++ b/unstable/virtual-keyboard/README > @@ -0,0 +1,2 @@ > +Virtual keyboard protocol > + > diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > new file mode 100644 > index 000..9eae804 > --- /dev/null > +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > @@ -0,0 +1,114 @@ > + > + > + > +Copyright © 2008-2011 Kristian Høgsberg > +Copyright © 2010-2013 Intel Corporation > +Copyright © 2012-2013 Collabora, Ltd. > +Copyright © 2018 Purism SPC > + > +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 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > +DEALINGS IN THE SOFTWARE. > + > + > + > + > + The virtual keyboard provides an application with requests which > emulate > + the behaviour of a physical keyboard. > + > + This interface can be used by clients on its own to provide raw input > + events, or it can accompany the input method protocol. > + > + > + > + > +Provide a file descriptor to the compositor which can be > memory-mapped > +to provide a keyboard mapping description. I suspect this needs the MAP_PRIVATE comment from wayland.xml as well. And in general a comment about the life time of that fd (until destroy, but it's nice to spell this out). > + > + +summary="keymap format"/> > + > + > + > + > + > + > + > + > + > + > +A key was pressed or released. > + > +The time argument is a timestamp with millisecond granularity, with > an > +undefined base. All requests regarding a single object must share the > +same clock. > + > +Keymap must be set before issuing this request. ... or else what happens? :) > + > + +summary="timestamp with millisecon
[ANNOUNCE] libinput 1.14.1
libinput 1.14.1 is now available. This release fixes a commonly seen regression on 1.14.0 where a two-finger interaction (click + drag) was interpreted as scroll event instead of the intended action. The RollerMouse v3 now has debouncing disabled so the double-click button works. And we now have zsh completions for the libinput command. Many thanks to Kevin, Matt and Ronan for what is the first ever libinput release solely made up of patches from "external" contributors. Time to celebrate! Kevin Kaland (1): Fix double click button. Matt Mayfield (1): touchpad: don't allow gestures with a clickpad button down by a finger Peter Hutterer (1): libinput 1.14.1 Ronan Pigott (2): completion: add libinput(1) zsh completions tools: fix typo in debug-events git tag: 1.14.1 https://www.freedesktop.org/software/libinput/libinput-1.14.1.tar.xz MD5: da29a704dc6f7ea2d5aac754db046340 libinput-1.14.1.tar.xz SHA1: 116438b914342a0b45dcea1804aab751c9d335df libinput-1.14.1.tar.xz SHA256: e333a3242835c019ca37d2cef8b51a87d3138eb47444119c0153dc7a8656ee70 libinput-1.14.1.tar.xz SHA512: 8416bab51ba1aab924fa1b41360bc2ad101fb60d3a82c73584bb1e2454554524716673e3eac7f08c18bd6a1ecdfa52ea3cfe09c7a866c59fcd47d75960e82d4c libinput-1.14.1.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.14.1.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.14.0
libinput 1.14.0 is now available. A flurry of patches over the last RC but most of these were CI related. Two new significant bugfixes: the calibration matrix is now returned correctly even when it is the identity matrix. And the tablet pressure range is scaled correctly into the available physical range. Previously, the bottom 5% where effectively missing and pressure offset on worn-out pens handling took some of the scale away from the top. Below is the text from the 1.14.rc1 announcement which lists the other big features added since the 1.13 release. We have new and improved thumb detection for touchpads, thanks to Matt Mayfield. On Clickpad devices this should make interactions where a thumb is resting on the touchpad or dropped during an interaction more reliable. A summary of the changes can be found here: https://who-t.blogspot.com/2019/07/libinputs-new-thumb-detection-code.html The Dell Canvas Totem is now supported by libinput. It is exposed as a new tool type through the tablet interface along with two new axes. Note that this is only low-level support, the actual integration of the totem needs Wayland protocol changes and significant changes in all applications that want to make use of it. A summary of the changes can be found here. https://who-t.blogspot.com/2019/06/libinput-and-dell-canvas-totem.html Touch-capable tablets now tie both devices together for rotation. If you set the tablet to left-handed, the touchpad will be rotated along with the tablet. Note that this does not affect the left-handed-ness of the touchpad, merely the rotation. Tablet proximity out handling for tablets that are unreliably sending proximity out events is now always timeout-based. It is no longer necessary to add per-device quirks to enable this feature and it is completely transparent on devices that work correctly anyway. The blog post below has a summary: https://who-t.blogspot.com/2019/06/libinput-and-tablet-proximity-handling.html Tablets that send duplicate tools (BTN_TOOL_PEN and BTN_TOOL_ERASER) now ignore the latter. This is an intermediate fix only but at least makes those tablets more usable than they are now. Issue #259 is the tracker for this particular behaviour if you are affected by it. The handling of kernel fuzz has been slightly improved. Where our udev rule fails to reset the fuzz on the kernel device, we disable the hysteresis and rely on the kernel now to handle it. Previously our hysteresis would take effect on top of the kernel's, causing nonresponsive behaviour. Note to distribitors: the python-evdev dependency has been dropped, the tools that used it are now using python-libevdev instead. As usual, the git shortlog is below. Benjamin Tissoires (3): gitlab-ci: allow to run on unprivileged containers gitlab-ci: force using docker format for the generated images tests: increase the timeout for the subprocess to receive the quit signal Brian Ashworth (1): evdev: always store user calibration matrix Peter Hutterer (14): tools: record: fix segfault on exit tools: record: fix two memory leaks meson.build: drop explicit install:true from configure_file gitlab CI: replace the user:password with a netrc file gitlab CI: fetch the WAYLAND_WEB_TOKEN from a file tablet: point the pressure offset log messages to the right URL tablet: add a comment explaining why we adjust the pressure offset downwards Add the ck_double_eq_tol() macros to the backwards compat headers test: fix the pressure offset tests tablet: make the pressure-offset inclusive of the axis minimum tablet: reduce the pressure range by the offset test: don't test at the 100 y range tablet: scale the available pressure range into the pressure thresholds libinput 1.14.0 git tag: 1.14.0 https://www.freedesktop.org/software/libinput/libinput-1.14.0.tar.xz MD5: 1c33d49fc7985926eab877e3de9c17eb libinput-1.14.0.tar.xz SHA1: 3a8f1ea7ba8a23868b2a7d48286924547ba6d108 libinput-1.14.0.tar.xz SHA256: 7cb85c24f8920b81bc5360220107e267ab4e0e718704c7690a8c7b03fa14fc67 libinput-1.14.0.tar.xz SHA512: e501c5b8a58bb287c175692af0e59ff766a8613eb576aaa0700686dfbb6c6ab63b7a5d3f148fce75397c8170bc49871068861d93c352355ab5d0d9e7f1b059ec libinput-1.14.0.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.14.0.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.13.902
libinput 1.14rc2 is now available. There weren't a lot of changes here, so unless something significant comes up, next will will be the time for 1.14. Better start getting that champagne in the fridge now. In this RC we have a fix for the Latitude 5580 trackpoint and more consistent assignment for the device group on the Wacom ExpressKey Remote, and a few minor tidy-ups. As usual, see the git shortlog for details. Jacob Moroni (1): Introduce Dell Latitude 5580 trackpoint multiplier Jason Gerecke (1): udev: Reproduce entire LIBINPUT_DEVICE_GROUP for paired ExpressKey Remote Peter Hutterer (5): tools: skip the event tests for eventless recordings in the YAML verifier tools: handle arguments correctly for the YAML verifier tool tools: record: when running from the builddir, load the quirks correctly test: mix tablet events into touch arbitration tests libinput 1.13.902 git tag: 1.13.902 https://www.freedesktop.org/software/libinput/libinput-1.13.902.tar.xz MD5: e42696c0f790a178a032b2d02aff37bf libinput-1.13.902.tar.xz SHA1: 577d0ec5b4536529bec25aa0e806d8aab93f3629 libinput-1.13.902.tar.xz SHA256: 04f7dff1fb4d71992b7579d9dfcf4abddc0f206ded159ddc84ba48c2ec570454 libinput-1.13.902.tar.xz SHA512: d661f90d49ee0b39c87b962f02968f9b6642f1b3dd141c3fa07d40bd4b170e4ba4163d294d66721317972a7a30b589109639829b48c70070004337580c0a2e36 libinput-1.13.902.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.13.902.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.13.901
The first RC for libinput 1.14 is now available. We have new and improved thumb detection for touchpads, thanks to Matt Mayfield. On Clickpad devices this should make interactions where a thumb is resting on the touchpad or dropped during an interaction more reliable. A summary of the changes can be found here: https://who-t.blogspot.com/2019/07/libinputs-new-thumb-detection-code.html The Dell Canvas Totem is now supported by libinput. It is exposed as a new tool type through the tablet interface along with two new axes. Note that this is only low-level support, the actual integration of the totem needs Wayland protocol changes and significant changes in all applications that want to make use of it. A summary of the changes can be found here: https://who-t.blogspot.com/2019/06/libinput-and-dell-canvas-totem.html Touch-capable tablets now tie both devices together for rotation. If you set the tablet to left-handed, the touchpad will be rotated along with the tablet. Note that this does not affect the left-handed-ness of the touchpad, merely the rotation. Tablet proximity out handling for tablets that are unreliably sending proximity out events is now always timeout-based. It is no longer necessary to add per-device quirks to enable this feature and it is completely transparent on devices that work correctly anyway. A summar of the changes can be found here: https://who-t.blogspot.com/2019/06/libinput-and-tablet-proximity-handling.html Tablets that send duplicate tools (BTN_TOOL_PEN and BTN_TOOL_ERASER) now ignore the latter. This is an intermediate fix only but at least makes those tablets more usable than they are now. Issue #259 is the tracker for this particular behaviour if you are affected by it. The handling of kernel fuzz has been slightly improved. Where our udev rule fails to reset the fuzz on the kernel device, we disable the hysteresis and rely on the kernel now to handle it. Previously our hysteresis would take effect on top of the kernel's, causing nonresponsive behaviour. Note to distribitors: the python-evdev dependency has been dropped, the tools that used it are now using python-libevdev instead. And of course a random assortment of fixes, improvements, etc. Many thanks to all contributors and testers. As usual, the git shortlog is below. Alex Flowers (1): quirks: add a quirk for the Lenovo X1 Yoga 1st gen Benjamin Tissoires (8): CI: remove the bootstrapping stage CI: heavily rework the container creation CI: clean up all but the correct tag CI: use the template for fedora CI: use templates for Arch CI: use templates for Ubuntu CI: do not rebuild the image for regular MR or pushes CI: simplify the logic for rebuilding the containers Ian Douglas Scott (1): Enable ModelTabletNoProximityOut quirk on HP Spectre 13-ap0xxx Jason Gerecke (3): fallback: Fix ubsan runtime error test: Clean up memory leaks test: abort when no default value is available for an axis Lubomir Rintel (1): quirks: speed up the TrackPoint on the IBM USB UltraNav keyboard a bit Matt Mayfield (7): touchpad: basic thumb detection within gestures gestures: improve scroll responsiveness for vertically aligned touches gestures: improvements to pinch detection gestures: Improve thumb detection, allow one finger scroll touchpad: revamp thumb detection touchpad: don't detect speed-based thumbs if there's already a thumb touchpad: stricter thumb detection if no pressure/size Michael Forney (6): Remove semicolons after function definitions Avoid unnecessary VLAs Avoid case ranges in switch statement Use bitwise test instead of __builtin_popcount Don't return expression in function returning void Replace one more __builtin_popcount with bitwise test Peter Hutterer (152): meson.build: add the toshiba quirks file to the file list quirks: add a test to make sure all our quirks files are listed in meson tools: record: increase value size to 6 digits tools: switch measure-fuzz to use python-libevdev tools: switch measure-touch-size to python-libevdev tools: switch measure-touchpad-pressure to python-libevdev tools: switch measure-touchpad-tap to python-libevdev meson.build: bump to 1.13.900 test: drop some unnecessary extern declarations doc/api: add since tags to all functions after 1.0 doc/api: minor style changes tablet: move the current tool bits into a substruct tablet: log a bug when a tablet switches between tools directly tablet: always enable the proximity out quirk tablet: add missing linebreak after error message tablet: fix some code alignment tools: use American spelling for 'unrecognized' tools: fix waiting for the tool to quit in the options test test: actually filter events when writing to udev test: filter BTN_TOOL_PEN correctly
[ANNOUNCE] libinput 1.13.4
libinput 1.13.4 is now available. This release fixes a regression introduced in 1.13.3, a wrong udev check caused the fuzz to be left as-is. As a result we ended up with some touchpads having the fuzz applied twice (kernel and libinput), resulting in non-responsive/imprecise behaviour. Since this got past the test suite and fixing that is more involved, here's a release with the revert only in the meantime. Peter Hutterer (2): Revert "udev: only change the fuzz on touchpads and touchscreens" libinput 1.13.4 git tag: 1.13.4 https://www.freedesktop.org/software/libinput/libinput-1.13.4.tar.xz MD5: 9ef817774bb5b4006cba95e34103e82c libinput-1.13.4.tar.xz SHA1: 14d7a14643d41c2e7512a7b3a6c0c9a3e7ba3242 libinput-1.13.4.tar.xz SHA256: d3eb57c714683b117aae29f6c0be76dd46de259f0a48f20cb43b9fa9f2e1401d libinput-1.13.4.tar.xz SHA512: ccfdfc704dab9ea19a503399ecd4ce3a95b8d9480b8dfddeb80be01236c34c6f2f472be0e12e0468092611470d303351e092141bc7491729639bcf7e64d7 libinput-1.13.4.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.13.4.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.13.3
libinput 1.13.3 is now available. Nothing too exciting, a few quirks for devices and a change in the udev callout so we don't change the kernel fuzz on devices we don't even handle. Alex Flowers (1): quirks: add a quirk for the Lenovo X1 Yoga 1st gen Peter Hutterer (6): quirks: handle ID_INPUT_KEY as udev keyboard match quirks: add trackpoint integration attribute doc/api: more CSS styling udev: only change the fuzz on touchpads and touchscreens doc: note that libinput measure is a separate package libinput 1.13.3 René Genz (1): doc/user: fix some typos Zach Moazeni (1): Better Thinkpad T480 trackpoint multiplier timrichardson (1): X230 trackpoint quirk git tag: 1.13.3 https://www.freedesktop.org/software/libinput/libinput-1.13.3.tar.xz MD5: 0205d720ae0b1caef1faeb4bba7f8c0f libinput-1.13.3.tar.xz SHA1: ea80070c087363415a4259ddc4bf828e18205195 libinput-1.13.3.tar.xz SHA256: f3ff113023a28631d83971c059c1f3057d51a90aa3746428776f3b3462131092 libinput-1.13.3.tar.xz SHA512: 427ec838975444571770e129ef78fd42e4438a11e89ed0b3fc98793184d00c0ca8ed282eab2045cc6cb345804ad6fce1061af563b4f41d75405cdf2f09cb01e1 libinput-1.13.3.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.13.3.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.13.2
libinput 1.13.2 is now available. Apple Bluetooth touchpads are now recognized with the correct touch size, which should make finger detection more reliable. External tablets with a touchpad component (e.g. Wacom Intuos Pro series) will now rotate the touchpad by 180 degrees when set to left-handed. Previously only the tablet pen rotated, leaving pen and touch with two different orientations. Note that users need to set both the tablet and the touchpad to left-handed to have this work correctly; a better fix is in the works but taking longer than anticipated. The button scroll timeout reduction introduced in 1.13 is reverted again, it caused a few regressions. If you had issues with your middle button, that's likely going to fix it. As usual, the git shortlog is below. Jason Gerecke (1): fallback: Fix ubsan runtime error Peter Hutterer (8): tools: use American spelling for 'unrecognized' test: use identifiable shortnames for the Intuos5 devices touchpad: rotate the touch part of tablets test: update valgrind suppressions for a glib leak Revert "Reduce button scroll timeout to 38ms" test: fix a bunch of tests expecting BTN_TOOL_TRIPLETAP test: fix the wacom bamboo touch device libinput 1.13.2 Sebastian Krzyszkowiak (3): quirks: add a new Apple vendor ID for Bluetooth devices evdev-mt-touchpad-buttons: use a model quirk instead of vendor ID to identify Apple devices CI: update arch package list git tag: 1.13.2 https://www.freedesktop.org/software/libinput/libinput-1.13.2.tar.xz MD5: 8b745894f5d1b2e883bfc686aebadcfe libinput-1.13.2.tar.xz SHA1: 7e9d1bb3f5d4f8809c829753791141416a67ab1f libinput-1.13.2.tar.xz SHA256: 1d9fa0698348dea46f75321d98788f8ac7181c069b70c4d10736910a12bb6a6d libinput-1.13.2.tar.xz SHA512: 26f11c5274c26acc38b9b5729195010c0799a9563f1eb0e0cd67e323f8ed73b0fc8db8584ec8fdf1b726417f64c2daeb54832167079832626c8c1190fccf459f libinput-1.13.2.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.13.2.tar.xz.sig ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libinput 1.13.1
libinput 1.13.1 is now available. Half of the commits are related to the gitlab CI and don't affect the actual library. Other than that, we have a quirk for a HP Spectre 13 tablet, the trackpoint in the IBM USB UltraNav keyboard and the Toshiba Satellite L855-14E Touchpad (by actually shipping that quirks file). So overall, not too excting unless you own one of those devices above. Benjamin Tissoires (8): CI: remove the bootstrapping stage CI: heavily rework the container creation CI: clean up all but the correct tag CI: use the template for fedora CI: use templates for Arch CI: use templates for Ubuntu CI: do not rebuild the image for regular MR or pushes CI: simplify the logic for rebuilding the containers Ian Douglas Scott (1): Enable ModelTabletNoProximityOut quirk on HP Spectre 13-ap0xxx Lubomir Rintel (1): quirks: speed up the TrackPoint on the IBM USB UltraNav keyboard a bit Peter Hutterer (6): meson.build: add the toshiba quirks file to the file list quirks: add a test to make sure all our quirks files are listed in meson tools: record: increase value size to 6 digits doc/api: add since tags to all functions after 1.0 doc/api: minor style changes libinput 1.13.1 Tobias Stoeckmann (1): Removed whitespace from filename. git tag: 1.13.1 https://www.freedesktop.org/software/libinput/libinput-1.13.1.tar.xz MD5: 869a7e68c4290d99868500a369645def libinput-1.13.1.tar.xz SHA1: a0338e5f2ff2cecbb88f91e5bf363f9b66770be2 libinput-1.13.1.tar.xz SHA256: e1d487d478ee2bb118890a64211c2b7f2348aaed7363b214bed4d642274841ab libinput-1.13.1.tar.xz SHA512: a19deec802e704038df0901c103a82a3370f56e0299f4cc1b6aa84c1832a66fb638e6f9d0fa708b51df6c3b939cdc1271e4ff547c645c566be03dce0bc9ff7e0 libinput-1.13.1.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.13.1.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC: Wayland high-resolution wheel scrolling
On 6/4/19 02:11 , Simon Ser wrote: On Wednesday, April 3, 2019 5:36 AM, Peter Hutterer wrote: I've been trying to sort out the new hi-res wheel scrolling that was added to linux 5.0 but it's been a bit of a struggle to say the least. For the impatient, skip forward to the protocol diff but the background info is important. Thanks for taking the time to write this big summary. It's pretty helpful! Everything below applies equally to horizontal and vertical scrolling, both directions and wheels and wheel tilts. The APIs that are involved for low-resolution wheel scrolling: kernel: - REL_WHEEL for every wheel click libinput uses pointer axis events for wheels: - pointer axis value: the movement of the wheel in degrees - pointer axis discrete value: the number of wheel clicks - pointer axis source: set to 'wheel' Usally this means you get discrete 1, value 15 for the standard 15-degree mouse wheel, discrete 2 value 30 is two wheel clicks within one hw frame. There is one implicit assumption here: the discrete value must be 1 or more for every event. Otherwise it's impossible to use the value and calculate the angle. More on that later. This API is effectively the same in the wayland protocol except for the unit of the 'value' which is is in screen coordinates, not degrees. wayland protocol: - pointer axis value: the movement in screen coordinates - pointer axis discrete: the number of wheel clicks - pointer axis source: set to 'wheel' The big difference here though: libinput's API is per-device, wayland's API is per wl-seat pointer. There's no way to tell in the protocol that you're scrolling simultaneously with wheels on two different mice. Let's see how the common compositors implement this: weston: - for source wheel, only the discrete value is handled and: - pointer axis discrete is sent as-is from libinput - pointer axis source is sent as-is from libinput - pointer axis value is always (discrete * 10) - otherwise the libinput pointer value (degrees) from a source wheel is ignored The magic multiplier 10 is afaik for historical reasons, weston used to do 10 so early libinput took that. When libinput switched to use physical dimensions instead of 10, that value was kept for backwards compatibility with existing wayland clients. mutter: - for source wheel, only the discrete value is handled and: - clutter-internal event for the discrete **direction** from libinput - i.e. discrete > 1 will still only generate one event,some events drop to the floor here for fast wheel movements - clutter-internal event with (value * 10) marked as 'emulated' but that event is ignored later when we're writing to the protocol - the discrete event is written as wl_pointer.axis_discrete and wl_pointer.axis with a value of 10 So, the same multiplier of 10 but fast scroll events with more than one click per frame appear to get dropped. kwin (through qtwayland): - doesn't handle discrete at all afaict - pointer axis events are passed through but I got a bit confused over the actual value written on the wire here. wlroots: - pointer axis discrete is sent as-is from libinput - pointer axis source is sent as-is from libinput - pointer axis value is sent as-is from libinput Because the physical angle is passed on from libinput as screen coordinates, this means wlroots has different scroll behaviour to GNOME/sway and it does scroll a larger distance for wheels with higher click angles. This is the opposite of the intended behaviour, manufacturers advertise these wheels as slow-scrolling wheels. Realistically though the physical movements is the same-ish and if a client uses discrete it doesn't matter anyway. Hmm, that's interesting. We wlroots devs have had assumed you'd want a given angle to always scroll the same amount of pixels. But this doesn't matter that much because we have a configuration option for the scroll multiplier anyway. We still should have good defaults of course. first, apologies if i got some of the details wrong, I hope the overall summary is still correct enough :) the thing with the angle in this case is that you cannot really decide that angle. The wheel forces you to whatever it's built as and that's it (more recent high-res wheels excepted). Even the earlier free-floating wheels still only send events every X degrees. Users (and manufacturers) thus don't think as angles as much as wheel clicks. A 20 deg wheel feels slower than the standard 15 deg wheel simply because you have to scroll more to get one click. And that's what's advertised too. The angle == pixels mapping makes sense for a continuous axis, I'm not sure it's as useful for the wheel as we have them. Then again, it's relatively niche and only a small subset of users notice and/or care about this particular issue. xf86-input-libinput: - X devices need to set up a scroll distance for scroll motion, the driver uses 120 (since Feb, before it was 15). This means any multiple of 12
RFC: Wayland high-resolution wheel scrolling
I've been trying to sort out the new hi-res wheel scrolling that was added to linux 5.0 but it's been a bit of a struggle to say the least. For the impatient, skip forward to the protocol diff but the background info is important. Everything below applies equally to horizontal and vertical scrolling, both directions and wheels and wheel tilts. The APIs that are involved for low-resolution wheel scrolling: kernel: - REL_WHEEL for every wheel click libinput uses pointer axis events for wheels: - pointer axis value: the movement of the wheel in degrees - pointer axis discrete value: the number of wheel clicks - pointer axis source: set to 'wheel' Usally this means you get discrete 1, value 15 for the standard 15-degree mouse wheel, discrete 2 value 30 is two wheel clicks within one hw frame. There is one implicit assumption here: the discrete value must be 1 or more for every event. Otherwise it's impossible to use the value and calculate the angle. More on that later. This API is effectively the same in the wayland protocol except for the unit of the 'value' which is is in screen coordinates, not degrees. wayland protocol: - pointer axis value: the movement in screen coordinates - pointer axis discrete: the number of wheel clicks - pointer axis source: set to 'wheel' The big difference here though: libinput's API is per-device, wayland's API is per wl-seat pointer. There's no way to tell in the protocol that you're scrolling simultaneously with wheels on two different mice. Let's see how the common compositors implement this: weston: - for source wheel, only the discrete value is handled and: - pointer axis discrete is sent as-is from libinput - pointer axis source is sent as-is from libinput - pointer axis value is always (discrete * 10) - otherwise the libinput pointer value (degrees) from a source wheel is ignored The magic multiplier 10 is afaik for historical reasons, weston used to do 10 so early libinput took that. When libinput switched to use physical dimensions instead of 10, that value was kept for backwards compatibility with existing wayland clients. mutter: - for source wheel, only the discrete value is handled and: - clutter-internal event for the discrete **direction** from libinput - i.e. discrete > 1 will still only generate one event,some events drop to the floor here for fast wheel movements - clutter-internal event with (value * 10) marked as 'emulated' but that event is ignored later when we're writing to the protocol - the discrete event is written as wl_pointer.axis_discrete and wl_pointer.axis with a value of 10 So, the same multiplier of 10 but fast scroll events with more than one click per frame appear to get dropped. kwin (through qtwayland): - doesn't handle discrete at all afaict - pointer axis events are passed through but I got a bit confused over the actual value written on the wire here. wlroots: - pointer axis discrete is sent as-is from libinput - pointer axis source is sent as-is from libinput - pointer axis value is sent as-is from libinput Because the physical angle is passed on from libinput as screen coordinates, this means wlroots has different scroll behaviour to GNOME/sway and it does scroll a larger distance for wheels with higher click angles. This is the opposite of the intended behaviour, manufacturers advertise these wheels as slow-scrolling wheels. Realistically though the physical movements is the same-ish and if a client uses discrete it doesn't matter anyway. xf86-input-libinput: - X devices need to set up a scroll distance for scroll motion, the driver uses 120 (since Feb, before it was 15). This means any multiple of 120.0 triggers legacy button emulation in the server, otherwise the number has no meaning. - for source wheel it uses the discrete value only, so effectively 120 * discrete. This driver had a division by 0 for discrete values of 0, fixed in the current release. More on this later. Let's look at how wheel events are processed in some of the clients: GTK: - for a discrete event, GDK_SCROLL_UP is passed on flagged as 'emulated' - the axis value is passed on as GDK_SCROLL_SMOOTH Qt: - doesn't handle discrete - multiplies the value by -12. This gives it a 120-based value which matches the Windows API provided the axis value is 10 of course. Qt on wlroots is probably off here. Xwayland: - X devices need to set up a scroll distance for scroll motion, Xwayland currently uses 1.0 for that. This means any multiple of 1.0 triggers legacy button emulation in the server. - wl_pointer.axis_discrete are used where available - wl_pointer.axis uses the value * 0.1. This effectively means Xwayland relies on the deltas to be 10 like in mutter/weston, X clients under wlroots will have off wheel click emulation. With me so far? Hooray, now let's introduce hi-res scrolling. All the examples below are for a quarter scroll wheel movement, i.e. you get 4 hi-res events for every 1 lo-res event. The kernel
[ANNOUNCE] libinput 1.13.0
libinput 1.13.0 is now available. A few remaining cleanups, primarily in the test suite. The API docs should be a bit more readable now thanks to some CSS changes. Other than that, nothing exciting. So let's copy-paste the RC1 announcements here: Only two notable features in this release but patches are accumulating on master, it's been 6 months since 1.12 and I've decided to postpone the two major features (hi-res scrolling and totem support) to 1.14. Touch arbitration has improved for tablets, especially on touch screens. A timer set on pen proximity out means we don't get ghost touches anymore when the hand lifts off slower than the pen itself. And location-based touch arbitration means that parts of the screen can be interacted with even while the pen is in proximity. libinput uses the tilt information where available to disable touches in a rectangle around the pen where the hand is likely to be but leaves the rest of the touchscreen available otherwise. Where the UI supports it, this allows for bimanual interaction. The test suite is installed on demand (meson -Dinstall-tests=true). Where run from the installed location it will use the normal library lookups and the quirks directory as defined by the prefix. This makes it useful for distribution-level testing, i.e. run this on a test machine after updating the package to make sure everything is as expected. Where available, you can invoke it with the "libinput test-suite" command. One user-visible change: multitap (doubletap or more) now resets the timer on release as well. This should improve tripletap detection as well as any tripletap-and-drag and similar gestures. valgrind is no longer a required dependency to build with tests. It was only used in a specific test run anyway (meson test --setup=valgrind) and not part of the regular build. Other than that, a load of fixes, quirks added, cleanups, tidy-ups and so on an so forth. As usual, the git shortlog is below. Many thanks to all the contributors. Konstantin Kharlamov (2): evdev: fix "always false" comparison evdev: remove unnecessary comparison Peter Hutterer (11): test: don't install our normal rules file in installed mode test: drop remnants of the test device udev rules test: let the device custom create method return a bool test: switch the protocol A test device to be an actual protocol A device test: mark the protocol A device as touch device Fix three coverity complaints doc/api: improve readability of the API docs tools: fix the tool option parse test to handle unittest arguments test: fix tool option parsing tests for signals test: add another valgrind suppression for Python libinput 1.13.0 git tag: 1.13.0 https://www.freedesktop.org/software/libinput/libinput-1.13.0.tar.xz MD5: ea0834452b03457f8a33359db3eabfbf libinput-1.13.0.tar.xz SHA1: eed489534c28d5dac6c12dc659b0e8b104ed libinput-1.13.0.tar.xz SHA256: eb27c95d35c8fc9c7b96b9f0b2de5a043c47eb5f4b2868f353ab1bd0be0b616d libinput-1.13.0.tar.xz SHA512: 0e3f53acf90fe142ad677b416d1ee830ad7f7f8a83b80023278ea7d3696ff7af5612379b387b1eb5daae6277a8c30d84c21f0086fe3d8b4b6189f239b1eeb4f8 libinput-1.13.0.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.13.0.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
