For some reason I thought one of the selling points of Wayland was that it could be more performant and less limited by not supporting the X11 Network Transparency functionality. Was I just completely misreading the motivations? Or is this a complete pivot for the project?
I think the selling point of Wayland at this stage is that “it’s not X”. Compare the presentations on it and see how much time is spent berating parts of Xorg versus actually saying what they want to achieve. “It’s not X, It’s simpler” - yet when you delve into the details, it’s very much a case of ‘the new boss, that looks strangely familiar to the old one". If you happen to be interested in this subject, compare two xorg devs. on how to proceed: https://www.youtube.com/watch?v=RIctzAQOe44 vs https://www.youtube.com/watch?v=-tNTqpH7XhE
There is a huge chasm between what x11- network transparency does and what this project attempted. X11 covers a lot of protocol bits about drawing primitives (bezier curves, text rendering and so on) and subsequently things like ‘what metrics will the given font have based on this input) which Wayland does away with entirely, which might’ve actually been one of many mistakes - but that’s a longer discussion. The reasoning was essentially “toolkits (meaning GTK, QT, anything else is pretty much discarded as old cruft) doesn’t use this feature, so why keep it”.
Anyhow, the “not supporting” parts: you don’t “know” more about a surface than if it comes via a pixel buffer through shared memory or as an opaque handle transmitted as one or several file descriptors that you then pass on to the EGL implementation (though there are some slight metadata available - like if there’s alpha channel information for blending, or if there are explicit relationships between different surfaces or if something is a popup - though the last case is more complicated than that). This means that network remoting boils down to VNC- like remote desktop features, and the implementation in the article is even worse, it’s just streaming uncompressed pixels and forwarding the line-format for events - but even that is really unsuitable for anything as soon as latency goes up.
Drifting out on a tangent: the input parts mentioned in the article belongs to some of the really “Worse than Xorg WTF” that’s inside wayland. Clients don’t deal with abstract inputs like XKeysyms used to (the overly verbose 16-bit abstract identifiers). Instead, you either get raw, linux evdev specific keycodes OR a file descriptor to a “simplified” (the real format is like ASN.1 kind of xcrazy, this just comes close). Every client is supposed to map this file, parse it and then maintain its own keyboard state-machine, including things like key-repeats. This introduces all kinds of problems since now the server can’t reliably know what state the client is in (think sequences like ‘a’+‘`’= à), making it impossible to safely inject/synthesize input. The list goes on..
Was I just completely misreading the motivations? Or is this a complete pivot for the project?
Neither. This was an external party’s proof-of-concept that, as noted further down in the comments, never evolved past that point.
<snark>Yay, they’ve re-invented X11! And the people of 1987 rejoiced?</snark>