Re: [E-devel] Porting E to an ARM based embedded system.

[Carsten H. (T. R. <ra...@ra...>]

On Sat, 26 Jul 2008 20:53:36 -0300 "Gustavo Sverzut Barbieri"
<bar...@pr...> babbled:

> > as such - all you need is an xserver.. and e will work. there is no porting
> > to do that is arm-related - the code has been fixed and cleaned long ago so
> > it "just works"... once you compile it. your biggest problem is a
> > cross-compile environment for building software - you need to solve this
> > anyway - and once you do (openembedded is a good option here), things just
> > work. openembedded already has builds for enlightenment in it - as far as
> > illume goes - it's a module for e17 to make e have a ui layout/setup that
> > is much more "phone/pda/handheld device" friendly ui.
> 
> well, I think his "port" was more about getting E into ltib, the
> canonical imx31 build platform. It's something like openembedded, but
> instead of .bb they use handicapped .rpm, with no dependency in the
> .rpm, since they moved dependency tracking to kconfig (linux kernel
> config/menuconfig, like busybox did)
> 
> ProFUSION just got one imx31 board from freescale brazil, we did some
> packages but they're not finished yet.

ok - sounds cool. you both have the same hw. :) you have something to work on.

> > as vincent mentioned... openglES is an interesting idea - to date i have not
> > had any time to really look at it. i know leonardo started playing with
> > it... but didn't have any success. one day i'll get to it! :) but as such
> > most of the work is done in the gl engine - it just needs some changes to
> > adapt to GLES.
> 
> Since we got one of these boards, we may try to give gles a try. But
> really, before even trying I might talk to you to check for things to
> look, like analyzing texture size and upload bandwidth, otherwise the
> port will be useless...   BTW, on my macbook with intel 965 mobile
> expedite reports about 2x gains on the software engine compared to gl,
> and this is using newer mesa/x, so I get the shaders and all fancy
> stuff on these boards.... Evas software engine rocks hard :-)

hahahah! well... the software engine does do LOTs of optimising. like avoiding
overdraw... the gl engine doesnt try this - it's brute force. i could try and
expend more cpu cycles smartening it up to avoid exess work... but the gl
engine needs some love - maybe a gl enigne that can do both GL and GLES based
off the current one (then phase the current one out) and in this one really put
in all the smarts, dot all the i's and cross all the t's... :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...