Graphic Subsystem

[Jeko]

While I'm writing kernel code, I'm thinking about which graphic subsystem would be the best choice for my OS.

There are X.Org, XFast, DirectFB

X.Org is a heavy implementation of the X Protocol, so I think isn't good for my OS (I want something fast and with small memory usage)

So I must choose between XFast (a small implementation of the X Protocol with a small Window Manager) and DirectFB.

Which do you think is the best between XFast and DirectFB?
Maybe DirectFB is better because it supports hardware acceleration, it needs only few libraries...
But in my OS, I want a X server, and I don't know if the DirectFB's X Server (XDirectFB) is a good implementation of it...

What do you think?

[Combuster]

X is complicated...
DirectFB looks like DirectX7, which is quite complicated too...

So if what you want is an X server, then you're probably better off using an X server that goes straight to hardware, instead of having to translate one set (X) to another (DirectFB). Since X.org comes with its own drivers, that package has you all set for doing whatever you need.
Oh and, X.org has support for hardware accelleration

I can't really comment on XFast though.

[Jeko]

X is complicated...
DirectFB looks like DirectX7, which is quite complicated too...

So if what you want is an X server, then you're probably better off using an X server that goes straight to hardware, instead of having to translate one set (X) to another (DirectFB). Since X.org comes with its own drivers, that package has you all set for doing whatever you need.
Oh and, X.org has support for hardware accelleration

I can't really comment on XFast though.

But X.org is really heavy! And I think it's difficult to port. Isn't it?

[Combuster]

X.org is "heavy" because people tend to run KDE on top of it

[Jeko]

X.org is "heavy" because people tend to run KDE on top of it

mmmmh. I think it's "heavy" compared to XFast for example... I don't think X.Org is used also in embedded systems as DirectFB.
I want something that supports hardware acceleration, but that is usable also in embedded systems.
XFast is a light X Server with a Window Manager, it can support hardware acceleration just as X.Org (with DRI/DRM and the X Protocol Extension GLX)
For DirectFB, I don't know very well how it works and if it's really useable (if there are hardware accelerated drivers for it and if it has a stable security system)

[quanganht]

So, what do you think is the best ?

[dr_evil]

Why do you want to use one of those subsystems? Why not create a simple one that fits the bill?

I don't see what the advantages of X would be...

[Owen]

If your gonna use X, use X.Org. XFast and DirectFB are designed for systems where the only graphics hardware takes pixels and shoves them to an LCD.

But, really, do you want X11? Would your own graphics server not be a better option?

[Jeko]

If your gonna use X, use X.Org. XFast and DirectFB are designed for systems where the only graphics hardware takes pixels and shoves them to an LCD.

But, really, do you want X11? Would your own graphics server not be a better option?

No, because for an existing graphics server (X or DirectFB) there are yet the drivers for video cards! No graphic vendor will be interested to develop drivers for my own graphic subsystem.

However DirectFB has also 3D accelerated drivers, so it isn't designed only for hardware that takes pixels and shoves them to an LCD...

I don't know which subsystem implement, because:
X.Org is highly supported from graphic vendors, but it is, I think, difficult to port
XFast is simple to port, but hasn't graphic drivers, it directly draw on the screen, so with XFast, I must implement a method to handle the GL X extension.
DirectFB has drivers, but they aren't supported by graphic vendors, and I don't know if it will be simple to port...

Maybe the better choice can be implementing XFast with Gallium, because the Gallium system is very highly portable (I think).

[Rohan123]

Jeko, You could try to port native Syllable graphical subsystem. AFAIK it is not very hard to do, because I heard about nearest plan to port it on Linux. It's more slim than Xorg.

[Owen]

From what I gather, the 3D acceleration support of DirectFB extends to four out of production old Matrox cards.

No, because for an existing graphics server (X or DirectFB) there are yet the drivers for video cards! No graphic vendor will be interested to develop drivers for my own graphic subsystem.

You still need them to write your kernel drivers. That might be possible for ATi and Intel cards now, with a LOT of reading documentation, but good luck doing it for nVIDIA cards

[Jeko]

From what I gather, the 3D acceleration support of DirectFB extends to four out of production old Matrox cards.

No, because for an existing graphics server (X or DirectFB) there are yet the drivers for video cards! No graphic vendor will be interested to develop drivers for my own graphic subsystem.

You still need them to write your kernel drivers. That might be possible for ATi and Intel cards now, with a LOT of reading documentation, but good luck doing it for nVIDIA cards

No, because there are yet drivers for video cards in X and DirectFB. For X, there are all the drivers for each video card, in DirectFB there are all the drivers, but they don't support every feature...

The only thing I must do for use X or DirectFB, is to integrate them in my kernel, I mustn't write any driver.

[DeletedAccount]

If you have sufficent time at your disposal , you can create a scaled down version of X . You may use the pointers given below for reference .

1) http://www.angelfire.com/linux/floorzat/2diskXwin.htm

2) http://www.modest-proposals.com/Hacklin.htm

Regards
Sandeep

[Owen]

No, because there are yet drivers for video cards in X and DirectFB. For X, there are all the drivers for each video card, in DirectFB there are all the drivers, but they don't support every feature...

The only thing I must do for use X or DirectFB, is to integrate them in my kernel, I mustn't write any driver.

THE X11/DIRECTFB DRIVERS DEPEND UPON THE KERNEL DRIVERS!

The hardware accelerated graphics are about 10% X server, 70% userspace, 20% kernel. The X server is responsible for controlling windows, etc. The kernel is responsible for arbitrating between users. The userspace drivers are the big massive things like libGL which talk to the hardware.

You will find that the X11 drivers mostly just talk to the kernel driver. The userspace drivers will probably do something using ioctls or such over a device such as /dev/nvidia0, and mmapping regions of the graphic's card's memory with the kernel driver's permission.

You still need to write your kernel driver. When using an nVIDIA card, *nix all load nvidia.ko. When using an ATi card, they load fglrx.ko. When using an intel card, they probably load something else.

X11 talks to the kernel through it's drivers which talk to the drivers for your video card. You still need your kernel driver, and for acceleration, you need some form of libGL, libGLU and libGLX (if your using X11)

For ATi and Intel cards, you could port the Linux kernel drivers, but be aware that they are GPLed. If your OS is GPLed, then that will be OK with you.

[Brendan]

Hi,

The hardware accelerated graphics are about 10% X server, 70% userspace, 20% kernel.

Hmm, that really does sound like the most best device driver design I've ever heard of....


Cheers,

Brendan