X.Org Server 1.15 Brings DRI3, Lacks XWayland Support 340
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."
Re:Good! (Score:5, Informative)
Really? Lots of configuration?
Last time I ran an X11 application remotely, I used SSH with X forwarding with a simple command line. Worked great. (Flawless, I might say.)
Last time I ran a multi-headed X box (where multi-head == "two or more independent monitors+keyboards+mice, each with their own root window and window manager"), the configuration wasn't trivial, but it wasn't hard either. And once it was done, any X11 "server" could connect to this "client" and run any program over 100-mbps Ethernet. (Look, ma! A terminal server! Hot-desking! Remote access! THE CLOUD! Buzzword-bingo on the end of a 20-year-old carrot!)
And it doesn't much matter when the "last time" was, since the methods haven't changed a bit over the past decade or two.
These are things that other graphical systems cannot do. And they are the reasons why X, or perhaps X11, is still important.
Those who do not understand X, are doomed to recreate it. Badly.
Re:Good! (Score:5, Informative)
No. I just like network-transparent applications. It was one of the main draws that I had toward Linux almost 20 years ago, and is why I still use it today.
(My home Linux boxen are all headless, and they can stay that way for all I care. If I want to run something graphical, it's trivial with X.)
(And no: VNC is more of a problem than it is a solution.)
Modern X(org,server.. et.el) really is not network transparent unless you are just talking about TWM mixed in with a xclock or an xterm, most modern apps and even window managers that are built on top of modern gui toolkits and/or extensions are not compatible with the basic X library which makes X network transparent. Most of what makes X tick now and days will not scale over the average network and you will be left with a lame ass system if you try. As such if you want to use your modern desktop environment over a network prepared to and plan to pull your hair out because you are relying on such outdated tech norms.
Wayland is the future and the way forwards fellow *inx junkies.
Daniel Stone core X.o dev on what's wrong with X (Score:5, Informative)
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 [youtube.com]
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.
Re:Can we have a discussion - not a slagging match (Score:5, Informative)
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.
Re:Good! (Score:2, Informative)
How to use remote X over ssh:
1. Do not configure the X server to refuse to forward X11 connections (i.e. it will work unless you broke it yourself).
2. Have the "xauth" command installed on both sides (it is by default, but you might be someone who broke it yourself...)
3. ssh -X user@target "libreoffce" (for example).
Done. And it will just work.