How Important Is The Wayland Display Server?

[movieman]

Do you know that both GTK and QT have bindings to DirectFB! So, simply speaking, any GTK and QT app can in theory be used in DirectFB.

Good for you.

Now, what makes you think we're talking about DirectFB rather than some undefined new 'X alternative'?

[energyman]

You seem to think i'm a DirectFB dev. not true. i just like the project and tried a few things with it.

as for rewriting X. then perhaps the X11 protocol is to bloated? i don't know, i didn't read it. What i do know is that X is heavy as hell and a less heavy version should be made or a alternative should be made/used. Like for example remove out the things that are nice for servers but not used much on desktops like remote x stuff. It's nice that it's possible but if you only remove that single part you will:
- get a much faster X
- way more memory friendly X
and perhaps more devs that are willing to maintain it.

O and removing out the default CTRL + ALT + BCKSP is really something to scare of new devs to help.

I'm not going to help X simply because i don't have that much c knowledge to be able to help.


It's not obvious if you quote me or someone else but if you mean me with DirectFB then no. DirectFB is still a layer between the application and the kernel framebuffer device. A normal user should not even use directfb to develop on. they should use a toolkit that works on top of it (GTK and QT do.)

And for the drivers. If galium gets accepted by all card manufacturers then you don't need to go back to "1985".. (2000 would be a better year)

and kernel framebuffer is as much as unaccelerated. Diretfb is crap. That simple. You think X is slow? Try to do the stuff KDE or Gnome do on a naked framebuffer (or directfb) - not possible. Because extremely slow.

[elanthis]

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.

[movieman]

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.

[elanthis]

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.

[energyman]

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.

[airlied]

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.

[nanonyme]

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.

[energyman]

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

[nanonyme]

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.