[HN Gopher] Gnome 40 Introducing Headless Native Back End, Virtu...
___________________________________________________________________
Gnome 40 Introducing Headless Native Back End, Virtual Monitors
Author : nikodunk
Score : 56 points
Date : 2021-03-12 18:51 UTC (4 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| deanclatworthy wrote:
| This is fantastic. I have a box in the corner with no display
| attached and wasn't able to RDP/VNC etc into it as there was no
| real display. I had mixed results with an abandoned virtual
| display package and ended up purchasing a tiny HDMI thing that
| plugs in the back and emulates a real display.
| haldean wrote:
| Do you have a link for the HDMI dongle thing?
| kevincox wrote:
| The virtual monitors feature is niche but very useful when you
| need it. It is useful for screensharing when you don't have a
| spare monitor to use but want to arrange a couple of windows. It
| is so useful that people by dedicated hardware to convince their
| system to give them another monitor. (HDMI dummy plugs)
| foobar33333 wrote:
| Its useful for steamvr too which shows you your monitors so a
| dummy monitor gives you an extra monitor in vr
| rektide wrote:
| This is one of the sort-of-frustrating as-a-user things about
| Wayland to me, that every compositor (nee window manager) has to
| implement capabilities like this for themselves, where-as in X,
| there was common tooling. And they'll all have different userland
| tools to use these capabilities.
|
| here[1] for example is wlroots/sway implementing headless.
|
| That said, the implementations are great, & really show how much
| Linux has progressed. For a while it wasn't possible (for some
| reason I wasn't having good luck with either mdi or dp dummy
| plugs on my type-c only laptop), but I'm really looking forward
| to using one laptop as a virtual desktop for another desktop, &
| this work is core to that effort. I like a lot that Gnome was
| super smart & made outputting a virtual monitor as a PipeWire
| stream built in!! Smart easy win to make screen capturing even
| easier.
|
| Edit: at my posting rate-limit, so tacking this on, especially to
| @spivak,
|
| I like the diversity a lot, yes. But I still would like to see a
| situation other than gnome having it's own tooling to configure
| virtual monitors, wlroots having it's own, kde having it's own.
|
| Is this just an insufficienct protocolization problem right now?
| Are there wayland protocols to do things like change a monitor's
| resolution? Or to change the mouse speed? I think of Wayland
| protocols as more between a running app and the compositor, which
| has all been nicely modularized & protocolized. But I don't
| understand what if any effort has been made to find a common
| ground to expose user tooling. It feels like they all have their
| own suite of command line utilities. Swaymsg in sway, for
| example. Whatever this virtual monitor tool gnome has. How do we
| begin to modularize these control interfaces?
|
| [1]
| https://github.com/swaywm/wlroots/commits/master/backend/hea...
| neolog wrote:
| There could be another library providing these common
| utilities, which multiple window managers could use.
| zbuf wrote:
| Is there a library providing these common utilities, which
| multiple window managers could use?
| tobasq wrote:
| Yes, wlroots is such a library.
| akvadrako wrote:
| Most wayland features implemented by a plurality of
| compositors are in the wlroots library.
|
| This feature probably isn't in a library though since it's
| from Gnome.
| sprash wrote:
| Or it could be part of the Wayland protocol from the get go
| sparing everyone of major headaches.
|
| At some point you arrive at a core functionality resembling
| X11 and you went full circle breaking everybody's workflow
| and tooling in the process for no reason other than severe
| NIHS.
| mixedCase wrote:
| Have you considered that maybe it was not done just to
| spite you and break your workflow?
|
| Or that maybe it does have something to do with having a
| maintainable implementation that doesn't work under
| assumptions that stopped being valid 20 years ago which
| make modern usecases extremely hard or impossible to
| support?
|
| And that indeed, the protocol has been growing and new
| standards have been in development concurrently with X.org
| maintenance in order to have a smooth transition?
|
| You're proposing that having everything ready from the get
| go would be much better, but that goes against pretty much
| every principle we know about designing large, complex
| systems, where BUFD results in huge messes that don't
| conform to reality, _and can never do so_ , unlike a
| minimalist protocol that grows over time with careful
| approaches.
| d110af5ccf wrote:
| > in order to have a smooth transition
|
| I was with you until that bit. I like the _idea_ of
| Wayland, but it simply wasn 't a viable daily replacement
| for typical desktop activities without certain key
| supporting features. Unfortunately, Wayland was rather
| aggressively pushed as a suitable replacement long before
| these things had been ironed out. Predictably, breakage
| and community backlash resulted.
|
| Typical "real life" usage absolutely requires
| standardized support for screenshots and screencasts. As
| far as I understand things, that requires Pipewire
| support at both the compositor and application levels.
| That's only just happening now.
|
| For gaming and 3D work, did the major implementations
| ever standardize a protocol for a window to capture the
| pointer? (I assume this has been done by now.)
|
| Did an approach for handling key remapping and macros
| ever get standardized across implementations? (I also
| assume this was finally taken care of.)
| chousuke wrote:
| It exists for Wayland: it's called wlroots.
|
| Unfortunately, wlroots is only used by everyone except Gnome
| and KDE, who seem to prefer to do their own thing.
| michaelmrose wrote:
| So its used by everyone except for 90% of users.
| chungy wrote:
| Not just that GNOME and KDE's Wayland support both predate
| wlroots, but they also go through the effort to support
| EGLStreams, necessary for NVIDIA compatibility. The wlroots
| author is explicitly against this.
| Spivak wrote:
| This is more a culture thing than anything technical. Wayland
| is meant as a replacement for X which is "just" the wire
| protocol that windows use to talk to the display server. But
| compositors like Sway, Mutter, and Kwin are angling to replace
| _Xorg_ , the single monolithic display server that happened to
| speak X. Xorg could have just added Wayland support (in theory
| not in practice) and so the death of Xorg left a huge hole that
| everyone is trying to fill and no dominant project as emerged
| yet and Wayland has made it easier than ever to just DIY.
|
| To me this is a good thing because having multiple competing
| implementations of a standard makes the standard authoritative
| and avoids the "do what Xorg does" problem.
| sprash wrote:
| > angling to replace Xorg
|
| The Xrandr extension enabling all this functionality is
| defacto part of the X11 protocol for a long time and not just
| "Xorg".
|
| > Xorg could have just added Wayland support
|
| You already can run any Wayland client in Xorg with a simple
| Weston wrapper script. However since X11 supports DRI3 which
| is as efficient as Wayland will ever be it is completely
| pointless.
|
| > To me this is a good thing
|
| Speak for yourself. For me standardization is a good thing.
| The "Desktop" is essentially a solved problem. There is no
| reason to invent a new incompatible standard every week. What
| is happening here is the opposite of standardization.
| d110af5ccf wrote:
| > The "Desktop" is essentially a solved problem.
|
| Serious question, what are the key differences and
| tradeoffs between the DRI3 and Wayland APIs? I've done some
| OpenGL programming, but always in a fully abstracted manner
| (ie using cross platform wrapper libraries).
|
| As a bystander, my impression is that the real issue
| (outside of refactoring a massive codebase & associated
| ecosystem on a volunteer basis) is one of security and
| efficiency. Without reworking the underlying protocol to
| require compositing, how do you properly sandbox
| applications from one another? And as long as you're making
| such a significant overhaul, why not throw out a bunch of
| cruft and split off any extra functionalities into their
| own standards? And as long as you're doing all that, why
| not completely restructure the protocol to handle things
| like minimized windows updating thumbnails of themselves at
| an interval determined by the compositor?
| [deleted]
| pedrocr wrote:
| It's a little bit more than just culture. The Wayland
| protocol has made the compositor, window manager and window
| server concepts a single thing whereas in X those are
| provided by different applications talking a standardized
| protocol. It did that for good reason and there are technical
| ways to then implement those parts with common code still.
| But since that sharing is not enforced by the protocol itself
| there's still duplication of things that in the Xorg world
| were more stabilized with no real competing implementations.
| d110af5ccf wrote:
| > more than just culture. The Wayland protocol has made the
| compositor, window manager and window server concepts a
| single thing
|
| I realize that any implementation of the Wayland protocol
| must of necessity involve compositing somewhere in the
| stack simply due to the nature of the protocol itself. And
| I also realize that all current Wayland "compositors"
| happen to roll all this functionality into a single
| monolithic implementation. But I honestly don't understand
| what's stopping someone from implementing a modular Wayland
| display server which you plug a conforming compositor into
| (with the caveat that, unlike X11, such a module would not
| be optional).
|
| Is there some technical issue I'm unaware of that would
| prevent a standalone display server implementation speaking
| the Wayland protocol from delegating all the necessary
| behavior via indirection?
| hollander wrote:
| ELI5 please. What is a headless native back end? These articles
| seem to be written for people who already know that it exists and
| what it is. How does that virtual monitor work?
| AceJohnny2 wrote:
| Desktop environments like Gnome assume the hardware on the
| machine they're running on is all the displays they'll ever
| have to deal with. "Headless" means there is no display (the
| "head" of the computer) connected to the machine.
|
| This update allows Gnome to use virtual monitors.
___________________________________________________________________
(page generated 2021-03-12 23:02 UTC)