Announcement

Collapse
No announcement yet.

How Important Is The Wayland Display Server?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic How Important Is The Wayland Display Server?

    How Important Is The Wayland Display Server?

    Phoronix: How Important Is The Wayland Display Server?

    Last November we detailed the Wayland Display Server, which came about as a lightweight alternative to the X.Org Server and leveraged the latest Linux graphics technologies (primarily kernel mode-setting), and is designed elegantly with the rendering and compositing all being done by Wayland. Quite a bit of work was going on with this project early on to the point of running two X Servers within Wayland and then talk of a Clutter back-end for Wayland, but over the summer there has not been much to report...

    http://www.phoronix.com/vr.php?view=NzUzMQ

  • Kamilion
    replied
    Originally posted by nanonyme View Post
    Originally posted by energyman View Post
    oh really? no, you can't. Because a framebuffer is nothing but a memory array reserved for screen data. Nothing else.
    Which can run OpenGL applications with Gallium3D.
    Isn't that the other way around? I'm not even sure a raw kernel framebuffer supports pageflips without jumping through library hoops like directfb.

    What about an ARM chip with nothing more than a raw segment of memory and a blitter?

    The framebuffer is the final landing point before hitting the CRTC/DAC.

    The other important question to ask here is, which framebuffer?
    In certain circumstances such as a machine I have with an onboard IPMI2.0 compliant baseboard management controller integrating a matrox g200 core & IPKVM, as well as a PCI express graphics card I tossed in to support my 90 degree LCD setup.

    The kernel seems to prefer to use the matrox, but X has always popped up on the Radeon 2600xt card.

    I realize I'm sort of splitting hairs here, but the semantics can be way different.

    Edit: Gah, forgot about G3d's softpipe. Sorry 'bout that.
    Last edited by Kamilion; 10-14-2009, 09:54 PM.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by energyman View Post
    oh really? no, you can't. Because a framebuffer is nothing but a memory array reserved for screen data. Nothing else.
    Which can run OpenGL applications with Gallium3D.

    Leave a comment:


  • energyman
    replied
    oh really? no, you can't. Because a framebuffer is nothing but a memory array reserved for screen data. Nothing else.

    Leave a comment:


  • nanonyme
    replied
    Could always have a Linux set-top box running only framebuffer with VDPAU over Gallium3D using EGL. Uses a lot less CPU and RAM which means you get along with a less powerful set-top box.

    Leave a comment:


  • airlied
    replied
    Originally posted by elanthis View Post
    Perhaps you'd like to read the thread and realize I've been participating for quite a while and realize that fact? The point is, DirectFB is proof that toolkits can and do implement backends besides X, and that claiming that "no application will support something besides X" is obviously bullcrap.



    There was no possibility for anything else before, because all of the hardware drivers were built into X itself. Nothing in the world stops DirectFB from using KMS/DRI2/Gallium like Wayland, X, and whatever else, so the technical limitations of what DirectFB could do are totally irrelevant at this point.

    You might as well argue that X can never ever support direct rendering because years ago it wasn't able to. Or that X can't do indirect accelerated rendering because years ago it wasn't able to. Or that X can't support composited desktops because years ago it wasn't able to. Etc.

    You can't just talk about unnamed hypothetical projects and then ignore any counter-arguments based on real projects. If you want to talk purely hypotheticals, go find a corner and do your intellectual masturbation there; nobody wants to watch you do it on the forums. Here in Real World Land(tm) actual projects are far more interesting than unnamable alternatives.
    DirectFB having acceleration is a hypothetical project, just as
    X have direct rendering 10 years ago was hypothetical, arguing about X having direct rendering now would be pointless since it has it, arguing
    that DirectFB is ever going to gain useful acceleration isn't since I don't think its in any way designed to allow useful acceleration.

    More likely we'll get accelerated direct render cairo on gallium clients with wayland before directfb is useful.

    Dave.

    Leave a comment:


  • energyman
    replied
    just because a toolkit supports something does not mean that the apps using the toolkit support the underlying graphics engine too. Or do you use gnome on windows? KDE on windows has its problems too. KDE/gnome on DirectFB?

    Nope - why? Because there is more to X than the toolkits provide.

    Also, Directfb and other framebuffer or 'we are not X' solutions (remember Berlin/Fiasco? Ywindows) have a couple of problems:

    NO HARDWARE ACCELERATION.

    And that means full stop and failure.

    Leave a comment:


  • elanthis
    replied
    Originally posted by movieman View Post
    Perhaps you might like to try reading the thread rather than trying to turn this into an 'X vs DirectFB' flame-war?
    Perhaps you'd like to read the thread and realize I've been participating for quite a while and realize that fact? The point is, DirectFB is proof that toolkits can and do implement backends besides X, and that claiming that "no application will support something besides X" is obviously bullcrap.

    and unless DirectFB has changed a lot since I last used it, I believe it only gives you access to a totally unaccelerated frame-buffer.
    There was no possibility for anything else before, because all of the hardware drivers were built into X itself. Nothing in the world stops DirectFB from using KMS/DRI2/Gallium like Wayland, X, and whatever else, so the technical limitations of what DirectFB could do are totally irrelevant at this point.

    You might as well argue that X can never ever support direct rendering because years ago it wasn't able to. Or that X can't do indirect accelerated rendering because years ago it wasn't able to. Or that X can't support composited desktops because years ago it wasn't able to. Etc.

    You can't just talk about unnamed hypothetical projects and then ignore any counter-arguments based on real projects. If you want to talk purely hypotheticals, go find a corner and do your intellectual masturbation there; nobody wants to watch you do it on the forums. Here in Real World Land(tm) actual projects are far more interesting than unnamable alternatives.

    Leave a comment:


  • movieman
    replied
    Originally posted by elanthis View Post
    What makes you think DirectDB does not qualify as the potential X alternative? Don't be an ass.
    Perhaps you might like to try reading the thread rather than trying to turn this into an 'X vs DirectFB' flame-war?

    The quote I was responding to was talking about some unspecified 'X alternative', not DirectFB... and unless DirectFB has changed a lot since I last used it, I believe it only gives you access to a totally unaccelerated frame-buffer.

    Leave a comment:


  • elanthis
    replied
    Originally posted by movieman View Post
    Good for you.

    Now, what makes you think we're talking about DirectFB rather than some undefined new 'X alternative'?
    What makes you think DirectDB does not qualify as the potential X alternative? Don't be an ass.

    Leave a comment:

Working...
X