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. Preview: AMD's FX-9590 Eight-Core At Up To 5.0GHz On Linux
  2. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  3. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  4. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
Latest Linux Articles
  1. How Intel Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers
  2. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
  3. Testing For The Latest Linux Kernel Power Regression
  4. The Most Energy Efficient Radeon GPU For AMD Linux Gaming
Latest Linux News
  1. Nouveau X.Org Driver Released With DRI3+Present, Maxwell, GLAMOR
  2. Microsoft & AMD Release C++ AMP Compiler With Linux Support
  3. AMD, Wine & Valve Dominated August For Linux Users
  4. Linux 3.17-rc3 Kernel Released Back On Schedule
  5. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  6. Mesa 10.3 RC2 Arrives Via Its New Release Manager
  7. Ubuntu 14.10's Lack Of X.Org Server 1.16 Gets Blamed On AMD
  8. MSI Motherboard BIOS Updating Remains A Pain For Linux Users
  9. See How Your Linux System Performs Against The Latest Intel/AMD CPUs
  10. AMD Steppe Eagle Flys To Coreboot
Latest Forum Discussions
  1. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  2. The dangers of Linux kernel development
  3. Updated and Optimized Ubuntu Free Graphics Drivers
  4. AMD Releases UVD Video Decode Support For R600 GPUs
  5. SSD seems slow
  6. Is laptop with Intel CPU and AMD dGPU worth buying considering especially AMD Enduro?
  7. Radeon HD5670 and Ubuntu 14.04
  8. Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs