> "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...
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.
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.
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.
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.
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.
- 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.