Wayland =~= X11
Weston =~= X.org/X86free/Anything else implementing X11
Ok, lemme get this right...
So, comparing this to vnc. First variant would be starting Xvnc being rendered locally yet viewed over the RFB protocol (which is optionally locally possible). This is comparable to a server with thin clients (right?). And the second variant would be running X locally, and have x11vnc polling for changes and making those available as an RFB stream (like me assisting my parents).Originally Posted by Nobu
But this time, it's integrated into the compositor in the new Wayland 'model'.
So, something like: a compositor (e.g. Weston) depending on a library (e.g. librender). This librender depends on libfreerdp, libvnc, libnx or whatever. So whatever compositor links against librender get's the rest for free. Would be nice.Originally Posted by renox
So, instead of what renox said: You write a compositor purely for RDP and another compositor purely for VNC and stack that on a compositor currently rendering on a local backend (like DRM or FB).Originally Posted by EricG
But for that to work, you need screen to manage this shell in order for this terminal to be available both locally and remotely. I guess Wayland is analogue to screen in this case?Originally Posted by elanthis
But you still need Wayland for every backend, right? E.g. gtk is ported to Wayland. So you should get GTK+ -> Wayland -> Weston -> FBDev. And not GTK+ -> Weston -> FBDev. And the final step depends on Weston supporting whatever back-end you want it to.Originally Posted by giselher
This is getting 'interesting'. X was split into Wayland and Weston. Okay, so one could say that Wayland is purely a middelman that connects toolkits to your screen. But to manage your screen you use a compositor that responds on user input. I follow on that. Now, this compositor get's all sorts of plugins. BUT, the functionality those plugins provide could also be used by (supposedly) other (stacked of course) compositors. So you have 2 ways of implementing the same functionality. Just one is compositor specific and the other one is not. However, the compositor specific method could be build into a library so that all the compositors that link to it recieve that same functionality.
Please understand that I don't quite follow the general idea anymore...
Wayland =~= X11
Weston =~= X.org/X86free/Anything else implementing X11
Your statements make no sense to me.
1) A librender would be a good idea, assuming its technologically feasible. I put that disclaimer inl because I don't know the design spec for Wayland compositors, and therefore maybe it wouldnt actually work. But assuming it could work, thatd probably be a good idea.
2) X, Wayland, and Weston are three VERY different things. X was not split into anything. X, was a protocol from the 1980s. Wayland is a new protocol started I think 2years ago, and Weston is the reference/example compositor for Wayland.
X and Wayland are JUST protocols, they don't actually handle screen management (maybe X did or can but it doesnt anymore, so peanut gallery: shush). To handle window management you need a separate application that speaks the X / Wayland (or both) protocol. For X we have like...God only knows. There's metacity, mutter, Kwin, the *boxes, the *poisons, E17, and tons of others.
For Wayland we have... Weston, which is the EXAMPLE compositor that the Wayland guys themselves wrote to show people how things work and what you should/shouldnt do when youre writing your own compositor. Gnome Shell and Kwin (KDE) Are in the process of being ported over to Wayland, they are doing it in such a way that they will detect at runtime whether they are being run on X or Wayland, and choose the appropriate codepath.
Now, as far as the backends. Typically you want to run Wayland on pure hardware. Not always though. Thats when the backends come into place: people have written a DRM backend (thats the hardware one) theyve written a Pixman one (thats software rendering on the cpu, bad idea for the most part. But if your graphics card is crap / broken drivers, it'll get the job done. So its a good backup to have.) They've now written an RDP one.
The idea of the backends is its different ways the compositor (not the protocol) can be run. So if you have a FreeRDP-capable compositor on a server, and you connect via a FreeRDP client to that server. The compositor will see the incoming connection, recognize it as FreeRDP, and give you a connection. Maybe it will be the current session, maybe it will be a new session (probably able to choose between those two) and a few seconds later the desktop will appear on the computer you're connecting from.
The protocol itself does not care about backends, backends are for the compositor. All the protocol cares about is getting pictures from A to B, where B is a screen.
Now, you brought up the X backend. The X backend, unless im mistaken, is XWayland. XWayland is so that if you have an application that was specifically written for X (Not done in a modern version of GTK or Qt) that they can still run under Wayland. Wayland will spawn a special X server that is the exact size of their window. X thinks its in charge but when it goes to display the contents of the screen, its actually pushing them to a Wayland buffer and then Wayland handles where, when, and how to display the contents.
Dear god do I hope that clears things up because your last post was a complete mess >.< (not your fault, everyone elses)
- X on Wayland: an X client which talks with a special X server (XWayland) which itself will use Weston as its backend and then Weston will send the data to its own backend.
- "Wayland" on X: Weston has an X backend, which means that instead of discussing directly with the hardware, Weston can send its buffers to an X server which will talk with the hardware.
This was mostly useful when developping Weston..
Also your clarifications about Wayland was a bit incorrect, Wayland is:
- the name of the project
- the name of a protocol
- the name of a library which implement this protocol.
Overloading is bad for communication, so I prefer to talk about the Wayland Foo (Foo=project, developers, protocol, library) than Wayland alone.
X clients under Wayland is XWayland (see: http://wayland.freedesktop.org/xserver.html) XWayland has to be merged into the X server to listen for Wayland connections.
I'm sure there was a Wayland-clients-under-X way but I have yet to see a link describing it.
You wrote "Now, you brought up the X backend. The X backend, unless im mistaken, is XWayland" and "XWayland has to be merged into the X server to listen for Wayland connections."
but wikipedia says "xwayland was written to enable running X11 applications through an X server, optionally rootless, running as a Wayland client" which means that XWayland is not listening to "Wayland connection"! It is listening for X client connections and then sending the buffer resulting of their (X) commands to Weston as a Wayland client.
Xwayland adds support into the X server to push the images to a wayland buffer, instead of the screen. You dont have to modify any clients to get this, but you do have to modify the X server. Its not seamless for the X server, it does actually know that its not in TOTAL control anymore because theres a special wayland code path (it gets wayland input devices, see above)Wayland is a complete window system in itself, but even so, if we're migrating away from X, it makes sense to have a good backwards compatibility story. With a few changes, the Xorg server can be modified to use wayland input devices for input and forward either the root window or individual top-level windows as wayland surfaces. The server still runs the same 2D driver with the same acceleration code as it does when it runs natively. The main difference is that wayland handles presentation of the windows instead of KMS.
Quite honestly im not even sure what we're debating at this point... See: https://vignatti.wordpress.com/2012/06/13/x-on-wayland/
The X server, with the Wayland backend on it (xwayland), keeps listening Weston via a special Wayland protocol interface. Weston binds such interface and announces back the socket that X clients will be connecting to (xserver_send_listen_socket event) and the first X client that was just connected (xserver_send_client event).
I think that we agree totally on how XWayland works, I was just pointing out that some of your sentences were a bit ambiguous, but maybe it's because I'm not a native English speaker..