Jorge Luis Zapata Muga wrote: > On Thu, Apr 3, 2008 at 5:09 PM, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: >> Jorge Luis Zapata Muga wrote: >>> was disappointed on how DirectFB API was heading (window manager >>> inside, too many interfaces, multimedia, input, etc), so this weeks >>> I've been developing a library that only abstracts the >>> layers/input/output of a graphic device, not 2d or 3d, similar to what >>> dfb was on the beginning, with two (un)supported devices for now (ti's >>> >> DirectFB has been 2D acceleration from its first moment on :) >> >> The integrated window manager capabilities have been added to support more >> than one application and toolkit running on one screen with transparency >> between them (simple compositing of client buffers) and management of the >> window focus with event routing. > > Yes i understand that, but the question is, was it needed inside > directfb itself? or better a library on top of it? is just that making > the library to be _the only_ entry point doesnt provide much options > to integrate with others, proprietary or not, components / libraries; > maybe im wrong, dunno =)
You need a horizontal architecture with powerful core components :) >> Is your library open source (yet)? > > Yes, you can find it at http://code.google.com/p/efl-research/ the > name is equanime. Dont be to too critic with it, it only has a month > of age :) Not bad, reminds me of the first lines of DirectFB code :) >>> dm320 and mp2520f) so I can use it below other graphics systems, like >>> >> How do you manage multiple processes, e.g. each accessing one layer as I >> understood you don't support multiple processes in one layer? >> > > I haven't decided it yet, maybe as a daemon, something like a gfx > daemon, dont know yet if do it as another library on top or on the > same, but it wont be that fine grained, someone else should handle the > multiprocess per layer, ... but what i do think is that it should be > only multiprocess or only single process. A daemon or another library "on top" wouldn't be as powerful. Dumb layers one on the other doesn't make an intelligent system IMO. > About drivers, I really prefer the user level drivers, imho linux is > encouraging developers to put drivers inside the kernel, but i dont > like that approach (personal preferences), equanime is using UIO as > the API to interact with the hardware (map the registers, the memory > regions, etc). I like the idea of not being O.S dependent, so on > equanime there will be the concept of a hardware abstraction layer > (only UIO for now). You're right there :) The system modules in DirectFB allow to run the same graphics driver on Linux/FBDev or on another embedded OS. Adding a generic UIO system module for embedded graphics drivers seems like a good idea. Is it just enumeration, memory and IO mapping or also interrupt handling? >>> EFL itself. But just now i've seen the new DirectFB 2.0 ideas on the >>> wiki and also the new Water; so, what will be left on the core side? >>> where is the develop taking? the other components are going to be >>> split into libraries? >>> >> It's not clear what will be left, but at least most if not all interfaces >> will become optional modules. The core should also get smaller by doing >> further abstractions and keeping only the code for the minimal usage in >> the core, using modules for features where feasible. The core will also >> have a more public API (still not for applications) to allow integration >> where it has been difficult before. >> >> I'm also thinking about shared memory protection in Fusion2, maybe up to >> a degree where only raw pixel data is shared between processes, like an >> X server with XShm. It needs to be configurable and supported without >> too much overhead for selecting different security levels from totally >> restricted as described and all open as with 1.x. > > Interesting, im not sure if we can converge in some point, but the > ideas you have in mind is what ive been coding / following for some > time, a memory manager for user provided chunks, a shm daemon, you can The Fusion shared memory pools allow that without a daemon. You can create pools of different max sizes and all mappings are done at same virtual addresses in every process, to allow shm pointing to shm. > find interesting things on the google code project. Maybe we can I did not find much, maybe you can point me to interesting code? :) Well, the rasterizer and other stuff in Enesim seem interesting, but most of the time I just found skeletons or generic constructs for object like C. Water could use some of the code for implementing different modules/classes. > discuss more things about the khronos APIs, specially openmax / > openvg, its a must :) There's not so much special about it, mostly EGL mapping on the surface core and some public APIs. I find it much more interesting what's happening with declarative scene rendering and applications, components and services going beyond its scope... -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev