Hi Folks, As you specify the framebuffer device to use when you start a DFB application, I see no fundamental limitation in DFB to using multiple framebuffers. However having multiple framebuffers on different planes on the same card has some issues, at least if those planes are being displayed on the same physical display. Of course DFB hardware drivers that map the device registers and program the graphics hardware directly then get into trouble, you need to virtualize the hardware or do something similar to multi-app support to handle this.
The main problem is the kernel FB system historically ties the physical FB dimensions to the display mode timings. If you have more than one framebuffer registered on the same physical device and display, what happens when you change mode? I have looked at this in passing and could not see a neat way of informing the kernel FB, VC upper layers or applications with an open file descriptor that a framebuffer's "var" had changed because _another_ framebuffer in the system had caused a mode change. So at this point you start to think about somehow dis-associating the FB dimensions from the actual display mode and having the framebuffer scale the image if there is a mismatch between the display mode and the framebuffer dimensions; I guess this is feasible if your hardware has arbitrary scaling on all planes. But this does drastically bend if not break the FB get/set var api. As an aside: there is another reason people have been asking me about having the FB dimensions and display mode active area different; that being to save memory when doing OSDs for HD devices, by drawing at an SD resolution and scaling it up. So far I have resisted this, but 1920x1080 32bit double buffered+space for offscreen bitmaps is a _lot_ of memory to reserve on an embedded device just for the OSD. However, back to the original question, why would you want to do this? DFB already has a mechanism for handling multiple planes on the same device (layers) and multiple applications (multi-app/fusion). Although I don't actually know; I assume that with multi-app enabled you can effectively have independent applications with their primary surface on different layers with little overhead. Denis? -stephen ----- Original Message ----- From: "Unger Richard" <[EMAIL PROTECTED]> To: "Daniel Laird" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Friday, July 28, 2006 9:23 AM Subject: Re: [directfb-dev] Multiple Framebuffer System Support Hi! I don't think the current fb system would prevent this. I believe a driver could easily create multiple framebuffer devices for different layers of the same card. There's probably drivers out there that do this... IMHO The problems start to arise more with the console - which framebuffer would the console go to? How would the user control this? Perhaps the driver could hardwire it to a certain layer (gfx?), where it makes sense... Richard > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Daniel Laird > Gesendet: Freitag, 28. Juli 2006 09:46 > An: [email protected] > Betreff: [directfb-dev] Multiple Framebuffer System Support > > > On the system I am using I have multiple layers. I want each > of these layers to be registered as a framebuffer device. > This obviously causes an issue with the current fbdev system > as it seems to support just the one framebuffer device. > Has anyone else looked into howto make this system (or maybe > a new one) support multiple framebuffer devices on a single screen. > > I am currently thinking that a new system is required called > multi_fbdev or something like that. It could be based upon > current fbdev system code but with array of fbdev devices etc > > Any thoughts etc would be welcomed. I do not intend to start > this is the near future but it is something I have to do. > > Cheers > Dan > -- > View this message in context: > http://www.nabble.com/Multiple-Framebuffer-System-Support-tf20 > 14005.html#a5535130 > Sent from the DirectFB Dev forum at Nabble.com. > > > _______________________________________________ > directfb-dev mailing list > [email protected] > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
