Slashdot Mirror
X.Org Server 1.15 Brings DRI3, Lacks XWayland Support
An anonymous reader writes "A belated holiday gift for Linux users is the X.Org Server 1.15 'Egg Nog' release. X.Org Server 1.15 presents new features including DRI3 — a big update to their rendering model — a rewrite of the GLX windowing system code, support for Mesa Mega Drivers, and many bug fixes plus polishing. The release, though, goes without any mainline support for XWayland to ease the adoption of the Wayland Display Server while maintaining legacy X11 application support."
Yet another good reason to disparage Wayland: Not even X supports it.
Kid-proof tablet..
even if you don't agree 100% with the design, you can perhaps help to make it more modular so you can do your own thing inside a common framework, but please, stop supporting that old rust bucket.
if all the people who worked on this ploughed their time into wayland, or other alternatives, we'd be done already...
x is dead, it's not even a challenger in the next game, the only reason it's alive is because nobody has a viable alternative they can use today.....
Its not obvious to me that XWayland and X should be merged. XWayland is a compatibility layer for Wayland, and the only things in needs to support is the published interface. Changes to the rendering model may well be irrelevant, as XWayland would render through the Wayland display layer anyway.
Before the using via network (remote X) is available for wayland, and includes root windowless mode, most of non-hobbyist users (in heterogenic corporate environments and such) will never switch over. There's nothing to get excited of if you aren't at even half-way feature parity.
If all of the competent people working on Wayland would stop wasting time on it and improve the X server, think how much better it might be.
Wayland lacks absolutely necessary features (true "over the net" and root window access, for example) for a significant number of applications and users. Until it has those, even if only through X emulation, it is simply not ready for use by me, and a lot of people like me.
It is asking too much for a link to *official* sources? (Hint: http://lists.x.org/archives/xorg-announce/2013-December/002384.html)
Having seen terrible X compatibility layers for Mac OS X and Windows, I have got to ask if I should expect XWayland to be better? Integration between applications talking the X protocol and applications talking a proprietary protocol has been ranging from terrible to nonexistent. Some implementations have taken the approach of creating a window inside which all X applications are rendered. This has potential for great compatibility among the X applications, but they are demoted to second class citizens, with no chance of integrating with anything happening outside that window. Others have been rendering X applications each in a separate window. But usually they still cannot see windows opened by applications talking the proprietary protocol, and thus cannot interact with them. Secondly that design has a tendency to treat windows opened by an X application I just started as if it was just one more window opened by another X application, which was already running. For example on Windows, that causes new windows to be opened behind existing windows instead of in front.
The lack of X has been the main technical drawback Mac OS X has been having compared to Linux. I'd much rather see Mac OS X catch up with Linux than for Linux to go down to the level of Mac OS X.
XWayland is a modified version of the X.org server, which instead of rendering though the kernel/hardware, renders as a Wayland client.
It makes no sense to try and maintain XWayland as a separate fork of the X.org server.
It's good enough for valve to base its console on (and not wayland), it's also good enough for me (FWIW) in that it works and at this point wayland does not as it is nowhere near feature parity with X11.
And when comparing X11 vs wayland for a simple desktop: wayland loses every single benchmark.
TODO: 753) write sig.
then you're using slow equipment, or you're eyes are broken in some way
oops, you're/your, maybe mine are broken too :)
When Citrix came out with ICA that should have been an indication where remote display tech should be headed, then we have Microsoft doing RDP and now the king pin is VMware with PCoIP. What we need is a way to remote a whole computer and not just the graphics. Why?
ALL USERS want the following:
1) Remote sound
2) Remote USB
3) Video Acceleration between a client and server
Why so that simple web pages with Flash content do not suck. And so that all this crappy USB stuff that end users have purchased can work on a remote session.
Your Average Joe
In a country long ago and far away there lived the good King X the eleventh.
He had a lot of ministers, the most important of which had become the minister of Composition. His job was to have peoples houses painted. If you wanted your house painted, you would have to ask the King. Every day the king would spend long hours with the minister of Composition, who would know all the houses in the country, had an exact knowledge of the Royal Paint Budget, and could call in the painters.
Although almost everyone lived in the capital called Localhost the King would sometimes travel around the country and kindly hear peoples paint requests. Every night the King would return to his palace, talk to the minister of Composition, and then decide whether you could have your house painted, and when.
Then on a dark winter's night, a group of grumpy people thought how much more efficient it would be if everyone would talk to the minister of Composition directly. Thus the Wayland Conspiracy was born. The next day, at daybreak, they deposed the good King and made the minister of Composition the head of state: president Compositor. To cater for the few people in remote villages they re-appointed the King as secratary to the president: the Secretary for Remote Villages. He would still travel around the country (albeit in a suit, and without his crown). He would still talk to president Compositor every night, like in the old days.
The press in other counties, like Windonia and Applestan, were very positive: finally this backward country had a modern government. Now its poor inhabitants could have the same beautiful colored houses they had. Welcome to the modern world!
The people in the country itself didn't notice a lot of difference, however. In the old days things took a little longer, but not everyone needs his house painted every day. Many still called the Secretary for Remote Villages "King", especially in the countryside.
But the people in Windonia and Applestan were very satisfied: they always had felt that their geovernment was superior, and the Wayland revolution had proved their point.
The King just smiled.
When something running under Wine runs faster with that translation than it does under windows, you cannot claim that the windowing system in X is slower and degrading performance of Linux compared to Windows.
It's taken as a matter of faith that this network transparency MUST be making it slow.
Merely because it is "obvious" that if something is flexible, it MUST be slower!
Yeah and even we don't use it any more. Well, not all of it anyway.
Yeah, I had a sig once; I got bored of it.
With respect, I believe you utterly miss the point. GP is right. While the desktop is animating uselessly, it is not doing anything useful. That is the definition of sluggish.
It has nothing whatever to do with "slow equipment". It has to do with waiting, however briefly, for bullshit eye candy with no purpose whatsoever. There is a class of users who perceive the time delay from clicking "open", until the window is fully opened and responsive, and who find anything that increases this delay a step backward.
We do realize that with the absurd oversupply of CPU and GPU power in recent desktops and laptops, this delay is completely a deliberate visual artifact, and that it does not mean the available power is being taxed. But while the time of the GMA 950 and processors of 1/10 or less the power found now is past, the principle is still valid. It should not require a vast profusion of transistors using 10 times as much power as should be necessary, just to draw a desktop.
As long as every last vestige of these "desktop effects" can be turned off in a straightforward manner, I have no objection to the Mars Bars being there for such people as want to subsist on them.
I confused. I know little of Wayland, I've used X happily for the past 10+years at work and at home. But you know, all this vitriol and immaturity on display just puts me off this Wayland thing?
It makes me ask myself if its so superior, why do you you need to be so aggressive and attack so much? Why aren't you secure enough about its superiority to advocate that people discover that for themselves? For all I know it is much better, and I'm always open and keen to explore new software, but this stuff is very immature and offputting.
Perhaps some positive advocacy might make me take a look. All this time and effort which is just serving to alienate people like me might be better spent in contributing to the development of the project itself?
I believe he's still part of X.org anyway, but he's working exclusively on Wayland.
For everyone that disparages Wayland without really understanding anything about Wayland, which seems to be most everyone, I highly recommend listening to this talk by a core X.org developer:
http://www.youtube.com/watch?v=RIctzAQOe44
TL;DR points:
- X11 is no longer "network transparent" and hasn't been so in a long time, due to reliance on DRI, Xrender, Xvideo, etc.
- X11 is already used in a manner that is similar to Wayland but with a very poor inter-process communication layer and synchronization issues, with most of X11's core bypassed (server-side fonts, drawing APIs, etc).
- X11 when used remotely is already like VNC, but very poor at it. Lots of round-trips, etc, all to show bitmaps.
In the end, there are a few things I need from Wayland, and I think they will be there in the end:
- app-based network transparency, not just remote desktop
- middle click paste. Maybe done with a virtual frame buffer and rdp to ship the final rendering across the wire.
- customizable focus policy (focus follows mouse, click to raise)
- user replaceable window/composite managers
I suspect we'll lose a few features that very few people use such as using a remote window manager to manage windows on a local server. For example, running Xming on Windows, and then running metacity or even twm on my remote linux machine. A full remote desktop would probably be the way to go here with wayland. And faster.
No, this is Slashdot, you can't have a serious discussion.
It's full of idiots who don't like shiny new things, idiots who adore shiny new things and both types of idiots love to shout at each other.
Ok. Seriously.
Wayland is a new architecture for the Linux graphics stack.
It merges the role of the display server and the window manager/compositor into one piece, called the Wayland compositor.
It is envisioned that writing a Wayland compositor is not more complicated than writing a X window manager/compositor.
Buttet point: We will not have A Wayland compositor, but serveral of them to choose from: Weston, Enlightenment, Mutter/Gnome Shell, KWin.
This is made possible because a) Linux now has a proper graphic driver stack and b) the Wayland protocol is much simpler.
The new model and the simplified protocol will allow
A) better control of the input (keyboard, mice). Currently, the X window manager/compositor do not have absolute control about the input. Besides posing some security risks, it makes it hard to implement some behaviors sanely. Things as simple as being able to mute the sound when you have a full screen application running are hard to do.
Wayland compositors, of course, get all the input and then they forward them to applications as they see fit.
B) better performance (except OpenGL full screen applications which already mostly bypass X). This will come from a number of place.
- Reduced number of rountrips (W app/W compositor/kernel instead of X app/X server/X compositor/X compositor/kernel).
- Better implementation (the X.org server isn't the fastest cookie in the world, but the protocol is so complex it's hard to do better)
- On embedded platforms (phones, tablets, Raspberri Pi) the compositor can be written to exploit hardware compositing capabilites (there's no good way to expose it though the X server).
Additionally, the Wayland protocol fixes several issues, some of which could be fixed with more extensions, some need breaking.
- Artifacts/tearing. X doesn't specify when the data sent by applications is drawn on the screen, so sometimes you get artifacts as the server or compositor draw the contents of a window in the middle of an application drawing. Wayland fixes this by making every frame perfect.
- Saner input model. The currently used X input extensions are too complicated (by the authors own admission), as they need to maintain backward compatibility with the X Core input model.
- Saner dynamic reconfiguration (resolution, orientation). Again, by authors admission, XRandR is too complicated.
- Binding versioning. Currently, if you have an application built upon components who support different versions of an extension (ie, input), it's a russian roulette on how it will pan out.
Bullet point: despite all the drama going on on Slashdot and other sites, the simple truth is that the majority, if not all, of the developers who actually put in time and effort to maintain and upgrade the X.org server, the X window managers we use, the application toolkits, etc seem convinced Wayland is the way forward and are putting in the time and effort needed to make it happen.
Wayland is not network transparent. And despite the drama, that's OK. Nobody cares about network transparency.
People (including me) do care about having rootless remote applications. We care to have something that works at least as well as "ssh -X".
For the short/medium term, Wayland desktops will run a X compatibility server (XWayland) and most Wayland capable applications will have a X fallback mode. So "ssh -X" will just keep working.
For a longer term solution, when we get Wayland only applications, we'll need to implement something like NX or Xpra for Wayland. Which is OK too, because for many of us, it's better than running X over the network.
Despite the capabilities of the X protocol, most X applications are in fact too bandwidth intensive and latency sensitive to run remotely outside LANs. And their developers can't be arsed to do it otherwise. That's why we use things like NX and Xpra in the first place.
The "attack" was started by the first poster "Adolf" who thought anyone who didn't use a computer they way he does i.e. use X, was a twat and he attacked Wayland like a knob head (and possibly scared of having to learn something new). Otherwise this might have been a reasonable discussion.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
I found it quite interesting. I get the feeling his real core dissatisfaction is something he never quite articulates - it's turd-polishing and he just doesnt like doing that. Which is fair enough to some degree, no one really does, but that's what you should expect when you quit coding for pure fun and start drawing a paycheck for your work.
And of course it's even less fun when you spend a lot of time specifically fixing little 'bugs' that are only visible because you are forcing the codebase into a spot of the sort where it was never intended to go. What a nightmare. I can feel for him, and why he, personally, would be much happier dropping X down a deep dark hole and taking a different direction entirely.
I dont have any of that personal investment, I am just trying to use my computer. X works. Wayland sounds like it might be a lot better on a phone... well I will remember that next time I am looking for a phone. But there is no desire for it on my workstation.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
In the end, there are a few things I need from Wayland, and I think they will be there in the end:
...
- middle click paste. Maybe done with a virtual frame buffer and rdp to ship the final rendering across the wire.
Middle-click paste has nothing to do with how rendering is done. It has to do with 1) the event loop in your toolkit being able to get middle-click events and 2) code in a GUI application (whether toolkit or application code) being able to get the contents of the most recent selection, even if that might happen to be in another application.
The issue with middle-click paste in Wayland appears to be with 2) and how to do that in Wayland.
app-based network transparency is a feature of RDP. It hasn't been implemented in Windows as far as I know of but I'm optimistic that Wayland's proposed reliance on RDP for network applications will implement it per-app rather than full desktop.
It has been implemented for Windows server, AFAIK.
But saying rootless RDP is network transparent is a hell of an abuse of the term "network transparent".
Which of course is the root of all this drama. People confuse rootless remote applications with network transparency and they jump in anger when they hear Wayland isn't network transparent.
Sorry. That was a cut and paste typo. That sentence belonged with the first point.
Except that it's a bit worse than polishing a turd. When he was one of only two or three people who had enough knowledge of X11 and its code base to fix obscure bugs, that's not sustainable. Yes someone probably could after years of tribulation learn the code and the subsystems as well as he had and moved the code forward.
We do realize that with the absurd oversupply of CPU and GPU power in recent desktops and laptops, this delay is completely a deliberate visual artifact, and that it does not mean the available power is being taxed. But while the time of the GMA 950 and processors of 1/10 or less the power found now is past, the principle is still valid.
Actually even the crusty GMA950 is a relatively powerful GPU. It should be able to run a composited desktop with a lot of eye candy, without even breaking a sweat.
Bullshit. I had someone running a legacy app from a machine with only a 10Mb/s connection the other day. It worked as if he was running it locally. We're now in the age of gigabit.
Don't blame your wireless network hassles on something else.
VNC is one to one and X is many to one. If you want to do things on only one remote machine at a time, VNC gets the job done with a bit of annoyance (eg. prevention of anyone using the local display on the remote machine), but the entire desktop thing is a pain with anything other than a simple one to one thing. So in short, VNC is good for one thing and sucks at some others.
I think the biggest problem in these threads is the case of WAN access over a slow link is used as the strawman instead of the very common situation of the two machines being on a LAN. However even when people roll out the strawman they just don't seem to understand what should be obvious. Sending a single window down the wire requires less bits than a full desktop. Compression methods are equivalent these days via ssh, NX or the same methods built into tightVNC etc. I've managed to use X on dialup but not VNC becuase there was less bits to send.
app-based network transparency is a feature of RDP. It hasn't been implemented in Windows as far as I know of but I'm optimistic that Wayland's proposed reliance on RDP for network applications will implement it per-app rather than full desktop.
It has been available for several years now. It is used in App-V to access applications running on a server but displaying it'a GUI in windows on the local machine. I don't think you can use app-based RDP in a client Windows to client Windows configuration, though.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
No, this is Slashdot, you can't have a serious discussion.
It's full of idiots who don't like shiny new things, idiots who adore shiny new things and both types of idiots love to shout at each other.
Actually the problem is even easier. The world is full of idiots who don't understand, thinking the new system will be a step backwards because it isn't bolting on the old system, who don't realise the architectural problems X has, and who think every effort to try and create something better should result in a Henry Spencer quote: "Those who don't understand Unix are condemned to reinvent it, poorly." Seriously check how many times that sentence appears in the comments right now by people who don't realise that the developers of Wayland actually understand a hell of a lot more about X than anyone else.
People for some reason think Wayland is an effort to take away their toys as change for change's sake and they get aggressive because those who understand the issues support the efforts behind Wayland.
Oh really? Do tell. Where does the magic come from? You are not seriously going to tell me that SSH and OpenGL do it all without X being involved are you?
I'm sure you know a lot about some subjects. Why not write about them instead of ignorant speculation with this one?
... why a project like X.org would provide support for a project whose entire existance is intended to put an end to X.org?
mark "that would be like me supporting Rush Limberger"
Way to ignore the much more common case of running a few apps remotely and having them be first class windows on my desktop, neatly mixed and matched with windows from localhost. It works just fine.
VNC, RDP, etc are not at all the same. They confine the remote apps to a ghetto within a single window. They don't do drag and drop with local windows, they barely (if at all) manage cut/paste.