[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
Re: [PATCH] unstable/drm-lease: DRM lease protocol support
Cc'ing Marius Vlad again, hopefully with a working e-mail address now. is defunct. > From: Marius Vlad > > Simple protocol extension to manage DRM lease. Based on the work by Keith > Packard in [1], respectively [2]. > > [1] > https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f > > Signed-off-by: Marius Vlad > Signed-off-by: Drew DeVault > --- > This updates Marius's original patch series implementing DRM leasing for > Wayland. This cleans up the XML style, reworks resource lifetimes, adds > a little link to xdg-output, and a few other changes. > > A server-side implementation of this protocol is under development and > available here: > > https://github.com/swaywm/wlroots/pull/1730 > > I've also rigged up Keith Packard's kmscube fork to support leasing from > Wayland instead of X: > > https://git.sr.ht/~sircmpwn/kmscube > > Run `./kmscube -l` to test it. While doing the research for this > protocol there was also some discussions in wlroots which may be > insightful: > > https://github.com/swaywm/wlroots/issues/1723 > > Background: > > DRM leasing is a feature which allows the DRM master to "lease" a subset > of its DRM resources to another DRM master via drmModeCreateLease, which > returns a file descriptor for the new DRM master. We use this protocol > to negotiate the terms of the lease and transfer this file descriptor to > clients. > > In less DRM-specific terms: this protocol allows Wayland compositors to > give over their GPU resources (like displays) to a Wayland client to > exclusively control. > > The primary use-case for this is Virtual Reality headsets, which via the > non-desktop DRM property are generally not used as desktop displays by > Wayland compositors, and for latency reasons (among others) are most > useful to games et al if they have direct control over the DRM resources > associated with it. Basically, these are peripherals which are of no use > to the compositor and may be of use to a client, but since they are tied > up in DRM we need to use DRM leasing to get them into client's hands. > > Previously there were some musings about the security considerations. > This version of the protocol allows the compositor to consider the lease > request in its own time, perhaps presenting the user with a dialog to > consent to the lease. Additionally, leased connectors can be added and > removed at the compositor's whim, and race conditions have been > considered to avoid disagreement between the client and compositor as to > which connectors are available for lease - the compositor being the > ultimate authority. > > In the coming weeks I intend to work on patches for Vulkan and Xwayland > adding support for this protocol, respectively to allow Vulkan clients > to utilize DRM leasing on Wayland and to allow X11 clients utilizing the > xrandr lease request[0] to fulfill their leases through Xwayland. > > https://gitlab.freedesktop.org/xorg/proto/xcbproto/blob/master/src/randr.xml#L909-938 > > Makefile.am | 1 + > unstable/drm-lease/README| 4 + > unstable/drm-lease/drm-lease-unstable-v1.xml | 203 +++ > 3 files changed, 208 insertions(+) > create mode 100644 unstable/drm-lease/README > create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 345ae6a..d9fff89 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -4,6 +4,7 @@ unstable_protocols = > \ > unstable/pointer-gestures/pointer-gestures-unstable-v1.xml > \ > unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml > \ > unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > \ > + unstable/drm-lease/drm-lease-unstable-v1.xml > \ > unstable/text-input/text-input-unstable-v1.xml > \ > unstable/text-input/text-input-unstable-v3.xml > \ > unstable/input-method/input-method-unstable-v1.xml > \ > diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README > new file mode 100644 > index 000..a25600c > --- /dev/null > +++ b/unstable/drm-lease/README > @@ -0,0 +1,4 @@ > +Linux DRM lease > + > +Maintainers: > +Marius Vlad > diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml > b/unstable/drm-lease/drm-lease-unstable-v1.xml > new file mode 100644 > index 000..8f52021 > --- /dev/null > +++ b/unstable/drm-lease/drm-lease-unstable-v1.xml > @@ -0,0 +1,203 @@ > + > + > + > +Copyright © 2018 NXP > +Copyright © 2019 Status Research Development GmbH. > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and
Re: [PATCH] unstable/drm-lease: DRM lease protocol support
Hi, Thanks for your work! Here is a first round of comments. On Thursday, June 27, 2019 10:46 PM, Drew DeVault wrote: > From: Marius Vlad > > Simple protocol extension to manage DRM lease. Based on the work by Keith > Packard in [1], respectively [2]. > > [1] > https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f > > Signed-off-by: Marius Vlad > Signed-off-by: Drew DeVault > --- > This updates Marius's original patch series implementing DRM leasing for > Wayland. This cleans up the XML style, reworks resource lifetimes, adds > a little link to xdg-output, and a few other changes. > > A server-side implementation of this protocol is under development and > available here: > > https://github.com/swaywm/wlroots/pull/1730 > > I've also rigged up Keith Packard's kmscube fork to support leasing from > Wayland instead of X: > > https://git.sr.ht/~sircmpwn/kmscube > > Run `./kmscube -l` to test it. While doing the research for this > protocol there was also some discussions in wlroots which may be > insightful: > > https://github.com/swaywm/wlroots/issues/1723 > > Background: > > DRM leasing is a feature which allows the DRM master to "lease" a subset > of its DRM resources to another DRM master via drmModeCreateLease, which > returns a file descriptor for the new DRM master. We use this protocol > to negotiate the terms of the lease and transfer this file descriptor to > clients. > > In less DRM-specific terms: this protocol allows Wayland compositors to > give over their GPU resources (like displays) to a Wayland client to > exclusively control. > > The primary use-case for this is Virtual Reality headsets, which via the > non-desktop DRM property are generally not used as desktop displays by > Wayland compositors, and for latency reasons (among others) are most > useful to games et al if they have direct control over the DRM resources > associated with it. Basically, these are peripherals which are of no use > to the compositor and may be of use to a client, but since they are tied > up in DRM we need to use DRM leasing to get them into client's hands. Maybe some of this can be integrated in the commit message. > Previously there were some musings about the security considerations. > This version of the protocol allows the compositor to consider the lease > request in its own time, perhaps presenting the user with a dialog to > consent to the lease. Additionally, leased connectors can be added and > removed at the compositor's whim, and race conditions have been > considered to avoid disagreement between the client and compositor as to > which connectors are available for lease - the compositor being the > ultimate authority. We still need a way to identify the client. See https://gitlab.freedesktop.org/wayland/weston/issues/206 > > In the coming weeks I intend to work on patches for Vulkan and Xwayland > adding support for this protocol, respectively to allow Vulkan clients > to utilize DRM leasing on Wayland and to allow X11 clients utilizing the > xrandr lease request[0] to fulfill their leases through Xwayland. > > https://gitlab.freedesktop.org/xorg/proto/xcbproto/blob/master/src/randr.xml#L909-938 > > Makefile.am | 1 + > unstable/drm-lease/README| 4 + > unstable/drm-lease/drm-lease-unstable-v1.xml | 203 +++ > 3 files changed, 208 insertions(+) > create mode 100644 unstable/drm-lease/README > create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 345ae6a..d9fff89 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -4,6 +4,7 @@ unstable_protocols = > \ > unstable/pointer-gestures/pointer-gestures-unstable-v1.xml > \ > unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml > \ > unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > \ > + unstable/drm-lease/drm-lease-unstable-v1.xml > \ > unstable/text-input/text-input-unstable-v1.xml > \ > unstable/text-input/text-input-unstable-v3.xml > \ > unstable/input-method/input-method-unstable-v1.xml > \ > diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README > new file mode 100644 > index 000..a25600c > --- /dev/null > +++ b/unstable/drm-lease/README > @@ -0,0 +1,4 @@ > +Linux DRM lease > + > +Maintainers: > +Marius Vlad Drew, maybe you could add yourself as a maintainer too. Is Marius Vlad still interested in being maintainer? > diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml > b/unstable/drm-lease/drm-lease-unstable-v1.xml > new file mode 100644 > index
[PATCH] unstable/drm-lease: DRM lease protocol support
From: Marius Vlad Simple protocol extension to manage DRM lease. Based on the work by Keith Packard in [1], respectively [2]. [1] https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f Signed-off-by: Marius Vlad Signed-off-by: Drew DeVault --- This updates Marius's original patch series implementing DRM leasing for Wayland. This cleans up the XML style, reworks resource lifetimes, adds a little link to xdg-output, and a few other changes. A server-side implementation of this protocol is under development and available here: https://github.com/swaywm/wlroots/pull/1730 I've also rigged up Keith Packard's kmscube fork to support leasing from Wayland instead of X: https://git.sr.ht/~sircmpwn/kmscube Run `./kmscube -l` to test it. While doing the research for this protocol there was also some discussions in wlroots which may be insightful: https://github.com/swaywm/wlroots/issues/1723 Background: DRM leasing is a feature which allows the DRM master to "lease" a subset of its DRM resources to another DRM master via drmModeCreateLease, which returns a file descriptor for the new DRM master. We use this protocol to negotiate the terms of the lease and transfer this file descriptor to clients. In less DRM-specific terms: this protocol allows Wayland compositors to give over their GPU resources (like displays) to a Wayland client to exclusively control. The primary use-case for this is Virtual Reality headsets, which via the non-desktop DRM property are generally not used as desktop displays by Wayland compositors, and for latency reasons (among others) are most useful to games et al if they have direct control over the DRM resources associated with it. Basically, these are peripherals which are of no use to the compositor and may be of use to a client, but since they are tied up in DRM we need to use DRM leasing to get them into client's hands. Previously there were some musings about the security considerations. This version of the protocol allows the compositor to consider the lease request in its own time, perhaps presenting the user with a dialog to consent to the lease. Additionally, leased connectors can be added and removed at the compositor's whim, and race conditions have been considered to avoid disagreement between the client and compositor as to which connectors are available for lease - the compositor being the ultimate authority. In the coming weeks I intend to work on patches for Vulkan and Xwayland adding support for this protocol, respectively to allow Vulkan clients to utilize DRM leasing on Wayland and to allow X11 clients utilizing the xrandr lease request[0] to fulfill their leases through Xwayland. https://gitlab.freedesktop.org/xorg/proto/xcbproto/blob/master/src/randr.xml#L909-938 Makefile.am | 1 + unstable/drm-lease/README| 4 + unstable/drm-lease/drm-lease-unstable-v1.xml | 203 +++ 3 files changed, 208 insertions(+) create mode 100644 unstable/drm-lease/README create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 345ae6a..d9fff89 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4,6 +4,7 @@ unstable_protocols = \ unstable/pointer-gestures/pointer-gestures-unstable-v1.xml \ unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml \ unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml \ + unstable/drm-lease/drm-lease-unstable-v1.xml \ unstable/text-input/text-input-unstable-v1.xml \ unstable/text-input/text-input-unstable-v3.xml \ unstable/input-method/input-method-unstable-v1.xml \ diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README new file mode 100644 index 000..a25600c --- /dev/null +++ b/unstable/drm-lease/README @@ -0,0 +1,4 @@ +Linux DRM lease + +Maintainers: +Marius Vlad diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml b/unstable/drm-lease/drm-lease-unstable-v1.xml new file mode 100644 index 000..8f52021 --- /dev/null +++ b/unstable/drm-lease/drm-lease-unstable-v1.xml @@ -0,0 +1,203 @@ + + + +Copyright © 2018 NXP +Copyright © 2019 Status Research Development GmbH. + +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
Re: [PATCH wayland-protocols] xdg-output: make xdg_output.description mutable
On Monday, June 24, 2019 1:29 PM, Daniel Stone wrote:
> Hi,
>
> On Sat, 27 Apr 2019 at 09:16, Simon Ser wrote:
> > The output description is a human-readable text describing the output.
> > Unlike
> > the name which uniquely identifies the output, it's intended to be
> > displayed to
> > the user.
> >
> > It might be desirable for a compositor to update an output's description.
> > For
> > instance, when only one output is plugged in, it's not necessary to dump
> > make,
> > model, serial and connector to the description, something like "Dell
> > U2717D" is
> > enough. However when two identical outputs are plugged in it's necessary to
> > add
> > e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1]
> > for
> > a discussion about this.
> >
> > This commit bumps xdg_output's version to allow compositors to update the
> > property.
>
> We definitely need to figure out 'done', and ideally have it come in
> the same version bump, but with that and one small nitpick resolved
> this is:
> Acked-by: Daniel Stone
Thanks!
> - xdg_output_manager.get_xdg_output). This event is only sent once per
> + xdg_output_manager.get_xdg_output) and whenever the description
> + changes. The description is optional, and may not be sent at all.
>
> To be honest, rather than have the clients open-code their own '(no
> description)' strings - and some of them will definitely forget to do
> it - I would keep the requirement that it is sent during initial
> advertisement.
The event was previously optional too. If we want to change that, I think it
belongs to another commit.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] xdg-output: make xdg_output.description mutable
On Monday, June 24, 2019 10:08 AM, Olivier Fourdan wrote: > On Mon, Jun 24, 2019 at 9:07 AM Jonas Ådahl jad...@gmail.com wrote: > > > On Sun, Jun 23, 2019 at 10:05:09AM +, Simon Ser wrote: > > > > > Hi Jonas, > > > What do you think of this patch? > > > > Maybe want to say something about how this interacts with 'done'? > > There is another patch to remove xdg_output.done as well, not sure > where we stand with that. > > I would also mention under which circumstances it may change (as it > was initially said that it would be sent once as the description does > not change, ever). I'd like to keep this compositor-defined: the compositor can change it whenever it wants. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] xdg-output: make xdg_output.description mutable
On Monday, June 24, 2019 10:06 AM, Jonas Ådahl wrote: > On Sun, Jun 23, 2019 at 10:05:09AM +, Simon Ser wrote: > > Hi Jonas, > > > > What do you think of this patch? > > Maybe want to say something about how this interacts with 'done'? Good idea. It depends what happens to [1] I guess, and in which order we want patches to be merged. It probably makes more sense to first merge [1] and then this patch, so that we don't have to fix the new behaviour's description. Did you have a chance to have a look at [1], Jonas? [1]: https://patchwork.freedesktop.org/patch/302299/?series=60019=1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
xfway: a Wayland compositor inspired by xfwm4
xfway is a Wayland compositor inspired by xfwm4: https://github.com/adlocode/xfway I'm not sure if this is an actual attempt at a port or more of a spin-off project a la Sway, but here it is, and I just wondered if you would like to have a look at it. It supports the wlr-foreign-toplevel protocol, which can be used for window management functions, and the wlr-layer-shell protocol, which can be used for creating panels etc. At the moment it's little more than a Weston clone with some wlroots support, but there you go. What do you think? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
