|Site sponsored by IGEL|
[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 : either fbdev_open(char * dev); /* /dev/fb1 */ or 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 dfb_config->device_major. 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 config_set(...) */ INITCHECK( fbdev_open(dfb_config->device) ); or /* dfb_config->device and dfb_config->device_major should be initialized to "/dev/fb" and 0 by default in misc/conf.c config_allocate(...) */ 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 misc/conf.c(config_set(...)) 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) vt_close(); and in core_deinit_emergency(...) if ( !dfb_config->device_major) vt_close(); 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 box and wants to play with them at the same time. What would be nice, would be to 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 email@example.com with "unsubscribe directfb-dev" as subject.