Quoting Shane Nay ([EMAIL PROTECTED]): > First of all, Merry Christmas everyone.
Merry Christmas to you, too. > What I'm working on right now is getting DirectFB running on SDL > within Xwindows, now you might think that's rather counter > productive, but it makes for a good development enviroment for > developing embedded applications. Right now I've got the first > screen shot floating about- > http://www.minirl.com/gtk-directfb-sdl.gif This is great, it's one of the 'multi' things that need to be added to DirectFB: multi-app, multi-head and multi-platform ;) 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. > There are redraw issues as can be seen from the screenshot, and I > haven't hooked up SDL Input yet. It's pretty clean right now except > for some hardcoded stuff to pickup redraw regions. It can decide if > you're running under X or console, and then choose to load via SDL or > framebuffer mode respectively. (via the DISPLAY enviroment variable, > if someone else has a better idea shoot it my way) 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()'. > Anyway, I'm putting this message up just to make sure I'm not > duplicating efforts and to get the vibe on whether there is interest > in bringing it into the core of DirectFB. I'm planning on > implementing full skin support, which basically makes the SDL pane > look like the device you are emulating. Here's an example of what I > mean from one of the embedded projects I'm working on right now- > http://www.minirl.com/skin_example.gif > > (This device runs PicoGUI, and this is PicoGUIs' skin support written > by Micah Dowty, pgui.sourceforge.net) Reminds me of XCoPilot ;) > I've got lots of other questions and issues, but I'll save them for > when I get closer to the baseline implementation. 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). 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. 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 ;) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" convergence integrated media GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
