| |||||||||||||
Wayland the "successor" LCA: The X-men speakWayland the "successor" LCA: The X-men speakPosted Feb 11, 2013 21:26 UTC (Mon) by atai (subscriber, #10977)Parent article: LCA: The X-men speak
The X people may not agree that Wayland is the "successor"?
(Log in to post comments)
Wayland the "successor" LCA: The X-men speak Posted Feb 11, 2013 22:18 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]
The X people ARE the Wayland people...
Wayland the "successor" LCA: The X-men speak Posted Feb 11, 2013 22:55 UTC (Mon) by pjhacnau (subscriber, #4223) [Link]
OK, time to display my ignorance ... As I understand it Wayland is _just_ a compositor. Whatever will actually replace X will be built on top of Wayland. So technically it isn't a successor.
Wayland the "successor" LCA: The X-men speak Posted Feb 11, 2013 23:40 UTC (Mon) by neilbrown (subscriber, #359) [Link]
You should watch the LCA video....
Wayland isn't "just" a compositor, though that is a lot of what is does.
But you are right in that wayland is just part of a complete solution. It is just a specification (I think).
Wayland the "successor" LCA: The X-men speak Posted Feb 12, 2013 17:58 UTC (Tue) by iabervon (subscriber, #722) [Link]
As the current article says, the new thing in X rendering is better buffer management, because clients already draw everything themselves to buffers that are shared with the X server. Wayland just drops support for drawing methods that modern clients don't use any more.
Wayland the "successor" LCA: The X-men speak Posted Feb 12, 2013 8:22 UTC (Tue) by rossburton (subscriber, #7254) [Link]
Just watch http://mirror.linux.org.au/linux.conf.au/2013/mp4/The_rea..., it explains what's broken with X and why Wayland is going to be the future. This future isn't ready yet, but it's getting close!
Wayland the "successor" LCA: The X-men speak Posted Feb 13, 2013 0:06 UTC (Wed) by daglwn (subscriber, #65432) [Link]
I was initially very skeptical about Wayland but after some long (and sometimes painful!) discussion here on LWN, I am really looking forward to what this will bring.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 8:30 UTC (Thu) by Serge (guest, #84957) [Link]
> I am really looking forward to what this will bring.
You can see it for yourself. There're wayland livecds. Download http://sourceforge.net/projects/rebeccablackos/ burn it to DVD or manually unpack to a bootable USB stick and try it.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 6:21 UTC (Thu) by Serge (guest, #84957) [Link]
Why people always talk about Wayland as an alternative to X and never mention DirectFB? It should be better than wayland in every aspect. It's fast and small, it works even on embedded devices. And looks nice: http://www.youtube.com/watch?v=xZ_YieaGDBM
DirectFB people never attempted taking the place of X.Org. They could, just never tried.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 13:56 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
It's definitely not "better in every aspect". DirectFB is a very lightweight X-server look-alike moved into the kernel. It has no real support for running OpenGL applications and can only do simple compositions.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 19:15 UTC (Thu) by Serge (guest, #84957) [Link]
> It's definitely not "better in every aspect".
Maybe. :) But it's not that obvious.
> DirectFB is a very lightweight X-server look-alike moved into the kernel.
It does not require kernel patches. It only builds a fusion kernel module for fast IPC. And it's much farther from X-server than Wayland.
> It has no real support for running OpenGL applications
DirectFBGL? You can see some 3D-looking samples in http://ilixi.org/ video.
> and can only do simple compositions.
Weston can also do simple compositions. It's up to the compositor, I guess.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 19:25 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
I had been watching DirectFB development very close back in early 2000-s. As far as I remember:
1) It uses Linux FB support for modesetting. So no multiple monitors, rotation, etc. 2) It has its own input stack. 3) It required custom kernel modules and direct hardware access from the userspace (ugh).
I don't remember it ever trying to support OpenGL, but I guess that blitting from a texture to framebuffer is not that complex to add if you have a working EGL.
In short, DirectFB is more like a classic framebuffer with several hardware accelerated operations. It's not nearly enough for modern graphics.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 15:14 UTC (Thu) by renox (subscriber, #23785) [Link]
> Why people always talk about Wayland as an alternative to X and never mention DirectFB?
Probably because DirectFB's documentations and introductory materials suck so much that I've never been able to understand how it works (I'm probably not the only one considering that all the discussions about DirectFB I've seen are "it works like this, no it works like that, no, etc").
> DirectFB people never attempted taking the place of X.Org. They could, just never tried.
You don't get to be successful by not trying.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 5:22 UTC (Thu) by Serge (guest, #84957) [Link]
> As I understand it Wayland is _just_ a compositor.
Well, Wayland is a protocol. The application implementing the server side of this protocol is a Compositor. Current reference compositor is called Weston.
You can think of wayland compositor as X.Org and Compiz and Emerald and Gnome-Panel and XScreenSaver and a few more things all in a single application.
Wayland protocol is simple. It does not allow you to do most of the things you use daily. I.e. you can't have a dockbar or system tray, can't manage multiple monitors, can't even have a password-protected screensaver. Since none of these are supported by the protocol they'll have to be done by the compositor.
If wayland becomes popular you'll end up choosing between compositor with a nice taskbar, compositor with multiple monitors support and compositor with useful window manager.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 5:30 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Nothing stops you from making a pluggable compositor. Or even creating a standard compositor protocol for screensavers and youtube-cat-video-viewer.
In reality, screensavers are not that a big deal. Making them pluggable is easy.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 6:10 UTC (Thu) by Serge (guest, #84957) [Link]
> Nothing stops you from making a pluggable compositor. Or even creating a standard compositor protocol for screensavers and youtube-cat-video-viewer.
Sure. And that's the point. Wayland is advertised as a simple replacement for X.Org, that is supposed to be smaller, faster and easier to use. But currently it's smaller than X.Org for same reasons as Paint is smaller than Photoshop — it lacks many features. If you add all the missing features into wayland protocol it will grow as large as X11 is now.
Turning those features into plugins won't help much as well. It's just instead of large and complex wayland protocol you'll get a simple protocol together with large and complex weston Plugins API.
What's the point of wayland then? Reinventing X.Org from scratch?
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 8:15 UTC (Thu) by khim (subscriber, #9252) [Link] Turning those features into plugins won't help much as well. It's just instead of large and complex wayland protocol you'll get a simple protocol together with large and complex weston Plugins API. Which can be happily ignored by most applications. The bits which are needed by applications (things like notification pupups or tray icons) are not supported by X anyway and are implemented separately even today.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 9:35 UTC (Thu) by Serge (guest, #84957) [Link]
> The bits which are needed by applications (things like notification pupups or tray icons) are not supported by X anyway and are implemented separately even today.
They ARE supported by X. That's the beauty of X. You don't have to patch X.Org to get system tray. You just need a tray host, and you can use regular X11 messages and EWMH to make it work, X11 is flexible enough for that.
Wayland is not that nice. To get system tray in wayland you first need to reinvent your own protocol, which will be used by all the applications to create tray icons. Then you need a patch (or a plugin) for wayland compositor and library. And you'll have to update that patch/plugin with every new compositor/library release. You cannot implement it separately.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 13:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Yeah, in Wayland your tray host and clients would exchange Wayland messages instead of custom X messages.
Big difference, I know.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 16:51 UTC (Thu) by Serge (guest, #84957) [Link]
> Yeah, in Wayland your tray host and clients would exchange Wayland messages instead of custom X messages. Big difference, I know.
In X.Org you just start your tray or taskbar host and it works. If you don't like it, you close it, open another one, and it works. No need to patch X.Org, no need to restart other apps. You can even have multiple taskbars, if you wish.
Wayland compositor IS the host. And there're no wayland messages to exchange. To have your tray you must write a patch/plugin for the compositor, and add your new messages as wayland protocol extension, then you will get the tray. And if you don't like it, you have to kill this compositor, with all the apps running there, and build another compositor with another tray patch.
Imagine that you have to patch and rebuild X.Org every time you want to look at Gnome/KDE/XFCE/LXDE/IceWM/FluxBox/OpenBox/etc. That's what you're going to get with wayland. That's the difference.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 16:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> If you don't like it, you close it, open another one, and it works. No need to patch X.Org, no need to restart other apps. You can even have multiple taskbars, if you wish.
Hm. I closed gnome-panel and opened xfce panel. I'm NOT seeing my applets from GNOME there. Skype's icon is also gone.
> Wayland compositor IS the host. And there're no wayland messages to exchange. To have your tray you must write a patch/plugin for the compositor, and add your new messages as wayland protocol extension, then you will get the tray.
> And if you don't like it, you have to kill this compositor, with all the apps running there, and build another compositor with another tray patch.
There is no standard protocol for this right now, but it's just a question of finding a consensus and making a standard, not some fundamental deficiency.
Also, X's tray protocol is woefully incomplete. So KDE and GNOME now use DBUS instead of X for communication.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 17:03 UTC (Thu) by raven667 (subscriber, #5198) [Link]
> Imagine that you have to patch and rebuild X.Org every time you want to look at Gnome/KDE/XFCE/LXDE/IceWM/FluxBox/OpenBox/etc. That's what you're going to get with wayland. That's the difference.
What?
I don't think this is how things work. Wayland is just the protocol, your compositor/WM has all the logic in it just the same as it is today. If your WM wants some window to be special such as a taskbar or whatever then that's its prerogative. There will be many different window managers surely, just as there is today, I'm not sure what this talk of patching and rebuilding has to do with anything...
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 13:37 UTC (Thu) by daniels (subscriber, #16193) [Link]
Multiple monitors are actually supported by the protocol. The other bits you've called out have no effect on clients, so they aren't supported in the client-server protocol. Kinda similar to how X11 doesn't put the paths to evdev devices (or udev listening sockets) in the protocol, it's just that the server everyone uses opens them for you and provides input events from them.
Weston is totally pluggable, so you can implement any shell, UX or policy you'd like on top of that, whilst reusing all its low-level infrastructure for policy, multiple monitor support, screensavers, input, etc, etc.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 17:06 UTC (Thu) by Serge (guest, #84957) [Link]
> Multiple monitors are actually supported by the protocol.
They're not really supported, just partially exposed. To configure them they must be supported by compositor. Userspace tools can no longer switch/move/rotate monitors. For X.Org you can use xrandr tool anywhere. For Wayland you'll have to use compositor-specific tool, if it exists. And you can't write a presentation tool that will automatically rotate monitor to portrait orientation and back, unless you make it part of the compositor.
> The other bits you've called out have no effect on clients, so they aren't supported in the client-server protocol.
"Client" definition in Wayland is different from X.Org. For X.Org all visible apps on the screen are X.Org clients. And most of them could never be Wayland clients. Under Wayland same apps have to be integrated with compositor.
> Weston is totally pluggable
As long as there's no stable Weston API for dynamically loadable plugins, "weston plugin" won't be much different from "weston patch".
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 17:16 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>They're not really supported, just partially exposed. To configure them they must be supported by compositor. Userspace tools can no longer switch/move/rotate monitors. For X.Org you can use xrandr tool anywhere.
Except with binary NVidia drivers.
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 17:16 UTC (Thu) by daniels (subscriber, #16193) [Link]
> They're not really supported, just partially exposed. To configure them they must be supported by compositor.
An X server has to support multiple monitors for X clients to be able to use them, too. Which wasn't the case for a very long time. Also, bear in mind that XRandR 1.2 is very recent - I think it landed in about 2007 or 2008? (And that massive massive chunks of how X works today, including multiple workspaces, etc, are not in any way part of the protocol, and require the compositor to participate in a number of _extremely_ complex protocols. But never mind that.)
> And you can't write a presentation tool that will automatically rotate monitor to portrait orientation and back, unless you make it part of the compositor.
We'd rather have the client tell the compositor about the orientation change, and let the compositor handle it in the most optimal way: either have the display rotated (which is only possible in a vanishingly small amount of hardware, and I do mean vanishing in the most literal way) by the hardware, or have the compositor do the rotation when it does the final blit. X usually emulates this with one extra blit from a shadow buffer, because it has no way to tell the compositor to do it. This has a very real power and performance cost.
Oh, and when your presentation tool crashes, one of your monitors isn't inexplicably left rotated. Also when anything else pops up on that monitor, it isn't inexplicably rotated because the monitor itself isn't actually rotated.
Ditto resolution changes: instead of having games change your resolution and then forget to change it back, with all your desktop icons moving around too, we have the games flag their window as fullscreen, and the compositor works out what to do - be it changing the mode or doing the scaling, or just centring the window if the client asks.
Again, instead of providing direct literal functionality equivalents, we've taken a step back, looked at the problem these interfaces were trying to solve, and tried to come up with a better way.
> "Client" definition in Wayland is different from X.Org. For X.Org all visible apps on the screen are X.Org clients. And most of them could never be Wayland clients. Under Wayland same apps have to be integrated with compositor.
Technically speaking, they (desktop, panels, screensavers) are actually Wayland clients; they're just using special private interfaces the compositor doesn't expose to arbitrary clients. They're not running in-process with the compositor.
> As long as there's no stable Weston API for dynamically loadable plugins, "weston plugin" won't be much different from "weston patch".
You might have more of a point if this actually changed frequently. The X server changes its driver API far more often than Weston does its shell API, and yet no-one complains (except driver authors).
Wayland the "successor" LCA: The X-men speak Posted Feb 15, 2013 17:57 UTC (Fri) by mgedmin (subscriber, #34497) [Link]
> Again, instead of providing direct literal functionality equivalents, we've taken a step back, looked at the problem these interfaces were trying to solve, and tried to come up with a better way.
And this is why I can't wait too have Wayland on my laptop!
Wayland the "successor" LCA: The X-men speak Posted Feb 15, 2013 18:37 UTC (Fri) by Serge (guest, #84957) [Link]
> And this is why I can't wait too have Wayland on my laptop!
You're free to try: http://sourceforge.net/projects/rebeccablackos/
Wayland the "successor" LCA: The X-men speak Posted Feb 21, 2013 9:47 UTC (Thu) by mmarq (guest, #2332) [Link]
" An X server has to support multiple monitors for X clients to be able to use them, too. Which wasn't the case for a very long time. Also, bear in mind that XRandR 1.2 is very recent - I think it landed in about 2007 or 2008? (And that massive massive chunks of how X works today, including multiple workspaces, etc, are not in any way part of the protocol, and require the compositor to participate in a number of _extremely_ complex protocols. But never mind that.) "
lol... by the tick pace that the IT clock usually goes, that is as old as my grandpa.
_extremely_complex ? ... can't think exactly why... matter of fact to work really well with modern GPU hardware, not crap or obsolete stuff posing as modern... the ideas that goes my mind is exactly making it _nec_plus_ultra_multi-threading_complex...
There are reasons why some have success while others don't... why some can while others don't... perhaps what the Linux graphics/display is in need, is of code "Ninjas"... first and before of thinking of any new mechanism...
Wayland the "successor" LCA: The X-men speak Posted Feb 14, 2013 17:47 UTC (Thu) by raven667 (subscriber, #5198) [Link]
> To configure them they must be supported by compositor. Userspace tools can no longer switch/move/rotate monitors.
Isn't the compositor a userspace tool? Can't it expose an interface for a command line tool if desired, maybe even have that interface standardized (such as via D-BUS). Doesn't the window manager/compositor have to participate at a fairly low level for R-and-R events anyway? I don't see this as something that's going to be a big change. The window manager/compositor already does mediate pretty much everything, with the existing X system being a giant wart on the side to be worked around.
Wayland the "successor" LCA: The X-men speak Posted Feb 21, 2013 9:19 UTC (Thu) by mmarq (guest, #2332) [Link]
And worst of all Wayland doesn't touch yet the MOST IMPORTANT "feature" that is proper Multi-GPU support... if it ever will properly... since its an event-driven mechanism very deep hard-wired in core, since that seemed to solved better some of the issues its developers focused the most(IPC like communications).
But what is REALLY REALLY needed is a *multi-threading protocol*... because the future is Multi-GPU or Multi-Core or Multi "compute unit" GPUs, that could be addressed exactly as CPUs are today. And this even for Ultra-Mobile GPUs of the phone/tablet ARM world.
I don't know why devs keep complaining hardware changes a lot... the writing has been on the wall for some(long) time now.
At least *Shatter* tries to address this... which "a priori" makes it already better than Wayland without any further issue.
Crazy gits on windows world, have been having boxes with even 4 GPU cards, while in Linux you got to be content to have one that works well... which is not often, and not with all GPUs... and worst of all, usually things tend to break from one version to the next of the all stack, from drivers to the WS, even if you keep the same card... or more frequently if you change for another, even if it is one of the same family and vendor.
Wayland solves nothing of this.
Only a more deep and direct involvement of the vendors could... but i'm afraid Linux is being set to be the battleground for pesky politics of hardware wars...
...screw the user... who pays the piper chooses the tune... so its my way or the highway... what is important is others not to supplant me... even if it means keeping it a 3th class gaming/desktop/display environment -> The Rational
Wayland the "successor" LCA: The X-men speak Posted Feb 21, 2013 9:23 UTC (Thu) by mmarq (guest, #2332) [Link]
Technically Wayland is NOT "a successor"(evolution whatever).. its a replacement...
Wayland the "successor" LCA: The X-men speak Posted Feb 21, 2013 10:42 UTC (Thu) by dgm (subscriber, #49227) [Link]
> Technically Wayland is NOT "a successor"(evolution whatever).. its a replacement...
Technically X.org 7.2 is a successor of X.org 7.1
Wayland the "successor" LCA: The X-men speak Posted Feb 21, 2013 11:22 UTC (Thu) by mmarq (guest, #2332) [Link]
Technically is not superior in the things that matter the most, and some of its ideas are not new... or could be even copy of older ones... see below NX
|
|||||||||||||