Tweet
Originally posted by Ironmask
View Post
Wayland is an alternative to X, not the next version of it.
-
Hmmm, I don't think that is true there are quite some differences, including X being a display server while Wayland is not.
Wayland is an alternative to X, not the next version of it. -
Spiritually, not literally.Originally posted by geearf View Post
There cannot be an X12 because, as I said, X11 is unmaintainable. No, not the Xorg source code, although that is also horribly unmaintainable. The entire X11 specification in itself has become an unmaintainable monster, requiring implementation of some insane and useless APIs that nobody has any need for anymore. There's a reason Xorg is the only complete X11 implementation. And as I said, to remove any of that is to break the X11 standard. If you have to break it, you may as well completely re-do the spec. This is why Wayland is the next Xorg, because that's what the Xorg team is doing.Comment
-
I think that project you were referring to was Xweston(?). Basically the Weston compositor that loads up a fullscreen Xweston.Originally posted by Quackdoc View Post
One issue with this is that Xweston is not very standalone; it shares much of the Xorg codebase (so doesn't achieve too much yet). But yes, that could be simplified in time and the underlying layers of Xorg replaced by the underlying layers in the Weston compositor and merged. However, the underlying layers of Xorg aren't actually too bad. In particularly the video drivers plugin design is quite clean and workable.
Some of the uglyness of X11 comes from the extensions (Xshape, etc). But there is far more uglyness in Win32 and Quartz and both of these are lightyears ahead of Wayland. Particularly because they don't get replaced nearly as often. The closest thing was Carbon but that was only a programming interface; not an entire display system.
X isn't a display server. Some random notes to clarify the software responsibilities if you find it useful.Originally posted by geearf View Post- Wayland is a protocol and X11 is a protocol.
- Xorg, Xsun, Xvnc, Xenocara, etc are X11 Xservers
- Weston, Sway, Hikari, etc are Wayland Compositors
- dwm, i3, openbox, cwm, fvwm, etc are X11 Window Managers
A Wayland Compositor is the equivalent to an Xserver + Window Manager. Some of us like that separation, some don't care.
Edit: There was also Postscript (protocol) for NeWS (the display system). It had a considerably similar concept. There was even Xnews as an intermediate during transition that was for Postscript and X10 and X11. Interesting stuff, the open-source world is just going in circles.Last edited by kpedersen; 23 March 2023, 07:20 PM.Comment
-
nah it was another project, I actually found a link to it, doesn't seem like it's in active development thoughOriginally posted by kpedersen View PostComment
-
-
That is a incorrect presume. Wayland compositor do exist that have Windows manager as a independent part but they are not popular. Most well known example of Wayland compositor with independent Windows Manager process is Mir. Wayland protocol does not forbid the separation or mandate it.Originally posted by kpedersen View Post
https://manpages.ubuntu.com/manpages...ton.ini.5.html weston using a dynamic library load equal to windows manager yes the shell thing.
What the advantage of merging the Xserver bit and the Windows manager into one less memory and cpu usage and reduced stalling. Yes having everything in the one process(PID) reduces the case of miss allocation cpu by the kernel scheduler so reduces cases of kernel scheduler caused stalling/stuttering of the interface.
Comment
-
Yes you need to take the X.Org Foundation page with a serous grain of salt.Originally posted by kpedersen View Post
Last edited Wed May 31 00:29:03 2017
That page is before Xwayland maintenance it take up by redhat as it own project and before Weston and Wayland moves over to freedesktop.org.
Yes 2017 X.org Board was still pretending they had infrastructure when they were basically leaching off of freedesktop.org without a proper deal for resources usage.
Do note the page I quote was current
Last edited Thu Oct 13 07:46:19 2022
Current state of the world Wayland is not under X.org Board control.
Do note where the wayland project is now. Nothing is linked back to parts X.org board members control. Wayland at one point use to use x.org mailing lists that changed in 2018.Last edited by oiaohm; 23 March 2023, 11:04 PM.Comment
-
A standalone Window Manager can't exist in the Wayland ecosystem. The design of Wayland prevents knowledge of other windows. This is one of the falsely stated "security" features of Wayland.Originally posted by oiaohm View Post
The closest the Wayland guys have is a plugin system (i.e Weston's Shell can be replaced, Mir does the same) but that isn't a Window Manager. That is more similar to i.e Fvwm's Modules.
I think the ratty Win32 API is closer to allowing a Window Manager than Wayland is.Last edited by kpedersen; 24 March 2023, 05:56 AM.Comment
-
This is where you have to be careful.Originally posted by kpedersen View Post
This is interesting right. So information about windows traveling over dbus. What about MIR. Mir use to have its own IPC guess what information about other windows could travel over that.The Introspect D-BUS API in mutter provides a way to list all toplevel windows.
The wayland ecosystem does not say the only IPC you have to use is Wayland Protocol.
No that is not the closest. Early MIR that is MIR protocol/ Wayland protocol hybrid and arcan get the closest. Arcan is also a Wayland compositor as well as A12.Originally posted by kpedersen View Post
The odd stall out for 5 second events that X11 server suffers from turned up with MIR and Arcan with windows managers as individual processes.
It never crossed you mind for one minute that this design of Wayland may not have been for security alone.
The more applications wanting access to the same information the deeper the stalllock you can generate and the more complex it can come for the kernel scheduler to allocate CPU time to dig self out of stalllock. Yes a stalllock is not a deadlock because there is way out the catch is working way out. Having the interface stop for 5 seconds + does not make users particularly happy.
The developer of Wayland had looked into X11 x.org random stalling problems. Limiting applications with access to screen positioning data limits how deep of a stall you can end up in..
WIN32 API does not attempt to use one IPC for everything either.Comment
-
Where do you get the crystal ball for your blank statements?Originally posted by Ironmask View Post
X11 is unmaintainable, and yet is it being maintained.
There is not a lot of new development, since it works well for ages.
It is a horrible mess, and yet just one year ago, it was used by 90% of Firefox Linux users.
How would you know which APIs are not used by nobody?
If really nobody would be using them, it would be simple to remove them, recompile everything, and we would have X11R8. Apparently there is old software, which use those APIs, and nobody actively develops that old software, but that does not mean nobody is using that software.
It is easy to break the standard and start a new protocol, but it is much harder to replicate the functionality of the old system, and win over the developers... or ever users, if you offer few tangible benefits, and backwards compatibility is not 100%. While rewriting old software is impossible.
X11 was "dead" from the time all Unix workstation manufacturers died. All major Unix related standards were developed by them (NFS, OpenGL, X11, Motif, C, Java, ...). Linux was leeching on this work, re-implementing the standards. To the point where Linux is the only relevant Unix left (being officially certified or not). But Linux has proved to be much less capable of making interoperable standards of its own, and have then accepted into non-Linux platforms. Wayland is the most prominent example of such failure. WSL(G) is struggling for years, and still it has not reached a state, where it would be usable for actual work.
Comment
Comment