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

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

[I-Jui Sung]

 Hi,
 After some work about porting Nano-X to eCos (I've done some work about
 porting Nano-X to Linux synthetic target last year),
 I think it may be more elegant to incorporate the (CVS Version of )
 Microwincows/Nano-X as a component of eCos,
 in some sort of eCos package since the nature of Nano-X is, in my opinion,
 closer to a library, not to an application.

 Making Nano-X an eCos component may also eliminate some unnecessary
 configuration in the Nano-X side
 if we adapt the eCos CDL mechanism to the Nano-X configuration mechanism
 (which is using makefile flags).

 Any comment for this idea?

 Regards,
 I-Jui Sung
 --
 mailto: ijsung@csie.nctu.edu.tw
 Department of Computer Science & Information Enginerring,
 National Chiao-Tung University,
 Hsin-Chu, Taiwan

> ----- Original Message -----
> From: "Julian Smart" <julian.smart@btopenworld.com>
> To: "Daniel Fandrich" <DFandrich@intrinsyc.com>; <nanogui@linuxhacker.org>
> Sent: Thursday, March 21, 2002 4:28 PM
> Subject: Re: [nanogui] eCos support in CVS
>
>
> > At 09:41 20/03/2002 -0800, Daniel Fandrich wrote:
> > >Is someone actively maintaining the eCos support code? Is anyone
> interested
> > >in diffs if not?
> >
> > If you don't hear anything from the eCos team it's certainly not for
> > lack of interest -- Nano-X is part of their long term graphics strategy.
> > So I'm very sure work in this area will be appreciated (I have an
interest
> > in it too for future projects).
> >
> > Thanks!
> >
> > Julian
> > ========================================================================
> > Julian Smart              mailto:julian.smart@btopenworld.com
> > 3 Water Street            http://www.anthemion.co.uk
> > Stamford, Lincs           +44 (0)1780 765976
> > U.K. PE9 2NJ
> > ========================================================================
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: nanogui-unsubscribe@linuxhacker.org
> > For additional commands, e-mail: nanogui-help@linuxhacker.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nanogui-unsubscribe@linuxhacker.org
> For additional commands, e-mail: nanogui-help@linuxhacker.org
>
>



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

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

[Bart Veer]

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

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

[I-Jui Sung]

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