Posted
by
Soulskill
on Tuesday March 26, 2013 @11:01PM
from the onward-and-upward dept.

kthreadd writes "Version 3.8 of the GTK+ GUI framework has been released. A new feature in GTK+ 3.8 is support for Wayland 1.0, the display server that will replace X on free desktops. Among the other new features are improved support for theming, fixes to geometry management and improved accessibility. There is also better support for touch, as part of an ongoing effort in making GTK+ touch-aware."

"A new feature in GTK+ 3.8 is support for Wayland 1.0, the display server that will replace X on free desktops."
Who said this is going to replace X on 'free desktops'? As far as I have been hearing, this is just another in a long line and because it hasn't done it yet, it is not justifiable to say it will.

So you can fire up the X cruft when the user starts an application that uses the X cruft, and you can shut down the X cruft when the user has closed the last application that uses the X cruft. As more GUI toolkits are ported to Wayland, fewer will require X to be running.

Which for many of us, won't be. As per my example, if I want to have a server running headless and connect via XDMCP, Wayland doesn't support this. Also, plenty of us use more then Linux, and Wayland is only being developed for Linux. No Solaris or BSD support (much less older UNIX systems, say IRIX).

Which for many of us, won't be. As per my example, if I want to have a server running headless and connect via XDMCP, Wayland doesn't support this.

Who's "us"? For most home users, if they want to run desktop apps on a server, they want those apps to keep running when the desktop is shut down, so they now use Xvnc and WaylandVNC will work just as well.

"Home users" clearly aren't the "us" that I was referencing. Otherwise, I wouldn't have mentioned IRIX. I'm much less concerned with "home users" then I am with the server room. When I have to tell my clients to stay away from Linux because it's too unstable, too focused on the "home users" it will be a sad day. But it's coming very quickly.// And some of those clients really wouldn't mind moving to Solaris either. Especially since stuff doesn't just randomly change for the sake of change.

You can go easy on the melodrama. X will still be available for those who want it - Wayland is an option, and suited perfectly for those who only use their own computer and don't do remote accesses to other servers. X will be there piggybacking on Wayland for applications that DO require things like your XDMCP, but it won't be needed for those who only need the Window managers.

The thing about free desktops is that they are free to ignore Wayland and either stick with X, or go the Ubuntu way and do their own thing.

Yes, free desktops are free to ignore Wayland and do their own thing. On the other hand, they are at the mercy of the distributions, such as Ubuntu, RedHat, Suse (and all the rest). Ubuntu is dropping X and not using Wayland and going with their own in house Mir, so those free desktops, if they want to run on Ubuntu will need to work with Mir. If Redhat goes with Wayland, as it appears it will be doing, then those free desktops will need to work with Wayland.

Ubuntu is executing Embrace-Extend-Extinguish, hoping that people will tolerate Unity and they can nuke Gnome-Shell by having it not work with Mir, thus making it inconvenient and hacky and crappy on Ubuntu. I moved to OpenSuSE to get away from this Ballmerization.

Of the free desktops, currently, only KDE and GNOME have endorsed Wayland. Qt5 and now GTK 3.8 will support Wayland, and so it will be up to DEs that use them, such as LXDE or XFCE or Razor-qt to support them or not. They can stay w/ X11 if they like - nobody is forcing them.

The people who need the remote accessing capabilities of X - mainly those who work w/ servers and who use their X terminals to access different servers remotely - those would usually be the people who need the terminals more than an

server == daemon == service. Like udev is a hardware server, it and the dbus service lets your system show the USB hard drive you just plugged in. The whole thing is an application layer waiting for client applications to give it information, because the thing drawing on your screen is one big application rather than a nightmare of 40 little applications trying to do it.

The thing that pisses me and probably others off however is instead the likelyhood of wayland only apps which can't be run remotely like the X ones - then we may as well be on MS Windows.If you have one fixed software licence for an occasionally used application in an office and it works with X you can just run it on the display of whoever wants it, but if you have the 1980s idea of a dumb local framebuffer you have to reserve a machine for that application and do hotseating. It's stepping back to the single user non-networked idea that was worn out before MSDOS was badly cloned as a cut down single user version of CP/M.As for X bloat, it runs on Kindles FFS so that should show how stupid the bloat claim is. Would Wayland with gtk perform acceptably on something like a Kindle?

Bandwidth is a far easier problem to solve, particularly for longer connections.

Are you talking wired or wireless? And how long of a connection? In a way, the sustained bandwidth of a typical connection is limited to 6 to 15 kbps. That's the 2 to 5 GB per month cap on a mobile data connection, times 8000000 kilobits per GB, divided by 2629746 seconds in an average month.

You have a bandwidth limited connection? That's nice. Pay some more money, and get more bandwidth.

But there is a limit to how much more money for bandwidth the user of an application will be willing to tolerate. Good luck affording enough bandwidth to run something like OnLive for 8 hours a day, 22 days a month.

Just that the fewer the round-trips, the less latency dependent it becomes.

And if the application is running locally in a sandbox, communicating with the other machine only to synchronize data, there are even fewer round-trips. One example is any web application written in JavaScript.

Wayland does not preclude a network transparent transport. Despite your aversion to framebuffers, that's exactly how most X apps draw themselves these days. They're not using X primitives, they're rendering themselves into surfaces using abstract drawing APIs like cairo.

So when you run a modern app over a network, X is just shifting chunks of bitmap around anyway. Producing something analogous for Wayland is hardly an insurmountable task, and in the meantime things like vnc exist. It's even possible that

I read it some time ago and think that losing flexability is a high price for the supposed benefit of as yet unproven performance increases. Wayland needs to move towards "better as shown by these numbers" instead of a handwaving "will obviously be better at some point than X because it sucks".

in the meantime things like vnc exist

It was only a very short one line post above - why didn't you read it before replying?

VNC? What if more than one user wants to use something on the remote machine? It's the age of the "cloud" where you can get a 64 core machine for around $9k, hook it up to fast storage and let a lot of people use it for very complex tasks. What is someone want to run things on multiple machines and doesn't want to juggle half a dozen full "desktops"? Sod this MSDOS single user non-networked approach - it's 2013 FFS!Also that block diagram implies speed hits from the complexity and ignores that the wayland server+compositor is going to be doing a similar number of things internally as both the X server and compositor, so it doesn't prove your point and I doubt the person that drew it intended it to be used to try to prove that point.It's been a long time and a lot of claims - why no benchmarks for identical task yet instead of handwaving and "X sux!!11!"

About 50 people where I work for a start. Different servers do different tasks so application windows are vastly better than a stack of slow VNC desktops and even large images are best dealt with on a node with 32GB instead of a desktop with 4GB.

hampered by X11

In what way exactly? Wayland hasn't progressed to a working demo state yet so how is X hampering people more than what is available?

X11 involves a large number of context switches thanks to all the processes working to update the display. The intent of Wayland is to reduce that complexity and context switches which means the desktop will be more responsive and lightweight. I'm quite willing to accept that it will take some time for Wayland to mature sufficiently to reach optimal performance and stability, but that aside, it's obviously a smart idea to pursue. Many prominent X devs think so do, such as Keith Packard.

Well if the inclusion of JFS meant that the experience for the majority using EXT3/4 or BTRS was degraded then yes. But it isn't, so it doesn't matter. But for the majority of people using a local desktop, they are suffering a degraded experience for the sake of a fairly esoteric workflow (one which can be accomplished anyway even if the desktop did move to Wayland).

VNC only restricts you to one session on windows. On Linux you can have one XVnc session per person if you liked. Or if the remote machine has X, then run a rootless X11 server over Wayland and run apps like you always have (just because your machine is Wayland doesn't mean the machine hosting the executable does). There'll probably be a vnc server running over Wayland too at some point, as well as a proper network protocol for Wayland.

Most of the objections raised about network transparency seem pretty s

So that is somehow supposed to be better than the seamless high performance behaviour of application windows as distinct from a stack of slow scraped bitmaps?

Most of the objections raised about network transparency seem pretty silly IMO. Network transparent apps are a niche feature even in Linux

It appears we've hit the problem of the person who is dismissing X out of hand does not actually understand why people use it, which I suppose it why your suggestions have failed to address the questions.Until Waylan

It appears we've hit the problem of the person who is dismissing X out of hand does not actually understand why people use it, which I suppose it why your suggestions have failed to address the questions.

I'm not dismissing X out of hand. That would be a straw man. What I am saying is that it clearly impacts on the local desktop performance (and it's not hard to find comments [lwn.net] by leading X devs who state this for a fact). And most of the objections raised for switching to something more efficient concern a feature that not many people use, and even if Wayland were to become the default experience, could be achieved anyway.

Anyone who absolutely cannot abide the change can just use an X11 fork, or vnc / MX /

There is also a very good explanation on the wayland site as to why X is so awful for performance

I don't see any benchmarks demonstrating how X is so awful for performance. The games I play perform similarly to their counterparts on Windows. Videos play smoothly. Window management is extremely responsive.

Premature optimization is the root of all evil. The Wayland folks haven't even demonstrated that there is a performance problem. And they expect us to abandon well loved features, for what? A flow cha

As long it's installed by default, everywhere, and usable without elevated permissions, and as easily invoked as 'ssh -X remoteapp', I'll be happy. But given how the Wayland developers have taken the issue, I'm not holding my breath.

The thing that pisses me and probably others off however is instead the likelyhood of wayland only apps which can't be run remotely like the X ones - then we may as well be on MS Windows.If you have one fixed software licence for an occasionally used application in an office and it works with X you can just run it on the display of whoever wants it, but if you have the 1980s idea of a dumb local framebuffer you have to reserve a machine for that application and do hotseating. It's stepping back to the single user non-networked idea that was worn out before MSDOS was badly cloned as a cut down single user version of CP/M.As for X bloat, it runs on Kindles FFS so that should show how stupid the bloat claim is. Would Wayland with gtk perform acceptably on something like a Kindle?

Would your Kindle allow you to run remote X sessions? You can't say the problem with Wayland is that you can't run remote X sessions and then use the Kindle a support for X as it doesn't let you run remote X session, either.

I meant the e-ink versions that run X and the "awesome" window manager (http://awesome.naquadah.org/) - pity the Kindle platform is so closed that it had to be reverse engineered before anyone could use it to put remote windows on.Such a lean X window manager also demonstrates a likely design flaw with wayland being stuck with the window management that is built in and no option to replace it with different window managers for different roles. Making a one size fits all system that can be tweaked to fit di

Isn't Wayland aimed for the mobile market as a light-weight replacement for X? So on Desktops, where you want to support many graphics devices and features like X-Forwarding, you will want to stick with X (unless you already follow a cross-device distro using e.g. Unity).

Actually Wayland is just a fix to a non-issue. There was a perceived issue quite some time ago, but that was fixed. Wayland is little more than a "Going out of Business" sign on a furniture store. There must be good deals in there!!! Wayland is not X and I've heard that this thing I use daily that works near perfectly is horrible so Wayland must be good.

Not light-weight in that respect, the main difference is it doesn't draw anything. Each application has to render its own window complete with decorations, then tell Wayland where to find it. The only thing Wayland does is to combine them, like if you have overlapping windows, transparency, transitions or 3D effects. So it should be able to handle multiple graphics devices, multiple monitors and all that locally. What it doesn't have is any forwarding, since shared buffers are inherently local and it has no

Actually it's not even a Wayland idea per-se. There is no reason -at all- that client side decorations need to be done by Wayland: it's entirely possible to get the compositor to draw them. For some reason, however the Wayland developers policy is client decorations.

Right now I'm browsing in Chrome on Win7, where the top window bar is full of tabs so where do the client decorations start and end? One of the main complaints I hear about CSD is that a frozen application will also freeze the windows, but you have a compositor - you can have a key combo show a pop-up menu to minimize/move the window or kill the application etc. - your options are very static if it's not responding. The other big one is consistency, but I'm not sure if you're better off just having Gtk+/Qt

To be fair, whatever Android uses -- and whatever TiVo and other embedded systems use -- are successful, and were never aimed at replacing X. They were aimed at providing graphical output strictly for their devices, and if they hit the market, did so nicely. Android's interface is used by a bunch of software these days.

The rest were all aimed at general desktop usage as a main priority, and absolutely you're right: X outlived them all. That doesn't imply that will always be the case, merely that it is much more difficult than most people think, for a wide variety of reasons.

There *does* seem to be much more momentum toward a change recently. It feels a bit like the XFree86 to XOrg leap era.

To be fair, whatever Android uses -- and whatever TiVo and other embedded systems use -- are successful, and were never aimed at replacing X. They were aimed at providing graphical output strictly for their devices

Android is Linux without X and with a new GUI. In a very real way, whatever Android uses does replace X. Prior portable Linux systems have used X, and you could do what Android is doing with X.

Back in XFree 4.0, we got support for DDC, aka "plug and play monitor". This is a protocol that allows the monitor to inform the computer about things like size and resolution, from which we get the DPI of the monitor, which is important to make things like fonts have the correct size on high DPI screens.

Around Xserver 1.7 (which is according to the new numbering system that was introduced after Xorg 7.0, they decided to do like XP, and just pretend a

Yeah. The advantages of Wayland are actually pretty esoteric, if the goal is "I want to draw shit to my screen fast and efficiently". People think X is some clunking mess, and yet it was playing videos on computers 20 years ago.

What X is, is old. And developers are bored with it. And they want something new and shiny and a chance to play with the hardware without abstraction throwing a wet blanket over their benchmark scores.

The benchmark of success for Wayland is that _users_ don't actually notice that any

What X is, is a heap of arcane apis which nobody uses and a raft of extensions that have popped up over time to make it cope with the modern world. It's inefficient, complex (since clients must explicitly code for exensions with fallback behaviour). Proposing to get rid of it is not "esoteric" or "boredom", it's rational and pragmatic.

And yes I'd like my desktop to "draw shit to my screen fast and efficiently". Doing away with X11 will facilitate that. And for people who "like using X11" can continue to d

What you *think* you're talking about is the font mechanism, which few people use any more. Oh the horror, X has a small unpopular part in the core protocol.

I guess it will take up kilobytes of space on disk while the unused code sits paged out.

Perhaps you're thinking of the drawing mechanism? Only some parts are unused. When coupled with the XRender extension it works just fine, and the two work together.

The reparenting mechanism is still used. The window manipulation mechanisms are still used. The remoting is still used. The elegant (and yes, it is elegant if you actually take the time to figure it out) copy/paste and now DnD mechanism is still used. The input basic mechanism is still used for most things. The screensaver mechanism works just fine.

And so on.

Basically most of it is just fine and for some reason people kile you get their knickers in a twist about an old protocol call which is not much used any more.

So... your solution for requiring clients keep massive backwards compatibility is to break backwards compatibility. Okay, but you could jus tnot code clients with backwards compatibility to non extended X as well. Did that even occur to you?

Okey dokey. So it's not OK if you do it with X but it is OK if you do it with Wayland. I sense the FUD is strong in this one.

Proposing to get rid of it is not "esoteric" or "boredom", it's rational and pragmatic.

Basically the only thing people seem to coherently complain about is the little used and unloved font mechanism in X. Removing that is certainly worth losing remoting for!

And yes I'd like my desktop to "draw shit to my screen fast and efficiently". Doing away with X11 will facilitate that.

You are apparently not aware that X supports direct rendering and so has been able to "draw shit efficiently" for quite a long time now. Switching to Wayland won't change the rendering path.

The only efficiency improvement is that you input events will go from kernel->wayland->program not kernel->X->WM->X->program. If that has measurable latency then you're running on a 386 (good luck---it's out of support for Linux now) and rendering is the least of your worries.

And for people who "like using X11" can continue to do so - over Wayland.

FUD ATTACK!!! This has been rebutted many times including by me (again) elsewhere in this thread.

Perhaps you're thinking of the drawing mechanism? Only some parts are unused. When coupled with the XRender extension it works just fine, and the two work together.

Huge swathes of X are obsolete or unused, glyphs, logical fonts, rendering primitives, codemaps, and more. The fact you mention XRender means you recognize how obsolete X11 is yet all that shit must be implemented all the same.

So... your solution for requiring clients keep massive backwards compatibility is to break backwards compatibility. Okay, but you could jus tnot code clients with backwards compatibility to non extended X as well. Did that even occur to you?

I can't even parse that. If you want backwards compatibility, install and run X11. Otherwise what do you mean? Most apps have minimal dependencies on raw X. There might be some which tap an API, or implicitly get stuck on X through GLX or similar. But most call GTK or QT. Moving to a

It doesn't work exactly like Gnome 2, despite being vastly superior. Look there's less shit on my screen, I have fast access to all my running tasks in an exploded view, I have automatic virtual desktops, I can context-search for applications to run quickly... and alt-tab behavior sucks, somebody fix that.

X11 has extensions that shift all the damage and recomposition out to hardware, but it requires jumping through inordinate hoops which impact on performance, e.g. passing messages around between processes which increases latency from additional context switching. Basically X is a bottle neck in the middle mostly handing off tasks to extensions these days.

"it's easier for me to oppose their project loudly enough that it will sink"
You don't have that sort of power. No matter how much you shout on slashdot or wherever, you won't be able to sink Wayland through your "opposition".

Yet more "waaah, they're taking my X remoting!" crap. Wayland will enable an X server to run on top of it just like Windows does, just like OS X does - whilst enabling a far more efficient and modern rendering pipeline.

sure, you can eat a shit sandwich too, but it won't be very palatable.

Wayland will enable an X server to run on top of it just like Windows does, just like OS X does

Yeah, and we al know how well that works...

It's terrible. X is very much second class. Here are all the things that don't work:

* Copy/paste of more than text between X and non X* Remoting of non X windows* Drag and drop from X to non X* Pleasant window management of non X windows

whilst enabling a far more efficient and modern rendering pipeline.

Evidence needed, and biased FUD from the Wayland team doesn't cut it.

X has supported direct i.e. nothing in the way rendering for ages now and that is very efficient.

Compositing window managers require a whole extra 2 socket round trips to the kernel *PER MOUSE MOVE*. Given that the kernel has a latency of positively micrseconds this is clearly a big blow for X/sarcasm.

X on Quartz (OS X) actually works quite well. Copy/paste is not an issue.

The person to whom you're responding said a problem was "Copy/paste of more than text between X and non X" (emphasis mine). Can you, for example, copy an image from a Quartz app and paste it into an X11 app or vice versa?

- Session-Oriented == hacks for log-in screen- Tied to VTs- Crashes take down all clients- Takes 3 programs to draw a window: the application (hosting a lib), the window manager, the compositor- Complex drivers tied to 1 version of X11- Driver switching is impossible: it would take down all clients- Hardware manipulation living outside the kernel (requiring root when we shouldn't)- More lines of code than the Linux kernel- Copy/Paste can't survive source program shutdowns (very common in Mobile)- Remoting (

How many more years to we have to wait for a Win32 port of GTK+3? There are several projects which only have old versions ported to Windows because their newer builds target GTK+3 and that's not available yet.

Do you think that Wayland or Mir could add speed and smoothness to the Linux 3D-accelerated desktop? Because that's the feature I'm anticipating the most. When you turn on a little bit of effects there's always that slight jerky feeling you start getting. And it eats the performance too much. There's little delays in things happening, or some animation might pause for a little while. The icing of the cake, the fine responsivity of Win/Mac is currently not there with Linux.