The main selling point of Wayland is the simplification of graphics pipeline

> "The wayland tag line is "every frame is perfect", by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker" -- Kristian Høgsberg, creator of Wayland [1]

Input handling and related issues are mere afterthought in comparison.

Besides that, this project is not really keylogging Wayland in any meaningful way. Wayland compositor sends the key events to the application and its the applications responsibility from there on to do whatever it pleases; in this case it printing them to stderr but that is incidental. Wayland can't just magically protect you from having malicious code running within your application.

edit: a strained analogy, but this thing is akin to saying that "you can eavesdrop https" and then show ld_preload hooks for intercepting openssl calls.

[1] https://www.phoronix.com/scan.php?page=article&item=xorg_way...

> a strained analogy, but this thing is akin to saying that "you can eavesdrop https" and then show ld_preload hooks for intercepting openssl calls.

Well, it would be fair game if it were popular to discuss how HTTPS helps against malicious local programs, like it is pretty popular with Wayland.

There are like 10 weak points in the linux security model. Wayland plugs one of them but there are still a bunch of ways around it. Yes any program you install from the package manager can still see everything but wayland combined with flatpak and SELinux gets really close to a secure system similar to MacOS.

The selling point is that it becomes possible to have a system that's resistant to keyloggers. If the rest of the system is secure then Wayland doesn't undo that unlike X.

What is "2021" about this Github repo?

The fact that the logger still works great.

It's hardly the main selling point, but yes, it's often stated in such language that is sufficiently bereft of technical specifics so that the lay user reading it will gain the impression that the aforementioned proof of concept is not possible, but also that, when præsented with it, semantics arguments can be fronted that are more technical, to allow a statement that it wasn't so intended.

On a more practical level: if the statement indeed eventually be phrased so that it does come with the technical truth, the practical gains are not of security, but performance, and only when not using nVidia cards.

Better phrased, it is:

> The current state of Wayland is that it allows for better hardware acceleration when sandboxing on X11 , except with nVidia cards, where on many compositors it does not allow allow for hardware acceleration at all.

X11 allows for similar sandboxing by way of a nested server, but hardware acceleration is insufficiently implemented as of this moment. — this is not a theoretical impossibility and it could be implemented; it simply isn't fully, at this time.

Giving every application its own X server kinda works but it breaks all the same things that Wayland does. The idea isn't all that different than XWayland.

The difference is that it's optional rather than globally enforced.

In theory it could also allow for finer tuning in deciding what is visible within what nested server, but that hasn't been implemented yet.

As I understand it, Wayland doesn't define a protocol for using the server's hardware to render. Waypipe requires rendering at the client (probably in software, because datacenter GPUs are a rare extra) followed by a video codec for remoting.

Yes, in both cases it is not not for technical reasons.

Many Wayland compositors simply lack support for nVidia cards as they use a different protocol than all the others, and many graphics acceleration calls are simply not implemented through nested servers.

What I’m getting at is that Wayland has better hardware acceleration only of compositing. It doesn’t seem to have any support for rendering shapes into pixels, even though that’s mostly why hardware accelerators were invented.

As far as I know, there is no technical reason why Wayland would have better hardware acceleration.

Modern X11 compositors work on very similar principles. — the only difference is the Wayland protocol requires that there be such a compositor, and on X11 one is free to even use outdated server drawing calls that have not been used for decades.

But there is no reason for X11 to be in the picture, it does absolutely nothing other than adding another communication step between the client and the compositor.

What dialect of English are you using?

I am not a native speaker; it can thus be assumed to be a combination of many different dialects. My pronunciation, however:

- features the trap–bath split

- is non-rhotic, has a fairly consistent linking-r, but no intrusive-r.

- ordinarily features the whine–wine merger, but does split them again in stressed interrogatives

- does not undergo flapping of alveolar stops

- ocasionally realizes fortis alveolar stops as glottal stops intervocallically, but never in a stressed context

- realizes fortis alveolar alveolar stops as affricativess before /u/ and /i/ in a stressed context, rather than as aspirates

- features l-vocalization in the coda of syllables

- features neither yod-dropping nor yod-coalescence such that “soot” “shoot” and “suit” are a minimal triplet

- fronts /ai/ to a realization of [ɑe̯]

I know of no actual English dialect that combines these features, as expected of a non-native speaker, with the exception of it's non-rhotic nature, it seems to gravitate towards a realization that mostly combines the different kdistinctions made in most dialects, assimilating splits, but not mergers.

I'm guessing "præsented" is what caught GP's eye. I've never seen that before, was is supposed to be "presented" or is that how it would be spelled in your native language/dialect?

Seems like a GPT-3 post to me.

How does that interact with things like the steam overlay were a third party UI is hooked into an application? I would expect that either that functionality is completely broken or that you could still implement keyloggers going this route.