Posted
by
Unknown Lamer
on Wednesday March 26, 2014 @12:20PM
from the almost-there dept.

An anonymous reader writes that XWayland is nearly ready to be merged into the main X.org tree "X.Org Server 1.16 this summer should support XWayland, the means of allowing X11 applications to run atop Wayland-based compositors without the need for any application/game changes. With the revised design, XWayland has generic 2D acceleration over OpenGL and a cleaner design compared to earlier revisions. With GNOME 3.12 having better Wayland support and Plasma Next around the corner, it looks like 2014 could be the year of Wayland's take-off!"
The patch series emails have more details. The big news here is that XWayland is ditching its old DDX model for one based on Glamor. eliminating the need for any X.org drivers to be written to support X11 on Wayland: "Finally, the last patch adds the Xwayland DDX. Initially Xwayland was an
Xorg module that exposed an API for Xorg video drivers to hook into
so that we could reuse the native 2D acceleration. Now that glamor is
credible and still improving, a much better approach is to make Xwayland
its own DDX and use glamor for acceleration. A lot of the code in the Xorg
approach was busy preventing Xorg being Xorg, eg, preventing VT access,
preventing input driver loading, preventing drivers doing modesetting.
The new DDX in contrast is straight-forward, clean code, only 2500 lines of
code and neatly self-contained." It does not yet have direct rendering or any acceleration, but those patches should come soon.

Ironically, in the post-desktop era, UNIX started out the leader, with Linux fairly quickly taking a commanding percentage of deployments. It is now Microsoft who is so far behind that the odds seem insurmountable.

A desktop computer is a computer that hooks up to a TV and is controlled with a mouse instead of touch. It lets you do two things that most tablet computers can't do. One is split the screen so that you can have two or more things showing at once, so that the calculator app doesn't need to cover everything else up. The other is let you make apps. You know all these apps you run on your tablet? Someone made them on a desktop computer. There are also laptops, which look like a tablet with a keyboard but run

And in practice the lack of functionality and apps made for GNU platforms has a-lot to do with GNU licensing. Maybe if the FOSS "movement" wasn't so aggressively anti-capitalism (aka copyleft) that wouldn't be the case.

I'm the opposite. I can't stand lacking the ability to dig in and change software when I don't like the way it works. It's rare that I actually do, but there's a huge freedom I get from knowing that when I need to extend the software, I can.

It's common for commercial software to not do what I want it to, either. I'd love to have a working amazon instant video client for my Android phone.

Because someone who pays for software instead of writing it themselves a "whiner", when all they're doing is saying they prefer to pay for software that works instead of hiring a contractor (10 - 50k sounds about right for a substantial result) to make FOSS software functional.
I wonder, did you build your car from metal you smelted mined from your back yard or are you just a crybaby that participates in an economy?

Hardware failure can't be avoided, but I think we can do better on the software side of things. I mean, if the Wayland project keeps going strong and the efforts to Not Break Everything keep progressing, we could end up with a case where X.org simply has a Wayland driver and while all the issues that can exist may exist, we can bypass a lot of the heartache if the project continues going smoothly. This article gives me hope that we're not destroying everything in this process.

It does not yet have direct rendering or any acceleration, but those patches should come soon.

The patch series emails have more details. The big news here is that XWayland is ditching its old DDX model for one based on Glamor. eliminating the need for any X.org drivers to be written to support X11 on Wayland:

This part kind of aggravates me, honestly. There's a chicken-and-egg problem when it comes to diddling with every relevant part of the stack and how they communicate with the driver layers. The most important part as far as maintaining compatibility and supporting existing systems is making it so that common (legacy is the wrong word) API layers continue to function utilizing the new back-ends, but the logistics of where that begins and ends are very much in flux with this development process. OpenGL is a n

OK, so I need to buy a clue here... does this move the ball forward with respect to being able to run an X-Windows client application on one node, and set the display back to a Wayland-based display server running on another node elsewhere on the network?

Actually, I do *NOT* want VNC. My objective is to run an X app on a server that itself has no video capabilities at all and have that window appear fully integrated on my workstation desktop. I do not want a window that contains an entirely unneeded desktop that contains the app window that I actually want.

In that case what you want is xpra [xpra.org]. Each window is rendered off-screen and forwarded individually, as a compressed video stream (x264 if it's available). You can detach from the xpra server and reattach later, from the same client or a different one, with all your applications intact. A lot like how Wayland remoting will work, really, except that in Wayland it will be better integrated due to not needing to support all the legacy parts of X11.

I do use xpra sometimes when I need the extra functionality and it works well. My point ws that VNC is a non-starter for that need (it works well for other situations, especially for providing remote user support).

As for Wayland, the only thing I've seen there is experimental support for running the full blown Wayland server and compositor on the server and it will use RDP if you want to view it remotely. It's hard to tell though since it's all very hand wavey at this point.

As for Wayland, the only thing I've seen there is experimental support for running the full blown Wayland server and compositor on the server and it will use RDP if you want to view it remotely.

Well, you will need a Wayland compositor on the server, since Wayland is a local/shared-memory IPC protocol. The compositor will take the place of the xpra server, and communicate with a proxy (Wayland client) on the user's machine. It doesn't have to merge the windows into a single desktop, however. The current RDP backend in Weston is limited to the desktop mode, but if you can forward a complete desktop then there's nothing technically difficult about forwarding an individual window; it's just a matter o

Do you really care about remote X protocol, or do you want a remote window with the app on it? 'Cause Wayland checked in per-app RDP a year ago and making a chromeless RDP viewer ought to be pretty straightforward (if it doesn't exist already). ssh handles X specially - handling RDP specially could be something it adds.

For some people the distinction matters, but for others it's good enough (or better), depending on which needs more bandwidth, as X can sometimes be an unreasonable pig on the wire (see als

Yeah, Linux seems to be killing BSD and all flavors of UNIX on the desktop that don't have an apple logo on them. I'm not sure why Non-linux support is really needed. However, if it is needed, it kind of makes sense to get it working rock solid and tested on the largest of the three ( linux, BSD, UNIX), before starting a port to the others. When Gnome and KDE have made the transition, then I think it would probably be ready for BSD & Unix Ports.

XWayland is the X server for Wayland, so that you can run traditional X applications on Wayland (as opposed to Qt etc. applications, which will talk directly to Wayland). http://wayland.freedesktop.org... [freedesktop.org]

Client X11 apps speak the X11 protocol to XWayland, XWayland speaks the Wayland protocol to Wayland so it's basically a big compatility shim. From Wayland's side it's just another client and if you use an X11 server you don't need it, it's not really part of either. Maybe the closest analogy is WINE, if you use Windows or run native Linux applications you don't need it. But if you want to run Windows applications on Linux you need WINE, likewise if you want to run X11 applications on Wayland you need XWayland. Basically you take an X11 server, stop it from talking to actual hardware and makes it draw to a Wayland window instead.

At this point, it's mostly just you. All this work going on vastly simplifies the stack. Wayland compositors are much simpler than the entire X stack (which has to be supported even though much of it isn't used). Unfortunately, X still needs to stay around in some capacity so we can still play our proprietary games,etc.

That's just not the case. I have been amused at the proliferation of Linux graphics stack diagrams that have emerged on Wikipedia as contributors try to explain this stuff. There are six (nice) distinct diagrams on this page [wikipedia.org], for instance. The fact is that rendering graphics is hard and lengthy pipelines tend to emerge and unless you have your head in it for some reason it appears "insanely complex."

Anything without acceleration is an experiment. It doesn't matter how many lines of code you've written, or how efficient it seems. 100% of the required functionality is acceleration.

Acceleration is why X is being replaced by Wayland. 2D X11 requires a separate driver for every different type of hardware. 3D X11, from what I read by the Wayland people themselves, has three different APIs. For a long time, the only drivers with good 3D acceleration were proprietary drivers from AMD and nVidia.

I want Wayland to succeed, but I feel that it's still a long way off. The devil is in the acceleration. Think about the time spent by XFree86 developers over the decades writing acceleration code versus everything else, and that's the part we're missing right now. I'm not very clear on just where the acceleration is missing, but it sounds like it's missing in a foundational piece.

Think about the time spent by XFree86 developers over the decades writing acceleration code versus everything else, and that's the part we're missing right now.

The Wayland developers are, for the most part, the X developers, so they not only have access to all that existing X driver code that took so long to write, they're the folks who best understand that code, and know how to adapt it to a new environment. They're standing on the shoulders of giants (and in some cases, are the giants).

The biggest changes we should expect to see are in the API. Under the hood, I expect to see a whole lot of code that's identical to the current Xserver, or nearly so. As I underst

This again? Two guys that worked on bits of Xorg are not collectively "the X developers". There are plenty of others out there working on stuff other than a nice tear free framebuffer for a phone. There are plenty of others that don't laugh at "running that app from 1996", who don't laugh at shaped windows, who don't bite the hand that is actually adding some wayland support and who have something better than a half finished presentation with no screenshots to show off their work.

And where did I say anything like "X sux..."? I said Wayland is going to have the benefit of the work that was done on X to create drivers, and the benefit of people on its team who generally understand those drivers. And you attacked like some sort of rabid mongoose.

I like X. I use its remote features regularly. And I'm quite satisfied with its performance. I'm going to be reluctant to switch to Wayland until it supports (directly or through XWayland) all the features I need. Nevertheless, I think I'm prob

It's not quite as bad as it sounds, the actual hardware drivers are still accelerated and exposed as OpenGL, it's just that XWayland doesn't make use of it. If you look at this diagram [wikipedia.org] it's the line between the X-server and libDRM that's broken when you use XWayland instead because Wayland can't talk directly down to that level. XWayland needs to be rewritten to accelerate graphics using OpenGL instead, then it'll hook into the green box above libDRM and all will be well. Luckily for the Wayland project so

It's advertised as a way to make things less complex. But it lacks critical functionality from day 1, it's already due a rewrite to support OpenGL properly (which I'd say is PRETTY BASIC FUNCTIONALITY), and certain other feature requests, like remote apps, get contradictory and often ridiculous responses, from "You don't need that" ("But I use it!) "Then you're just wierd, fuck off weirdo" to "Oh, in Wayland we'll be turning each window into a live H.264 video stream! That'll have no l