11 ms·
Why don't you propose a protocol to solve the issues you have? If it solves a problem other users have it would get adopted I'm sure (except maybe GNOME). I'm
by c487bd62 6y ago
Why don't you propose a protocol to solve the issues you have? If it solves a problem other users have it would get adopted I'm sure (except maybe GNOME).
I'm not a Wayland developer but it's what I observed in the issue tracker of my WM. A limitation is often overcome by a protocol and a basic implementation after. If you put the work in, the wlroots and KDE people are always very nice and will help you get started.
https://github.com/wayland-project/wayland-protocols/tree/master/stable https://github.com/wayland-project/wayland-protocols/tree/ma...
https://github.com/wayland-project/wayland-protocols/tree/master/unstable https://github.com/wayland-project/wayland-protocols/tree/ma...
https://github.com/swaywm/wlr-protocols/tree/master/unstable https://github.com/swaywm/wlr-protocols/tree/master/unstable
- hedora 6y agoThey did propose a protocol: X11 plus sandboxing, modeled after the windows approach to sandboxing.
- c487bd62 6y agoAnd they are free to continue adding features and maintaining their preferred software choices. Nobody else seems to want to do it. IIRC the X11 maintainers are the same people who started Wayland. > https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/ https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fed... > Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is. But we were talking about Wayland here. You're free of course to fantasize about hypothetical scenarios or propose features to software nobody wants to maintain.
- hedora 6y agoYeah, the end game for this seems pretty horrible. Wayland (still) doesn’t work, and is user-hostile (at least for this user). The BSD’s and most applications I use seem to be sticking with x.org. Maybe this is the end of portable, open source video stacks.
- ComputerGuru 6y agoOne of the problems is that X is effectively being deprecated in favor of something that isn't X 2.0: it has different goals, different targets, different ideologies, and not to mention different architecture. Eg Wayland is unashamedly Linux-centric (mind you, definitely not the same as Linux exclusive), while X most definitely isn't. One was designed to allow for remote rendering, one wasn't. One integrates the window manager functionality and one doesn't. The list of course goes on.
- ATsch 6y agoThe things you list have not really been true in the real world for a long time. Modern Xorg uses the same Linux exclusive APIs as Wayland, is not network transparent, relies heavily on window manager and compositor features, etc. Modern Xorg and Wayland are more or less conceptually identical. Wayland just replaces the X server with a UNIX socket and has a clean slate for APIs.
- vetinari 6y agoOr, in another words, Wayland is the same as the modern X, minus the legacy core that couldn't be removed from X because it is not extension (anyone using stippled unaliased lines yet?) and plus sandboxing.
- wott 6y ago1. You're conflating X and Xorg. 2. Network transparency is still there and I use it everyday. The problem is toolkits (GTK and others) who decided it would be 'simpler' to redo everything themselves in a canvas. Of course the result of not taking advantages of X primitives was a massive slowdown over the network. 3. Wayland sits at an odd place, not having the advantages of being a proper protocol in the sense of X (complete abstraction from the substrate), while at the same time not having the advantages of being a direct API to hardware (simplicity, performance).