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

Reply via email to