Slashdot Mirror
Wayland 1.2.0 Released With Weston
An anonymous reader writes "Wayland 1.2 & Weston 1.2 have been released. Features of this quarterly update to the X.Org/Mir display competitor is support for color management, a new input method framework, a Raspberry Pi renderer/back-end, HiDPI output scaling, multi-seat improvements, and various other changes for this next-generation Linux desktop display protocol and compositor."
Wayland & Weston are coming along pretty well and we are seeing increased adoption in both GTK+/QT toolkits and in desktops with upcoming versions of KDE.
One area where the developers need to go out and evangelize is on the front of EGL for proprietary drivers. Yes it's great that Intel's open source drivers (and to a lesser extend the open-source AMD & Nvidia drivers) have EGL support, but both AMD & Nvidia need to be convinced that EGL is important to their upcoming proprietary drivers too.
The irony here is that Mir, which is is seen as a huge competitor to Wayland, could end up helping Wayland enourmously since Canonical doesn't seem to be afraid to pick up a phone and call people at AMD/Nvidia to talk about updating the drivers.
AntiFA: An abbreviation for Anti First Amendment.
since I'm using X11 ;-(
Wayland ist not a Xorg/Mir competitor, as mir is not affiliated in any way with xorg. Wayland is the planned successor of Xorg, while Mir is some Ubuntu project.
Is Weston the only choice, or is there anything vaguely analogous to i3 or dwm in terms of how windows are laid out and managed?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Daniel Stone made a great presentation explaining various problems with X11 that Wayland tries to fix:
http://mirror.linux.org.au/linux.conf.au/2013/ogv/The_real_story_behind_Wayland_and_X.ogv
The same presentation is also on YouTube:
https://www.youtube.com/watch?v=RIctzAQOe44
For starters, me and many others wanted an accelerated desktop for the Raspberry Pi. Through the shitty documentation and poor ass code structure, I couldn't come close to figure out how to write a video driver for X. In Wayland, you have a reference implementation (Weston) to build one. That alone is a huge advantage
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Which is misleading because it uses the X hardware drivers.
Go and watch Daniel Stone's 2013 presentation for info from the horses mouth
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Actually, your observation is misleading. Graphics drivers on Linux have been using a lot of Linux features for a long time to improve performance, implement modern features, and handle hardware management in the kernel, where it belongs. No rule says that code can then only be used by X. They are Linux drivers, not X drivers.
Is it possible to run a Wayland display server in a big full-screen window on X11? That would be a fairly easy way to test wayland out and develop using the wayland GTK or Qt libraries. One huge advantage to this would be that I don't need to wait for driver support. As long as X11 had a driver, I'd be good to go. Since Wayland would be writing through (presumably) openGL to a full screen window, none of X11's asynchronous speed problems would be noticeable; waylands renderings within the window would all be snappy and synchronized. Granted too many layers of redirection could become a problem.
This is a similar idea (stop-gap of course) to what SuSE did years ago with the old Xglx project, which ran on top of X11 and opengl, which was eventually phased out in favor of AIGLX and Xrender.
Will those "X sux and wayland is the answer" put up some numbers (they don't even have to good ones just something to show future promise) or shut up?
Sometimes when you're fiddling with context menus too much, you manage to lock up the X server completely -- all you can do is move the mouse pointer, which at this point mostly points north-east or has turned into a cross.
Whenever an X client is somehow busy, does something bad or hogs up resources, the whole server freezes, sometimes periodically for half a second every two seconds or so. You can see it e.g. during graphically intensive redraws, or when Chrome loads several tabs simultaneously -- all the animations in the tab headers stop periodically, and the mouse pointer freezes at the same times. When I opened a few Chrome tabs too many lately, the load skyrocketed up to about 60, and the machine was inoperable for 10 minutes, before calmed down again, on its own. This has happened more than once too. These may in part be implementation issues (Xorg being single-threaded and all), and I don't know how well Wayland does in those kinds of situations, all I know is that the OSX display server fares much better. Individual clients may freeze, but the compositor always works, the mouse pointer never freezes, and you never see half-drawn frames or other random artifacts.
Sure.
Speed of light 186,282 miles per second .0683 seconds
Speed that a human can detect jitter of an icon tracing a finger 1/100th of a second
size of the earth 26k miles
circumference of the earth 24,901
fastest possible a round trip can occur from the worst 2 spots on the earth assuming 0 latency beyond the speed of light:
or the earth is about 7x too big for X11 to work.
Chance of us being able to fix either the speed of light or the size of the earth 0%
sorry .0683 seconds is for a one way trip. Round trip is double that. i.e. earth is 13.5x too big.
Here's a very simple question with hopefully no wiggle room: Suppose I have two Linux boxes, each running Wayland. They do not run X11 in any form or fashion. I am on the console of one of them and in Wayland. Can I start a terminal emulator, ssh over to the other box, issue a command that starts some graphical program (which uses only Wayland coding, no X11), and expect that program's window to show up on the first box? Assume that ssh has already been modified to allow for this sort of thing. If this cannot be done, what prevents it from being done? I have yet received no complete answer for this.
They are the driver written for xorg and not for the linux kernel.
Which reminds me - a major drawback of Wayland is it is designed around some features that only exist in linux and not in other versions of *nix. Whether that will be corrected later (as happened when gnome started the same way) or not remains to be seen.
Nice joke, but could I get an answer from a grown up please?
That's X - please answer the question and tell me how your chrome usage on Wayland behaves under the same conditions.
Where are the benchmarks to back up all the claims that it is better than X? Even something showing catchup or even a degree of usability would be nice.
The other advantage is that Canonnical can cock it up without affecting anyone else.
“Common sense is not so common.” — Voltaire
Seriously, how the hell is the parent post a troll.
These articles are always full of X sux trolls. How is asking for some evidence trolling?
SJW n. One who posts facts.
No, the people making the extraordinary claims are the ones that are expected to provide evidence of it. They have not which is why I am asking for it.
X11 is permanently unfixable. That's not a minor issue. A grown up is going to tell you that latencies over the public internet is worse than that and with QoS becoming more important and mobile latencies are likely to increase over the next generation.
The poster is pretty well known to dismiss good answers he's gotten over the years.
The problems with X11 start at things like the number of round trips the client and server have to engage in. Anyone can watch the protocol chat back and forth in RAM and them imagine that they were on a connection with 100ms, 200ms latency....
It isn't hard to do the math for some of these bad cases:
150 round trips x 200 ms latency = 3 seconds till the window gets finished drawing.
Anyone who has used X11 over a WAN has seen this problem for themselves.
Even worse is there are so many replies yet nothing better than someone hoping for a fast display on a Pi and the usual Wayland ignorant fanboy pretending to be stupid with some speed of light calcs to make fun of me.
I wish these guys would learn about the software they are pushing instead of just parroting something they've heard second hand.
To avoid time wasting trite rubbish light speed of light stuff, what I mean above is the performance in terms of how long it takes for the application to call for something to be drawn, then it going through the layers to the compositor before being sent to the video hardware. I still remain unconvinced by block diagrams that hide internal complexity which is why I keep asking for benchmarks.
Another post supplied some hope that you were going to treat this seriously but now you're off again into the land of wild irrelevant claims insulting the intelligence of the readers. Could you please push off and let somebody who actually knows something about Wayland or X reply?
Wayland already has a FreeBSD port in progress for the last 5 months.
So far
you've claimed there is no non-Linux solution when there has been one since Feb
you didn't know about benchmarks
you didn't know about them finishing the port of FreeRDP
I'd say you might want to change you tone about who doesn't know stuff about X or Wayland.
I still don't know - hence the SUBJECT HEADING, and instead of pointing me somewhere where I can find out you go on with joking rubbish (totally irrelevant to a local display) about the speed of light and the size of the earth implying that networking in general is useless.
If I knew about Wayland I wouldn't be asking about it. What pisses me off is if anyone who has a clue about Wayland is replying they are hiding their clue very well.
So then, how about proving you are more than just a fanboy that has heard of the thing but never even seen it and pointing out where those benchmarks I'm supposed to know about are?
Also where's the non-linux solution and how does it get around Wayland being tied specifically to the current linux device model? Also, if it has actually existed for less than six months how do you expect somebody outside the group of wayland developers and fans to have heard about it - that's a bit steep to hold against me. If it is true (and your other posts don't fill me with confidence on that), wouldn't it be far better to present it as a correction instead of an accusation?
What was the point of posting a Mir benchmark to a question about Wayland?
Were you hoping I would not follow the link and you could tell yourself you had won some sort of childish mass debate game? Until now you had me half considering you may know what you are writing about. Can someone with a clue reply instead in?
The problems with X11 start at things like the number of round trips the client and server have to engage in.
If we're talking about WAN network connections, then yes. For local stuff, people still complain about X being slow, but the data just doesn't support it.
150 round trips x 200 ms latency = 3 seconds till the window gets finished drawing.
X is a bit chatty. There seem to be several reasons.
1. The protocol itself is a bit too chatty. This could be improved greatly if the server could push out events for certain things so that the client can cache them reliably.
The NX people have essentially shown that this is indeed possible and the NX extended protocol seems to be one of the best remote graphical displays to use over a WAN.
2. People can't code X11 protocol for toffee. A classic example is making heavy use of XInternAtom as a synchronus call. In fact Keith Packard himself uses that as a reason for X11 having problems. If you need 100 atoms, you have to wait for 100 round trips.
Interestingly though in the protocol this is not a synchronus call. The newer XCB binding actually has it as an asynchronus call and in fact one of the first examples in the XCB documentation is how to get all your atoms in a single round trip.
Xlib (not X11) is substantially at fault. The correct thing (implementing a new C binding, namely XCB) has been done. However, even with Xlib, toolkit authors seem to love working under the assumption that they're working locally and misuse the protocol in all sorts of bad ways, making round trips where none are necessary.
SJW n. One who posts facts.
I agree with you X11 in theory could be designed to work better with WANs. I also agree that NX has somewhat demonstrated that. Your comment about toolkit authors focusing on locally is interesting. But I don't think that unusual. I think ultimately though that
a) Local
b) LAN
c) WAN
require often opposite optimizations. If Wayland takes over the local case X11, freed from having to worry about local at all might be able to become a far better WAN protocol. I just think it is unlikely that what works well for (a) should work well for (c) and visa versa. If I have 100ms I want to buffer to make sure I don't have to fetch again. If I have .1ns latency I want to fetch again and avoid the expense of the copy involved in buffering.
(b) which is X11's sweet spot is a very rare use case in 2013.