On 1/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Mike > > I think I have a least a conceptual understanding of how WM's > traditionally work, what we need to do, and of how you propose to do it. > > I suggest that at least in the beginning you could delegate the work to me > and others, since you seem to have the best overview. I tried checking out > the "mike_surface" branch but that did not compile. > I went off the deep end a bit on that one :) Consider it notes.
> The work you have allready done! Is that in cvs, in a branch or not ? > I suppose we would need to create a branch at least untill we have > factored out the WM so it loads a a module. > Correct I asked on the list about moving away from cvs and svn seemed to be acceptable I'd like to see us use svn for this type of work. Dennis any chance of a move to SVN in the near future ? If not I'll make another branch in CVS. > So if you could take charge at least here in the beginning and give me > something to work on. If there is a not too complex and lengthy thing we > need done that would probably be the best! > Great. The first step is to create a new core data type like CoreWindow and CoreLayer that will represent our Z ordered surface. For now it can just draw a rectangle as its opp. I have to give a demo on Wed but after that I'll have some free time to start working a little. If you have not done any internal dfb programing the first thing you need to do is work through how the fusion calls work between the interface and the core object. So your homework is to play with fusion a bit so you see how it works in multi and single mode. Probably it would be best to create our own Fusion world for this also. The best approach I think is to set up your own master slave sample server you can use the one in DirectFB/tests as a example. I can add the base data type after Wed on a branch. I think I'll call the new data type CoreDrawable since thats easier to spell than CoreComposite and its main purpose in life is a place to draw. The constructor takes a surface and we need to have the ability to change the surface to a new one. The software cursor will become a sprite CoreDrawable so the first real test would be to show we have a cursor working correctly. This means we probably need to support z order layer conceptual grouping in the CoreDrawable so its easier to keep groups above and below other groups. Initially it will be a z ordered tree of rectangles with only a fill rect supported. The WM will attach to the screen get events and is full responsible for user events. First of course we have it just drag windows around and click to raise lower. To finish I hope to get some feedback from Dennis on this and I'll cut a branch off after next Wed and add the new CoreDrawable data type and we can then work on filling in the details. You play with fusion for a few days until your comfortable with it thats the only part of directfb that is different once you grok fusion its basically regular C programming. The first goal is a z ordered list of drawable that support fill rect operator and a soft cursor along with a simple wm using CoreDrawable. The next goal will be to add Surface blit/flip support as a operator from CoreWindow and add more drawing operators. At this point we can look at splitting CoreWindow between the new WM module and CoreDrawable. This means need one more new datatype interface DFBWindowManager. > -Martin L > > > I guess I should say where I'm at on this project. > > > > On the X11 side I've written a kdrive based directfb X11 server that > > runs full screen > > on the display layer. So we have X11 now in full control of the screen. > > > > The next step is to rip the WM or probably more correct ignore the > > current Directfb wm code > > and write the simple region manager with a basic drawing list. This > > can reuse a good bit of the current wm code and simply have the > > structures renamed I call them CoreComposite right now since we have > > used all the good words ( I'm open to suggestions ) > > > > Then we need to move back to X11 and hook the creation functions to > > defer back to the dfb composite manager the rootless and composite > > api's can be used to guide how to preform this hook. > > > > Then back to directfb you can now rip the remaining CoreWindow code > > out and let it defer to our CoreComposite manager. Done correctly when > > a DFBWindow is added it adds a CoreComposite the X11 WM picks up this > > request and wraps it in the X11 api creating a X11 window that can now > > be hooked by current X11 wm's. Yes this means that X11 is running on > > directfb and directfb windows are emulated under X11 but thats by > > design honest :) > > > > Once we have good directfb wm's the reverse would be true with the X11 > > wm api rerouted to and simulated by directfb via a compatibility > > library. > > > > This is a lot of work but now DFB can be running on the desktop and it > > works via integration with the existing X11 code base we have plenty > > of time to develop new cool desktops DFB core can be adopted and > > deployed using the existing technology via the above hooks. > > When compelling "pure" DFB desktop are available that support > > applications expecting a X11 WM the X wm can be replaced. > > > > My opinion is that we can offer a saner and easier api for WM > > development from directfb so I think that in time people will prefer > > the DFB api if its widely deployed. The migration route solves this > > problem. The WM/App interaction can then be hidden via a wrapper > > programming interface so your not doing X programming directly. In any > > case the options for evolution/revolution are open so it really up to > > what gets adopted technically there are no limitations. Overtime I > > think that direct X11 programming will fade and a agnostic api will > > develop. This is already common with libraries like Gdk/QT but they > > add a lot of other junk to the wraps. I'm talking about a saner > > Xlib/DFB style simple api that hides the window impl without adding a > > widget toolkit. > > > > > > > > > > > > > > > > > > On 1/17/07, Mike Emmel <[EMAIL PROTECTED]> wrote: > >> On 1/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> > I am still reading up on WMs. Just tried to compile and run metacity > >> in an > >> > Xnest, and reading their HACKING document. > >> > > >> > Still a lot of questions and things I need to get familiar with, but > >> for > >> > now just one question: > >> > What exactly do you mean by: > >> > "open the directfb api to allow X11 to work well i.e allow X11 wm etc > >> to > >> > function and manage all windows including dfb windows." > >> > > >> > Do you wan't existing X Window Managers to actually compile "out of > >> the > >> > box" under DirectFB. > >> > > >> > Perhaps it's just me which still havent figured out how exactly th WM > >> > interacts between the server and the client program showing windows. > >> By > >> > messages? Or by hooking in directly on Xserver functions? > >> > > >> > Hope these questions are not too stupid :-) .. but's the only way to > >> learn... > >> > > >> > -Martin > >> > > >> > >> No these are fine questions you would need to know the guts of a wm to > >> understand. > >> > >> All wm work by capturing events and drawing commands and configuration > >> changes > >> such as resizes and re-directing them through the wm for pre-processing. > >> > >> Directfb default and running X11 with no wm ( really the internal one) > >> are the simplest. > >> They draw no borders and process events as documented in the application > >> api. > >> > >> Anything more than this and you need a shadow window or a way to draw > >> a border and capture events in this border for resize etc. And of > >> course other events like creation need to be captured to allow the wm > >> to create the right border for the window. I think your finding that > >> wm are actually fairly complex. > >> > >> What I mean by opening up the directfb API is that both X11 and > >> Directfb assume a certain design for the wm built in. What people > >> generally consider WM are actually privileged applications that hook > >> various wm functions and redirect them to do further processing before > >> generally calling back into the real wm and preforming the default > >> action. > >> > >> The core design is written in stone so to speak in both however the > >> hooks exported are fixed. For X11 this resulted in a new manager the > >> composite manager which adds additional hooks to support alpha > >> blending of window on screen. DFB by design already allows the wm to > >> control compositing. My point is not who has the better design ( DFB > >> :) but that maybe the whole concept needs to be rethought. Why do we > >> have too fix the design of the wm in the core architecture there are a > >> lot of ways to build wm and design tradeoffs etc esp when your looking > >> at embedded devices. > >> > >> X11's composite manager shows in a sense that you can go with a more > >> primitive public api in the core and move most of what is hardcoded > >> now in both X11 and directfb out as a variable design. What you > >> really need at the core is actually quite simple. > >> > >> 1.) A unified list of all z order regions > >> 2.) A hook when compositing is needed to callback to show these regions. > >> 3.) A way to specify how these regions are drawn so the composite can > >> happen without blocking on another process. > >> > >> Directfb is actually pretty close to right but it exports these z > >> ordered regions as a application accesible api DFBWindows and it > >> assumes all top level windows are buffered. > >> > >> So the changes on the directfb side are to recognize two things. > >> > >> 1.) All you need in the core is a unified list of these z ordered > >> regions to run you composite > >> manager. This is required. > >> 2.) The composite manager really just needs a list of instructions for > >> drawing a region when > >> it composites blitting a buffer is simply one operation thats really a > >> subset of a list of graphics primitives that could be performed in the > >> simplest case you could have either fill rect or blit etc. The key is > >> that at composite time the drawing instructions are fixed but they can > >> be a complex list. > >> > >> Event handling is simply forwarded to the wm and no events are > >> generated in the core. > >> We don't even need to do hit detection in the core although helper > >> routines can be provided see below. > >> > >> With this design how a wm works is no longer defined all that is > >> defined the shared list of regions and a way to specify draw ops when > >> you run the real composite algorithm. > >> > >> The WM also intercepts all request to create a "real" window and > >> provides the hook for this. > >> > >> > >> Now with all these changes the reason that its possible to embedded > >> the wm in the core in the first place is generally you have a limited > >> way to actually write a real wm so all this code can be moved out into > >> a optional helper library or toolkit library for someone who wants to > >> write a wm. This library in the case of directfb could create a > >> default implementation of a DFBWindow and could have hooks to allow a > >> alternative WM to wrap the default > >> or of course the wm can do a custom version and simply reuse the code > >> it needs from the library since its open source. > >> > >> With this design and some small changes to the X11 server which can > >> now run full screen > >> existing X11 wm can be used to manage directfb apps and new dfb > >> centric wm can be developed that manage X11 windows. Since we have a > >> wealth of X11 wm getting dfb embedded in the traditional desktop > >> cleanly is my first priority. > >> > >> What this means is that on the X11 side you need to divert the hooks > >> created for the composite manager extension to run back into dfb to > >> create these regions. > >> > >> And if your creating a native dfb window it needs to defer to the X11 > >> server/wm to allow X11 to create a X window proxy for each region. > >> > >> You can see that by moving the wm implementation out of the core and > >> just leaving the bare minimum you can now write a wm using any api you > >> want and if you have the hooks any other api works as a "child" or > >> slave wm to your chosen one. The interaction is cooperative between > >> the supporting api's with the core providing the base level of > >> cooperation which is the z order list and a way to declare the drawing > >> commands. > >> > >> The ability of one wm to emulate another say the X11 wm api can in > >> time probably be extracted as a simple library with a basic backside > >> api. So if I write a pure dfb wm I should not have to do that much > >> work to allow it to pose as a X11 wm. The directfb api is simple > >> enough that the reverse allowing current X11 wm to create dfb windows > >> is fairly easy. > >> But again this can be moved into a support library. The exciting thing > >> is this opens the door for custom embedded wm that export their own > >> windowing api and support whatever current api they choose. A open gl > >> dfb/desktop need only support managing these 2D z ordered surfaces for > >> example and provide its own window api while still allowing DFB and > >> X111 windows to function. In this case all of these 2D windows would > >> be embedded in OpenGL surfaces. > >> > >> I'm interested for example in making all the windows part of a browser > >> running full screen so in my case all windows would also show as tags > >> in a dynamic full screen document. > >> > >> Thus the sky is the limit on how you actually write the WM and what it > >> capabilities are and you have access eventually to simple libraries > >> that allow existing apis such as X11 and DFB and others to run on your > >> new "cool" desktop. All we need to do is make some small changes to > >> directfb to remove some assumptions and expose basically the > >> CoreWindow api to the WM and let it create the DFBWindow interface. > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >> > > On 1/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> > >> Seems you know more about the DirectFB architecture than I. > >> > >> I will try to read up on that, if I can find any documentation. > >> > >> Today I have tried to look a bit on other Window Managers and also > >> found > >> > >> and read the "Extended Window Manager Hints" specs, which both > >> > >> KWin(KDE), > >> > >> Metacity(Gnome), AfterStep and a lot of other WM's more or less > >> adhere > >> > >> to. > >> > >> > >> > >> It also helped me understanding where the line is between the WM > >> and eg. > >> > >> the Desktop. So perhaps we need to make a Desktop also? The WM in > >> itself > >> > >> seems to be more of a base on which to build a desktop. > >> > >> > >> > > The line is quite blurry generally the last part of a wm that makes > >> > > the desktop is > >> > > a plugin framework for applets that run on the desktop or root > >> window. > >> > > Most modern X11 wm seem to be basically full desktops outside of > >> these > >> > > applets. > >> > > > >> > >> I will continue to read about the existing WM's and looking a their > >> code > >> > >> in order to see if it would be possible to use any of them as a > >> base, > >> > >> converting all X-related functions to DirectFB calls. Ofcourse if > >> we > >> > >> want > >> > >> to use an existing I suppose we better stick to those using LGPL or > >> less > >> > >> restrictive licences.... > >> > >> > >> > > > >> > > I went down this path already with metacity my conclusion is we > >> needed > >> > > to open up > >> > > the design of directfb to create the wm foundation toolkit I've > >> > > described to handle pretty much any wm design. > >> > > > >> > > My current approach is to first open the directfb api to allow X11 > >> to > >> > > work well i.e allow X11 wm etc to function and manage all windows > >> > > including dfb windows. > >> > > For a non X11 wm I'd like to instead take a different approach and > >> > > make WebKit the wm. > >> > > > >> > > The cool thing would be the whole desktop would be xml programmable. > >> > > Its basically one > >> > > big web page/ xul app. So directfb have a cooler desktop than anyone > >> else > >> > > :) > >> > > A shared XML doc makes it much easier to do the detailed > >> > > interoperability needed to pose as a X11 wm. > >> > > > >> > > > >> > >> -Martin L > >> > >> > >> > >> > On 1/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> > >> >> Hi again > >> > >> >> > >> > >> >> Sounds like very reasonable and good considerations. > >> > >> >> I actually started making a window manager which to some extend > >> was > >> > >> >> intendedn to be platform independent, but really in the first > >> shot > >> > >> was > >> > >> >> intended for SDL (and perhaps then later make a OpenGL backend). > >> > >> >> > >> > >> >> However SDL does not have a Window concept and neither a multi > >> app > >> > >> >> possiblitity, so when I started to look into the latter I > >> checked how > >> > >> >> DirectFB was doing it and concluded that DirectFB would be a > >> better > >> > >> >> choice. > >> > >> >> > >> > >> >> The only thing I have programmed for DirectFB is trying to make > >> an > >> > >> X11 > >> > >> >> system, but it's only partly working. But making a WM for > >> DirectFB > >> > >> seems > >> > >> >> like a real good project. > >> > >> >> > >> > >> >> Would it make sense to try to refine the design goals and after > >> that > >> > >> >> perhaps firsk make all header files and definitions before > >> moving > >> > >> onto > >> > >> >> actual implementation? > >> > >> >> > >> > >> > > >> > >> > My plan was to extract the current directfb wm out of the core > >> and > >> > >> > make it load as a plugin module. > >> > >> > > >> > >> > Currently the directfb wm is semi embedded in the core and half > >> > >> > plugin. The problem is this means a lot of design decisions on > >> the WM > >> > >> > side are present in the core library. > >> > >> > > >> > >> > Instead the core should only be a composite manager responsible > >> for > >> > >> > showing the windows when needed. > >> > >> > > >> > >> > Right now the windows draw routine would be hooked to the buffer > >> > >> > flipping but after the first set of changes is in it could be > >> made > >> > >> > into a generic draw list handler. > >> > >> > > >> > >> > On the interface side directfb exposes locking a assumed backing > >> store > >> > >> > for direct drawing but this is already a bit broken for sub > >> windows > >> > >> > since they can lock a parent buffer and draw through any sibling > >> > >> > subwindows that overlap and of course it hands back the buffer > >> pointer > >> > >> > for the main window forcing you to figure out where you are on > >> the > >> > >> > root before you can draw. > >> > >> > > >> > >> > In anycase the window interface for directfb in my opinion needs > >> more > >> > >> > work and needs to be made more flexible but we can address this > >> when > >> > >> > we get to it. > >> > >> > > >> > >> > But the first steps are to simplify the core and ensure that the > >> > >> > current api is supported as a module. > >> > >> > > >> > >> > My next step would be to alter my kdrive X11 server to be both > >> full > >> > >> > screen and defer to this new core composite manager when creating > >> > >> > windows so that I can prove the new api can handle a alternative > >> > >> > approach. Right now I plan to do this by building in the X11 > >> composite > >> > >> > manager and making it defer to directfb or at least the guts of > >> one. > >> > >> > This would mean of course for X11 under directfb you can't use > >> any X11 > >> > >> > composite manager but this should be the only difference between > >> > >> > standard X11 and X11/directfb. > >> > >> > > >> > >> > The above is useful of course but more important it shows that we > >> have > >> > >> > created the right core composite manager support to run any > >> windowing > >> > >> > api on directfb with a good simple core api. > >> > >> > > >> > >> > The fun part is building out directfb window mangers customized > >> to > >> > >> > different types of devices > >> > >> > and desktop styles. Done correctly any window management design > >> should > >> > >> > work. > >> > >> > > >> > >> > I did check in a branch that explored these concepts and more but > >> its > >> > >> > not useful more of a R&D project on my part to make sure its > >> possible. > >> > >> > On that branch I refactored a lot of code to show that its > >> possible to > >> > >> > rip various parts of the current core into libraries. I went way > >> to > >> > >> > far but I'm comfortable that we can do what we need to do. > >> > >> > > >> > >> > From that experience my suggestion is we start with the screen > >> layer > >> > >> > and add a new type that represents this composited object backing > >> the > >> > >> > window managers. > >> > >> > > >> > >> > We have used most of the english concept words such as layer and > >> > >> > window for other stuff so the best I have now is CoreComposite. > >> > >> > Other names for this are welcome. We may need to save CoreWindow > >> for > >> > >> > advanced wm interaction so we should keep the concept of this z > >> > >> > ordered composited drawing area different. > >> > >> > > >> > >> > It should have the following. > >> > >> > > >> > >> > Z order position. > >> > >> > A draw routine thats replaceable i.e accessed via a function > >> pointer. > >> > >> > > >> > >> > The concept of bounds this could be complex i.e non rectangular > >> or a > >> > >> > alpha image along with a rectangular bounding box. So we probably > >> need > >> > >> > a new CoreBounds object that represents the region owned by the > >> > >> > Composite. The composite manager just needs to know the > >> rectangular > >> > >> > bounds and if the composite is opaque for optimizing the > >> rendering but > >> > >> > we I think should store a complex object that can be provided by > >> the > >> > >> > wm along with a good default implementation. > >> > >> > > >> > >> > > >> > >> > A mouse hit test routine that replaceable or better generic > >> event > >> > >> > handler concept. > >> > >> > I'd like to defer as much event handling to the wm as possible > >> but the > >> > >> > core system should > >> > >> > be able to find out who has focus etc. The important part is you > >> > >> > should be able to find out which composite is active and also get > >> > >> > enter/leave events from each composite. > >> > >> > > >> > >> > > >> > >> > My plan for doing this was to introduce the CoreComposite and > >> just > >> > >> > default the rendering to fill a rectangle for testing. Also > >> > >> > CoreComposites should nest without changes to the api or > >> programming > >> > >> > model. The drawlist concept could and I think should be built > >> into the > >> > >> > core as the default drawing routine with fillrect and the current > >> > >> > buffer flipping as the basic routines supported in general all > >> the > >> > >> > core graphics ops could then be added. > >> > >> > > >> > >> > > >> > >> > Then move the current CoreWindow api out into a module on top of > >> the > >> > >> > new CoreComposite. > >> > >> > It would then simply register the buffer flipping as its drawing > >> op > >> > >> > and its current event handling as the event handler. At this > >> point the > >> > >> > current directfb api should be fully supported. > >> > >> > > >> > >> > > >> > >> > > >> > >> > So the core composite built into directfb would handle most > >> programing > >> > >> > styles for wm's and it is pluggable to allow the wm to replace > >> objects > >> > >> > and api's and still keep the correct CoreComposite api. > >> > >> > > >> > >> > > >> > >> >> -Martin L > >> > >> >> > >> > >> >> > >> > >> >> > Hi, > >> > >> >> > > >> > >> >> > I'm not a DirectFB hacker neither, but I would be interested > >> too. > >> > >> >> There > >> > >> >> > have been some emails during November/December discussing this > >> > >> issue. > >> > >> >> > > >> > >> >> > I think starting from scracth could be a good idea. "Unique" > >> could > >> > >> be > >> > >> >> > useful just for having some ideas at the beginning of > >> development. > >> > >> >> > > >> > >> >> > I think that a good starting point could be having a kind of > >> > >> wish-list > >> > >> >> of > >> > >> >> > the things we want the DFB WM to do and how it will do it. > >> > >> >> > > >> > >> >> > A first draft could be the this list (points 4 and 5 were > >> taken > >> > >> from > >> > >> >> Mike > >> > >> >> > Emmel emails). > >> > >> >> > These are only some fuzzy ideas that need a lot of work to > >> make > >> > >> them > >> > >> >> real: > >> > >> >> > > >> > >> >> > 1. Provide a light, fast and reliable windowing system for > >> > >> DirectFB. > >> > >> >> > > >> > >> >> > 2. Provide transparently the benefits of DirectFB > >> > >> >> > - It's fast > >> > >> >> > - It's light > >> > >> >> > - It's stable > >> > >> >> > - It has a small size > >> > >> >> > > >> > >> >> > 3. Capable to be used in embedded devices: > >> > >> >> > - Reduced resources usage, specially memory and > >> processor > >> > >> >> > - Small foot-print > >> > >> >> > - Support of small resolutions > >> > >> >> > - Support of a full-screen windowing system > >> > >> >> > > >> > >> >> > 4. Refactor the code so all of the current wm is loaded as a > >> shared > >> > >> >> > library. Once this is done its up to the WM to provide the > >> > >> DFBWindow > >> > >> >> > interface implementation. > >> > >> >> > > >> > >> >> > 5. Consider expanding the concept of a window to be two parts: > >> > >> >> > First a region for events. > >> > >> >> > Next consider the current back buffer flip only one operation > >> that > >> > >> can > >> > >> >> > be performed to show a window. > >> > >> >> > The operator is a chain of primitives that is executed to show > >> a > >> > >> >> window. > >> > >> >> > The default operator is to flip a back buffer but other > >> operations > >> > >> are > >> > >> >> > possbile. The only restriction is that any needed resources > >> such as > >> > >> >> images > >> > >> >> > would need to allocated in shared memory. The base set of > >> operators > >> > >> >> would > >> > >> >> > be all the core drawing ops of directfb. > >> > >> >> > > >> > >> >> > For "secure" apps one operator would be a custom callback that > >> > >> exists > >> > >> >> > in a shared library loaded into the root process. > >> > >> >> > > >> > >> >> > Libraries like cairo could be used to generate advanced > >> > >> >> drawing/blitting > >> > >> >> > chains. > >> > >> >> > > >> > >> >> > 6. Support for GTK+ > >> > >> >> > If Cairo is the graphics rendering engine and the other > >> GTK+ > >> > >> libs > >> > >> >> > are available (Glib, ATK, ...) support can be provided for > >> GTK+ > >> > >> >> > taskbars, statusbar, panels, icons and potentially Gnome > >> apps > >> > >> >> > > >> > >> >> > 7. Support of virtual desktops > >> > >> >> > In embedded devices it could become a full-screen windowing > >> > >> system > >> > >> >> > > >> > >> >> > > >> > >> >> > I hope in the following days to start working on it (as time > >> and my > >> > >> >> > real-job allow). > >> > >> >> > > >> > >> >> > Pedro Aguilar > >> > >> >> > > >> > >> >> >> Hi > >> > >> >> >> > >> > >> >> >> I would like to give a WindowManager for DirectFB a shot. > >> > >> >> >> Could anyone give me a few pointers or things I should be > >> aware > >> > >> of. > >> > >> >> >> Have a little experience with DirectFB, but not too much. > >> > >> >> >> Should I use the "default" or "unique" WM as stating point or > >> > >> none? > >> > >> >> >> > >> > >> >> >> How does DirectFB select a WM? > >> > >> >> >> What kind of functions/API must the WM facilitate ? > >> > >> >> >> > >> > >> >> >> Regards Martin L�tken > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> _______________________________________________ > >> > >> >> >> 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 > > > > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
