Re:HW accelerated Xwayland rendering for Nvidia merged
by espadrine on Saturday April 10, 2021 @06:55AM
(#26760545)
In X11, every client is equal.
In Wayland, the compositor has special standing. For instance, KWin will only allow the currently active window to paste.
There is more information here: https://phabricator.kde.org/T4449#192501
Re:HW accelerated Xwayland rendering for Nvidia merged
by atq2119 on Saturday April 10, 2021 @03:56PM
(#26764552)
Leaving aside for the moment that this policy is only a partial protection against a malicious client, the same policy could well be implemented in X11. (The window manager is not fully equal.)
At a meta level, this is probably the most frustrating thing about Wayland: all of its benefits could be realized in the X context itself, even the getting rid of legacy baggage (deprecate parts of the protocol leading up to the definition of an X12).
People actively chose not to do this and instead delayed progress by at least a decade.
Ideally, Wayland would have just served as a tech demo to guide the evolution of X. But as a community, we give too much credit to people working on shiny new things.
With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.
Can you elaborate?
This sounds implausible, wishful thinking since key bindings are managed by individual applications. Whoever holds the clipboard must trust the application that claims to have received a paste command from the user. I don't see anything that could prevent spoofing without just blocking clipboard access entirely or making the usability a lot worse.