| |||||||||||||
Canonical reveals plans to launch Mir display server (The H)Canonical reveals plans to launch Mir display server (The H)Posted Mar 6, 2013 17:08 UTC (Wed) by Serge (guest, #84957)In reply to: Canonical reveals plans to launch Mir display server (The H) by Cyberax Parent article: Canonical reveals plans to launch Mir display server (The H)
> Nowadays X-server simply uses kernel support for modesetting, display and input device discovery, etc.
It also "simply" provides all that information to X-clients and "simply" allows them to configure and use it. Xorg also has methods and standards for communications among all the X clients.
> So actually recreating all the X functionality is easy.
Sure, if Xorg was just about drawing, but it's not. That's why after 5 years of Wayland development it's still not much better than Windows 2.0, except being true-color.
> At this point it simply makes sense to write something from scratch
Makes sense? For what? Who's going to win from that? It adds more work for toolkit developers. It breaks compatibility with lots of existing software (window managers, dock bars, etc). But who's going to win from Wayland? Where are those people?
> After all, X server has a freaking x86 real mode emulator to run BIOS VESA modesetting on x64 hosts.
And Wayland has what? Or are you trying to say that X works when Wayland does not? Well, that's true.
(Log in to post comments)
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 18:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
> It also "simply" provides all that information to X-clients and "simply" allows them to configure and use it. Xorg also has methods and standards for communications among all the X clients.
So?
>Sure, if Xorg was just about drawing, but it's not. That's why after 5 years of Wayland development it's still not much better than Windows 2.0, except being true-color.
>Makes sense? For what? Who's going to win from that? It adds more work for toolkit developers.
> And Wayland has what? Or are you trying to say that X works when Wayland does not? Well, that's true.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 19:55 UTC (Wed) by Serge (guest, #84957) [Link]
> So?
Wayland does not.
> You can just say: "I know nothing about Wayland". It'd be much more concise and clear. Okay?
Since you mix Wayland (protocol) and Weston (implementation) I guess you really know nothing about Wayland. Have you at least seen Wayland/Weston? No? Then stop here, install Weston from your repository and try using it. If you can't do that, at least download RebeccaBlackOS LiveCD and boot it in native Wayland mode.
Current Wayland/Weston is just a toy. It's fun to run it and play with it a little. But it's useless. Even IceWM had more features 15 years ago than Weston has now.
> It also adds very nice features ("every pixel's perfect, every pixel's great") that are not possible in X
What "features" are you talking about? Xorg does not stop you from drawing "perfect pixels", does it? ;)
> and works significantly faster on modern hardware.
It's not. Unless you know some benchmarks with some popular real-world applications that everyone can check.
> Toolkit developers actually don't seem to complain
Sure, people always like having more work to do.
> toolkits are glad because Wayland opens them a way to yet another class of devices.
And what "yet another class of devices" would that be?
> Yep. Because we really care about Ye Olde VGA adapters that X-server still supports.
This excuse does not change the fact that Xorg is better than Wayland/Weston because it works when Wayland/Weston does not.
And you still ignored the main question: if Wayland is so good then where are those people that it's so good for? Who it was created for?
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 22:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
> Current Wayland/Weston is just a toy. It's fun to run it and play with it a little. But it's useless. Even IceWM had more features 15 years ago than Weston has now.
No it isn't. Wayland in fact has features that are not possible (without lots of pain) in X.
Now, Weston _is_ a toy - because it's the reference implementation. It was not (and still isn't) meant to replace all the window managers. In fact, KDE is porting their compositor to Wayland (with server-side decorations).
> What "features" are you talking about? Xorg does not stop you from drawing "perfect pixels", does it? ;)
> And what "yet another class of devices" would that be?
>This excuse does not change the fact that Xorg is better than Wayland/Weston because it works when Wayland/Weston does not.
Yet another Wayland thread Posted Mar 7, 2013 18:09 UTC (Thu) by Serge (guest, #84957) [Link]
> No it isn't. Wayland in fact has features that are not possible (without lots of pain) in X. Now, Weston _is_ a toy
But Wayland (protocol) is useless without compositor (Weston). You can't write real applications without using compositor extensions. And most of those extensions are just "possible" and do not exist yet. Are you saying that those non-existing features of Wayland are not possible in X? ;)
> KDE is porting their compositor to Wayland
KDE added Wayland support to kwin (that wasn't hard) and it's incompatible with Weston. That's one of the key Wayland problems: it encourages people to write multiple incompatible compositors, so we may end up with many different compositors, and no usable ones.
> Yes it does. The support for timed buffer updates is still not complete so we STILL have tearing and flicker.
I don't know why YOU still have them. I don't.
> Resizing windows often results in ghosting effects, etc.
Have you seen Wayland/Weston yet? Download RebeccaBlackOS, boot it in native Weston mode and try resizing some windows. Then reboot it into KDE+Xorg (it starts in compositing mode by default) and try resizing the very same windows. See any difference? Except KDE being faster?
>> And what "yet another class of devices" would that be?
:-) So, Wayland brings no new device classes. At least we agree on that.
> A horse can pass through woods and swamps. Does it mean that it's better for transportation on the modern roads than a RAV4?
My question still stands. If Wayland (is it horse or RAV4?) is so good and has so many features, then where are those roads? Who is supposed to feel the benefits of Wayland?
For example Canonical is going to get benefits from Mir, because they need some GUI applications isolation, and they expect to get it in a few months. What about Wayland?
Yet another Wayland thread Posted Mar 7, 2013 22:28 UTC (Thu) by renox (subscriber, #23785) [Link]
> KDE added Wayland support to kwin (that wasn't hard) and it's incompatible with Weston. That's one of the key Wayland problems: it encourages people to write multiple incompatible compositors, so we may end up with many different compositors, and no usable ones.
Do you have a link which describes the port and the issues?
Yet another Wayland thread Posted Mar 9, 2013 0:06 UTC (Sat) by Serge (guest, #84957) [Link]
> Do you have a link which describes the port and the issues?
A link to KDE implementation of wayland? I don't. I've read about it here on LWN, seen some screenshots, but never used it myself.
One of the key difference between Weston and KDE/kwin implementation of wayland is that kwin uses server-side decorations. The list of related issues were here: http://blog.martin-graesslin.com/blog/2010/05/open-letter...
I also remember people here were commenting that they'll probably implement missing wayland features in kwin and then hopefully agree them with other compositors.
Yet another Wayland thread Posted Mar 11, 2013 9:38 UTC (Mon) by micka (subscriber, #38720) [Link]
> I also remember people here were commenting that they'll probably implement missing wayland features in kwin and then hopefully agree them with other compositors.
Which is already how it works on X. Someone launches a discussion on a new net_wm hint, sometimes after some time, most implementors (ie wm maintainers) agree, and they add it (or the other way, someone implements it, asks if it could be more general etc.).
Yet another Wayland thread Posted Mar 12, 2013 22:23 UTC (Tue) by Serge (guest, #84957) [Link]
> Which is already how it works on X. Someone launches a discussion on a new net_wm hint, sometimes after some time, most implementors (ie wm maintainers) agree, and they add it (or the other way, someone implements it, asks if it could be more general etc.).
There're two differences. First: that's already done for X, standards are already created, well know and implemented, but for Wayland you have to spend 10 more years to do that again because it implements everything differently. Second: on X you don't have to patch X server to add the support for your new hint, wayland protocol is not so flexible. Can you imagine patching and rebuilding Xorg every time you want to test some new WM property? That's what you get with Wayland.
Yet another Wayland thread Posted Mar 12, 2013 22:53 UTC (Tue) by micka (subscriber, #38720) [Link]
I'm not familiar with the actual apis under the window hints, so I'll tell how I imagine it and I can be corrected :
The client sets a property (a hint) and the window manager, if it knows it, interprets it.
When you decide to use a new hint, you change the window manager to interpret it and then use it in the client. So you must recompile the WM.
In wayland world, all this happens between the client and the compositor. If you must add a hint, you change and recompile the compositor.
In both cases, the work to add a new hint is exactly the same.
Where was I wrong ?
Yet another Wayland thread Posted Mar 15, 2013 8:27 UTC (Fri) by Serge (guest, #84957) [Link]
> When you decide to use a new hint, you change the window manager to interpret it and then use it in the client. So you must recompile the WM. X provides the communication transport.
You CAN recompile WM, but you don't have to. Your program and WM are independent. You can build your program on another WM and it will work there, just your hint will be ignored.
> In wayland world, all this happens between the client and the compositor. If you must add a hint, you change and recompile the compositor.
In Weston/Wayland you MUST recompile the compositor. Your program links with compositor, they share protocol. People won't be able build it until they update the compositor too.
> In both cases, the work to add a new hint is exactly the same.
You forget about the first difference. For the last 20 years most hints were already added, standards for them were already written and implemented in WMs. But in Wayland world you have to spend those 20 years again to reimplement them all from scratch. And you cannot reuse those standards, because Wayland does everything differently.
So in wayland world in addition to the work of adding a new hint you have to also do a lot of work to add all the old hints. It's a weird world...
Yet another Wayland thread Posted Mar 15, 2013 9:37 UTC (Fri) by micka (subscriber, #38720) [Link]
> But in Wayland world you have to spend those 20 years again to reimplement them all from scratch.
For my part, I will assume that wayland devs are intelligent beings that are even able to make use of all the hard word that's been done in the past.
Yet another Wayland thread Posted Mar 15, 2013 16:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
> In Weston/Wayland you MUST recompile the compositor. Your program links with compositor, they share protocol. People won't be able build it until they update the compositor too.
Weston/Wayland? What is it?
Wayland and Weston are completely separate and independent components.
Yet another Wayland thread Posted Mar 13, 2013 1:43 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Stop lying and misleading people. Wayland can be used to transport private messages (i.e. new hints) just fine without any recompilations.
Yet another Wayland thread Posted Mar 14, 2013 6:02 UTC (Thu) by Serge (guest, #84957) [Link]
> Wayland can be used to transport private messages (i.e. new hints) just fine without any recompilations.
I'm not sure what you're trying to say, but Wayland is a protocol. It cannot transport private messages and you cannot compile it.
Yet another Wayland thread Posted Mar 14, 2013 17:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Actually, Wayland is also the name of the implementation.
And I was answering to this:
You CAN use Wayland protocol to pass private messages just fine. No recompilation required.
Yet another Wayland thread Posted Mar 15, 2013 7:17 UTC (Fri) by Serge (guest, #84957) [Link]
> Actually, Wayland is also the name of the implementation.
Then what're Weston and QTWayland?
> You CAN use Wayland protocol to pass private messages just fine. No recompilation required.
I still don't understand what you mean. Protocol is a document, messages that are not in scope of that document are not part of the protocol. So you cannot send your private messages unless your "private messages" are part of the protocol. Technically you can send them through the same socket, but it won't make them part of Wayland protocol.
It's like saying that you can use GIF to store MP3 data just because you can put mp3-file to the directory with gif-files.
Yet another Wayland thread Posted Mar 15, 2013 7:44 UTC (Fri) by micka (subscriber, #38720) [Link]
> It's like saying [...]
More like saying you can use TCP to send HTTP request.
Yet another Wayland thread Posted Mar 15, 2013 9:09 UTC (Fri) by Serge (guest, #84957) [Link]
> More like saying you can use TCP to send HTTP request.
TCP has "data" section that is designed to carry another protocol. But you won't find a placeholder for another protocol in wayland.xml.
Yet another Wayland thread Posted Mar 15, 2013 16:08 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
> Then what're Weston and QTWayland?
Weston is a _compositor_. I.e. it's something like a WM in X world. And QTWayland is simply a name of QT integration with Wayland.
> I still don't understand what you mean.
> It's like saying that you can use GIF to store MP3 data just because you can put mp3-file to the directory with gif-files.
Yet another Wayland thread Posted Mar 16, 2013 7:46 UTC (Sat) by Serge (guest, #84957) [Link]
> Basically, Wayland provides a way for processes to communicate using a special form of IPC. Applications can use this IPC to exchange any type of data they want. Wayland itself also provides some services (described in wayland.xml) using this IPC.
Looks like you have your own understanding of the word "Wayland". Can you give me a link to the specification of THAT Wayland?
Yet another Wayland thread Posted Mar 16, 2013 9:06 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
http://cgit.freedesktop.org/wayland/wayland/tree/doc/Wayland - enjoy...
What exactly do you not understand? That Wayland is both the name of a protocol AND its default implementation (i.e. Wayland)? Or that Wayland protocol can be used to carry app- and shell-specific data?
Yet another Wayland thread Posted Mar 16, 2013 14:33 UTC (Sat) by cortana (subscriber, #24596) [Link]
I don't mean to sound thick, but I thought the reference implementation was called Weston?
Yet another Wayland thread Posted Mar 16, 2013 20:24 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Wayland is both a protocol and a library implementing that protocol. Weston is a compositor based on the Wayland library.
Yet another Wayland thread Posted Mar 17, 2013 9:45 UTC (Sun) by Serge (guest, #84957) [Link]
> http://cgit.freedesktop.org/wayland/wayland/tree/doc/Wayland - enjoy... What exactly do you not understand?
"Wayland is a protocol for a new display server", "The wayland protocol is an asynchronous object oriented protocol", "The interfaces, requests and events are defined in protocol/wayland.xml". I don't see anything about "IPC" or applications that "can use this IPC to exchange any type of data".
> That Wayland is both the name of a protocol AND its default implementation (i.e. Wayland)? Or that Wayland protocol can be used to carry app- and shell-specific data?
The link you posted states that Wayland is a protocol and Weston is implementation. Have you read it yourself? ;-)
Yet another Wayland thread Posted Mar 17, 2013 10:04 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
> "Wayland is a protocol for a new display server", "The wayland protocol is an asynchronous object oriented protocol", "The interfaces, requests and events are defined in protocol/wayland.xml".
This makes it an IPC, by definition.
> I don't see anything about "IPC" or applications that "can use this IPC to exchange any type of data".
Yet another Wayland thread Posted Mar 17, 2013 11:11 UTC (Sun) by Serge (guest, #84957) [Link]
> This makes it an IPC, by definition.
Hm. But it allows you to communicate with compositor only, and using protocol/wayland.xml messages only. Among others you also have a weird definition for "IPC"...
> Check the source code. There are no restrictions on message content.
protocol/wayland.xml is the source code of the protocol.
> Weston is a reference implementation of the Wayland compositor. Which is a separate piece from Wayland protocol or library. What do you not understand?
Ah! So what you called "Wayland" was libwayland-client (or was it libwayland-server?) I wonder, when you said "X" were you talking about libX11?
Anyway, I understand you now. Yes, libwayland allows you to send messages that are not part of the Wayland protocol, and you don't have to rebuild libwayland to send custom messages.
But that does not change much. In X world if you want your app displayed in some special way in your dockbar you need to patch you app and your dockbar, but you don't have to patch WM or X-server. In Wayland world you need to patch your app, dockbar and compositor. And it will work on your compositor only.
Yet another Wayland thread Posted Mar 17, 2013 10:05 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
> The link you posted states that Wayland is a protocol and Weston is implementation. Have you read it yourself? ;-)
Weston is a reference implementation of the Wayland compositor. Which is a separate piece from Wayland protocol or library. What do you not understand?
Yet another Wayland thread Posted Mar 8, 2013 22:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
> But Wayland (protocol) is useless without compositor (Weston). You can't write real applications without using compositor extensions.
Erm... Wayland applications do NOT depend on the compositor. They might want to use advisory "window state" interfaces.
> KDE added Wayland support to kwin (that wasn't hard) and it's incompatible with Weston. That's one of the key Wayland problems: it encourages people to write multiple incompatible compositors, so we may end up with many different compositors, and no usable ones.
>Have you seen Wayland/Weston yet? Download RebeccaBlackOS, boot it in native Weston mode and try resizing some windows. Then reboot it into KDE+Xorg (it starts in compositing mode by default) and try resizing the very same windows. See any difference? Except KDE being faster?
> My question still stands. If Wayland (is it horse or RAV4?) is so good and has so many features, then where are those roads? Who is supposed to feel the benefits of Wayland?
Yet another Wayland thread Posted Mar 9, 2013 0:56 UTC (Sat) by Serge (guest, #84957) [Link]
> Erm... Wayland applications do NOT depend on the compositor.
You must be talking about some theoretical Wayland again. Real world applications have to use compositor-specific interfaces. For example how are you going to take a screenshot without depending on the compositor? How are you going to make a taskbar without using compositor extension?
> ROTFL. As if X Windows has exactly one compositor and window manager.
That's the point! Single X window system implementation has many WMs. But every single Wayland compositor implementation has just one WM. By design. Encouraged by Wayland. You do know that Wayland server is called "compositor", don't you?
> Yeah, I see tearing in X Windows.
That was an optical illusion. And it was under Wayland. :)
Really, get back to the real life, and at least check RebeccaBlackOS LiveCD to actually see that Wayland you're talking about.
> Indirectly - everyone. Directly - developers who can now write better applications with better graphics stack.
What developers? Developers of what? Developers using toolkits aren't supposed to see any changes. So no benefits for them. Developers of those toolkits just got more work to do, which obviously no good for them too, unless they like to work a lot. Then what developers are you talking about?
Yet another Wayland thread Posted Mar 9, 2013 4:38 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>You must be talking about some theoretical Wayland again. Real world applications have to use compositor-specific interfaces.
No they don't. Basic shell protocols are already defined.
>For example how are you going to take a screenshot without depending on the compositor? How are you going to make a taskbar without using compositor extension?
> That's the point! Single X window system implementation has many WMs.
Whoops.
>Really, get back to the real life, and at least check RebeccaBlackOS LiveCD to actually see that Wayland you're talking about.
Yet another Wayland thread Posted Mar 9, 2013 19:04 UTC (Sat) by Serge (guest, #84957) [Link]
> I've read Wayland source code and I've actually tried it back when it could only display a primitive terminal window and rotating flowers.
Then why you're saying things like "Wayland opens a way to yet another class of devices" and constantly mix up Wayland and Weston as if you've never seen them and don't know anything about them?
>> You must be talking about some theoretical Wayland again. Real world applications have to use compositor-specific interfaces.
Have you read sources of those applications? Read again. :) You'll see that *real-world* applications use compositor-specific interfaces.
> And they are compatible, right? Say, does IceWM support that nice tray popup dbus protocol?
Yes, it does. Even more, they're supported without WM at all (notification-daemon).
> Whoops.
Are those tray popups supported in Wayland/Weston? No. Whoops. :)
You are arguing that Xorg is not too good, and Wayland is not too bad, while you should be arguing who it's good for. Nothing else matters if Wayland is good for noone.
Yet another Wayland thread Posted Mar 10, 2013 21:46 UTC (Sun) by renox (subscriber, #23785) [Link]
>No they don't. Basic shell protocols are already defined.
For Weston... But I wonder if the other compositor developers will like them!
Yet another Wayland thread Posted Mar 10, 2013 21:57 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Most of protocols are in the Wayland namespace. And it's not like X window managers developers get to vote on whether they like certain features of X protocol.
|
|||||||||||||