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

The Wayland Situation: Facts About X vs. Wayland

Eric Griffith

Published on 7 June 2013
Written by Eric Griffith
Page 3 of 4 - 282 Comments

Some Misconceptions about X and Wayland

I) “X is The UNIX Way.” The Unix Way says to do one thing and do it well-- X handled printing, it handled buffer management, it was its own toolkit, it handled fonts, it was a binary interpreter, along with loads of other things. What ONE THING was X doing and what ONE THING was X doing well?

II) “X is Network Transparent.” Wrong. Its not. Core X and DRI-1 were network transparent. No one uses either one. Shared-Memory, DRI-2 and DRI-3000 are NOT network transparent, they do NOT work over the network. Modern day X comes down to synchronous, poorly done VNC. If it was poorly done, async, VNC then maybe we could make it work. But its not. Xlib is synchronous (and the movement to XCB is a slow one) which makes networking a NIGHTMARE.

III) “The Wayland developers are only re-implementing X11 because they don't understand it.” Wrong. Most of the Wayland developers ARE former X11 developers. They know how terrible it is. They know where its failings are. They want to do better than X11.

IV) “Wayland requires 3D.” Wrong. It requires compositing, but that's not necessarily 3D. Nothing in Wayland requires 3D, there is even a Pixmen backend for software rendering.

V) “Wayland can't do remoting.” Wrong. Wayland should be BETTER than X at remoting, partially do its asynchronous-by-design nature. Wayland remoting will probably look a like a higher-performance version of VNC, a prototype already exists. And this is without us even giving it serious thought about how to make it better. We could probably do better if we tried.

VI) “Wayland breaks everyone's desktop.” Also wrong. Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with. There is one known snag and thats with window transformations because app thinks its in the top right corner of the screen (yay global coordinates) because that client's X server is locked to the size of that client's window.

Latest Linux Hardware Reviews
  1. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
  2. Sumo's Omni Gets Reloaded
  3. AMD A10-7800 & A6-7400K APUs Run Great On Linux
  4. Radeon Gallium3D Is Running Increasingly Well Against AMD's Catalyst Driver
Latest Linux Articles
  1. Intel's Latest Linux Graphics Code Competes Against OS X 10.9
  2. Intel Sandy Bridge Gets A Surprise Boost From Linux 3.17
  3. Open-Source Radeon Graphics Have Some Improvements On Linux 3.17
  4. CPUFreq Scaling Tests With AMD's Kaveri On Linux 3.16
Latest Linux News
  1. Steam Now Supports VA-API For In-Home Game Streaming
  2. GNOME 3.14 Beta Released
  3. Mesa 10.3 Branched & RC1 Released, Mesa 10.4 On Master
  4. Intel Sandy Bridge Gains On Linux 3.17 Extend Beyond Graphics
  5. LinuxCon: What's Going On With Fedora.Next
  6. Canonical Joined The Khronos Group To Help Mir/Wayland Drivers
  7. EFL 1.11 Is A Big Milestone For Enlightenment Users
  8. DirectFB Updates GTK3 Support, Working Towards DirectFB 1.8
  9. Userptr Support Set For AMD Radeon GPUs In Linux 3.18
  10. NVIDIA Releases CUDA 6.5 As A Huge Update
Latest Forum Discussions
  1. Systemd 216 Piles On More Features, Aims For New User-Space VT
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs
  4. OSS radeon driver for A10-7850K (Kaveri)
  5. AMD Offers Mantle For OpenGL-Next, Pushes Mantle To Workstations
  6. ATI CrossFire Does Not Support On This Platform When Enabling (Ubuntu Lucid)
  7. Dead Island for Linux (?)
  8. The dangers of Linux kernel development