Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wayland vs. X – Overview

wayland.freedesktop.org

Post reply on HN
Print view View original

151–160 of 186 posts

Re: Wayland vs. X – Overview

#151

Post by superkuh »

craftkiller wrote: post #97
superkuh wrote: post #79

Earlier quoted context omitted.

Ah yes, sway, the one of the waylands that refuses to add support for complex mouse/keyboard and alternate input devices. https://github.com/swaywm/wlroots/issues/2378 . You've been running a wayland, not wayland, because there is no "wayland": only many different waylands.

> You've been running a wayland, not wayland, because there is no "wayland": only many different waylands. I am aware, that is why I specified which compositor I am running. The comment I replied to said (emphasis mine) "*Wayland* won't work well on non-Linux systems" which is clearly false. To put it into another context: only a subset of C programs run on windows, but it would be silly to claim C won't work on wind…

>support for the standardized protocols?

What standardized protocol? Each wayland makes a different choice. That's the problem. And yeah, I guess I can't say this is a sway issue, their choice is reasonable enough. But it highlights how reasonable actions in a broken system like the waylands can cause problems. They're not doing anything "wrong" and neither are the waylands using libei (all the mouse/keyboard sharing programs target libei, maybe in the future some can target whatever sway comes up with). But it does lead to things not working across waylands. Whereas in X things do work no matter what X implementation you use.

Re: Wayland vs. X – Overview

#152

Post by yencabulator »

westurner wrote: post #120
superkuh wrote: post #75

Earlier quoted context omitted.

It will be fixed on some Waylands with libei, but it will never be fixed on other waylands that find libei distasteful (like sway). And that's the waylands in a nutshell: many different things, never "wayland" always "waylands".

libei looks useful. But IDK why libei is necessary to run Barrier with Wayland? For client systems, couldn't there just be a virtual /dev/input/XYZ that Barrier forwards events through And for host systems, it looks like xev only logs input events when the window is focused. Is xeyes still broken on Wayland, and how to fix it so that it would work with Barrier? With Barrier, when the mouse cursor reaches a screen bou…

> For client systems, couldn't there just be a virtual /dev/input/XYZ that Barrier forwards events through

You seem to be asking for kernel thing, not something Wayland. But let's assume you wanted a protocol on top of Wayland to do this:

Why can't arbitrary Wayland clients always see the mouse pointer, snoop on the keyboard, and inject keypresses? Because of security, by design.

Why is it taking a bunch of work to provide that capability in an access-controlled way? Because it's a bunch of work. For example, quoting libei: "However, the events are distinguishable inside the compositor to allow for fine-grained access control on which events may be emulated and when emulation is permitted."

Re: Wayland vs. X – Overview

#153

Post by yencabulator »

vetinari wrote: post #117
nolist_policy wrote: post #110

Earlier quoted context omitted.

And Windows apparently has a Wayland compositor for WSL

They use RDP RAIL (RDP-for-a-single-window) on top of Weston, and then the resulting surfaces are managed by the DWM. Which is actually an interesting approach; linux native compositors should "steal" that idea and implement it too. It could lead to RemoteApp-alike for Linux.

ChromeOS transports Wayland over virtio so windows opened from virtual machines are seamlessly part of the main desktop.

Waypipe proxies Wayland over SSH etc: https://gitlab.freedesktop.org/mstoeckl/waypipe/

Re: Wayland vs. X – Overview

#154

Post by yencabulator »

account42 wrote: post #102
SilverCode wrote: post #31

Earlier quoted context omitted.

"combine (two or more images) to make a single picture, especially electronically" ... sucks? I can't even begin to think how you would present multiple windows to a user if you didn't composite them into a single image. Even if you are doing a 3D virtual desktop, you still have to composite the layers down to 2 single slightly offset images.

Compositing in the context of window management hase a more specific meaning: https://en.wikipedia.org/wiki/Compositing_window_manager vs. https://en.wikipedia.org/wiki/Stacking_window_manager There are advantages and disadvantages to both approaches. Note that X.org is traditionally a stacking window manager but has had the compositing model bolted on for a long time now.

Compositing WM is not "versus" stacking WM. Practically all mainstream Wayland desktops are floating ("stacking") based UI paradigms, while using compositing to construct the final screen image. The wikipedia article you linked to shows examples of stacking window management on the compositing window manager page!

Are you thinking of tiling WMs? The major tiling Wayland compositors support floating windows when you want them, too.

Re: Wayland vs. X – Overview

#155

Post by yencabulator »

ur-whale wrote: post #128
RealCodingOtaku wrote: post #92

Earlier quoted context omitted.

You can do it with waypipe[1]. But Wayland itself doesn't support remote rendering by choice[2] as it is outside its scope. [1] https://gitlab.freedesktop.org/mstoeckl/waypipe/ [2] https://wayland.freedesktop.org/faq.html#heading_toc_j_8

So remote in Wayland is a bag on the side that requires work and integration. Hard pass on wayland right there. At least until it offers RR natively (meaning: I don't have to waste hours of my life to get it working).

Secure remote in X11 is a bag on the side that requires work and integration. SSH has to explicitly transport it for you, carefully setting it up the right way. Even worse, SSH has to meddle with X11 internals to prevent your desktop session being trivially pwned by the remote.

Re: Wayland vs. X – Overview

#156

Post by yencabulator »

superkuh wrote: post #73

It should probably be "Waylands vs. X" since each of the Waylands supports different features and libraries to try to achieve the same ends. For example, some of the waylands use an external library, libei, to be able to support features like being able to share mouse/keyboard between computers. But some waylands, like sway, are actively hostile to libei and have made a point of never supporting it. So some waylands…

By that logic, there is also no TCP, HTTP, HTML, Linux, x86, ...

Re: Wayland vs. X – Overview

#157

Post by marrs »

hollerith wrote: post #147
psanford wrote: post #60

Earlier quoted context omitted.

Yes this. If you use gnome or kde you probably will have no issue with the transition to Wayland. If you use any other window manager then the transition will be painful because there's a bunch of things that don't simply map over from x WMs to Wayland compositors. I just did this switch and found it incredibly frustrating. Simple things like, "I would like to be able to log out and return to my greeter" don't just w…

[flagged]

> so you have to adapt

No I don't. X11 works perfectly well for me. Wayland doesn't. Until I can migrate without issue, I'll be sticking with what works. If it gets to a point where Linux becomes unusable for me, I'll just move to an OS that works. Linux isn't the only game in town. Boo hoo.

Re: Wayland vs. X – Overview

#158

Post by marrs »

pjmlp wrote: post #129
DonHopkins wrote: post #122

Earlier quoted context omitted.

Since when did Windows or Macs ever have great window managers? If you just ran a web browser directly on the hardware (or native window system in full screen mode) instead of bothering with non-great X11 or Wayland or Windows or Mac window systems, then you could write great window managers using open standards that ran identically across Linux, Mac, and Windows, plus mobile and VR devices too. https://news.ycombina…

Better than what most GNU/Linux folks use, many of whom apparently would be quite happy using twm.

I doubt that. Most of the WMs available for Linux are way more capable than their standard counterparts. There's a rich diversity of UXs available on the platform. Hopefully their ideas won't die with them if they get left behind by Wayland.

Re: Wayland vs. X – Overview

#159

Post by marrs »

DonHopkins wrote: post #116
hedora wrote: post #58

Earlier quoted context omitted.

There's nothing wrong with the transport layer's security, as far as I can tell. (For one thing, it's usually tunneled over SSH). The X11 security model assumes that anything with access to the screen has at least as much privilege as the user account that owns the session. In practice, that's true (things like flatpack claim to support fake sandboxing, but whatever.) Hypothetically, in a universe where Wayland was r…

> they're expecting all software to be rewritten. ALL software was ALREADY rewritten for the web, so just use a web browser running directly on the hardware instead of bothering with X11 or Wayland or some hypothetical replacement like X12. That's just an extra useless layer that nobody needs. A web browser is totally extensible and scriptable in JavaScript and WASM. Standards based. Excellent networking support. Str…

I write software for web browsers for a living and I shudder at the thought of having all of my apps trapped in some bloaty, slow sandbox that's different enough from all the other bloaty and slow sandboxes to not actually support all the software it needs to run.

If I have to live on your world, I'll probably just chuck it all in and work with my hands for a living instead.

Re: Wayland vs. X – Overview

#160

Post by bradrn »

jsrjenkins wrote: post #114
bradrn wrote: post #40

Earlier quoted context omitted.

Odd, I use Arch (well, EndeavourOS) with Sway and have experienced no problems. Quite on the contrary, my setup with a high-DPI laptop + external monitors is far nicer with Wayland than with X.

How is it nicer with Wayland? I have a high-DPI laptop and it works great with X11. What would I gain with Wayland?

What you gain is that programs render at the native resolution of both displays. In terms of appearance, it looks noticeably clearer, since no downsampling or upsampling necessary. But the nicest thing is that it just works — I don’t need to configure any settings to prevent windows from being displayed unreadably small or gigantically large.
Post reply on HN