| |||||||||||||
Canonical reveals plans to launch Mir display server (The H)Canonical reveals plans to launch Mir display server (The H)Posted Mar 4, 2013 23:28 UTC (Mon) by dlang (✭ supporter ✭, #313)In reply to: Canonical reveals plans to launch Mir display server (The H) by tchernobog Parent article: Canonical reveals plans to launch Mir display server (The H)
as long as the result can be run everywhere, there isn't a problem
However, if you get into the position where you can't run two different apps on one box because of the toolkit they use and the display server they require.
This is what concerns people about the Wayland one-way X compatibility, and now that there will will be four choices
X
the concerns get stronger.
(Log in to post comments)
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 1:01 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
from further reading, it appears that Mir will also have the ability to have X apps connect to it, so it's got the same compatibility as Wayland.
One other piece of information that I found interesting
Mir can use Android video drivers, so this may be a big advantage when dealing with portable devices.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 3:37 UTC (Tue) by drag (subscriber, #31333) [Link]
The ability to use android drivers is due to the plan to use opengl is as its API. Its a standard that modern android drivers must support.
Stop me if this sounds familiar.
http://ppaalanen.blogspot.fi/2012/07/wayland-on-android-s...
Because wayland already had the capacity to run on android drivers....
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 5:12 UTC (Tue) by swetland (subscriber, #63414) [Link]
It sounded more like they were planning on sitting on top of the Android Hardware Composer HAL, which is definitely the way to go. SurfaceFlinger uses GL ES as a fallback for composition if the hwcomposer can't do some or all of the work. Taking advantage of hardware overlays or other 2d composition engines is pretty important for reasonable performance on a lot of these platforms -- they can avoid additional memory to memory copies and offload the GPU (which apps also want to use to draw).
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 15:37 UTC (Tue) by mmarq (guest, #2332) [Link]
IS that "notion" that i find very strange
> offload the GPU
There isn't that need since even phone chips will have GPU integrated to the bone... they already do... more than that, next crop of those integrated GPUs will be several times >100% more powerful than current ones, and perhaps even ultra-mobile will have more than 1 GPU, meaning perhaps the concept big.LITTLE can cross to GPUs also.
The idea of offload the GPU is applicable only when your system doesn't support the respective drivers, or does a very lousy job at it, and that has been the problem all along. Native *integrated* support for GL languages is the way, and this almost all DS already do, being X perhaps the more cumbersome(quite fixable i think, i just remember compiz/fusion)... and support for seamless *multi-GPU* the lacking factor, this Mir seems to target, so its already superior to wayland only by this factor, X is doing the first steps on it, while Wayland seem definitely lacking...
IMO a lot of *convergence* could be achieved if large part of the "input stack" passes to systemd / kernel, that is, even before any DS is applied, and who knows "consoles" can use a lot of "mouse" functionality and other input devices, that is, why not "touchscreen" support for "consoles" ?
In this X is the one that would need the most work, but nothing unachievable i'm positive... and a favor to them... any X release would be excused from deliver any input drivers, and a same "pointer theme" could serve all from Grub/whatever to the desktop/screen.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 19:36 UTC (Tue) by swetland (subscriber, #63414) [Link]
When you're driving large displays with multiple layers and moving a lot of pixels around, an overlay engine that reads from multiple layers and combines them directly into the scanout path, without requiring memory-to-memory copies is often a more efficient use of available bandwidth than using the GPU.
Not taking advantage of hardware composition blocks leaves performance on the floor, and it's performance well worth taking advantage of.
CPUs and GPUs are becoming more powerful, certainly, but displays are getting larger, software is drawing more complex stackups (with more alpha and effects between layers), and there's seldom as much graphical compute as you'd like on embedded platforms, even the higher end ones.
Also, efficient multitasking between multiple GPU clients is still rather hit or miss. I've seen beefy Win7 desktop machines start becoming unresponsive to window drags, etc, when throwing a complex load at high end desktop GPUs because the compositor and application are fighting for the available GPU and the hardware and/or drivers don't time-slice it well enough to remain smooth. The problem is typically worse on embedded platforms.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 22:11 UTC (Tue) by mmarq (guest, #2332) [Link]
ummm... your parallel is far from convincing.
Embedded platforms are not real display multitasking systems. The same can be said about phones, the GUI is simply not tailored for it.
The rest seems to go in the opposite direction, i mean, is the kernel that manges the GPU memory, and all is managed as a single pool of Virtual Memory... is inherently an UMA... and is not only about HSA, and are not only its members that are about to implement "hardware features" (advanced caches, TLB, pre-fetch, etc that molds nicely to the data programming patterns) that makes those round trip memory copies a thing of the pass.
I happen to read a lot of patents(not only for work), i'm expecting something in that direction, matter of fact Sony PS 4 as revealed is a Single unified chip who's main memory is GDDR5, that is, is the GPU side that has all the memory, is the CPU side that shares, if it is HSA modeled, and more in AMD style, those memory-to-memory copies will not apply... remains to know what OS (or version) they will employ. So the more efficient use in PS 4 will be exactly the GPU not the CPU.
So in this sense the wise approach would be to move anything of those pertinent mechanisms out of the windowing systems... yes more stuff in the kernel... or more stuff in the systemd as example.
Then the DS can even be multithreading, almost like any other app, and you can have several windows open even on several displays, all with active windows with focus, and drag & past things from one to another without complications and rendering complexities, of windows getting minimized or the all operation getting cumbersome with virtual desktops.
This is not necessary for those "embedded or portable" systems, but making it the standard, and force all to follow it, IMO is like trowing Linux desktop more than 10 years back... perhaps DOS is not after all a bad idea, 1 app at a time!...
And saying it will *never* apply to embedded/portable is a risky bet, *never* is always a very risky word in IT... some more adventurous hardware vendor might yet conceive remote display for a superphone, now that wifiG is a done deal, and you have your phone GUI splashed into 2 wireless big displays... never say never, at least you'll not lose for the waiting, but where is the Linux display system for this ?
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 22:36 UTC (Tue) by mmarq (guest, #2332) [Link]
And if you care to ask... yes, not only advanced caches, but also pre-fetch, TLB and MMU of sorts in a GPU also, matter of fact context/exception handling, and its own "cooperative" interrupt engine to. Very little differences to a CPU.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 23:14 UTC (Tue) by robclark (subscriber, #74945) [Link]
just a side note, but if the hw supports it, weston can use overlays to do composition bypass too. So again this is not a valid argument against wayland.
(But when you have hw that supports it, and when used properly, using the display block to do composition can be a very big win. That is for sure.)
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 10:36 UTC (Tue) by renox (subscriber, #23785) [Link]
> and now that there will will be four choices
> X > Wayland (including X apps) > Flinger (Android) > Mir (unknown compatibility)
Currently there are two main existing choices: X and SurfaceFlinger (DirectFB doesn't seem to catch much interest, I'm not sure why).
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 13:14 UTC (Tue) by paulj (subscriber, #341) [Link]
Shame LWN doesn't have +1 ability. :)
Your comment is spot on. The Wayland devs are in no position to criticise Canonical for unnecessary forking, given there is already a tested, widely used replacement for X shipping on millions and millions of devices. ;)
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 13:47 UTC (Tue) by renox (subscriber, #23785) [Link]
> Your comment is spot on. The Wayland devs are in no position to criticise Canonical for unnecessary forking, given there is already a tested, widely used replacement for X shipping on millions and millions of devices. ;)
I am not trying to 'earn points', this was a real question..
As for the criticisms: Wayland developers didn't criticize Canonical for making another project but for writing incorrect technical points about Wayland: contrary to what is written in Mir's wiki, Wayland doesn't suffer from X's input security weakness.
As always security isn't free though: it means that Wayland clients cannot send events and that (for example) a visual keyboards cannot be a "normal Wayland clients".
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 14:11 UTC (Tue) by paulj (subscriber, #341) [Link]
I gather the misrepresentation was one issue, but needless forking was another criticism that appeared to be made in the IRC log posted in another comment.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 17:05 UTC (Tue) by mmarq (guest, #2332) [Link]
> Wayland doesn't suffer from X's input security weakness.
What a lame excuse ! ... now the apps that a user can install are a "security" concern ??...
I welcome those security threats anytime... i'm very concern with those that don't "display" anything whatsoever, and those are never an app that need a DS.
All this "clash" is because several projects want to be the next "must have" thing for dedicated Linux hardware... yes, the future points that if you want a Linux desktop, from ultra-mobile to workstation, you'll have to buy compliant hardware with proper drivers developed for them.
Hey! at least someone will pay for something... else go windose, which is exactly the same thing, the price of the software is included in the hardware(pre-install), and the rest is similarly free... in a warez/freeware style.
Matter of fact Windose will win triple with this, they can keep a good part of the warez/freeware in place, while Linux will tend to be plagued with "incompatibilities", no matter if everything is free.
And by doing so, they can prepare for the next big push... or "exclusive encrypt hardware or UEFI 2"... and so relegate Linux client/desktop to levels equal to 10 years ago or worst, and so achieving (union makes the strength, disunion makes the weakness no matter your much larger numbers) they can go after the server side to, meaning the "clients" for those servers will be very "cosi" about what software those servers might run.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 3:19 UTC (Wed) by drag (subscriber, #31333) [Link]
> What a lame excuse ! ... now the apps that a user can install are a "security" concern ??...
This is always been true. If you want to secure the OS the first step is to reduce it's functionality as much as practical.
> while Linux will tend to be plagued with "incompatibilities", no matter if everything is free.
I'd actually rather Ubuntu diverge massively from the rest then see it plod along with trying to improve things and not worry about 'being compatible' in the traditionalist Linux approach.
That way if they succeed that is a huge win and shows the road going forward for Linux as a desktop/workstation/whatever. If they fail then it shows what not to do as plain as day.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 16:55 UTC (Wed) by mmarq (guest, #2332) [Link]
>This is always been true. If you want to secure the OS the first step is to reduce it's functionality as much as practical.
md5 trusted origin and non-root privileges are not enough ?
seems to me the "practical" target seek is beyond most "client users" are used to, or care, or is indeed practical. You alienate the masses of "end users" then wonder why distros are in trouble, and why there isn't more adoption lol ...gezzz wonder why !?...
for really security concerned deployments there is always system/network admins... unless those are also considered a security threat, and must get out of job... lol (good going!).
>I'd actually rather Ubuntu diverge massively from the rest then see it plod along with trying to improve things and not worry about 'being compatible' in the traditionalist Linux approach.
they will try to diverge in any case... i think it was already decided that way... and the main concern is the "business" side and its model, its not about improve, compatibility or tradition... its all about business and $...
I think they are going to fail. No! nothing against Ubuntu, but something lots of ppl seem to have forgot is that there is already a king for the business model they try emulate, a ruthless despotic king supported by a "status quo" that seems completely bent in having an "harmonization" of systems where they can control, with all its implanted back doors, report to master etc... go ahead, insult if you must...
Ubuntu to have the success they seek, will have to ask permission, sign deals, and after all that be content to be a very secondary alternative... that is why after UEFI 1 i speak of UEFI 2...
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 17:46 UTC (Wed) by drag (subscriber, #31333) [Link]
> md5 trusted origin
Last time I checked md5sums don't check the source code for security bugs and hidden backdoors.
> and non-root privileges are not enough ?
My user account on Linux does not have root rights. Therefore all the critically important information that I have is stored under my user account. There almost no permissions within that context.
Therefore root permissions are not enough.
> they will try to diverge in any case... i think it was already decided that way... and the main concern is the "business" side and its model, its not about improve, compatibility or tradition... its all about business and $...
The tradition is shit. It's not working for Ubuntu or anybody else that has tried to penetrate the desktop and consumer market following it. And therefore change is necessary to survive.
The tradition for Linux is to have huge amounts of duplicated work to deal with insignificant and unimportant technical details that distributions refuse to agree on. It creates headaches for developers and makes it difficult to install and almost impossible for end users to maintain the software they want to use at the versions they want to have.
The tradition for Linux is not have any sort of layers or design in the system. We have 2 layers, Kernel and 'everything else'. It's all one big mush with a maze of inter dependencies so complex and lavish that it resists any attempt for people to map it out and document it. One change in one aspect of program or library and you have chance of causing a wave effect throughout the system of changes and recompiles.
I could go on, but hopefully everybody is aware at this point what the problems are.
Any significant deviation from this that actually works out well is going to be a improvement.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 18:20 UTC (Wed) by mmarq (guest, #2332) [Link]
>Last time I checked md5sums don't check the source code for security bugs and hidden backdoors.
True... but what happened to "trusted origin" ?... unless you mean "you damn distros, i don't trust you a little bit"
> My user account on Linux does not have root rights. Therefore all the critically important information that I have is stored under my user account. There almost no permissions within that context.
>Therefore root permissions are not enough.
Encrypt the real sensitive stuff... or like a joke in my country; "don't want to have children... don't do it", the perfect contraception model... meaning don't have anything sensitive directly connected to your system, even top military security wacos can agree... its the best model...
Unless you think that Linux must be like a "baby-sitting" system to all the crazy ignorant gits out there... i have some experience with that, good luck with that lol (boy! i can't think of worst punishment)... cause for those the worst security threat is that they can't resist to the phishing and social engineering of; "click here to see a celebrity without panties" lol... there is no system that can really help more than they already do, which is already good...
and last... what happened to the system and network admins ?... don't they count ? ... or the intention is put a "virtual" admin in every box of every crazy git out there ?...
>for really security concerned deployments there is always system/network admins... unless those are also considered a security threat, and must get out of job... lol (good going!).
TPTB will love it, but i'm afraid it will flop terribly, because what the crazy gits want is exactly do crazy and very insecure things...
Why do i sense "security paranoia" ? ... as a lame excuse for many things, including being toppled by a "status quo" that sees the all F/OSS Linux itself as a threat... but to them ?
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 18:45 UTC (Wed) by mmarq (guest, #2332) [Link]
Forgot...
>And therefore change is necessary to survive.
This is the central issue. I can agree with many things, many things are true, even things that are obviously contradictory in many aspects.
But change by itself means nothing... absolutely nothing... if you don't identify correctly the root problems of your woes.
And most of the root problems of the Linux world, IMHO, is NOT in the code. Why this and that!?.. well, is it correctly identified ?... than what are the solutions ? ... and most pertinent of all, why can't everybody push in the SAME DIRECTION to solve the most afflicting woes ?
That is the correct approach IMHO... change per se, can only mean change to nowhere, or for worst...
Example; what are the REAL correct reasons for UEFI ? ... what are the solutions ? ... just for the sake of argument as i pointed elsewhere, what will happen if something like UEFI 2 happens (exclusive encrypt hardware) ?
the rest can be like chichens without head, that go in circles before drop to the side...
SAME DIRECTION Posted Mar 9, 2013 20:00 UTC (Sat) by Wol (guest, #4433) [Link]
And what if that's the WRONG DIRECTION?
That is one of FLOSS's *S*T*R*O*N*G* points - that we quite happily throw massive engineering resource at multiple possible solutions before we settle on the correct one (that is, if there even IS a correct one!)
That is the PROBLEM with the MS approach - there is only one solution, and if it's the wrong one, tough. For example, imho Word is crap. Pretty much all word processors are trying to copy Word. In other words, it is almost impossible now to find a word processor that is capable of industrial strength work - they're all aimed at people who don't know how to type!
One size does NOT fit all.
Cheers,
SAME DIRECTION Posted Mar 11, 2013 12:43 UTC (Mon) by dgm (subscriber, #49227) [Link]
> That is one of FLOSS's *S*T*R*O*N*G* points - that we quite happily throw massive engineering resource at multiple possible solutions before we settle on the correct one (that is, if there even IS a correct one!)
That's only a benefit if we can finally agree on a correct one, and drop those that do not add much value. Want to bet Canonical will NOT drop Mir, even if it proves to be an inferior solution? Hint: BZR, Upstart.
The problem is not that Canonical develops an alternative. That's fine, even for Kristian Høgsberg (Wayland's architect and main developer). They could be doing it as a side project, like Wayland is. Instead Canonical is endorsing it, unleveling the play field and creating an artificial barrier for Wayland (or any other) to enter. I despise profoundly saying that, but in that sense Canonical is not better than Microsoft.
But let's wait and see. Maybe this time they will do the right thing.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 19:23 UTC (Wed) by mmarq (guest, #2332) [Link]
Other example
>The tradition is shit... The tradition for Linux is to have huge amounts of duplicated work to deal with insignificant and unimportant technical details that distributions refuse to agree on. It creates headaches for developers and makes it difficult to install and almost impossible for end users to maintain the software they want to use at the versions they want to have.
If i had points to give, i would give you all for the daring
ummm... don't. That is, don't even try to maintain it. Oh! many will came back complaining furiously... but there must be a tough "conscious inner voice" that simple refuses and points the correct approach. The point is that the notion of "dumping for others to maintaining it" is just WRONG. There must be very concise technical merits, and there is also LSB for this -> support it, make your case there...
What you describe is the failure of LSB. Somehow it must get out of any distros influence... or any distro simple ignorance of it... ppl must have the courage to make it "independent", make it bigger, make it better...
>It's all one big mush with a maze of inter dependencies so complex and lavish that it resists any attempt for people to map it out and document it.
And in this is why "changing" have been making things much more harder not easier... the gross mass of "independent" or semi-independent devs, finds it easier to start all over, than to try to understand some pieces of code and attach themselfs to *collaborate* on something that is already there, to make it better...
... i just can't imagine why *trowing more into the maze* in a way that the originator himself understands better, and so half documented or documented in a way those original devs understand... does any good to improve the matters...
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 23:25 UTC (Tue) by robclark (subscriber, #74945) [Link]
surfaceflinger is only recently getting better and some very basic things (and afaiu still has a way to go), like proper vblank handling and hotplug, multi-display, etc, etc
It has been good enough for mobile devices for a while.. doesn't really make it a mature replacement for X in a desktop environment. And nothing that is missing from wayland is really present in SF.
I don't know of anyone who really knows much about desktop window management or graphics who things SF on desktop is a good idea.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 23:55 UTC (Tue) by raven667 (subscriber, #5198) [Link]
Would a SF compatibility shim for Wayland make sense? For example PulseAudio has direct ESD compatibility as well as shims for ALSA and OSS which helps a lot. At least some coordination so that they can both be used on the same system and can use the same underlying graphics drivers.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 0:55 UTC (Wed) by robclark (subscriber, #74945) [Link]
possibly.. it might be kinda cool to be able to play angry birds while waiting for something to compile :-P
afaiu (from people who have looked into the details more than I have), it might require cutting in at deeper APIs in the android gfx stack which might change from release to release. But still it could be an interesting way to have linux and android coexisting to some extend. (Well, that solves the gfx part.. not sure about binder or other parts of the android stack that an app might depend on.)
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 5:45 UTC (Wed) by Serge (guest, #84957) [Link]
> what I don't get is why SurfaceFlinger doesn't seem to be considered as a basis for replacing X, and instead 'from scratch' projects Wayland and now Mir were created..
Modern Linux has a good graphical stack. In times of early X11 there was just text console and some random framebuffers around. That's why Xfree86/Xorg had its own userspace device drivers (microkernel fans, where are you).
But when people look at modern Mesa, DRI, EGL, they think "hey, it's so easy to draw something on a screen, you can even get 3D acceleration, and you don't need that bulky Xorg". So it's actually easy to create some basic hello-world-window-system from scratch. Much easier than dig through the code of Xorg/Wayland/DirectFB/etc.
The problem is that Xorg is not just about drawing, but about communication of very different programs. There can be video player, playing dvd on a side of a cube, rendered by compiz, recorded by recordmydesktop, remotely controlled over x11vnc, and none of them have to know about the others. Xorg supports every configuration possible, multiple monitors, multiple keyboards, even multiple mouse pointers on the same screen. It took years to turn all these things into stable standards. To make something new "better than Xorg" one have either convince everybody that they don't need all those features or reinvent them all.
Canonical/Mir devs have an excuse: they don't want to replace Xorg, they want something for mobile/tablets, that can isolate applications from each other (somewhat like Xnest) and looks working. Wayland devs don't even have that excuse.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 9:22 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Nowadays X-server simply uses kernel support for modesetting, display and input device discovery, etc.
So actually recreating all the X functionality is easy. At this point it simply makes sense to write something from scratch (Wayland is just several KLOC clear C code!) and add yet another compatibility layer to X.
After all, X server has a freaking x86 real mode emulator to run BIOS VESA modesetting on x64 hosts.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 6, 2013 17:08 UTC (Wed) by Serge (guest, #84957) [Link]
> 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.
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.
Canonical reveals plans to launch Mir display server (The H) Posted Mar 5, 2013 16:16 UTC (Tue) by mmarq (guest, #2332) [Link]
> the concerns get stronger.
Oh! yes... the Jumping Monkey of Redmond, is already jumping and kicking chairs around in euphoria... and biting wet towels hard with all the expectation...
while you "fork" and battle each other with secondary issues, a strong divergent impulse, he has other plans *UEFI 2*
It will take great "care", "maneuverability", "cleverness" and "sense of opportunity"... while their main "enemy" is entertained fighting each other and making things more difficult for the "client/desktop" side, with all the incompatibilities and bugs that it can bring... he might be preparing to require a "dedicated chip/encrypting circuit" for their "safe boot" schemes, which has nothing about security, unless we consider the "user" of those systems the main malware threat...
And this Redmond does, consider the "end user" as the main malware threat, since those users now can always show the finger and install other OS and respective applications... something that must be "taking care of" ... capice! lol
So i don't understand why this things deliver so much controversy, soon end users will have no other choice but to install the Redmond crap software... all done under ppl noses while they are distracted, pointless bickering and or at sleep...
So who cares about Mir etc... soon if you are not a "full system deployer", that is, have your own hardware, like Canonical and other seems to target, the only choice from ultramobile to desktop will be GDI/directX...
The Correct Strategic Counter-Action (strategic NOT code) would be to promote Coreboot with all strength until exhaustion... it could even have UEFI on top, for those who wish... but no!... actually the only "strategic mind" around is bashed with pity and sarcasm and Coreboot labeled as a failure...
So free is a misnomer, or for having Linux on the client you will have to pay and buy Canonical or other's hardware... it was to be expected since almost nobody pays for any software, and those companies to survive have little other choices ( one pertinent choice would be to compile install everything from online into an "end user" machine, force them to pay for a really tunned system, but this choice is fading with UEFI to)... or you will be out of luck.
Lets give back to the community lol <what a sarcastic joke>
|
|||||||||||||