On Thu, Apr 3, 2008 at 5:09 PM, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> Jorge Luis Zapata Muga wrote:
>
> > Hi all,
> >
> > I've followed the DirectFB code for several years and also coded a
> > directfb backend for the EFL (enlightenment foundation libraries), but
> >
>
>  The public one?

Yes, i did ecore_directfb, ecore_evas_directfb, i sent an email about
that to this list ;)

>
>
>
> > 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 =)

>
>  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 :)

>
>
>
> > 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.

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).

>
>
> > 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
find interesting things on the google code project. Maybe we can
discuss more things about the khronos APIs, specially openmax /
openvg, its a must :)

Best regards,

Jorge "turran" Zapata

>
>  --
>  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