I still wonder how it's possible to start developing replacement for something as entangled in Unix culture as X, then just say "yeah, we're not going to do the killer feature of it" and have community go on with it.
If the point of Wayland is to replace "unmaintainable mess" that X supposedly is, they should show how to provide better protocol for X features, instead of cutting them off and claiming they solved something.
The problem with X11 is that it's everything-and-the-kitchen-sink. You can't solve that by making another everything-and-the-kitchen-sink. You need to cut down in some places and modularize the other things.
One perfectly legitimate way of doing that is to do one of those things and ask others to do the other things. Development would not go faster, if they put those other aspects at the end of their To-Do List as well.
Linux desktop development abandoned Unix culture a while ago. The very few desktop developers do whatever they want and the community mostly goes along with it because they don't have a choice.
Funny, almost everything in the market says the "killer graphics server" feature is extremely high performance, flicker-free video from frame 0 and HiDPI support. X cannot do either of those things, period. It just wasn't designed for it.
Extremely vocal minority users like you and the others on Hacker News are simply not in anyone's support matrix. Luckily, all of you folks crying for the lack of this feature are all tech experts - if you want it, go code it up yourself.
Meanwhile, anyone and everyone else that cares will just switch to VNC and move on as if nothing happened.
That train left more than 10 years ago, and nobody noticed. The applications you were using during these years used a local mechanism (MIT-SHM, DRI, etc) to transfer buffers between the application and X server. If you try to force them to use a socket (you know, to emulate a really fast network), you would not be satisfied with the user experience.
So basically, nobody noticed, because nobody is using it in this scenario. That occasional remote dbca session doesn't count ;)
I think in practical terms that will end up being a toolkit/framework question. In many cases remote usability is already ruined under X simply due to clients doing wildly inefficient stuff, assuming MIT-SHM, or what have you. I've used one program where it was blatantly slow just going across a virtual switch to a VM on the same machine.
Technically, wayland does not have a display server.
It has a compositor, which could be considered more equivalent to X11 window manager than to X11 server. The compositor handles display and input by itself (using KMS, DRI, libinput, etc.). Examples are Gnomes Mutter, KDEs KWin and Sway.
Among other things it means less context switches and synchronization when trying to display something, smoothly.
The new Ubuntu GNOME desktop doesn't use Mir, but Mir is still being developed for other uses, like embedded devices. It's also one potential way Ubuntu MATE may get Wayland support.
So it should really say "Next steps for Wayland support in MIR". As it is, it seems a lot like this is for Ubuntu proper and not just those who want to maintain MIR. If MIR isn't the main path forward for Ubuntu, then this is not relevant for a lot of Ubuntu users.
This is a Wayland-based 3D compositor for usage in VR (HTC Vive, etc). Imagine a future Ubuntu that let you navigate your work in highly immersive 3D environments. :-)
Given the graphical glitchiness and inconsistency of even 2d desktop environments in Linux the idea of experiencing that in 3d seems... irritating at best, nauseating at worst.
> There’s currently not a good Wayland test suite - something you can run against your compositor implementation to verify that your implementation of the protocol behaves as expected.
Bad test suite was one of the reasons why Canonical started Mir in first place. It is good to see this ported to Wayland.
20 comments
[ 4.1 ms ] story [ 50.4 ms ] threadremote windowing support.
that would be great for the ecosystem.
If the point of Wayland is to replace "unmaintainable mess" that X supposedly is, they should show how to provide better protocol for X features, instead of cutting them off and claiming they solved something.
One perfectly legitimate way of doing that is to do one of those things and ask others to do the other things. Development would not go faster, if they put those other aspects at the end of their To-Do List as well.
Extremely vocal minority users like you and the others on Hacker News are simply not in anyone's support matrix. Luckily, all of you folks crying for the lack of this feature are all tech experts - if you want it, go code it up yourself.
Meanwhile, anyone and everyone else that cares will just switch to VNC and move on as if nothing happened.
So basically, nobody noticed, because nobody is using it in this scenario. That occasional remote dbca session doesn't count ;)
It has a compositor, which could be considered more equivalent to X11 window manager than to X11 server. The compositor handles display and input by itself (using KMS, DRI, libinput, etc.). Examples are Gnomes Mutter, KDEs KWin and Sway.
Among other things it means less context switches and synchronization when trying to display something, smoothly.
This is a Wayland-based 3D compositor for usage in VR (HTC Vive, etc). Imagine a future Ubuntu that let you navigate your work in highly immersive 3D environments. :-)
Bad test suite was one of the reasons why Canonical started Mir in first place. It is good to see this ported to Wayland.