Wayland 1.5 Released

An anonymous reader writes "Wayland 1.5 has been released, along with Weston Compositor 1.5. Wayland/Weston 1.5 carry many new user features, with a new libinput back-end, XWayland support, a full-screen shell, and many other changes. This release is particularly important as Fedora 21 will run on GNOME Wayland and X.Org Server 1.16 will be released this summer with integrated XWayland support."

Re:Will it really go the pulseaudio way?

[Microlith]

Wayland is critically important, which is why (unlike Pulseaudio) it hasn't already been rolled out yet. Qt has integrated it, Gnome has, KDE is porting KWin to implement it. There have been fairly few technical criticisms, the only one I've seen made with any muster has been network transparency - but even that could be solved rather easily given the way Wayland works with framebuffers.

On the flip side, Xorg has you dragging around unused cruft and the way it interfaces with the kernel forces some possible security holes be left open, holes that Wayland will fix.

Re:Will it really go the pulseaudio way?

[Anonymous Coward]

This might be useful.

http://tech.slashdot.org/story/13/04/03/1219239/remote-desktop-backend-merged-into-wayland

Re:Will it really go the pulseaudio way?

[Anonymous Coward]

not any time soon.
Problem is not with Wayland.
Problem is with NVIDIA binary drivers. They simply have no support of it and are rather in very initial stage of Wayland compatibility development. AMD open source drivers also suck at the moment when it comes to many aspects. So there is long road ahead.

Re:Will it really go the pulseaudio way?

[Tailhook]

RDP protocol support was merged [slashdot.org] into Wayland over a year ago. Wayland's original developer prototyped [youtube.com] a remote display implementation almost two years go, before 1.0 was released. This is in addition to XWayland [freedesktop.org] already providing an X server to host legacy X apps.

Wayland will have good remote display. The peanut gallery rant-fests around here not withstanding.

Anyhow. Now you know. If I'm wrong get a refund.

Re:Will it really go the pulseaudio way?

[Anonymous Coward]

Virtually none of the features (remote drawing) that X provided over the network are used today (line/polygon drawing) and tool kits like Qt/GTK+ have you shipping framebuffers across the network

I'm using Motif and tcl/tk over tunnelled X every day you insensitive clod.

And when I do have to use a bling app, 'ssh -CX' generally tames the beast, even web browsers with horribly inefficient and unwanted fade in - fade out effects.

Check out some supercomputer cluster management software some time. Bling doesn't matter one iota. Having the damn thing do its job matters.

grumble grumble lawn grumble grumble hipsters grumble grumble cold dead hands.

Re:Will it really go the pulseaudio way?

[DrXym]

There is already a reference RDP implementation in Weston. So to answer your question, it's happened already.

Re:Will it really go the pulseaudio way?

[DrXym]

Wayland is the protocol that clients talk with the compositor, not the compositor itself. The reference compositor Weston already implements an RDP server and does so in a remarkably small amount of source code.

As for it's performance, it will be no worse than X (or Xvnc) on modern apps because as everyone has stated, most modern apps are pushing pixmaps around anyway. If anything performance has the potential to be better because the remoting protocol can be asynchronous (unlike X) and the server doesn't have a handful of X and extensions processes with all their context switches to worry about.

Re:Clipboards?

[serviscope_minor]

Clipboard? It's a framebuffer with a compositor on top. Clipboards are a client problem (as are many other things).

Well, no, it's not. It's also a keyboard and mouse input system.

It also deals with copy and paste and drag and drop:

http://lwn.net/Articles/491509... [lwn.net]

Because it's a windowing system and it turns out that just a compositor alone isn't enough (who knew, eh?). It's also interesting. Apparently Wayland implements passing of data by just passing a file descriptor, apparently instead of reimplementing 10 pages of ICCCM grot. The thing about the 10 pages of ICCCM grot is it's really REALLY well specified and a random person from the internet can come along, read the ICCCM, grok it (yes, I have actually implemented copy/paste and XDnD from the specs) and get it working. It's not that hard.

The wayland one seems poorly specified by comparison. For example they don't specify teeny-tiny details liekl whether the FD must be seekable, for example. So, do you have to write a local file, or can you pass a socket? Who knows! It's really easy to have a short, simple spec when it's full of ambiguity and people haven't had 26 years to beat it into a definitive, unambiguous state. Anyway, I digress.

Now do you get why the "X sux" stuff from Wayland fanboys is annoying?

Yes, but it's more annoying when it comes from the Wayland author FUDmonsters who understand X11 and yet still make silly claims about it. For example, from the link above, Packard claims:

X was created before there was MIME or Unicode, so there are many pages expended in the X specifications to do things that are more easily handled with MIME types and UTF-8 these days. For cut-and-paste and drag-and-drop, Wayland uses MIME-labeled UTF-8 encoded objects.

Well, that sounds all like OMG X sucks we need MIME and UTF-8. Well the thing is, in order to list types from a copy/paste transfer, applications exchange a string (i.e. atom) with the type name(s) available. And guess what? Almost everything these days except for plain text is exchanged using MIME types. If the MIME-type specifies UTF-8, then the data will be in UTF-8 format. So basically, X names types with a string, just like MIME, and MIME works *perfectly* without modifying or respecifying anything.

You can verify this easily: download and install a copy/paste debugger/sniffer and look at the list of types available that programs offer.

The ICCCM also specifies a few (non-MIME) types that you might like to support, such as TEXT, which maps perfectly on to text/plain and is all of 1/2 a line to implement (if(typeAtom == TEXT || typeAtom == textPlainAtom)...). And X11 sends arbitrary data (including NULs) because it represents data as data+length not a string, so you can exchange anything, such as UTF8.

Anyway, KP implies that that doesn't work with X11 copy and paste, whereas in truth it works perfectly and without any faff or hacking.

Wayland is designed to be something different to X with different goals.

Not so much. It's designed to replace X wholesale. It does windowing, compositing, input, copy/paste/DnD, and a bit opf inter client communication.

Those of us that "want to run software from 1996" are made fun of in Wayland presentations,

Yeah us with our legacy programs. From stroustrup:

"Legacy code" often differs from its suggested alternative by actually working and scaling.

Meanwhile, I shall keep using legacy programs productively. XTerm works amazingly well, still. gvim works great---though I find I sometimes have to compile it with GTK disabled and with XAW (seriously WTF??) support because GTK can't seem to get its shit in order with fonts and everytime ubuntu updates itself/reboots, the font size changes. Xfig is old but works really well within its domain for producing simple, effective figures.

etc etc blah blah.

I also use some more modern programs too. And they all w

Re:Will it really go the pulseaudio way?

[TheRaven64]

Multi-second lag on X sounds like misuse of the protocol. Unfortunately, this is largely the fault of Xlib. The X11 protocol was carefully designed to be asynchronous, but then they wrapped the whole thin in a synchronous C API. This means that you end up sending a small amount of data to the server then blocking while you wait for the reply. Used correctly, you'd send all of the display updates sequentially, get the updates as the arrive, and later handle any errors that appear. Similarly, input events would be handled as they arrived, rather than synchronising everything. Unfortunately, although XCB fixes this, most toolkits are designed around the synchronous model so they don't really take advantage of it.