I sure hope Wayland supports warping the mouse pointer, as doing so is necessary for automated GUI testing and scripting. Even if it's through a simulated event source that delivers absolute pointer events to the server, it's got to be there.
Hm, seems like a few people are not grasping where Wayland fits in.
You can consider Wayland to be more like a new 'DirectFB' video card driver for X.org, that sits on top of EGL contexts, and passing around GEM objects instead of raw framebuffer video memory blitting around bitmaps.
It *also* manages keyboard and 'mouse' input from evdev in the modern fashion of a relative-tablet system that will be very touchpad/multitouch friendly.
Since evdev's keyboard support has gotten so much better than we had Xfree86 sitting on top of 10 years ago, we will also lack most of the retardedness of X's keyboard mapping madness, and support true multimedia keys with unicode instead of raw keyboard matrix scancodes. (I believe the underlying hardware support for this already exists, but XKB doesn't currently play well with it for me)
What we will need, is an EGL stack compatible with a given video chipset. When Gallium support works; we should be able to use the softpipe driver over a framebuffer on older hardware lacking DRI or possibly even lacking major 3D functionality entirely. (Trident Cyberblade XP, anyone? Or the always annoying Radeon IGP320M, who was a really a Radeon 7500 lacking it's texture and lighting unit under the hood )
Intel support's already there, reaching back to the i8xx era. Seems to work fine on my netbook at a reasonable clip; don't own any intel hw other than that.
Radeon support's getting there, but pageflip's still a patch-in and evergreen support's in early infantcy. Doesn't seem to like my 780Gs yet either.
nVidia has basically said they're not going to be working on an EGL frontend for their drivers at the moment. This will likely change once the Tegra team is getting hounded for EGL support.
Nouveau seems poised to snap up and cover that driver sinkhole; which is good, especially considering the state of the PS3's new linux reimplementation, AsbestOS, which does have RSX (NV47/"7800") access.
I have high hopes we'll see the first actually usable linux desktop on the PS3 with 11.04's release.
I seriously doubt remotely accessing an Xserver running on top of wayland will be all that difficult. Wayland is an output device; a way for multiple clients to talk to the monitor, keyboard and mouse. That's it. Your apps can still be X based; And for many of them, they should *stay* X based, especially 2D apps. It's far easier to trim down the X protocol ala NoMachine's NX 3.4 compression library (NX runs it's own proxy Xserver which compresses everything and removes the local latency that *kills* RawX-over-SSH application performance by effectively removing the entire round-trip time for an event response back to an app.) and run everything else that *requires* a local 3D context with Wayland.
If you TRULY want 3D over network; I would suggest someone start work on some sort of EGL->H.264-encoder stack with (Optional) GPU Acceleration and get direct support for such a monstrosity as a wayland backend 'device'. Anything worth using as a client these days has some form of MPEG4-derived decode in hardware; why not make use of it? (In fact, I think I'll go propose that to the mailing list myself after I post this. Maybe it will spark something.)
*EVERYTHING ELSE* other than *BASIC WINDOW MANAGEMENT* will be handled by the compositor. Yes, that means you can still alt-grab a client window and move it around, even if the client is frozen or otherwise occupied. The window will move, but the *contents* will not change until the app redraws it's contents.
Wayland can recover window damage as well; since each app renders to an offscreen buffer, moving one window in front of another will simply redraw the windows's last contents from the offscreen buffer and not leave pixel garbage trails all over the place until the app underneath redraws. I *HATE* that in Windows, and it's almost as annoying in X.org when firefox is chugging on rendering a big page with a lot of tabs open.
Yes, that means you can have non-rectangular windows. The flower demonstration is actually a moving transparent window in the shape of a flower or a 'guitar pick'.
By the way... That compositor? It will be one we know and love/hate, Compiz.
Which is already pretty much a window manager on it's own. With emerald, it's possible to have compiz decorate windows as well. And it's trivial to embed a simple rootless X server inside a decorated window; and poof, we're right back to where we are right now. Only without 90% of the cruft in the way.
Perhaps this will clear it up further if my explanation was lacking:
On Sat, Nov 13, 2010 at 1:23 AM, Chris Wilson <email@example.com> wrote:
> Take a step back. It's time to review the system architecture once more.
> Wayland is a input/output [de-]multiplexer. It does no rendering on the
> behalf of the client, only compositing the many clients onto the scanouts.
> The clients must prepare for themselves the shared memory buffers that
> they pass to Wayland for compositing. (Under GEM those shared memory
> buffers are merely GEM objects and therefore can also be used with
> hardware accelerated rendering.)
> On Sat, 13 Nov 2010 12:20:29 +0800, Justin Lee <firstname.lastname@example.org> wrote:
> > Yep, I guess cairo-gl used by Wayland should get similar performance
> > boosts as cairo-drm if it's also direct-rendered (by mesa-dri?). It
> > seems that mixing 2D drawings with 3D drawings makes problems,
> > therefore we want to draw everything by OpenGL even if for 2D
> > graphics. Maybe that's the purpose of cairo-gl i.e. being a wrapper
> > library which use OpenGL to draw 2D graphics.
> The difference between theory and practice...
> To put it bluntly, cairo-gl on my fastest boxes [g45, ironlake] is still
> slower than cairo-xlib on one of my slowest boxes [q35, for pnv it's
> close but the Atom is just no match for the CPUs in the desktop boxes].
> This is all due to driver quality and the fact that RENDER is much easier
> to accelerate than a full GL implementation. This also implies that there
> is less opportunity for acceleration of RENDER because so much information
> is thrown away upfront. (Having said that cairo-xlib on g45/ilk is
> atrocious and much slower than cairo-gl on the same platforms, again due
> to driver quality.)
> The promise of GL is that we only need to write one good driver per
> The promise of Wayland is that every pixel is perfect. It takes the
> architecture that X has organically developed over the last 25 years and
> aims to implement that in a small footprint, low latency system.
> One of the killer ideas of Wayland is that it is self-hosting.
> Chris Wilson, Intel Open Source Technology Centre
@Kamilion: great post!
Was solved 4 years ago on Windows and a little more than that on Linux. Compiz/Aero/Kwin/[you name it] ensure a garbage-free desktop by design. You'll only see garbage if you disable your compositor (...why?)Wayland can recover window damage as well; since each app renders to an offscreen buffer, moving one window in front of another will simply redraw the windows's last contents from the offscreen buffer and not leave pixel garbage trails all over the place until the app underneath redraws. I *HATE* that in Windows, and it's almost as annoying in X.org when firefox is chugging on rendering a big page with a lot of tabs open.
compositor garbage my starcraft 1 battlenet.. it says i use wrong version while use compositor...
I just span a lot of browser, NX, putty, xming, and winscp windows. Nothing too special there. It's more of an xterminal that can play games... *chuckles*
My work box is similar to Home; a quad 3Ghz AMD Athlon II 640 AM3 with 4 gigs and onboard 880G. That one runs stock Ubuntu Maverick, with Desktop Effects set to Extra for the pretty wobbly windows. Same thing there; stack up over a hundred tabs and try to move the download window around under load from a couple VMs running in virtualbox and I promise you'll starve the CPU bus just enough to leave a couple of frames of garbage behind as compiz desperately tries to get enough of a scheduler priority boost to composite and scanout an update.
Switching to Chromium 9.0 on both platforms has made the issues almost disappear with the new GPU render support though, since that can offload a huge chunk of work off the CPU. KSM (Kernel Samepage Merging) REALLY helps the multiprocess chrome architecture. Works *really* well on the work box, since it's lacking cache; plus onboard-only shares main memory and has it's own dedicated DMA lane. Yummy.
@Kamillion: Poorly coded applications can always display garbage. It is not the OS/compositor that is at fault here.
For instance, Pidgin/win32 displays garbage when resized. I do not blame Windows for that.
For what it's worth, I'm using a 2.6GHz Core 2 / 8GB RAM / Ati 4850 (or Nvidia 9500GT) and keep a couple of VMs open at all times (+ several instances of MonoDevelop / Visual Studio, Opera, messengers, terminals, a mail client and a media player) and I've never seen the kind of garbage you describe. I may get dropped frames and mouse lag on Compiz (which is probably a scheduling issue) but I've never seen it render garbage.