Slashdot Mirror

As far as drivers, the abstraction layer is supposedly EGL / OpenGL ES. Of course, that assumes every OpenGL ES implementation works flawlessly out of the box without hacking around bugs, etc, which is rarely the case.

AFAIK, Weston only supports Mesa right now. Nvidia doesn't provide an OpenGL ES library or Mesa support in their binary drivers, so you'd be stuck with the open source nouveau driver if you want to use Weston.

There's also the concept of nesting compositors, where the desktop window manager (kwin, gnome-shell, etc) would run as a session compositor and handle window decorations, drag events, and compositing, and then it would send the full screen image to the system compositor which would just do a dumb blit to the screen.

I'm curious about of the performance of this, since it sounds like you basically have:

1) App renders widgets/video/3D using OpenGL to a window pixmap, and sends the pixmap to session compositor.
2) Session compositor uploads window pixmaps to OpenGL textures and then renders the scene to a full-screen pixmap, and sends it to the system compositor.
3) System compositor sends full-screen pixmap to the OpenGL drivers, which displays it.

which seems like it'd use a fair amount of bandwidth shuffling back and forth pixmaps that might be nearly 2650x1600 for a maximized window, at 60fps. There might be some optimizations to pass off the images without compositing, e.g. for a full screen window or if there's no overlap, but there might also be some degenerate cases.

Note they also sometimes drop support for old formats too:
https://bugs.freedesktop.org/show_bug.cgi?id=59902

This is all pretty much exactly why freedesktop.org (formerly XDG) was formed.

n+1 standards and all that, but the major specs have been adopted by every DE that I'm aware of.

As to when it will all filter down to distros to split out unnecessary package dependencies, I have no idea. I'm not familiar with a whole lot of packaging systems, but AFAIK there is no package installer which can mirror the compile-time --enable-feature and --disable-feature behaviour of configure scripts such that you only draw in packages dependencies based on the optional features you select, and don't end up installing pulseaudio because you wanted a lightweight notepad-like text editor (for a made-up example).

This is all pretty much exactly why freedesktop.org (formerly XDG) was formed.

n+1 standards and all that, but the major specs have been adopted by every DE that I'm aware of.

As to when it will all filter down to distros to split out unnecessary package dependencies, I have no idea. I'm not familiar with a whole lot of packaging systems, but AFAIK there is no package installer which can mirror the compile-time --enable-feature and --disable-feature behaviour of configure scripts such that you only draw in packages dependencies based on the optional features you select, and don't end up installing pulseaudio because you wanted a lightweight notepad-like text editor (for a made-up example).

systemd is extremely well documented:

http://www.freedesktop.org/software/systemd/man/
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks/
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
http://freedesktop.org/wiki/Software/systemd/Debugging
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

what the heck could you possibly be missing?

systemd is extremely well documented:

http://www.freedesktop.org/software/systemd/man/
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks/
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
http://freedesktop.org/wiki/Software/systemd/Debugging
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

what the heck could you possibly be missing?

systemd is extremely well documented:

http://www.freedesktop.org/software/systemd/man/
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks/
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
http://freedesktop.org/wiki/Software/systemd/Debugging
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

what the heck could you possibly be missing?

systemd is extremely well documented:

http://www.freedesktop.org/software/systemd/man/
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks/
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
http://freedesktop.org/wiki/Software/systemd/Debugging
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

what the heck could you possibly be missing?

systemd is extremely well documented:

http://www.freedesktop.org/software/systemd/man/
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks/
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
http://freedesktop.org/wiki/Software/systemd/Debugging
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

what the heck could you possibly be missing?

What do you mean, "shouldn't Wayland be out already"? The fact that it has had twelve public releases to this day, that it is available to be installed from recent distros' repositories and that desktop environments and window managers plan to have something based on Wayland by next fall?

from the Wayland faq it seems that the X developers have a different perception of the X protocol:

What is wrong with X?

The problem with X is that... it's X. When you're an X server there's a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. For example, core fonts; this is the original font model that was how your got text on the screen for the many first years of X11. This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!). Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extensions such as XRandR, XRender and COMPOSITE and to some extent phase out less useful extensions. But we can't ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to an optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if don't plan for it.

Too many flames in these weekly Wayland discussions and not enough facts (or maybe the facts are downmodded; I've gotten to the point where if I look at a wayland article, I don't read all of the comments).

So, I just spent 5 or 10 minutes skimming the Wayland FAQ and architecture diagram.

For comparison, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that it *is* a compositor that provides both window manager functions and some of the functionality of an X server.

Intentionally misstating things rather badly, it sounds like the reason Wayland doesn't support remote displays is because it also doesn't support local displays! More accurately, wayland supports local displays (of course), but unlike X11 provides no way to render to them. Wayland doesn't do rendering; it apparently "just" knows how to swap video buffers to a display device and coordinate buffers between multiple clients.

I'm thinking that, for example, if you want to write a graphical app, you might target OpenGL or cario and then expect your code to work in both Unix (with X) and on Windows (without X). With Unix/X, I'd expect an opengl library that handed X primitives to the X server. With Wayland, you'd apparently have an opengl library that rendered to a buffer and then handed the buffer off to the Wayland compositor.

So, Wayland isn't doing some of the things we'd expect an X server to do. Wayland is never working with drawing primitives. It seems obvious that you'd never be able to run apps that use the old X toolkit libraries against Wayland without an X server in the picture. And, the FAQ admits this and notes that you'll need an X server in addition to Wayland for the foreseeable future.

However, as others have noted, an obvious question is how efficiently a "native" Wayland app could be displayed remotely. If the app and its libraries are rendering graphics primitives into display buffers, it seems obvious that low level primitive operations are lost by the time wayland gets the buffers, so you now have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient... OTOH, it seems unlikely that apps would include their own rendering code instead of using as library. So, we can hope that the libraries offer both wayland and X backends, I guess.

Not an X server developer nor a Wayland developer. I'm sure I garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the weekly Wayland discussions.

Too many flames in these weekly Wayland discussions and not enough facts (or maybe the facts are downmodded; I've gotten to the point where if I look at a wayland article, I don't read all of the comments).

So, I just spent 5 or 10 minutes skimming the Wayland FAQ and architecture diagram.

For comparison, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that it *is* a compositor that provides both window manager functions and some of the functionality of an X server.

Intentionally misstating things rather badly, it sounds like the reason Wayland doesn't support remote displays is because it also doesn't support local displays! More accurately, wayland supports local displays (of course), but unlike X11 provides no way to render to them. Wayland doesn't do rendering; it apparently "just" knows how to swap video buffers to a display device and coordinate buffers between multiple clients.

I'm thinking that, for example, if you want to write a graphical app, you might target OpenGL or cario and then expect your code to work in both Unix (with X) and on Windows (without X). With Unix/X, I'd expect an opengl library that handed X primitives to the X server. With Wayland, you'd apparently have an opengl library that rendered to a buffer and then handed the buffer off to the Wayland compositor.

So, Wayland isn't doing some of the things we'd expect an X server to do. Wayland is never working with drawing primitives. It seems obvious that you'd never be able to run apps that use the old X toolkit libraries against Wayland without an X server in the picture. And, the FAQ admits this and notes that you'll need an X server in addition to Wayland for the foreseeable future.

However, as others have noted, an obvious question is how efficiently a "native" Wayland app could be displayed remotely. If the app and its libraries are rendering graphics primitives into display buffers, it seems obvious that low level primitive operations are lost by the time wayland gets the buffers, so you now have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient... OTOH, it seems unlikely that apps would include their own rendering code instead of using as library. So, we can hope that the libraries offer both wayland and X backends, I guess.

Not an X server developer nor a Wayland developer. I'm sure I garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the weekly Wayland discussions.

It's not reinventing the wheel so much as reorganizing it to remove legacy cruft from the performance-critical hotpath b/t clients and hardware.

From the Wayland architecture overview:

Most of the complexity that the X server used to handle is now available in the kernel or self contained libraries (KMS, evdev, mesa, fontconfig, freetype, cairo, Qt, etc). In general, the X server is now just a middle man that introduces an extra step between applications and the compositor and an extra step between the compositor and the hardware.

Wayland's native remoting protocol is under development but "only at the proof of concept state". http://cgit.freedesktop.org/~krh/weston/log/?h=remote http://lists.freedesktop.org/archives/wayland-devel/2013-April/008555.html

All the people talking about RDP keep in mind that that's a stopgap and won't be needed long-term.

Wayland's native remoting protocol is under development but "only at the proof of concept state". http://cgit.freedesktop.org/~krh/weston/log/?h=remote http://lists.freedesktop.org/archives/wayland-devel/2013-April/008555.html

All the people talking about RDP keep in mind that that's a stopgap and won't be needed long-term.

Why not link to the mailng list post? Don't give hits to the spammy fuckers. Link to the source! Use the source Luke! http://lists.freedesktop.org/archives/wayland-devel/2013-April/008631.html

This has nothing to do with Gallium 3D or Mesa which are 3D graphics related. The only similarity is that some of the targets happens to be GPU. The person has no clue what the hell he was talking about. May be he is confused it with OpenGL!?

This is AMD's answer to CUDA.

No, you're quite wrong and he's entirely right. This has everything to do with Gallium and Mesa. Despite it sometimes being called "Gallium3D", Gallium is not just for graphics. It also supports GPU compute, specifically OpenCL, through the Clover state tracker.

You must not recognize the name of Dave Airlie - among other things, he's an active Mesa developer, one of the main X.Org developers, and the maintainer of the Direct Rendering Manager in the Linux kernel; i.e., he is the person who submits the pull requests to Linus for the graphics drivers in the kernel. Not exactly the kind of person who would get confused over the difference between OpenGL and OpenCL, or who has "no clue" what he's talking about.

Dave Airlie is right. There is no good reason for Intel to duplicate all of the work already done on Clover. Of course, Intel hasn't used Gallium for anything before, but their GL drivers have been around since before Gallium drivers became the standard and their video decoding implementation came before there were Gallium state trackers for video decoding.

This, however, just seems like mismanagement to me. Maybe it has to do with this being developed by Intel OTC China instead of Intel OSTC Portland where Intel's Mesa developers are employed, but we now have two frontends that do the same thing.

From the readme in its repository, it seems that Beignet is still far from complete. Hopefully Intel will change its mind and use Clover if it wants OpenCL working on its hardware under Linux.

A comment on their discussion page is more insightful and likely to be right:

So it looks like that comment is right: everything's hidden in a binary blob and there is no source code released at all at this time.

A comment on their discussion page is more insightful and likely to be right:

So it looks like that comment is right: everything's hidden in a binary blob and there is no source code released at all at this time.

Ack! I've been bothered by this too (but not too much; I mainly use the Linux desktop for work nowadays, which does not require dealing with all those annoying human languages). Now I learn that they have provided an interim solution after all, and proper fixes are on the way. Great! Wait... your comment was supposed to point out how uncooperative the developers are? I guess by the prevalent opinion on this site, they should have immediately prostrated in infinite shame before everybody who has obtained GNOME for free, and locked themselves in a remote hermitage for a solemn hackfest to last until all the conflicting outside opinions on implementing the UI are addressed. Do it, or face the Slashdot rage!

XKB has always been a wretched hive of complexity where no sane human should dare to step in. It tells a lot that nobody came forward to fix this bug for seven years, and it's still not mainlined. Not that iBus looks much better, though... I hope they will provide something more sensible atop Wayland.

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 GTK / QT and other APIs could intelligently detect which backend to use, e.g. by looking at the DISPLAY variable and the app largely doesn't have to care. And if the app in question is not modern, e.g. it's an older GTK or hits X APIs directly then an X server can be run locally over Wayland to host it - but without requiring everyone else suffer the same overhead.

There is also a very good explanation on the wayland site as to why X is so awful for performance which can be summarised as too much context switching. It would be worth reading it.

Poor summary. Wayland allows the running of X11 applications through an X server, with work being done to support this on Intel and AMD graphics:

http://lists.freedesktop.org/archives/wayland-devel/2010-November/000292.html

I'll do you better than design:

http://lists.freedesktop.org/archives/wayland-devel/2013-March/007740.html

It's done.

Here's a better example than X/OpenGL:

Q: Does Linux support email?
A: No, that is outside the scope of Linux.

There is not a single line in Linux that is written to support email. Does that mean you can't do email in Linux? Of course not! Similarly, you can have remote display when using Wayland, it's just not part of the Wayland core.

What's more, remote display on Wayland has already been prototyped. Twice.

Here's a better example than X/OpenGL:

Q: Does Linux support email?
A: No, that is outside the scope of Linux.

There is not a single line in Linux that is written to support email. Does that mean you can't do email in Linux? Of course not! Similarly, you can have remote display when using Wayland, it's just not part of the Wayland core.

What's more, remote display on Wayland has already been prototyped. Twice.

Hey, guess what?

X is not network transparent.

No, really. I mean, it was, but it isn't anymore. Why? Because nowadays everybody uses SHM and DRI2, which don't work over the network.

So unless you're using Motif, then all X is doing is shipping bitmaps over the network, and doing it in an extremely chatty way that involves lots of round-trips from server to client for every single frame, injecting huge amounts of latency for no reason.

But chances are you don't really care about network transparency. Chances are you just think it's a synonym for remote display.

Guess what else?

Wayland supports remote display.

Here's one implementation, and here's another implementation written by somebody else.

Now, technically, those projects do not add remoting to Wayland, but instead add it to Weston, the reference compositor for Wayland. That's because the Wayland developers follow the Unix philosophy: do one thing really well. Wayland is not a kitchen sink like X is. It's part of a stack of interchangeable parts, and there's no reason remoting needs to be implemented directly in the display server.

Hey, guess what?

X is not network transparent.

No, really. I mean, it was, but it isn't anymore. Why? Because nowadays everybody uses SHM and DRI2, which don't work over the network.

So unless you're using Motif, then all X is doing is shipping bitmaps over the network, and doing it in an extremely chatty way that involves lots of round-trips from server to client for every single frame, injecting huge amounts of latency for no reason.

But chances are you don't really care about network transparency. Chances are you just think it's a synonym for remote display.

Guess what else?

Wayland supports remote display.

Here's one implementation, and here's another implementation written by somebody else.

Now, technically, those projects do not add remoting to Wayland, but instead add it to Weston, the reference compositor for Wayland. That's because the Wayland developers follow the Unix philosophy: do one thing really well. Wayland is not a kitchen sink like X is. It's part of a stack of interchangeable parts, and there's no reason remoting needs to be implemented directly in the display server.

get the Wayland developers to guarantee that Wayland apps will be network transparent

Well, I should quote the Wayland FAQ here:

"Is Wayland network transparent / does it support remote rendering?

No, that is outside the scope of Wayland."

Really, everybody should read that and understand it, and also its consequences. Frankly, to me, the idea, that by switching to Wayland will somehow mean that you lose network transparency it just as absurd that by switching to X you lose OpenGL support (which is absolutely not a part of the X protocol - X11 came out in 1987, OpenGL in 1992). So while Wayland itself will not support network transparency, the full stack surely will.

Does anybody know how well the Linux Steam client runs on this?

Unless they really ripped things up more than expected(or Steam demands a bunch of proprietary libraries, rather than just blobbing them in), I'd assume that it would run more or less entirely the same.

The only significant caveat, of course, is that games tend to be hard on the GPU, and FOSS GPU driver performance can be a bit... touchy. Intel GMAs work about as well as they ever do with free drivers(does Intel even bother to maintain a proprietary branch on linux?); but just aren't that fast. AMD GPU performance under free drivers varies by family; but tends to lag their proprietary driver in pure punch(although it sometimes leads it in playing nicely). Nvidia's proprietary driver is generally considered the best; but the alternatives are either Nouveau, which makes the AMD FOSS drivers look mature and powerful, or almost nothing(Nvidia's official advice is as follows Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation until they can download and install the NVIDIA Linux driver from their distribution repositories or from nvidia.com.

So, you will likely be able to install it; but unless you have an Intel GPU, or specific AMD parts, or even more specific Nvidia parts, you'll end up shoving so much binary blob into your kernel in order to meaningfully use it that your objective in installing it isn't really clear...

You're just betraying your ignorance of Wayland. Wayland does NOT replace X windows. In fact Wayland was designed from scratch so that an X server can run in wayland WITH NO PERFORMANCE PENALTY.

You should at least read the Wayland FAQ before calling someone ignorant. Because I think you'll be surprised about who actually is the 'ignorant' one. (Why even do an ad hominem attack at all?)

Wayland DOES replace X windows. It just allows you to run an X server alongside it (like OS X does). They even go so far as state that Wayland native applications will not offer network transparent remote rendering (you will have to run remote desktop software like Windows and native OS X). Also unlike your claims, the FAQ explicitly states that there will be some minimum performance overhead for X windows applications running within Wayland.

Those were issues with Xglx (mostly raised by nVidia specifically) which was supposed to be a stop-gap measure. Xegl was the long term approach. It wasn't just purely technical but rather a debate if the current X display server was salvageable. Red Hat and nVidia thought it was.

I reference David Reveman's post to the xorg mailing list.

I think the arguments made by nvidia to why X on OpenGL would be worse
than the current driver architecture can be debated on until forever. I
think it all boils down to if we want put some more effort to it and
take the big scary step to something new or if we want to stick to the
old well known. Not too surprising, we have people who are in favor of
both and we'll likely have development being done on both, which I don't
think is that bad after all.

So far I haven't heard a single argument for why X on OpenGL is a a bad
idea other than that it's a big step and a lot of work will have to be
done. If that would stop me from working on Xgl, I wouldn't have started
working on it in the first place

So yes I did do my homework. I did it 7 years ago and the teacher just forgot to collect it.

OK, it was incredibly hard to dig it out from an obscure document confusingly called the FAQ:

Q: What is the drawing API?

A: "Whatever you want it to be, honey". Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer. When the client is, it informs the Wayland server of the new contents. The current test clients use either cairo software rendering, cairo on OpenGL or hardware accelerated OpenGL directly. As long as you have a userspace driver library that will let you render into a sharable buffer, you're good to go.

XBMC = XBox Media Center - http://xbmc.org/ SDL = Simple DirectMedia Layer - http://www.libsdl.org/ Wayland = http://wayland.freedesktop.org/

Some Linux distros don't include it because they're not happy with its license.

http://lists.freedesktop.org/archives/distributions/2008-October/000276.html

One thing I do hope to see in PC-BSD is Wayland support - it's not needed in FBSD, but PC-BSD ought to have it.

It looks like Philip Withnall started working on Wayland for FreeBSD, look for his messages in the ML.

Either that's no longer true or they got enough 3d stuff working to support 2d already:

http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=a60d2152e928a7011fc7c44a885a34c3cdd4f0fe

Since we're complaining about old bugs, I have the stupid udisk floppy bug. I need floppies to transfer stuff to this antique laptop I'm fooling around with, and guess what? Most every linux distro has had this ridiculous bug in udisk for YEARS: Freedesktop entry ; also at Ubuntu's Launchpad

  Basically, udisk stupidly force-umounts floppies the instant they're mounted, so you can't "mount /media/floppy" and use it. Ever. It's fixed in the new codebase, udisk2, but the bug in udisk1 (which many distros, including mine will be using for the near future as udisk2 works in a whole different way) is unfixed. (Apparently it appeared because somebody couldn't figure out how to avoid a delay when booting, as udisk searched for a nonexistant floppy drive on systems without one. So he solved it in a way that BROKE. ALL. FLOPPY. DISKS.)

  Not only that, but one developer actually acknowledged that it's broken, then told people affected by the bug that "floppies are rare, so I don't care," and marked the fucking bug as "WORKSFORME" (!!) because it doesn't affect the entirely seperate udisk2 codebase.
    Which is some of the stupidest shit I've ever seen. WONTFIX, while it is the douchiest tag, would be more appropriate since he flat-out admits it doesn't work. I think the udisk devs are hoping to beat ffmpeg out for "biggest dickhead developers." (They have a lot of ground to make up, though. Heh.)
  Fortunately, I use the command line and can issue a "udisk --mount /dev/fd0" instead as a workaround, but all integrated desktop floppy handling is borked for the time being by a years-old bug. I love linux, and this kind of shit really holds it back, IMO.

You can't run 10 year old linux binaries on something that just works for years and years.

You can if you have the code. Even then, libraries might have changed. But it's mostly about using deprecated C standards -which should be easily fixable. This, by the way, is one reason that I don't trust languages like Python, Ruby, or anyone of these little languages-du-jour. Developers are still struggling with their design. Guido is still learning about programming language features, such as closures, or inheritance, or metaclasses, LOL!. That means that Real Soon Now, they'll get around to what the good and smart people decided on about language design long ago. Hey, maybe they'll even read their papers ;-). OTOH, I can take C code from 1996, or I've ran Common Lisp code from 1998 without a problem. Same goes for Smalltalk. Vendors are still around, but there's open source if you wish to use it, good stuff, too.

Of course, you're talking software for John Doe, not some weird C code for wavelets or genetic programming.

GUI stuff is completely horrible in that way in Linux. If you want stuff to keep working you better stick with some very old toolkit for X Windows, like Athena, Motif, etc.

See here, for example: this libXaw(Athena) repository goes back to 2003 and patches are incoming in 2012, still.

You appear to be unaware of the details of protected content vis-a-vis Flash; I shall try to lay it out for you:

Protected content sold by Amazon, and also by Google Play, is protected via Adobe Flash Access.

Adobe Flash Access relies on a unique machine identifier to implement the key escrow in order to lock your content to the download machine so that it can not be re-uploaded in a digital form without having to use the analog hole in order to degrade the content.

The way it obtains this unique machine identifier is by synthesis of a lot of different machine information via libhal (a library with an associated daemon, intended as a Hardware Abstration Layer). As you can easily see here: http://www.freedesktop.org/wiki/Software/hal libhal has been deprecated since May of 2008, yet Adobe chose to require it anyway.

This four-year-out-of-date library is not installed by default on Ubuntu systems, and doesn't give the answers Adobe Flash Access wants in order to be able to successfully run on 64 bit systems. Even when hacked up, there are typically symptoms during video playback, such as the video playing fine up to the first commercial break, and then after the commercial, the audio continues working, but the video is nothing but a black screen.

These problems do not occur on a 32 bit Linux, as they do on a 64 bit Linux running 32 bit software. The need to support multiple Linux platforms, combines with the Jan 31st 2012 rollout of the new version of Adobe Flash Access protection on content by Amazon no doubt influenced the decision, announced Feb 20 2012, to drop Adobe Flash Support for Linux outside official Google Chrome builds: http://blogs.adobe.com/flashplayer/2012/02/adobe-and-google-partnering-for-flash-player-on-linux.html

Now that you have the context, do my earlier comments on 64bit vs. 32 bit make more sense?

From the FAQ:

How can I replace Wayland's Window Manager?

The Wayland architecture integrates the display server, window manager and compositor into one process. You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.

This may sound like a lot of work, but one of the key points about Wayland is that the boilerplate code to a Wayland compositor is comparable or less than the X boilerplate involved in becoming an X window manager and compositor. Bringing up EGL and GLES2 on the Linux KMS framebuffer and reading input from evdev can be done in less than a thousand lines of code. The Wayland server side library provides the protocol implementation and makes it easy to put the pieces together.

http://wayland.freedesktop.org/faq.html#heading_toc_j_11

I'm not saying that's the issue both both applications you mentioned use GTK so maybe that's one reason why it works but may not work in other cases.

And GNU/Linux isn't all GTK.

"All GTK" may be sufficient to make cut/copy/paste work between applications, but it's not necessary. I just did a quick Wireshark build (to get a GTK+ application) on my Fedora-16-with-KDE-4 (virtual) machine, and was able to cut with ^X or copy with ^C from the Wireshark filter text box and paste with ^V into the app launcher Search text box and KWord, and cut or copy from either of the latter and paste it into the Wireshark filter text box.

So it works at least between those versions of GTK+ 2.x and Qt 4.x. There's no guarantee it will work between toolkits A and B for arbitrary values of A and B, but if a toolkit implements cut/copy/paste as per the freedesktop.org clipboard consensus - as that page notes, Qt and GTK+ both do - cut/copy/paste should work between applications using that toolkit and other applications using that toolkit and other toolkits that implement cut/copy/paste as per that consensus. (According to the page on that consensus, Qt 2 and GNU Emacs 20 didn't implement cut/copy/paste as per that consensus, but Qt 3 and GNU Emacs 21 would.)

None of that, BTW, gets rid of paste-current-selection, i.e. the action usually bound to the middle mouse button on many UN*X GUIs.

(Note, BTW, that the X11 term "selection" doesn't necessarily mean "what you've selected in the application"; that's the PRIMARY selection, but there's also the CLIPBOARD selection, which is whatever you've cut or copied, and the SECONDARY selection, which is probably unused unless you're using an XView application.)

I'm not saying that's the issue both both applications you mentioned use GTK so maybe that's one reason why it works but may not work in other cases.

And GNU/Linux isn't all GTK.

"All GTK" may be sufficient to make cut/copy/paste work between applications, but it's not necessary. I just did a quick Wireshark build (to get a GTK+ application) on my Fedora-16-with-KDE-4 (virtual) machine, and was able to cut with ^X or copy with ^C from the Wireshark filter text box and paste with ^V into the app launcher Search text box and KWord, and cut or copy from either of the latter and paste it into the Wireshark filter text box.

So it works at least between those versions of GTK+ 2.x and Qt 4.x. There's no guarantee it will work between toolkits A and B for arbitrary values of A and B, but if a toolkit implements cut/copy/paste as per the freedesktop.org clipboard consensus - as that page notes, Qt and GTK+ both do - cut/copy/paste should work between applications using that toolkit and other applications using that toolkit and other toolkits that implement cut/copy/paste as per that consensus. (According to the page on that consensus, Qt 2 and GNU Emacs 20 didn't implement cut/copy/paste as per that consensus, but Qt 3 and GNU Emacs 21 would.)

None of that, BTW, gets rid of paste-current-selection, i.e. the action usually bound to the middle mouse button on many UN*X GUIs.

(Note, BTW, that the X11 term "selection" doesn't necessarily mean "what you've selected in the application"; that's the PRIMARY selection, but there's also the CLIPBOARD selection, which is whatever you've cut or copied, and the SECONDARY selection, which is probably unused unless you're using an XView application.)

I have been following the LibreOffice development, and the prerequisite for fixing this (replacing all uses of the obsolete String classes) is being done all the time (it is a huge code base, so it will take some time until it is all replaced). I see work on that almost every day. So LibreOffice will probably get this bug fixed earlier than OpenOffice. If you want to follow, it is this bug: https://bugs.freedesktop.org/show_bug.cgi?id=30668 and this bug: https://bugs.freedesktop.org/show_bug.cgi?id=38838.

I have been following the LibreOffice development, and the prerequisite for fixing this (replacing all uses of the obsolete String classes) is being done all the time (it is a huge code base, so it will take some time until it is all replaced). I see work on that almost every day. So LibreOffice will probably get this bug fixed earlier than OpenOffice. If you want to follow, it is this bug: https://bugs.freedesktop.org/show_bug.cgi?id=30668 and this bug: https://bugs.freedesktop.org/show_bug.cgi?id=38838.

Not true. LibreOffice has some serious bugs when working with doc, docx, & odt that are extremely problematic and have not been fixed for months on end. Exhibit A is the "read-error" bug when files have images.
https://bugs.freedesktop.org/show_bug.cgi?id=52226
This renders a word processor basically unusable. The solutions are either disabling autosave or not using images. I've been using OpenOffice for over a decade & I am this close to going back to MS Office. It used to be good. Post-fork, it's a piece of junk, & the community refuses to acknowledge this. Sticking our heads in the sand will not help.

Apparently it has better support for docx. https://bugs.freedesktop.org/show_bug.cgi?id=55820

These two files, window.c and image.c, are an entire simple GUI toolkit and an example program using that toolkit, for use with a Wayland compositor.

This directory is an entire compositing window manager that speaks the Wayland protocol. This is already impressively small, but keep in mind that most of the complexity here is in actually drawing to the screen and getting input events from hardware, something that Wayland has nothing to do with, and it's *still* small.

Wayland is simple because it is small, and it's small because it only concerns itself with communication between compositors and applications. There are already good APIs for drawing (cairo, opengl), so Wayland lets application developers use those, or whatever else crops up in the future.

These two files, window.c and image.c, are an entire simple GUI toolkit and an example program using that toolkit, for use with a Wayland compositor.

This directory is an entire compositing window manager that speaks the Wayland protocol. This is already impressively small, but keep in mind that most of the complexity here is in actually drawing to the screen and getting input events from hardware, something that Wayland has nothing to do with, and it's *still* small.

Wayland is simple because it is small, and it's small because it only concerns itself with communication between compositors and applications. There are already good APIs for drawing (cairo, opengl), so Wayland lets application developers use those, or whatever else crops up in the future.