This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fw: [nanogui] Nano-X as a component of eCos? (Was: Re: [nanogui] eCos support in CVS)


Ok, it now looks like the eCos may needs some sort of standardization on the
framebuffer device.
Or, being more aggressive, standardization of multimedia devices support on
eCos?

Is it possible (or anybody already doing so?) to port the SDL to eCos as the
multimedia abstraction
layer? However the SDL licensing issue (SDL uses LGPL) may make things more
complicate..

I-Jui Sung
----- Original Message -----
From: "Bart Veer" <bartv@redhat.com>
To: <ijsung@csie.nctu.edu.tw>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Monday, April 08, 2002 7:12 PM
Subject: Re: [ECOS] Fw: [nanogui] Nano-X as a component of eCos? (Was: Re:
[nanogui] eCos support in CVS)


> >>>>> "I-Jui" == I-Jui Sung <ijsung@csie.nctu.edu.tw> writes:
>
>     I-Jui>  After some work about porting Nano-X to eCos (I've done
>     I-Jui>  some work about porting Nano-X to Linux synthetic target
>     I-Jui>  last year), I think it may be more elegant to incorporate
>     I-Jui>  the (CVS Version of ) Microwincows/Nano-X as a component
>     I-Jui>  of eCos, in some sort of eCos package since the nature of
>     I-Jui>  Nano-X is, in my opinion, closer to a library, not to an
>     I-Jui>  application.
>
>     I-Jui>  Making Nano-X an eCos component may also eliminate some
>     I-Jui>  unnecessary configuration in the Nano-X side if we adapt
>     I-Jui>  the eCos CDL mechanism to the Nano-X configuration
>     I-Jui>  mechanism (which is using makefile flags).
>
>     I-Jui>  Any comment for this idea?
>
> We are already thinking along similar lines. In fact our current
> internal repository has a microwindows tree as an eCos package, for
> experimental purposes.
>
> However doing it right involves various complications. For example,
> right now the microwindows code contains the drivers for the display,
> pointer, and keyboard. Therefore to port to a different eCos target
> requires modifying the core microwindows package, and that is not how
> eCos packages are expected to work. Instead we would want to have
> separate framebuffer device driver packages etc., with a generic
> microwindows package that can work with any framebuffer device. Rather
> like the TCP/IP stack, where porting to a new target simply involves
> writing the appropriate ethernet device driver, with no modifications
> to the stack itself.
>
> Of course people may then want to use the framebuffer device drivers
> with code other than microwindows, so the specification for such
> drivers must be generic rather than support just microwindows. That
> makes it a much more difficult problem than a one-off port of
> microwindows to a given target.
>
> I do not know when any of this work will be generally available. As
> usual there are many different demands on our time.
>
> Bart
>
>



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]