[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: wayland-protocols scope and governance
Hi, I've been following along on this thread, and I really appreciate that you've reached out to me. The current document seems reasonable to me. It will be a positive for the ecosystem to have a clearly-defined method of proposing and stabilizing new protocols for adoption. I'm not quite as active in the Wayland space as I have been historically, but EFL/Enlightenment does have interest in joining this community and I'm still probably the best point of contact at this time. Regards, Mike PS. The email address you used for Derek is no longer active (it hasn't been for years) and you should likely check with him on IRC for a more up-to-date address and/or interest. On Wed, Oct 16, 2019 at 5:17 AM Simon Ser wrote: > [Cc'ing more people] > > > > Points of contact I had in mind: > > > > > > - KWin: Roman Gilg > > > - Mutter: Jonas Ådahl > > > - Weston: Pekka Paalanen , > > > Daniel Stone > > > - wlroots: Drew DeVault , Simon Ser < > cont...@emersion.fr> > > > > > > I think it would make sense to include this initial list in a MEMBERS > > > file in the upcoming wayland-protocols patch series that adds this > > > governance document. > > > > > > Thoughts? > > > > Sounds good to me! > > > > Prodding toolkit projects for people would be good, and also > > Enlightenment. > > Hi all, > > We've been discussing for a while about wayland-protocols governance. You > can > find the latest proposal at [1]. > > We're discussing about the initial list of members. Would Enlightenment, > Qt and > GTK be interested in being initial members as well? > > Feedback is welcome. Thanks, > > [1]: > https://lists.freedesktop.org/archives/wayland-devel/2019-October/040919.html > > Simon > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
On Wed, 16 Oct 2019 10:54:08 +0200 Olivier Fourdan wrote: > Hey Carlos, > > On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho wrote: > > > > This protocol takes over 3 different, but interrelated aspects of > > DE/client interaction: > > - Startup notification: presenting feedback about applications > > being launched, either through the compositor or another client > > - Focus stealing prevention: letting the compositor figure out > > whether immediately switching focus to a surface makes sense. > > - Window raising/activation: allowing existing clients to request > > focus in a controlled manner. > > > > Signed-off-by: Carlos Garnacho Hi Carlos, this seems well written and a good idea to me. More comments inline. > > --- > > Makefile.am | 1 + > > unstable/presentation/README | 5 + > > .../presentation/presentation-unstable-v1.xml | 175 ++ > > 3 files changed, 181 insertions(+) > > create mode 100644 unstable/presentation/README > > create mode 100644 unstable/presentation/presentation-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index d2c89a8..bd0e52d 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -24,6 +24,7 @@ unstable_protocols = > > \ > > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > > > unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > > \ > > unstable/primary-selection/primary-selection-unstable-v1.xml > > \ > > + unstable/presentation/presentation-unstable-v1.xml > > \ > > $(NULL) > > > > stable_protocols = > > \ > > diff --git a/unstable/presentation/README b/unstable/presentation/README > > new file mode 100644 > > index 000..5a77e97 > > --- /dev/null > > +++ b/unstable/presentation/README > > @@ -0,0 +1,5 @@ > > +Presentation protocol > > + > > +Maintainers: > > +Carlos Garnacho > > + > > diff --git a/unstable/presentation/presentation-unstable-v1.xml > > b/unstable/presentation/presentation-unstable-v1.xml > > new file mode 100644 > > index 000..84bf961 > > --- /dev/null > > +++ b/unstable/presentation/presentation-unstable-v1.xml > > @@ -0,0 +1,175 @@ > > + > > + > > + > > +Copyright 2018-2019 © Red Hat, Inc. > > + > > +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. > > + > > + > > + > > +This description provides a high-level overview of the interplay > > between > > +the interfaces defined this protocol. For details, see the protocol > > +specification. This is the protocol specification, the whole file. > > + > > +The finality of the protocol is defining a compositor context for > > +surfaces requesting to be presented. Presentation requests are usually > > +initiated by an existing surface, and acknowledged by a surface being > > +mapped. By having both ends talk with the compositor through this > > protocol, > > +the compositor has the information to implement different commonplace > > +policies: > > + > > +- Startup notification: The compositor may track wp_presenter > > interfaces > > + being created from the launcher side, and replied upon on the > > launchee > > + side. Compositors may also perform the application launcher role > > + themselves. Ok, I see that. > > + > > +- Focus stealing prevention: The compositor may know whether there is > > + recent user input that happened after the presentation request, and > > + ensure no disruptions happen. This might need elaboration on how this is supposed to work. > > + > > +- Window raising/activation: The presented
Re: wayland-protocols scope and governance
[Cc'ing more people] > > Points of contact I had in mind: > > > > - KWin: Roman Gilg > > - Mutter: Jonas Ådahl > > - Weston: Pekka Paalanen , > > Daniel Stone > > - wlroots: Drew DeVault , Simon Ser > > > > I think it would make sense to include this initial list in a MEMBERS > > file in the upcoming wayland-protocols patch series that adds this > > governance document. > > > > Thoughts? > > Sounds good to me! > > Prodding toolkit projects for people would be good, and also > Enlightenment. Hi all, We've been discussing for a while about wayland-protocols governance. You can find the latest proposal at [1]. We're discussing about the initial list of members. Would Enlightenment, Qt and GTK be interested in being initial members as well? Feedback is welcome. Thanks, [1]: https://lists.freedesktop.org/archives/wayland-devel/2019-October/040919.html Simon ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
On Wed, 16 Oct 2019 10:43:00 +0200 Carlos Garnacho wrote: > This protocol takes over 3 different, but interrelated aspects of > DE/client interaction: > - Startup notification: presenting feedback about applications > being launched, either through the compositor or another client > - Focus stealing prevention: letting the compositor figure out > whether immediately switching focus to a surface makes sense. > - Window raising/activation: allowing existing clients to request > focus in a controlled manner. > > Signed-off-by: Carlos Garnacho > --- > Makefile.am | 1 + > unstable/presentation/README | 5 + > .../presentation/presentation-unstable-v1.xml | 175 ++ > 3 files changed, 181 insertions(+) > create mode 100644 unstable/presentation/README > create mode 100644 unstable/presentation/presentation-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index d2c89a8..bd0e52d 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -24,6 +24,7 @@ unstable_protocols = > \ > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > \ > unstable/primary-selection/primary-selection-unstable-v1.xml > \ > + unstable/presentation/presentation-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/presentation/README b/unstable/presentation/README > new file mode 100644 > index 000..5a77e97 > --- /dev/null > +++ b/unstable/presentation/README > @@ -0,0 +1,5 @@ > +Presentation protocol > + > +Maintainers: > +Carlos Garnacho > + > diff --git a/unstable/presentation/presentation-unstable-v1.xml > b/unstable/presentation/presentation-unstable-v1.xml > new file mode 100644 > index 000..84bf961 > --- /dev/null > +++ b/unstable/presentation/presentation-unstable-v1.xml > @@ -0,0 +1,175 @@ > + > + > + > +Copyright 2018-2019 © Red Hat, Inc. > + > +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. > + > + > + > +This description provides a high-level overview of the interplay between > +the interfaces defined this protocol. For details, see the protocol > +specification. > + > +The finality of the protocol is defining a compositor context for > +surfaces requesting to be presented. Presentation requests are usually > +initiated by an existing surface, and acknowledged by a surface being > +mapped. By having both ends talk with the compositor through this > protocol, > +the compositor has the information to implement different commonplace > +policies: Why does a presentation request have to come from a surface? I would expect that, similarly to creating a surface, presenting it would not require anything but a client (and maybe even no specific client) at least in the case of startup notification. > + > +- Startup notification: The compositor may track wp_presenter interfaces > + being created from the launcher side, and replied upon on the launchee > + side. Compositors may also perform the application launcher role > + themselves. > + > +- Focus stealing prevention: The compositor may know whether there is > + recent user input that happened after the presentation request, and > + ensure no disruptions happen. > + > +- Window raising/activation: The presented surface may be another > previously > + existing one, which might require bringing it to focus. "may be another" - is there a word like "related to" missing? > + > +A client that wishes to present another surface (of its own or from > another > +client)
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
Hey Carlos, On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho wrote: > > This protocol takes over 3 different, but interrelated aspects of > DE/client interaction: > - Startup notification: presenting feedback about applications > being launched, either through the compositor or another client > - Focus stealing prevention: letting the compositor figure out > whether immediately switching focus to a surface makes sense. > - Window raising/activation: allowing existing clients to request > focus in a controlled manner. > > Signed-off-by: Carlos Garnacho > --- > Makefile.am | 1 + > unstable/presentation/README | 5 + > .../presentation/presentation-unstable-v1.xml | 175 ++ > 3 files changed, 181 insertions(+) > create mode 100644 unstable/presentation/README > create mode 100644 unstable/presentation/presentation-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index d2c89a8..bd0e52d 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -24,6 +24,7 @@ unstable_protocols = > \ > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > \ > unstable/primary-selection/primary-selection-unstable-v1.xml > \ > + unstable/presentation/presentation-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/presentation/README b/unstable/presentation/README > new file mode 100644 > index 000..5a77e97 > --- /dev/null > +++ b/unstable/presentation/README > @@ -0,0 +1,5 @@ > +Presentation protocol > + > +Maintainers: > +Carlos Garnacho > + > diff --git a/unstable/presentation/presentation-unstable-v1.xml > b/unstable/presentation/presentation-unstable-v1.xml > new file mode 100644 > index 000..84bf961 > --- /dev/null > +++ b/unstable/presentation/presentation-unstable-v1.xml > @@ -0,0 +1,175 @@ > + > + > + > +Copyright 2018-2019 © Red Hat, Inc. > + > +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. > + > + > + > +This description provides a high-level overview of the interplay between > +the interfaces defined this protocol. For details, see the protocol > +specification. > + > +The finality of the protocol is defining a compositor context for > +surfaces requesting to be presented. Presentation requests are usually > +initiated by an existing surface, and acknowledged by a surface being > +mapped. By having both ends talk with the compositor through this > protocol, > +the compositor has the information to implement different commonplace > +policies: > + > +- Startup notification: The compositor may track wp_presenter interfaces > + being created from the launcher side, and replied upon on the launchee > + side. Compositors may also perform the application launcher role > + themselves. > + > +- Focus stealing prevention: The compositor may know whether there is > + recent user input that happened after the presentation request, and > + ensure no disruptions happen. > + > +- Window raising/activation: The presented surface may be another > previously > + existing one, which might require bringing it to focus. > + > +A client that wishes to present another surface (of its own or from > another > +client) will call wp_presentation_manager.create_presenter to create a > +presentation request. Compositors may use this object to track the > source of > +the request in order to apply its policies when mapping the surface or > +bringing an existing one to focus. > + > +In the presented surface
[RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
This protocol takes over 3 different, but interrelated aspects of DE/client interaction: - Startup notification: presenting feedback about applications being launched, either through the compositor or another client - Focus stealing prevention: letting the compositor figure out whether immediately switching focus to a surface makes sense. - Window raising/activation: allowing existing clients to request focus in a controlled manner. Signed-off-by: Carlos Garnacho --- Makefile.am | 1 + unstable/presentation/README | 5 + .../presentation/presentation-unstable-v1.xml | 175 ++ 3 files changed, 181 insertions(+) create mode 100644 unstable/presentation/README create mode 100644 unstable/presentation/presentation-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index d2c89a8..bd0e52d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -24,6 +24,7 @@ unstable_protocols = \ unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \ unstable/primary-selection/primary-selection-unstable-v1.xml \ + unstable/presentation/presentation-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/presentation/README b/unstable/presentation/README new file mode 100644 index 000..5a77e97 --- /dev/null +++ b/unstable/presentation/README @@ -0,0 +1,5 @@ +Presentation protocol + +Maintainers: +Carlos Garnacho + diff --git a/unstable/presentation/presentation-unstable-v1.xml b/unstable/presentation/presentation-unstable-v1.xml new file mode 100644 index 000..84bf961 --- /dev/null +++ b/unstable/presentation/presentation-unstable-v1.xml @@ -0,0 +1,175 @@ + + + +Copyright 2018-2019 © Red Hat, Inc. + +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. + + + +This description provides a high-level overview of the interplay between +the interfaces defined this protocol. For details, see the protocol +specification. + +The finality of the protocol is defining a compositor context for +surfaces requesting to be presented. Presentation requests are usually +initiated by an existing surface, and acknowledged by a surface being +mapped. By having both ends talk with the compositor through this protocol, +the compositor has the information to implement different commonplace +policies: + +- Startup notification: The compositor may track wp_presenter interfaces + being created from the launcher side, and replied upon on the launchee + side. Compositors may also perform the application launcher role + themselves. + +- Focus stealing prevention: The compositor may know whether there is + recent user input that happened after the presentation request, and + ensure no disruptions happen. + +- Window raising/activation: The presented surface may be another previously + existing one, which might require bringing it to focus. + +A client that wishes to present another surface (of its own or from another +client) will call wp_presentation_manager.create_presenter to create a +presentation request. Compositors may use this object to track the source of +the request in order to apply its policies when mapping the surface or +bringing an existing one to focus. + +In the presented surface side, the request token will be notified upon +through the wp_presentation_manager.acknowledge request. The method to pass +the token across clients is considered an implementation detail, and is +explicitly not observed here. + +Upon a successfully acknowledged presentation token,
Re: wayland-protocols scope and governance
On Tue, 15 Oct 2019 20:04:43 + Simon Ser wrote: > > New members are proposed by current members but no initial members > > have been defined. I think we need that in a single sentence, > > otherwise how could the first members join? I would propose the > > initial members to be the compositors (in alphabetic order): KWin, > > mutter, weston, wlroots/Sway. > > I guess we need to maintain a list of members in the repo. We need an > initial list and I also had these 4 compositors in mind. Maybe also GTK > and Qt? But after all, the goal is to just bootstrap the members list. > We shouldn't try to build an exhaustive list, it's easy to add new > members. > > Points of contact I had in mind: > > - KWin: Roman Gilg > - Mutter: Jonas Ådahl > - Weston: Pekka Paalanen , > Daniel Stone > - wlroots: Drew DeVault , Simon Ser > > I think it would make sense to include this initial list in a MEMBERS > file in the upcoming wayland-protocols patch series that adds this > governance document. > > Thoughts? Sounds good to me! Prodding toolkit projects for people would be good, and also Enlightenment. Thanks, pq pgpyCi0GEkhN1.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
