1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Two Features Wayland Will Have That X Doesn't

Wayland

Published on 10 November 2010 11:29 AM EST
Written by Michael Larabel in Wayland
59 Comments

While the discussion surrounding the Wayland Display Server and Canonical's plans to deploy Ubuntu atop Wayland continue to be ongoing within our forums (here, here, and here) and elsewhere, some new technical capabilities and plans for Wayland have been discussed. Here's two features that Wayland is set to have that is not currently supported by the X.Org Server.

First off, while the state of Linux laptop GPU switching is currently poor for those newer notebooks with dual GPUs, Wayland will have the capability of switching between GPUs for rendering. This is a feature currently lacking by the current xorg-server for notebooks, desktops, and all devices. When it comes to Wayland and GPU hot-swapping, Jerome Glisse mentioned:
Outcome of discussion between Dave, Kristian, Jesse and me while riding a bus is that we should add a way for wayland to ask its client to redraw their surface using a another EGL driver and that wayland server should be able to handle client reporting failure doing so. Maybe i did get this wrong, feel free to correct me :)

I think to cover all use case Dave presented we should have somethings like this:

- wayland provide a list of EGL driver it can texture from (optimus case where we can migrate texture from nvidia to intel)
- wayland can ask to it's client to switch GL driver and report if they can switch or not (i think this should happen in 2 step first ask and gather answer from all client if one client says it can't then forbid the switch, otherwise ask to all client to redraw with new driver)

All this wouldn't need restart from wayland.

So Wayland ultimately will be able to switch between GPUs and drivers without requiring a restart of the display server.

The other feature brought up is concerning full-screen applications on Wayland and how that will be handled in an attempt to make this display server better for handling games than an X.Org Server. As said by Kristian Høgsberg:
Nope, you're spot on and I agree. Carsten Haitzler recently posted a good writeup on the good and bad things games do under X:

http://lists.x.org/archives/xorg/2010-September/051152.html

and at the end of the email he's proposing something similar to what you describe. I even think we shouldn't expose the full modesetting API to regular applications, just enough that they know the screen sizes and layout. Either the compositor can run a special client with access to the modesetting interface or changing the resolution and/or screen layout could just be part of the compositor.

Either way, a native resolution fullscreen mode is definitely planned. Both scaling (with or without aspect ratio/black bars) and native modes (we can page flip directly to the applications buffer) make sense, but I think that will be policy/configuration options in the compositor. What will be in the protocol will be a way to request to be fullscreen, which the compositor will honor when the application has focus, but it will always be possible to alt-tab away (or press the "home button" or similar). So the compositor is in control, it will change the resolution, scale and draw black bars, or maybe even just center the application window and fade out the rest of the desktop around it.

This also ties in with capturing the mouse pointer and relative events (which Carsten also talks about in his mail). Typically games also want to make sure the pointer stays inside the window and they want relative events. It's no good if you're trying to turn around in quake and the pointer leaves the window or hits the screen edge. X applications solve this by grabbing the mouse, confining it to the window and continuously warping the cursor into the center to simulate relative events. This is obviously a hack, and wayland isn't going to support open-ended pointer or keyboard grabs, nor warping the pointer. Instead, we provide relative events when the device generates them, and in fullscreen mode, all the events go to the fullscreen application, so no need to confine the pointer. Possibly, an application can request "application pointer", where the compositor hides the pointer when the fullscreen application receives focus, doesn't update its location and only sends relative events. This is a pointer mode that may be useful to allow when an application has a button grab as well (that is, grabbing the pointer for the duration of a button click).

Anyway, this is all kinda half-baked, but it is the general direction I see this going.

Kristian

This is all good news for gamers when hopefully running Wayland within a few years time and also for other applications like Wine.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. MSI X99S SLI PLUS On Linux
  2. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  3. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  4. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
Latest Linux Articles
  1. RunAbove: A POWER8 Compute Cloud With Offerings Up To 176 Threads
  2. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  3. Ubuntu 14.10 XMir System Compositor Benchmarks
  4. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
Latest Linux News
  1. openSUSE Factory & Tumbleweed Are Merging
  2. More Fedora Delays: Fedora 21 Beta Slips
  3. Mono Brings C# To The Unreal Engine 4
  4. Coreboot Now Has Support For Intel Broadwell Hardware
  5. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  6. GTK+ Lands Experimental Backend For Mir Display Server
  7. Ubuntu 14.10 Officially Released
  8. Mesa 10.4 Might Re-Enable HyperZ For R600g/RadeonSI
  9. Intel GVT-g GPU Virtualization Moves Closer
  10. GTK+ 3.16 To Bring Several New Features
Latest Forum Discussions
  1. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Linux hacker compares Solaris kernel code:
  4. HOPE: The Ease Of Python With The Speed Of C++
  5. Advertisements On Phoronix
  6. Users/Developers Threatening Fork Of Debian GNU/Linux
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed