Re: Multihead with wayland, similar to
On Tuesday, June 1st, 2021 at 10:33 AM, Pietro Battiston wrote: > Can you confirm that creating headless outputs is a specificity of Sway > (at least as far as you know)? So basically what's missing to GNOME is > the ability for mutter to create headless outputs? Or could/should > another software be providing it for mutter, maybe in a compositor- > agnostic way? Yes, the method I described is Sway-specific. Adding a compositor-agnostic way to do this would require designing new cross-compositor APIs. For GNOME, see Jonas' reply. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Multihead with wayland, similar to
On Tue, Jun 01, 2021 at 11:57:50AM +0200, Pietro Battiston wrote: > Sorry if I'm bothering again with non-dev questions, but this should be > my last mail on the topic. I've more or less understand where we stand > but I need one further clarification: > > Il giorno gio, 27/05/2021 alle 08.23 +0200, Jonas Ådahl ha scritto: > > [...] > > * Introduce "virtual" monitor screen recording to > > org.freedestop.portal.ScreenCast > > (https://github.com/flatpak/xdg-desktop-portal) and the portal > > backend relevant to you. > > > > Can you tell me if my understanding is correct? > > - (starting with Mutter 40.0) GNOME can work on headless/virtual > monitors Correct. > - ... so it can also work across a headless/virtual monitor and a real > one Correct in theory; there seems to be an issue when mixing that I haven't fixed yet. > - ... but PipeWire is unable to isolate one monitor out of a multi- > monitor desktop if such monitor is a virtual one With PipeWire, every streamed monitor is streamed in isolation, and be it virtual or not makes no difference; what needs to know how to select "virtual" vs "physical" is the entity that creates the streams. For the portable approach, what is lacking is the API in org.freedesktop.portal.ScreenCast to request screen casting of a virtual monitor, and in the GNOME case, the hooks to org.gnome.Mutter.ScreenCast (implemented in xdg-desktop-portal-gtk) to record from a virtual monitor instead of a real one. If you're interested in prototyping that let me know, so I can describe in detail how it could work. > - ... and so the same applies to GNOME Remote Desktop? Currently GNOME Remote Desktop can run headlessly with a pre-created virtual (headless) monitor; it doesn't yet know how to create them itself. > > (because my understanding of > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698#note_1023317 > is that GNOME Remote Desktop should be perfectly able to stream a > single Wayland-GNOME virtual monitor...) In theory, yes it can. For "remote login" (compared to "remote assistance" which is what it's capable of now) it'll use these virtual monitors and "configure" them depending on the capbilities and state of the remote desktop clients. However, right now there is no patch that does s/RecordMonitor/RecordVirtual/ however, more work is needed her than switching method to record, as e.g. the size needs to come from the client, as well as login session management etc. Jonas > > Thanks again, > > Pietro > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Multihead with wayland, similar to
Thanks once more, Jonas, Il giorno mar, 01/06/2021 alle 12.31 +0200, Jonas Ådahl ha scritto: > [...] > With PipeWire, every streamed monitor is streamed in isolation, and > be > it virtual or not makes no difference; what needs to know how to > select > "virtual" vs "physical" is the entity that creates the streams. For > the > portable approach, what is lacking is the API in > org.freedesktop.portal.ScreenCast to request screen casting of a > virtual > monitor, and in the GNOME case, the hooks to > org.gnome.Mutter.ScreenCast > (implemented in xdg-desktop-portal-gtk) to record from a virtual > monitor > instead of a real one. > > If you're interested in prototyping that let me know, so I can > describe > in detail how it could work. Unfortunately, my skills are by far insufficient to be useful: I have limited programming experience, and none in this field. The most I can do and did was to "popularize" a bit the current state of things: https://superuser.com/a/1652951/289928 Pietro ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[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
