Hi Karim,
I already visited the gfxdrivers directory; I just wanted to make sure
that a) nobody else already implemented something like that outside of
direcfb.org and b) none of the existing drivers work undocumentedly on
the GMA3150. As I've had both experiences with other open-source
projects in the past, I thought one e-mail woudn't hurt. :-)
You're right, an email doesn't hurt ;-)
Thus, if you want to use directfb with hardware acceleration on your
board, you would have to port the relevant part of the xorg driver to
DirectFB. Given that there is already a working xorg driver and given
the hardware programming docs at intellinuxgraphics.org, this should be
feasible :-)
I'm not all that experienced when it comes to driver programming under
Linux (most of my software development is done on embedded systems
without an operating system to speak of), but I will take a look and see
if that can be managed in a reasonable amount of time. Do I just need a
DirectFB gfxdriver, or would I neet a linux kernel frame buffer driver
as well?
You need a linux kernel frame buffer driver if you want to use DirectFB's
'fbdev' backsystem (nearly all DirectFB drivers use this).
The intel driver is 'intelfb', see
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.33.y.git;a=tree;f=drivers/video/intelfb;
Unfortunately, it only supports
"830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/945GME/965G/965GM"
chipsets. However 'intelfb' seems to be largely a port of the i810/i830 XFree86
driver, which in turn
is what the current xorg intel driver
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/
is based on. If you compare the code of both, they look very similar :-)
As I said before, if there are no problems that are hiding in the details
of the xorg intel driver, it should be feasible to
a) extend the intelfb kernel driver to support your chipset
b) write a new DirectFB gfx driver for the GMA 3000/3100/3150
(based on the i830 gfxdriver if this works out)
The system which runs my application boots with frame buffer
(depending on mainboard, either viafb, intelfb, or uvesafb) activated,
and I imagine there might be problems when the kernel uses uvesafb and
DirectFB tries to access the device directly.
For hardware acceleration to work with DirectFB you need a kernel frame
buffer driver for your hardware, i.e. matroxfb for (supported) Matrox hardware,
intelfb for (supported) Intel hardware, etc.
You should get DirectFB to start up with the builtin software rasterizer
when using vesafb. Hmm, I don't know about uvesafb. Maybe someone on this
list knows if this will work? Anyway, there will be no hardware acceleration
from
DirectFB when using 'xxvesafb'.
But perhaps I don't even need hardware acceleration - the Atom isn't all
that fast, but I'm just blitting a few images and write a few strings
onto the display, nothing fancy. However, I don't really get why
DirectFB woudln't even start:
| [2010-03-30 18:50:20] (*) FBDev/Surface: Allocated 1280x1024 32 bit RGB32
buffer (index 0) at offset 0 and pitch 5120.
| [2010-03-30 18:50:20] (!) DirectFB/FBDev: Panning display failed (x=0 y=0
ywrap=0 vbl=1)!
I just call the libary via
| DirectFB::Init("--dfb:mode=1280x1024,depth=32,pixelformat=RGB32");
and create a double-buffered primary surface:
| dsc.flags = DSDESC_CAPS;
| DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_PRIMARY);
| DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_VIDEOONLY);
| DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_DOUBLE);
| DFB_ADD_SURFACE_DESC(dsc.flags, DSDESC_PIXELFORMAT);
| dsc.pixelformat= DSPF_RGB32;
|
| primary=dfb->CreateSurface(dsc);
Is there any reason why this should fail like above when using the
software rasterizer? And how can I get around that without hardware
acceleration?
Ahh, did I said you don't get hardware acceleration with vesafb?
In addition, you can't switch modes with directfb, as you attempted
above. It seems that this is what went wrong ;-)
From the DirectFB README:
>>
The generic VESA frame buffer device does not support mode switching
and you will not get hardware acceleration. To make DirectFB work with
veasfb, you should add the following lines to /etc/lilo.conf:
append="video=vesa:ywrap,mtrr"
'ywrap' enables panning with wraparound.'mtrr' enables setting caching
type for the frame buffer to write-combining.
vga=791
This sets the mode on startup. 791 means 1024x...@16, 788 means 800x...@16.
<<
Hope this helps.
Maybe someone who is more into DirectFB can comment on these things?
Oliver
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
