Wait is there a separate implementation for sway and other wlroots? Because sway is wlroots based, that's where wlroots originates?

I might be wrong about Sway not being wlroots based. But there are a lot of compositors that are not based on wlroots

Yeah, sway is wlroots. But GNOME and KDE are both doing their own thing, so the point is in generally perfectly valid.

This is growth pains.

Once the the need is understood well enough, a common extension will be written, and Mutter, KWin and sway/wlroots will implement it.

This is better for security than X11 free-for-all.

I agree that Wayland by design can be more secure - but judging from my personal threat model, if malicious code gets to attack X or Wayland, it's already all over.

> a common extension will be written, and Mutter, KWin and sway/wlroots will implement it.

Like how they standardized nice simple things like taking a screenshot?

Isn't the use case of apps injecting mouse and cursor events the "security free for all" that Wayland is trying to prevent?

Full disclosure, I am a Wayland skeptic. I don't think your focus on X input security is as justified as you probably think.

I think Wayland's security model was more worried about reading inputs than writing them (i.e. preventing keyloggers). Of course https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.htm... also exists, so...

Writing events is certainly a potential security problem.

I know in the Windows world, one of the UAC features was that a less privileged process can't send events to an elevated window.

In X11, I think last I checked most distros disable the XTEST extension by default out of security concerns. Skimming the warpd code, they are using XTEST for the X backend.

As I think of the keylogger problem, it's not really privilege escalation, is it? If you're running as the same user as all the other clients, you could ptrace(2) them and intercept their event loops. I guess there are some container-based app deployment solutions now where you could run stuff at different security levels, so maybe it's more of a legit issue now...

If it is implemented it will most likely go through the xdg-desktop-portal, with a policy controlled by compositor.

And most likely it won't be injection of mouse and cursor events, but something higher-level, like focus switching requests.

Are you aware that the use case here is simulating a mouse? Focus switching is not enough.

Ah, I mixed it up with another tool, sorry.

This one looks like a small feature in a compositor and not an external tool, really.

I guess it would take 100-200 LoC to implement in GNOME Mutter.

Then you'd need to implement it in every compositor.

Excuse me for being blunt. I don't know if you understand how shitty of a design you advocate. Solid designs do not require modifying core components to write application level features the original authors did not envision.

Excuse me for being extra blunt. I don't know if you understand how shitty of a design you advocate. Solid designs do not open users to being attacked and their credentials stolen by malicious applications, including sandboxed ones.

Moving cursor around is a compositor's domain, not some arbitrary application's that decided to fiddle with the user's input.

To you it's an arbitrary program. To the user it's a program they want to work.

An API should not be so preachy about which programs can theoretically be written. It should provide broad mechanisms.

It is very frustrating to work with people who think like you do, that 3 or 4 unrelated projects have to carve up narrow exceptions to how the platform works for every single use case, nominally because of theoretical harm of this exploit no one will write, but actually more based on your ego perception that you know better than every other developer on the planet.

So Wayland has this long list of impossible applications which are doable everywhere else. It's a prima donna.

Where were you seeing that. I only glanced through a handful of files, but it appears to be one implementation for me:

https://github.com/rvaiya/warpd/tree/master/src/platform/way...

If there is a distinction, and there might be, "completely separate" is exaggerating.

Edit: I see that only wlroot based implementations are supported so far, and of those there are some things broken in wayfire. Perhaps this is what you're referring to?

The wayland implementation does not support Gnome Shell on wayland (arguably the most mainstream combo since it's the default in ubuntu). To support Gnome Shell on Wayland, you need to include a Gnome Shell extension which has some headaches. X is a third implementation. And then there is one additional implementation per Wayland compositor that is not based on wlroots

Not a full and completely separate implementation though. Just wrappers to mask differences in compositor extensions that haven't been stabilized yet. If there are none the implementation is simply impossible.

Personally I don't think Wayland will get to a good spot until one compositor "wins" and provides interfaces for modification/extension such as e.g. X-like ability to write window managers without replacing the whole compositor. At this point I see no compelling reason to switch to Wayland for my own part.

There's XWayland for interop. Besides that, people have been moving away from X11 for years now.

I still question myself as to why

Have you actually used Wayland? Besides the obvious current issues (compatibility and/or missing features), it is way better. Even something as simple as moving and resizing windows feels noticeably faster and more responsive on Wayland compared to X.

I don't use it at the moment because of compatibility issues with some software that I use, but that's not Wayland's fault.

> Besides the obvious current issues (compatibility and/or missing features)

I mean, that's the whole biggest criticism of wayland, 15 years in and it still doesn't work (well?) with the biggest GPU brand. The criticism has always been about whether it is worth it to fragment linux land and throw away a few decades worth of work on X.

My criticism of Wayland has always been that they dropped a spec, forgot to make an actual server, and now every window manager needs to implement support for various extensions separately. It's a fine design if you assume everyone only uses Gnome, but...

It's not just throwing away a decade's worth of work on X, it's making everyone redo that work per display manager (thankfully wlroots exists as a kind of Wayland shared library).

You can reduce that list from 4 to 3 (sway and others use wlroots. GNOME is the one weird out in Wayland)

Eh. Sway uses wlroots, but KDE is a completely different option that they didn't list so it comes out in the wash.