Slashdot Mirror


KDE Plans To Support Wayland In 2012

An anonymous reader writes "During the 2011 Desktop Summit plans were brought up by a KDE developer to support KDE on the Wayland Display Server, which is dubbed the successor to X11. The KDE Wayland support is expected to come in three phases, with the first two phases expected to be completed next year during the KDE SC 4.8 and 4.9 development cycles. Farewell X?"

4 of 413 comments (clear)

  1. Misleading! The point is to keep X compatibility. by dfaure · · Score: 5, Informative

    Typical slashdot: the article distorts the truth in order to get reactions.

    It was pretty clear during that presentation that the goal was to make it possible to still run X applications -- using a rootless X server -- and that this would also allow X-over-the-network use cases.
    X11 is not going away, the idea is to use Wayland -and- X.

  2. Re:What's wrong with X11? by Chemisor · · Score: 5, Informative

    The main problem with X11 is the complete lack of frame boundaries. Applications just send a stream of drawing commands with no indication of where one frame stops and the next one begins. Consequently the server has to keep drawing stuff as it comes in, resulting in flicker. Flicker is the first thing a novice X11 programmer complains about and online forums have been filled with pleas for help with this problem for decades. The traditional solution was to render to an offscreen image and send it to the server. This requires a lot of bandwidth, so the next step is to use MIT-SHM extension to avoid this traffic. Then came XComposite extension which automatically handles double buffering. XComposite has the luxury of being able to sync to vretrace, but not knowing where the frame boundaries are it can't do it lest it cut the instruction stream in the wrong place and draw half-a-screen. In the meantime, after two decades of deliberation, the XSync extension still does not implement the ability to detect vretrace.

    Wayland solves the above by moving rendering into the client, as in the render-to-image solution above, and then copying the image to the server. This can be done though shared memory as well. The rendered image on the client represents the complete frame.

  3. Re:Stupid by ThePhilips · · Score: 5, Informative

    So somebody that has not even heard of the root window is trying to tell us all what X can or can't do and getting it wrong?

    I'm pretty sure Keith Packard, as a lead of X.org, has heard of the root window.

    Here is the video I was referring to: X and the future of Linux Graphics.

    --
    All hope abandon ye who enter here.
  4. Re:Stupid by Trepidity · · Score: 4, Informative

    Hmm, interesting; thanks for the link. I hadn't realized that the X.org people are moving in the same direction. Doing a bit of googling, this LWN article summarizes a Packard talk from last year that seems to be hitting some similar points.