Waypipe: a transparent Wayland proxy
For the last few weeks, I've been working on a program which can be used to transparently proxy Wayland clients over a network. (Like "ssh -X ...", except here it's "waypipe ssh ...".) https://gitlab.freedesktop.org/mstoeckl/waypipe/ Waypipe needs to be run on both ends of a socket connection, with one instance acting as a Wayland server, and the other creating Wayland clients as needed. It emulates shared files between the different systems on each end of the connection, using twin file copies to quickly identify file changes. To determine how and when exactly to replicate and update a file, Waypipe parses the protocol messages that it forwards between the actual Wayland client and server that it has connected to. [Exact details are slightly more complicated.] It currently supports both shared-memory and DMABUFs, although there are still rough edges with the latter when it comes to layout modifiers and multiplanar/multibuffer images. Performance on a local network is acceptable for terminals and relatively static applications, although games are often unplayable due to FPS drop from the delay needed to send a screenful of data over the network. (There's a command line option for low latency h264 video encoding, but it only applies to linear-layout DMABUFs at the moment.) Waypipe has become stable and usable enough at this point that having more people testing it would be appreciated. I'm also still looking for feature requests, any applications which don't yet work correctly via Waypipe, and command line interface improvements. Questions, if you have any, would also be nice. mstoeckl ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
XDC 2019: 10 days left to submit your talks!
Hello! Onlyh 10 days to go to submit your talks, workshops or demos for this year's X.Org Developer Conference, which will be taking place in beautiful Montréal, Canada on October 2-4, 2019! Whether it's the Linux kernel, Mesa, DRM, Wayland or X11, if it's related to the Open Source graphics stack, please send it in! Head to the XDC website to learn more: https://xdc2019.x.org/ The deadline for submissions Sunday, 7 July 2019. Best, Mark ___ 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
Hi Pekka, On Fri, 2019-06-28 at 12:58 +0300, Pekka Paalanen wrote: > On Fri, 28 Jun 2019 11:23:53 +0200 > Philipp Zabel wrote: > > On Thu, 2019-06-27 at 20:36 +, Simon Ser wrote: > > > What would be other use-cases for DRM leases? Probably fullscreen games? > > > > One use case I'd like would be presentation software, where tagging the > > projector as non-desktop beforehand would avoid spilling the desktop > > onto the presentation display upon connection, before the presentation > > is started. > > Hi, > > I don't think that is a good idea. Presentation software (Libreoffice, > web browsers, Evince, ...) probably does not want to grow a whole DRM > KMS backend just to be able to drive a projector. > > It would be much better for compositors to handle presentation outputs > specially on their own to not extend the normal desktop contents there, > and have a simple dedicated extension for presentation software to put > a wl_surface on a presentation output (if necessary, maybe xdg_output > and fullscreening to a specific wl_output is already enough). > > There are much more categories of outputs than just "desktop" and > "non-desktop". I would avoid extending and confusing the meaning of > "non-desktop" from what it currently is in the Linux kernel. > > Personally I am sceptical that even non-VR games would really benefit > from DRM leases, because games might want to switch between windowed and > fullscreen, users might want to see desktop notifications sometimes, > etc. and again the DRM KMS backend is not easy to write. > > VR apps at least can rely on a VR runtime that knows how to drive DRM > KMS properly, and there the use of DRM leases is well justified. I can't argue with this, all of it makes sense. Another possible use case could be applications for special purpose displays like the Looking Glass lenticular displays, or anything that we know for sure the Wayland compositor or normal Desktop applications won't be able to produce meaningful content for. regards Philipp ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: dpms with wayland
Hi Vladimir On Tue, 25 Jun 2019 at 18:05, Pekka Paalanen wrote: > > On Tue, 25 Jun 2019 14:51:08 + > "Jovic, Vladimir" wrote: > > > > -Ursprüngliche Nachricht- > > > Von: Pekka Paalanen > > > Gesendet: Dienstag, 25. Juni 2019 16:37 > > > An: Jovic, Vladimir > > > Cc: wayland-devel@lists.freedesktop.org > > > Betreff: Re: dpms with wayland > > > > > > On Tue, 25 Jun 2019 14:07:51 + > > > "Jovic, Vladimir" wrote: > > > > > > > Thanks, but is there any more info on that? I tried setting > > > > "idle-second" in [core] to some value, as explained in man pages for > > > > Weston.ini, but that did nothing. Wasn't that supposed to turn off the > > > > monitor after N seconds? > > > > > > Yes, check your syntax. There is also the command line option -i for the > > > same. > > > > I tried both and neither worked. > > First I tried this: > > weston -i 3 --tty 3 > > and that didn't turn off the screen after 3 seconds. I know because I set > > the background. > > > > Then I tried Weston with this configuration: > > [core] > > shell=ivi-shell.so > > modules=ivi-controller.so > > idle-time=3 > > > > [ivi-shell] > > ivi-input-module=ivi-input-controller.so > > bkgnd-surface-id=1000 > > bkgnd-color=0x00ff > > > > [output] > > name=Unknown-1 > > transform=normal > > > > Again, the screen would not go off after 3 seconds. > > Does the screen at least go black? > > There may be a secondary timeout before it goes off, I've forgot > how it works. I'm pretty sure it should go off with the > DRM-backend, but maybe that has regressed then. The dpms handling is implemented in the compositor-drm but it requires trigger from somewhere, e.g. shell :-) compositor will fire a idle_signal and shell can register for this and trigger the dpms handling. the "-i" will configure the timeout for this signal > > It should work with the desktop-shell, but since you are using > ivi-shell, I'm not sure it's implemented. No, ivi-shell is not implementing the idle_signal handler, since same question was asked in genivi-ivi-layer-managem...@lists.genivi.org I will provide details how to implement this feature with wayland-ivi-extension there thanks jeka > > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ 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
On Thursday, June 27, 2019 11:36 PM, Simon Ser wrote: > > 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 I'm now wondering if DRM leasing is that much different from xdg-shell set_fullscreen requests. Is DRM leasing that much of a big deal regarding security? (Especially if the compositor has a policy to lease only non-desktop outputs) One thing I'm concerned about is buffers read access. Someone posted a Weston patch [1] to remove framebuffers when switching VTs, because the new master could potentially read them. Would this type of thing be possible with DRM leases? Could a lessee read buffers from the compositor's connectors? [1]: https://gitlab.freedesktop.org/wayland/weston/merge_requests/175 ___ 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
On Friday, June 28, 2019 12:58 PM, Pekka Paalanen wrote: > On Fri, 28 Jun 2019 11:23:53 +0200 > Philipp Zabel p.za...@pengutronix.de wrote: > > > On Thu, 2019-06-27 at 20:36 +, Simon Ser wrote: > > > > > What would be other use-cases for DRM leases? Probably fullscreen games? > > > > One use case I'd like would be presentation software, where tagging the > > projector as non-desktop beforehand would avoid spilling the desktop > > onto the presentation display upon connection, before the presentation > > is started. > > Hi, > > I don't think that is a good idea. Presentation software (Libreoffice, > web browsers, Evince, ...) probably does not want to grow a whole DRM > KMS backend just to be able to drive a projector. I totally agree. > It would be much better for compositors to handle presentation outputs > specially on their own to not extend the normal desktop contents there, > and have a simple dedicated extension for presentation software to put > a wl_surface on a presentation output (if necessary, maybe xdg_output > and fullscreening to a specific wl_output is already enough). > > There are much more categories of outputs than just "desktop" and > "non-desktop". I would avoid extending and confusing the meaning of > "non-desktop" from what it currently is in the Linux kernel. > > Personally I am sceptical that even non-VR games would really benefit > from DRM leases, because games might want to switch between windowed and > fullscreen, users might want to see desktop notifications sometimes, > etc. and again the DRM KMS backend is not easy to write. > > VR apps at least can rely on a VR runtime that knows how to drive DRM > KMS properly, and there the use of DRM leases is well justified. Yes. +1 to all of this. ___ 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
On Friday, June 28, 2019 12:23 PM, Philipp Zabel wrote: > > I'm not sure the client is in the best position to decide which connectors > > to > > pick here. > > The client may be the only one with enough knowledge to pick, see below. > > > Maybe it would be better for the client to say why it needs a lease (e.g. it > > needs the non-desktop connectors for VR) and let the compositor pick > > appropriate > > connectors. > > How then would the desktop compositor decide which of the non-desktop > connectors the client requires? > > For example, if I have two simultaneously connected VR headsets, each > running their own VR client, how would the two clients each lease only > the non-desktop connector corresponding to their headset? […] > > If the compositor advertizes both non-desktop outputs (for VR) and > > desktop outputs (for games), how should the VR client pick the right > > output? > > Depending on the hardware and setup, the VR client may match the serial > number contained in the EDID with one retrieved via USB to identify the > correct connector to render to a given VR headset, or it may just > compare the vendor and product id. In a CAVE setup the client may have > manual configuration telling it which projectors to render to, so I > think the client needs access to at least the uniquely identifying parts > of the EDID. Indeed, that makes sense. So another idea that was floating around would be to allow the client to get a lease FD with zero leased resources, let it inspect the connectors via DRM properties, then let the client request a particular connector ID and get a second lease. We could also expose make/model/serial instead. In any case, the connector name probably won't help a lot. ___ 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
On Friday, June 28, 2019 10:51 AM, Marius Vlad wrote: > >> + > >> + > >> +The compositor may choose to advertise 0 or more connectors which > >> may be > >> +leased to clients, and will use this event to do so. This object > >> may be > >> +passed into a lease request to lease that connector. See > >> +zwp_drm_lease_request_v1.add_connector for details. > >> + > >> +When this global is bound, the compositor will send all connectors > >> +available for lease, but may send additional connectors at any > >> time. > > > > I'm not sure the client is in the best position to decide which connectors > > to > > pick here. > > If you assume connectors are (always) dynamic, they can appear and > disappear at will (which is the real world). My initial take on this was > to limit which connectors to advertise using the configuration file, > idea being that the connectors advertised are already vouched by the > compositor, but doesn't play that nicely with the idea of connectors > appearing and disappearing. > > > Maybe it would be better for the client to say _why_ it needs a lease (e.g. > > it > > needs the non-desktop connectors for VR) and let the compositor pick > > appropriate > > connectors. > > > > What would be other use-cases for DRM leases? Probably fullscreen games? If > > the > > compositor advertizes both non-desktop outputs (for VR) and desktop outputs > > (for > > games), how should the VR client pick the right output? > > Testing. The ability to run 2 applications simultaneously was the > initial use case for us, even though we didn't had any kind input for > it. For instance I imagine intel-ci BAT running a bit faster (at least > for some of the tests). dEQP was our candidate for speeding it things a > bit and an internal testing framework. Showcasing. I don't think we can run BAT faster, because we rely on dmesg, which is global state. > Maybe include the/a kind of connector type (based on that property - > !non_desktop && non_desktop) besides the name of the connector. This > combined with the connector name might provide enough information for > the client to choose the correct HMD? See Philipp Zabel's reply. ___ 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
On Fri, 28 Jun 2019 11:23:53 +0200 Philipp Zabel wrote: > On Thu, 2019-06-27 at 20:36 +, Simon Ser wrote: > > What would be other use-cases for DRM leases? Probably fullscreen games? > > One use case I'd like would be presentation software, where tagging the > projector as non-desktop beforehand would avoid spilling the desktop > onto the presentation display upon connection, before the presentation > is started. Hi, I don't think that is a good idea. Presentation software (Libreoffice, web browsers, Evince, ...) probably does not want to grow a whole DRM KMS backend just to be able to drive a projector. It would be much better for compositors to handle presentation outputs specially on their own to not extend the normal desktop contents there, and have a simple dedicated extension for presentation software to put a wl_surface on a presentation output (if necessary, maybe xdg_output and fullscreening to a specific wl_output is already enough). There are much more categories of outputs than just "desktop" and "non-desktop". I would avoid extending and confusing the meaning of "non-desktop" from what it currently is in the Linux kernel. Personally I am sceptical that even non-VR games would really benefit from DRM leases, because games might want to switch between windowed and fullscreen, users might want to see desktop notifications sometimes, etc. and again the DRM KMS backend is not easy to write. VR apps at least can rely on a VR runtime that knows how to drive DRM KMS properly, and there the use of DRM leases is well justified. Thanks, pq pgpKaE8cR9CQK.pgp Description: OpenPGP digital 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
On Thu, 2019-06-27 at 20:36 +, Simon Ser wrote: [...] > > + > > + > > +The compositor may choose to advertise 0 or more connectors which > > may be > > +leased to clients, and will use this event to do so. This object > > may be > > +passed into a lease request to lease that connector. See > > +zwp_drm_lease_request_v1.add_connector for details. > > + > > +When this global is bound, the compositor will send all connectors > > +available for lease, but may send additional connectors at any > > time. > > I'm not sure the client is in the best position to decide which connectors to > pick here. The client may be the only one with enough knowledge to pick, see below. > Maybe it would be better for the client to say _why_ it needs a lease (e.g. it > needs the non-desktop connectors for VR) and let the compositor pick > appropriate > connectors. How then would the desktop compositor decide which of the non-desktop connectors the client requires? For example, if I have two simultaneously connected VR headsets, each running their own VR client, how would the two clients each lease only the non-desktop connector corresponding to their headset? > What would be other use-cases for DRM leases? Probably fullscreen games? One use case I'd like would be presentation software, where tagging the projector as non-desktop beforehand would avoid spilling the desktop onto the presentation display upon connection, before the presentation is started. > If the compositor advertizes both non-desktop outputs (for VR) and > desktop outputs (for games), how should the VR client pick the right > output? Depending on the hardware and setup, the VR client may match the serial number contained in the EDID with one retrieved via USB to identify the correct connector to render to a given VR headset, or it may just compare the vendor and product id. In a CAVE setup the client may have manual configuration telling it which projectors to render to, so I think the client needs access to at least the uniquely identifying parts of the EDID. regards Philipp ___ 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
On Thu, 27 Jun 2019 15:46:27 -0400 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 > --- Hi Drew, you write a lot of good explanations and rationale below, but then you mark it to be ignored by git-am so it will never end up in the commit message. I think that would be a loss. Don't be afraid to add "too much" rationale in commit messages, it cannot hurt (it's not in the code that people will read repeatedly and it doesn't need maintaining), but it certainly can help posterity when questions arise. Thanks, pq > 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 pgpAqiYoS3_kT.pgp Description: OpenPGP digital 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
Hi Drew, Thanks for taking the time to reboot the lease protocol! On 6/27/19 11:36 PM, Simon Ser wrote: > 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
