> This is great, it's one of the 'multi' things that need to be added > to DirectFB: multi-app, multi-head and multi-platform ;)
Cool :). > There were already some thoughts about writing backends for X or > BeOS. Actually we cannot really speak of 'backends' yet, because > the core of DirectFB was not intended to provide that feature when > it was designed. We need a bit more abstraction in the core, > especially for things in 'fbdev.c', 'gfxcard.c' and 'vt.c'. I'm > sure you had to change a lot there ;) Also some input drivers can't > be used with all targets, there need to be some platform specific > drivers. E.g. having an SDL input driver that registers a keyboard > and a mouse while the LIRC driver could be used as long as DirectFB > runs under Linux. Yep, there is some very bigtime ugliness for what I'm doing in all of the mentioned files, and even in the base keyboard module called from input.c. I had to insert a boolean variable into dfb_core for SDL to skip around the mmap logic in gfx_card.c . The others I just completely skipped over. The input.c is nice except for when it tries to load the keyboard module it assumes that the vt fd is up and running..., it should check those things, and if they don't match just bounce out "NO DEVICE" or whatever. The current method I'm using is just stuffing all the input related stuff into the "sdl' subsystem that is replacement for fbdev. (I'm doing this right now anyway, just starting on some work now after a huge Christmas dinner) Right now I'm focussed on achieving baseline functionality so that the app programmers can get busy on this stuff. > Did you try SDL with DGA support yet? What about running the SDL > target on the Framebuffer? Though I don't think any target could > offer as much possibilities and driver support as the 'native' > Framebuffer target. Especially thinking of hardware acceleration > and display layers. Anyway the drivers are ready for running in any > environment (thinking of BeOS) where you can mmap the graphics card > registers. The only thing that makes the display drivers related to > the framebuffer device are the accelerator IDs themself that are > checked during probe. Everything else is already abstracted, e.g. > 'gfxcard_get_accelerator()' or 'gfxcard_map_mmio()'. No, I haven't tried either. I'm not terribly interested (at the moment) with accelerated operations on the X86. I'm more interested in the performance in the target platform which really has no acceleration capabilities with the chips I'm looking at right now. (Though NeoMagic is going to be putting out an ARM920T with their accelerated graphics controller built in..., if I can get specs and a dev board I'll definetly work on getting DirectFB ready for that) I agree that DirectFB is more suited directly to manage any acceleration related activities. > Reminds me of XCoPilot ;) Yea, it's a confortable way for programmers that don't need to know every detail of cross compiling, romdisk prep, and the waiting involved. Also management types tend to like that crufty stuff because it gives them something to show others ;-). > This is the best place for discussing implementation details. I > think it's better doing too much planning than doing too less. The > backend or platform abstraction should be as clean as possible > (that doesn't mean that I think you aren't doing it clean enough). No, I freely admit that it is not clean enough. Especially the redraw mechanism, which I'll go ahead and ask about now- At the moment basically what I'm doing is allowing software to do all the actual drawing, i.e. I'm not using any of the specialized SDL functions like Blitting. So there is absolutely no acceleration at this point. I'm basically just changing the mmap call in gfx_card to the address that SDL gives you for the writable framebuffer. I started with fbdev as a "patern", and used that to implement the sdl initiliazation and connectivity. It can change the modes to whatever, etc. The problem I came up against is I'm not really sure when I need to tell SDL to update a Rectangular region, and where. Right now I just stuck it in the Blit code because that was convenient. However, where should it go?..., is there a central place where all the "dirty rectangles" pass through? I thought update_region would do the trick, but apparently that gets by-passed in a non-window situation? > The goal would be a modularized backend/platform support that makes > it possible to have native Linux backends and native Windows (e.g. > DirectX) backends. That would be optimal..., actually PicoGUI has a really good system for this that is very generalized. We also need a configuration method I think..., ./configure --with-suger-on-top-and-everything-nice gets a little painfull after a while. What about using "make menuconfig" like the kernel? What would probably work out pretty well is dumping vt_initialize, fb_intialize, etc. And just have something like input_intialize, graphics_intialize, acceleration_intialize..., then based on what modules you have installed it would "ping" each of it's potential modules until it finds a match. The module would then carry out the individual steps like initiliazing the vt, fb, etc. as appropriate. (Kind of like make everything like input.c is currently structured, but of course make the actual modules like keyboard less sensitive to the failure of other pieces) > SDL is nice as it's itself platform independent, > but I think for best efficiency one should consider custom backends > later on. And I don't want to know what happens if you run SDL on > DirectFB on SDL ;) Hehe, yes, I was in fact thinking about that the other day. Custom backends are the "way to go" when you need performance, and I plan on writing a custom backend if I can get some accelerated hardware on the device I'm working on. However, what I'm working on right now has absolutely zero need for acceleration while being "emulated". Thanks, Shane Nay. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
