Hi there!
I just heard of directfb (http://www.directfb.org) and thought that SDL
should support it. Is anybody working on this?
so long
Thomas–
___ Obviously we do not want to leave zombies around.
/\ - W. Richard Stevens
( ^ >
/ \ Thomas Krennwallner
(/) Fingerprint: 9484 D99D 2E1E 4E02 5446 DAD9 FF58 4E59 67A1 DA7B
I just heard of directfb (http://www.directfb.org) and thought that SDL
should support it. Is anybody working on this?
we could support it as a backend right away, but since we already have
an fbcon target it might make more sense to incorporate the missing stuff.
But if someone writes a directfb target I see no reason not to include it
DirectFB has some really interesting ideas (and some likely mistakes
which I won’t elaborate on right now). we should look hard on it for
the 1.3 revision/redesign
SDL can already use the linux FB device to output its graphics… Does
DirectFB offer anything above and beyond basic FB access?
(Though, looking at GTK+ under DirectFB,
I would expect that, if DirectFB does add anything new to the mix, it ought not
be too hard to add support for.)On Thu, 10 May 2001, you wrote:
Hi there!
I just heard of directfb (http://www.directfb.org) and thought that SDL
should support it. Is anybody working on this?
–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >
SDL can already use the framebuffer as a backend, why would we want to
add another layer?
BryanOn Thu, May 10, 2001 at 07:52:36PM +0200, Thomas Krennwallner wrote:
I just heard of directfb (http://www.directfb.org) and thought that SDL
should support it. Is anybody working on this?
–
http://www.bokeoa.com/ | @Bryan_Stillwell
GPG fingerprint: 3608 4610 8C08 B8EB 0970 9686 8A93 386C 6116 EFE2
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010510/7e417b81/attachment.pgp
I just heard of directfb (http://www.directfb.org) and thought that SDL
should support it. Is anybody working on this?SDL can already use the framebuffer as a backend, why would we want to
add another layer?
Because it adds the hardware acceleration that fbdev doesn’t have built into
it. The idea is that fbdev should have only the lowest level stuff in kernel
space, and the rest in user space, somewhat like the XFree86 4.x DRI module +
server design.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 10 May 2001 21:18, Bryan Stillwell wrote:
On Thu, May 10, 2001 at 07:52:36PM +0200, Thomas Krennwallner wrote:
Yes, but it would be better to support these accelerated features
directly in SDL fbcon backends instead of adding another layer. SDL
already exploits some of the hardware features in the matrox and 3dfx
fbcon drivers.On Thu, May 10, 2001 at 10:30:21PM +0200, David Olofson wrote:
On Thursday 10 May 2001 21:18, Bryan Stillwell wrote:
On Thu, May 10, 2001 at 07:52:36PM +0200, Thomas Krennwallner wrote:
I just heard of directfb (http://www.directfb.org) and thought that SDL
should support it. Is anybody working on this?SDL can already use the framebuffer as a backend, why would we want to
add another layer?Because it adds the hardware acceleration that fbdev doesn’t have built into
it. The idea is that fbdev should have only the lowest level stuff in kernel
space, and the rest in user space, somewhat like the XFree86 4.x DRI module +
server design.//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’
Bother! said Pooh, as Geordi found a NEW problem.
Ok… But from what I’ve seen of the fbdev code, it hardly contains any real
h/w accelerated features at all. It only contains the basic stuff needed to
set up displays, and the layer that’s required for user space drivers to
access the hardware in a nice way.
That is, unless I’m missing something DirectFB in fact contains a set of
hardware specific drivers (that is, low level code, rather than hooks to
existing features in the fbdev drivers), which doesn’t seem to be something
that should be reimplemented and integrated with SDL.
Are we talking about features simple enough to be included in the fbdev
kernel drivers, and if so, do a significant number of drivers actually
implement them?
(I guess I should read some kernel source again - long time since… 
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 10 May 2001 22:57, Martin Donlon wrote:
Yes, but it would be better to support these accelerated features
directly in SDL fbcon backends instead of adding another layer. SDL
already exploits some of the hardware features in the matrox and 3dfx
fbcon drivers.
Yes, but it would be better to support these accelerated features
directly in SDL fbcon backends instead of adding another layer. SDL
already exploits some of the hardware features in the matrox and 3dfx
fbcon drivers.
Rilly? I didn’t know that… is there any online documentation detailing how to
go about utilizing this? (I am /very/ new to this whole fbcon stuff… but was
thrilled when Tux Typing ran natively in it without recompile 
As a curiousity, it’d be interesting to see DirectFB/examples/df_dok.c
ported over to use SDL/SDL_ttf natively, and see how SDL’s framebuffer
driver holds up against DirectFB’s in terms of speed.
I agree… I would be very interested in this (not just in terms of speed, but
also in terms of code and library size… I have been debating about creating
my own animated boot-up sequence [I wanted something dramatically different
from Aurora, in case anyone suggests I just use that]).On Thu, 10 May 2001, you wrote:
–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >
Yes, but it would be better to support these accelerated features
directly in SDL fbcon backends instead of adding another layer. SDL
already exploits some of the hardware features in the matrox and 3dfx
fbcon drivers.
As a curiousity, it’d be interesting to see DirectFB/examples/df_dok.c
ported over to use SDL/SDL_ttf natively, and see how SDL’s framebuffer
driver holds up against DirectFB’s in terms of speed.
–ryan.
./src/video/fbcon/SDL_fbmatrox.c and SDL_fb3dfx.c
Only, rects, and colorkey blits are accelerated though
Haven’t look at directfbOn Fri, May 11, 2001 at 12:00:17AM +0200, David Olofson wrote:
On Thursday 10 May 2001 22:57, Martin Donlon wrote:
Yes, but it would be better to support these accelerated features
directly in SDL fbcon backends instead of adding another layer. SDL
already exploits some of the hardware features in the matrox and 3dfx
fbcon drivers.Ok… But from what I’ve seen of the fbdev code, it hardly contains any real
h/w accelerated features at all. It only contains the basic stuff needed to
set up displays, and the layer that’s required for user space drivers to
access the hardware in a nice way.That is, unless I’m missing something DirectFB in fact contains a set of
hardware specific drivers (that is, low level code, rather than hooks to
existing features in the fbdev drivers), which doesn’t seem to be something
that should be reimplemented and integrated with SDL.
Bother! said Pooh, as the bungie cord broke.