DirectFB - Home of the pragmatist Roadmap

[directfb-dev] Directfb on Multiple Frame Buffer
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-dev] Directfb on Multiple Frame Buffer

Hi all,

I am new to directfb, I've started to read and test the code and I have
some informations to ask you guys.

1) I've faced this problem with all and every frame buffer lib I've tested
so far. It is impossible for one to specify on which frame buffer one
wants to work on. I mean in my case I have 2 fb /dev/fb0(VESA or whatever
gfx card fb) and /dev/fb1 (a USB LCD panel). The result is that I can't
use directfb on /dev/fb1 out of the box. I need to replace "/dev/fb0" by
"/dev/fb1". What I propose is to add a cmd line parameter
--frame-buffer-device=/dev/fb? and then pass this string to the
fbdev_open() function, which the new prototype would be :

fbdev_open(char * dev); /* /dev/fb1 */
fbdev_open(char * dev, int major); /* /dev/fb 1 */

which one do you think is the best, I would prefer the 2nd one.

If using only one parameter the device has to be split in /dev/fb and n
before the fb open(...) in core/fbdev.c fbdev_open(...).
if using 2 parameters the device has to be split in misc/conf.c and the
result put in what could be dfb_config->device and

We have to change in core/core.c fbdev_open(...) by something like
        dfb_config->device should  be initialized to "/dev/fb0"
        by default in misc/conf.c config_allocate(...) if
        dfb_config->device is differrent from default we can pass
        the value straight, it has been check in misc/conf.c
    INITCHECK( fbdev_open(dfb_config->device) );


        dfb_config->device and dfb_config->device_major should
        be initialized to "/dev/fb" and 0 by default in misc/conf.c
    INITCHECK( fbdev_open(dfb_config->device, dfb_config->device_major) );

of cource the intergity of, either dfb_config->device or
dfb_config->device_major would have been tested in

3) moreover when the device major of the frame buffer is > 0, 1..n we know
that the fb doesn't acquire any vt because it has already been aquired by
the fb0. There is no vt state to save/restore . So there is no need for
vt_open(...) and vt_close(...) to be excecuted in such circumtances.
We could add something like :

in core/core.c core_init(...)

    if ( !dfb_config->device_major)
        INITCHECK( vt_open() );

in core_deinit(...)

     if ( !dfb_config->device_major)

and in core_deinit_emergency(...)
    if ( !dfb_config->device_major)

In theory all this should work ! If I provide the patch are you willing to
integrate it ?

3) Now what happen still in my case if I want from the same proggy draw on
two frame bufferis, it is the same for anymone who has 2 gfx cards in his
and wants to play with them at the same time. What would be nice, would be
be able to specified which layer is link to which framebuffer.
This way it should be possible to do something like

primary->FillRectangle (..) /* primary beeing linked to fb0 */
secondary->FillRectangle (..) /* secondary beeing linked to fb1 */

for instance.
Does anyone working on it?

4) In core/fbdev.c(~360) there is no way to specify a var.vmode  |=
FB_VMODE_NONINTERLACED. If the driver only underdstand that kind of vmode
the next ioctl FBIOPUT_VSCREENINFO will obviously fail, is it a
forgetfullness or not ?
What about FB_VMODE_MASK ?

thanks for your time.

Fabien Lebaillif Delamare
R&D Engineer
Office : +65 844 1301
HP : +65 9848 1431
18 Tannery Lane 
#03-05 Lian Tong Building
Singapore 347780

Info:  To unsubscribe send a mail to with 
"unsubscribe directfb-dev" as subject.

Home | Main Index | Thread Index / Development / Old Archives