Re: [e-users] Really don't know how to start with
On Wed, May 1, 2013 at 8:30 PM, Carsten Haitzler ras...@rasterman.comwrote: On Thu, 2 May 2013 01:35:47 +0800 hYde hyde@gmail.com said: Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the self awareness feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. actually i don't think we want a branch. we're happy to work with you and make what you need a profile. right now basically we have a full bloated profile. you want something much more stripped down. you MAY also want to use ecore, ecore_fb and ecore_evas too to save dealing with mainloops, the fb device handling, input (kbd/mouse etc.) (well this is linux kernel fbcon etc.) - but this will add more to what i quoted above, but won't double it. another few hundred kb, but now your mainloop and input infra is done too. if you don't need png then of course that saves a little bit too (and eet itself handles lossless images with alpha as well as lossy, tho eet does still need zlib and libjpeg). it's not a profile, similar to PSL1GHT it's a new platform. Platforms can selectively enable/disable stuff, as done already. i think the best thing you can do is go through some iterating of modifying configure.ac and turning off what you don't need and making it a profile, then feeding that back to us and so on - we can advise you on the next step etc. and pretty much end up with a lean result and it'll then become probably a few simple configure options and then some post-install script that maybe strips out a few extra build outputs like .la files, includes and other things you wont need at runtime. yes, except ignore it as a profile and make it a platform. EFI != WindowsXP or other stuff compile from mingw. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Hi, Digged into configure.ac I found out I could just flip the switches on / off to customized my porting, but somehow still rough, have to fine tune it in c code On Fri, May 3, 2013 at 1:01 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, May 1, 2013 at 8:30 PM, Carsten Haitzler ras...@rasterman.comwrote: On Thu, 2 May 2013 01:35:47 +0800 hYde hyde@gmail.com said: Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the self awareness feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. actually i don't think we want a branch. we're happy to work with you and make what you need a profile. right now basically we have a full bloated profile. you want something much more stripped down. you MAY also want to use ecore, ecore_fb and ecore_evas too to save dealing with mainloops, the fb device handling, input (kbd/mouse etc.) (well this is linux kernel fbcon etc.) - but this will add more to what i quoted above, but won't double it. another few hundred kb, but now your mainloop and input infra is done too. if you don't need png then of course that saves a little bit too (and eet itself handles lossless images with alpha as well as lossy, tho eet does still need zlib and libjpeg). it's not a profile, similar to PSL1GHT it's a new platform. Platforms can selectively enable/disable stuff, as done already. i think the best thing you can do is go through some iterating of modifying configure.ac and turning off what you don't need and making it a profile, then feeding that back to us and so on - we can advise you on the next step etc. and pretty much end up with a lean result and it'll then become probably a few simple configure options and then some post-install script that maybe strips out a few extra build outputs like .la files, includes and other things you wont need at runtime. yes, except ignore it as a profile and make it a platform. EFI != WindowsXP or other stuff compile from mingw. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
On Thu, 2 May 2013 14:01:20 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Wed, May 1, 2013 at 8:30 PM, Carsten Haitzler ras...@rasterman.comwrote: On Thu, 2 May 2013 01:35:47 +0800 hYde hyde@gmail.com said: Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the self awareness feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. actually i don't think we want a branch. we're happy to work with you and make what you need a profile. right now basically we have a full bloated profile. you want something much more stripped down. you MAY also want to use ecore, ecore_fb and ecore_evas too to save dealing with mainloops, the fb device handling, input (kbd/mouse etc.) (well this is linux kernel fbcon etc.) - but this will add more to what i quoted above, but won't double it. another few hundred kb, but now your mainloop and input infra is done too. if you don't need png then of course that saves a little bit too (and eet itself handles lossless images with alpha as well as lossy, tho eet does still need zlib and libjpeg). it's not a profile, similar to PSL1GHT it's a new platform. Platforms can selectively enable/disable stuff, as done already. actually it's both. its a new platform where only a small subset of features should be enabled (minimal number of loaders, etc. etc.) i think the best thing you can do is go through some iterating of modifying configure.ac and turning off what you don't need and making it a profile, then feeding that back to us and so on - we can advise you on the next step etc. and pretty much end up with a lean result and it'll then become probably a few simple configure options and then some post-install script that maybe strips out a few extra build outputs like .la files, includes and other things you wont need at runtime. yes, except ignore it as a profile and make it a platform. EFI != WindowsXP or other stuff compile from mingw. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Hello, On Tue, Apr 30, 2013 at 9:48 PM, hYde hyde@gmail.com wrote: that's why I explicitly removed Edje. Edje pulls too much, and will not aggregate that much value for the BIOS case (show menu and similar). Of course it would be nice to have a complete environment with Elementary and all, but I don't think it's doable without LOTS of effort, so stick with Evas first -- particularly pre-Eina Evas. I wouldn't recommend to go so far in the past. EFL 1.7 is the most portable version we did. A lot of effort went in to make it portable. That why exotic, evil and escape where possible with it. Sadly the merge in 1.8 has reduced that portability and it will take month before it get back to the same level. Windows build for EFL was working until a few days ago (Some header mess did bork it). So back to the subject, use 1.7, best portability ever. If you want to go up to ecore, look at what evil, escape and exotic do and do provide a limited wrapper there. Exotic should make your life easier for those kind of wrapper. In Ecore you can override the select inside it and so handle manually a wrapper of it in your own ecore_mybios that could be initialised by the right ecore_evas. Porting to a limited OS that wasn't posix, provided a framebuffer, some file I/O and a way to get event and wait for some time took me 1 month on 1.7. I do think that someone without any experience in EFL will take much more. So start building layer by layer and you need to understand the build system. Play with EFL on Linux and on Windows (I am going to fix again the windows build and I hope to soon get a bot to spank whoever break stuff again). Maybe I misunderstood about Edje, I thought that was some kind of C like meta-language layer to seperate UI and code. I'll try to use pre-Eina Evas though I still couldn't get my Win7 + MinGW right (lots of autotool error) For EFL 1.8 if you want to help on making it back as portable: https://phab.enlightenment.org/w/windows/ For EFL 1.7, https://trac.enlightenment.org/e/wiki/EFLWindowsXP . I should start writing a doc on how to port EFL to your exotic environment. I hope to push back exotic in 1.9 and have a more portable system again. If you need to strip the libraries, I'd recommend to remove the following chunks from Evas: - Gradients: it was removed in current Evas, but the pre-Eina still contained it with lots of useless code; - Textblock: if you don't need text markup or multi-line text, you can remove this and lots of code. I'l need Textblock for further usage. Building all EFL 1.7 with dependencies to the minimum and including up to Elementary will use 5MB. That is with a static build. And of course choose the minimum set of engines and options, I'm not sure the bootloader can use MMX/SSE, then you can compile out those with ./configure flags. Yes, we have SSE2, which is for security check, grab them libs to use will be okay. In UEFI environment we have events and notify, basic Bit blit function to access raw framebuffer, timers..etc. Not much like the OS but will do some good. Do you have a doc to the API you have in that state ? NOTE: which hardware are you using this? It seems like a nice hobby project I'd help on weekends, but I'd need to have a way to test :-) I use coreboot or UDK2010 ( http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UDK2010) , the later has some NT32 simulation, which can use as a basic test on host machines. But if you are talking about real platform, I almost have everything because I work in a vendor. Not familiar to all of this (toolchain, environment and I don't know how to find E17's writing guide) I have to apologize :( , so t is hard for me to catch up all the information. But my target is to port a open-sourced UI lib for BIOS to use, not only in setup menus, but also some UEFI shell applications, it will magically reduce a lot of working hour, for BIOS / Driver developers to work only on the function, not to take care the unawareness of the UI. I do still believe that the cost to go up to Ecore is not much higher than to stop at Evas and once you have Ecore, Edje and Elementary will come for free. I should really write that doc how to port EFL... -- Cedric BAIL -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:
Hi,
On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.comwrote:
On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said:
Since my BIOS has only about 8MB of space, I take Evas + Edje.
you'll need ecore, eet and eina too then. (well some of ecore).
that's why I explicitly removed Edje. Edje pulls too much, and will not
aggregate that much value for the BIOS case (show menu and similar). Of
course it would be nice to have a complete environment with Elementary and
all, but I don't think it's doable without LOTS of effort, so stick with
Evas first -- particularly pre-Eina Evas.
well you still need eina anyway. so edje adds eet and ecore (ecore, ecore-imf,
ecore-file, ecore-evas, ecore-input, ecore-evas). these ecores are fairly
small, and ecore-evas pulls in ecore-con and ecore-ipc.
there likely will be the need for ecore anyway for a mainloop etc. so i'd guess
it doesnt end up too bad, and relying on eet as a way of nicely encapsulating
data into a single file will be helpful. lossy compression for images with
alpha (that jeg doesnt do and png doesnt do) will save you space too if you use
such image data much. so in the end i am not sure it will be too bad.
elementary thought makes things a whole new level.
May I ask what is pre-merge?
efl 1.7.x ... from efl 1.8 we have a single build tree and we have upped
our
dependencies. 1.8 is not out yet.. but release is scheduled for end of may.
Yes, but I'd strongly encourage to find out the Evas version before Eina
was introduced. Then you don't need Eina, just Evas types that were built
in (saves a lib to care and some Kb in the final image).
With Evas all you need is to create an engine similar to FB, give Evas
the framebuffer (pixels) to paint and that's it. If you can configure your
FB, then it should be pretty simple to get it running. You can copy
Expedite's model, that is basically a loop:
while (1) {
event = get_event();
if (event) process_event(event);
evas_render_updates(evas);
}
from process_event() you can arrange your objects as you wish (create,
move, resize...), evas_render_updates() will take care to draw them to
output. Eventually you'd have to ask the FB to update itself, depends on
your setup.
If you need to strip the libraries, I'd recommend to remove the following
chunks from Evas:
- Gradients: it was removed in current Evas, but the pre-Eina still
contained it with lots of useless code;
- Textblock: if you don't need text markup or multi-line text, you can
remove this and lots of code.
And of course choose the minimum set of engines and options, I'm not sure
the bootloader can use MMX/SSE, then you can compile out those with
./configure flags.
NOTE: which hardware are you using this? It seems like a nice hobby project
I'd help on weekends, but I'd need to have a way to test :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
wow... Looks like I need to dig in more to study more stuff :(
Is it possible to reduce code size to about 400~700KB after all this?
On Wed, May 1, 2013 at 5:56 PM, Carsten Haitzler ras...@rasterman.comwrote:
On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:
Hi,
On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said:
Since my BIOS has only about 8MB of space, I take Evas + Edje.
you'll need ecore, eet and eina too then. (well some of ecore).
that's why I explicitly removed Edje. Edje pulls too much, and will not
aggregate that much value for the BIOS case (show menu and similar). Of
course it would be nice to have a complete environment with Elementary
and
all, but I don't think it's doable without LOTS of effort, so stick with
Evas first -- particularly pre-Eina Evas.
well you still need eina anyway. so edje adds eet and ecore (ecore,
ecore-imf,
ecore-file, ecore-evas, ecore-input, ecore-evas). these ecores are fairly
small, and ecore-evas pulls in ecore-con and ecore-ipc.
there likely will be the need for ecore anyway for a mainloop etc. so i'd
guess
it doesnt end up too bad, and relying on eet as a way of nicely
encapsulating
data into a single file will be helpful. lossy compression for images with
alpha (that jeg doesnt do and png doesnt do) will save you space too if
you use
such image data much. so in the end i am not sure it will be too bad.
elementary thought makes things a whole new level.
May I ask what is pre-merge?
efl 1.7.x ... from efl 1.8 we have a single build tree and we have
upped
our
dependencies. 1.8 is not out yet.. but release is scheduled for end of
may.
Yes, but I'd strongly encourage to find out the Evas version before Eina
was introduced. Then you don't need Eina, just Evas types that were built
in (saves a lib to care and some Kb in the final image).
With Evas all you need is to create an engine similar to FB, give Evas
the framebuffer (pixels) to paint and that's it. If you can configure
your
FB, then it should be pretty simple to get it running. You can copy
Expedite's model, that is basically a loop:
while (1) {
event = get_event();
if (event) process_event(event);
evas_render_updates(evas);
}
from process_event() you can arrange your objects as you wish (create,
move, resize...), evas_render_updates() will take care to draw them to
output. Eventually you'd have to ask the FB to update itself, depends on
your setup.
If you need to strip the libraries, I'd recommend to remove the following
chunks from Evas:
- Gradients: it was removed in current Evas, but the pre-Eina still
contained it with lots of useless code;
- Textblock: if you don't need text markup or multi-line text, you can
remove this and lots of code.
And of course choose the minimum set of engines and options, I'm not sure
the bootloader can use MMX/SSE, then you can compile out those with
./configure flags.
NOTE: which hardware are you using this? It seems like a nice hobby
project
I'd help on weekends, but I'd need to have a way to test :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
On Wed, 1 May 2013 22:59:43 +0800 hYde hyde@gmail.com said: wow... Looks like I need to dig in more to study more stuff :( Is it possible to reduce code size to about 400~700KB after all this? compressed or uncompressed? evas minus all dependencies and zero modules in current dev is 1.4m once stripped. its 570k when compressed (so assuming cramfs or so then its in your size range), but thats just evas. remember this is also with all features on/built in and -O2 with optimization. -Os may do better. so evas+eina alone come out at 744kb compressed (again assuming cramfs) (1.8m uncompressed). this happens to include buffer engine, a whole bunch of image format loaders and more. chances are u can shave off maybe 100-200k by configuring off things (maybe 100-200k compressed savings). problem is at least with current dev (and 1.8) you need to modify configure.ac - we dont have a bios profile currently. :) now if i go disable a bunch of loaders in configure.ac specifically and use -Os... and i compress things down.. including eet suport for loaders, jpeg and png loader, freetype support no fontconfig), frameubuffer enigne (and buffer engine) with small dither array, with eina, eet, evas, and eo... uncompressed its 1.6m, compressed 636kb. thats enough stuff there to do display, build a ui yourself (place text, images, rects etc.), handle input when fed in from code (and route to the right target) load png's and jpgs (assuming u provide libpng and libjpeg), render ttf text with anti-aliasing, handle all common/sane bit depths (from monochrome up to 24bpp), lots of other fun rendering stuff (smooth interpolated scaling), scene graph, text layout and formatting with markup and unicode (no RTL support though), and being able to pack data resources into single eet files for access via key values. you will need in addition libc/libm/libdl/libpthread, zlib (png needs this anyway), freetype. thats actually about it. you dont need much more. so we can get down to about 640kb plus some external deps. remove png and jpeg loader.. if u want to rely on eet entirely and u can save maybe 20k compressed. i am sure we could do there things to trim more, but not a hell of a lot. so is 640k compressed (out of 8mb) worth using for a pretty complete display/rendering subsystem including high level text formatting, image decoding rendering, event routing etc? if i include the deps (freetype, libjpeg and libpng - i am skipping zlib, libc etc. as i assume these will be there no matter what you use for display), your entire footprint (compressed) is 1.1M for everything you need to display. input is still your problem. :) as it creating widgets and doing layout. you dont need full blown widgets for a bios i imagine... i'd say 1.1m of 8mb is a perfectly adequate footprint. you can probably get the rest (kernel, libc base etc) down to about 3m, so as such u'll probably have about 4.. maybe 5m for the core os and what not. that leaves u with 3m for the bios app and data files (jpg's, png's etc.). am i far off the mark here? btw your project is rather fascinating. :) On Wed, May 1, 2013 at 5:56 PM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: Hi, On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said: Since my BIOS has only about 8MB of space, I take Evas + Edje. you'll need ecore, eet and eina too then. (well some of ecore). that's why I explicitly removed Edje. Edje pulls too much, and will not aggregate that much value for the BIOS case (show menu and similar). Of course it would be nice to have a complete environment with Elementary and all, but I don't think it's doable without LOTS of effort, so stick with Evas first -- particularly pre-Eina Evas. well you still need eina anyway. so edje adds eet and ecore (ecore, ecore-imf, ecore-file, ecore-evas, ecore-input, ecore-evas). these ecores are fairly small, and ecore-evas pulls in ecore-con and ecore-ipc. there likely will be the need for ecore anyway for a mainloop etc. so i'd guess it doesnt end up too bad, and relying on eet as a way of nicely encapsulating data into a single file will be helpful. lossy compression for images with alpha (that jeg doesnt do and png doesnt do) will save you space too if you use such image data much. so in the end i am not sure it will be too bad. elementary thought makes things a whole new level. May I ask what is pre-merge? efl 1.7.x ... from efl 1.8 we have a single build tree and we have upped our dependencies. 1.8 is not out yet.. but release is scheduled for end of may. Yes, but I'd strongly encourage to find out the Evas version before Eina was introduced. Then you don't need Eina, just Evas types that were built in
Re: [e-users] Really don't know how to start with
On 01/05/2013 18:00, Carsten Haitzler (The Rasterman) wrote: On Wed, 1 May 2013 22:59:43 +0800 hYde hyde@gmail.com said: wow... Looks like I need to dig in more to study more stuff :( Is it possible to reduce code size to about 400~700KB after all this? [snip awesome technical stuff] btw your project is rather fascinating. :) I'll say :-) Horribly OT of course but that was my first thought too - a decent looking boot environment driven by EFL? How cool is that! -- Alan McKinnon alan.mckin...@gmail.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the self awareness feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. Hope I don't get many issue in office so I could get this work as soon as possible, thank you all. On Thu, May 2, 2013 at 12:00 AM, Carsten Haitzler ras...@rasterman.comwrote: On Wed, 1 May 2013 22:59:43 +0800 hYde hyde@gmail.com said: wow... Looks like I need to dig in more to study more stuff :( Is it possible to reduce code size to about 400~700KB after all this? compressed or uncompressed? evas minus all dependencies and zero modules in current dev is 1.4m once stripped. its 570k when compressed (so assuming cramfs or so then its in your size range), but thats just evas. remember this is also with all features on/built in and -O2 with optimization. -Os may do better. so evas+eina alone come out at 744kb compressed (again assuming cramfs) (1.8m uncompressed). this happens to include buffer engine, a whole bunch of image format loaders and more. chances are u can shave off maybe 100-200k by configuring off things (maybe 100-200k compressed savings). problem is at least with current dev (and 1.8) you need to modify configure.ac - we dont have a bios profile currently. :) now if i go disable a bunch of loaders in configure.ac specifically and use -Os... and i compress things down.. including eet suport for loaders, jpeg and png loader, freetype support no fontconfig), frameubuffer enigne (and buffer engine) with small dither array, with eina, eet, evas, and eo... uncompressed its 1.6m, compressed 636kb. thats enough stuff there to do display, build a ui yourself (place text, images, rects etc.), handle input when fed in from code (and route to the right target) load png's and jpgs (assuming u provide libpng and libjpeg), render ttf text with anti-aliasing, handle all common/sane bit depths (from monochrome up to 24bpp), lots of other fun rendering stuff (smooth interpolated scaling), scene graph, text layout and formatting with markup and unicode (no RTL support though), and being able to pack data resources into single eet files for access via key values. you will need in addition libc/libm/libdl/libpthread, zlib (png needs this anyway), freetype. thats actually about it. you dont need much more. so we can get down to about 640kb plus some external deps. remove png and jpeg loader.. if u want to rely on eet entirely and u can save maybe 20k compressed. i am sure we could do there things to trim more, but not a hell of a lot. so is 640k compressed (out of 8mb) worth using for a pretty complete display/rendering subsystem including high level text formatting, image decoding rendering, event routing etc? if i include the deps (freetype, libjpeg and libpng - i am skipping zlib, libc etc. as i assume these will be there no matter what you use for display), your entire footprint (compressed) is 1.1M for everything you need to display. input is still your problem. :) as it creating widgets and doing layout. you dont need full blown widgets for a bios i imagine... i'd say 1.1m of 8mb is a perfectly adequate footprint. you can probably get the rest (kernel, libc base etc) down to about 3m, so as such u'll probably have about 4.. maybe 5m for the core os and what not. that leaves u with 3m for the bios app and data files (jpg's, png's etc.). am i far off the mark here? btw your project is rather fascinating. :) On Wed, May 1, 2013 at 5:56 PM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: Hi, On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said: Since my BIOS has only about 8MB of space, I take Evas + Edje. you'll need ecore, eet and eina too then. (well some of ecore). that's why I explicitly removed Edje. Edje
Re: [e-users] Really don't know how to start with
On Wed, May 1, 2013 at 2:35 PM, hYde hyde@gmail.com wrote: Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the self awareness feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. Hope I don't get many issue in office so I could get this work as soon as possible, thank you all. sure! once you're fine with that we can help you to get it into upstream-able form, like a new platform efi that can setup the set of loaders/engines for the user. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
On Thu, 2 May 2013 01:35:47 +0800 hYde hyde@gmail.com said: Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the self awareness feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. actually i don't think we want a branch. we're happy to work with you and make what you need a profile. right now basically we have a full bloated profile. you want something much more stripped down. you MAY also want to use ecore, ecore_fb and ecore_evas too to save dealing with mainloops, the fb device handling, input (kbd/mouse etc.) (well this is linux kernel fbcon etc.) - but this will add more to what i quoted above, but won't double it. another few hundred kb, but now your mainloop and input infra is done too. if you don't need png then of course that saves a little bit too (and eet itself handles lossless images with alpha as well as lossy, tho eet does still need zlib and libjpeg). i think the best thing you can do is go through some iterating of modifying configure.ac and turning off what you don't need and making it a profile, then feeding that back to us and so on - we can advise you on the next step etc. and pretty much end up with a lean result and it'll then become probably a few simple configure options and then some post-install script that maybe strips out a few extra build outputs like .la files, includes and other things you wont need at runtime. Hope I don't get many issue in office so I could get this work as soon as possible, thank you all. On Thu, May 2, 2013 at 12:00 AM, Carsten Haitzler ras...@rasterman.comwrote: On Wed, 1 May 2013 22:59:43 +0800 hYde hyde@gmail.com said: wow... Looks like I need to dig in more to study more stuff :( Is it possible to reduce code size to about 400~700KB after all this? compressed or uncompressed? evas minus all dependencies and zero modules in current dev is 1.4m once stripped. its 570k when compressed (so assuming cramfs or so then its in your size range), but thats just evas. remember this is also with all features on/built in and -O2 with optimization. -Os may do better. so evas+eina alone come out at 744kb compressed (again assuming cramfs) (1.8m uncompressed). this happens to include buffer engine, a whole bunch of image format loaders and more. chances are u can shave off maybe 100-200k by configuring off things (maybe 100-200k compressed savings). problem is at least with current dev (and 1.8) you need to modify configure.ac - we dont have a bios profile currently. :) now if i go disable a bunch of loaders in configure.ac specifically and use -Os... and i compress things down.. including eet suport for loaders, jpeg and png loader, freetype support no fontconfig), frameubuffer enigne (and buffer engine) with small dither array, with eina, eet, evas, and eo... uncompressed its 1.6m, compressed 636kb. thats enough stuff there to do display, build a ui yourself (place text, images, rects etc.), handle input when fed in from code (and route to the right target) load png's and jpgs (assuming u provide libpng and libjpeg), render ttf text with anti-aliasing, handle all common/sane bit depths (from monochrome up to 24bpp), lots of other fun rendering stuff (smooth interpolated scaling), scene graph, text layout and formatting with markup and unicode (no RTL support though), and being able to pack data resources into single eet files for access via key values. you will need in addition libc/libm/libdl/libpthread, zlib (png needs this anyway), freetype. thats actually about it. you dont need much more. so we can get down to about 640kb plus some external deps. remove png and jpeg loader.. if u want to rely on eet entirely and u can save maybe 20k compressed. i am sure we could do there things to trim more, but not a hell of a lot. so is 640k compressed (out of 8mb) worth using for a pretty complete display/rendering subsystem including high level text formatting, image
Re: [e-users] Really don't know how to start with
Since my BIOS has only about 8MB of space, I take Evas + Edje. May I ask what is pre-merge? And what really confuses me is I'm not porting it on any OS, just an environment with framebuffer support, so any OS based config would not work on my base, still working on stripping the code and figure out why MinGW always fails on me.. Hi, this is quite of a hard task and I'd request you to evaluate the requirements before digging much. How does coreboot behaves? How much space do you have? Having it to compile should be the simplest task, but then you need to implement the OS layers EFL expects in Ecore: main loop (timers, file descriptors, ...), I/O (wayland, fb, x11)... Unless coreboot already emulates a real OS, you'll have lots of work to do, maybe base yourself on PSL1GHT work (PS3 native port). Also, EFL takes around 5mb by default, if you don't have that memory (flash, RAM) you'll have extra work to strip it. My take on this is: get Evas (pre-merge) and port only it, integrate it directly in coreboot. Base your UI in Expedite, as it looks okay using just Evas, no other EFL. If you need to strip down, consider using Evas before Eina, then you do not rely on other EFL. Yes, you'll end with a fork, but your project just need a simple way to show graphics on screen, the extra features of EFL are likely unneeded and will do more harm than good. Regards, -- Gustavo On Mon, Apr 29, 2013 at 6:55 PM, hYde hyde@gmail.com wrote: Hi all: I've been thinking porting elementary into my open source BIOS loader (coreboot), to beautify my BIOS setup menu, but I don't know how to start with. Because the BIOS loader are C code, build with Microsoft Visual C++ compiler, the first step I'm trying to do is to make elementary out of the box of MinGW, which is very hard. So I tried to build them with MinGW on my working machine (Windows 7) first, to observe the makefile and result, and to make a doable solution for MSVC10, but after following the instructions https://phab.enlightenment.org/w/windows/#windows-64-bits I keep failing on the autoconf section with errors like : configure: error: cannot find install-sh, install.sh, or shtool in . ./.. . /../.. make: *** [builddir/efl] Error 1 I'm a real newbie to linux toolchains, stucked here for about two weeks... please help me with some tutorials, I'm really hitting the wall, thanks. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said: Since my BIOS has only about 8MB of space, I take Evas + Edje. you'll need ecore, eet and eina too then. (well some of ecore). May I ask what is pre-merge? efl 1.7.x ... from efl 1.8 we have a single build tree and we have upped our dependencies. 1.8 is not out yet.. but release is scheduled for end of may. And what really confuses me is I'm not porting it on any OS, just an environment with framebuffer support, so any OS based config would not work on my base, still working on stripping the code and figure out why MinGW always fails on me.. Hi, this is quite of a hard task and I'd request you to evaluate the requirements before digging much. How does coreboot behaves? How much space do you have? Having it to compile should be the simplest task, but then you need to implement the OS layers EFL expects in Ecore: main loop (timers, file descriptors, ...), I/O (wayland, fb, x11)... Unless coreboot already emulates a real OS, you'll have lots of work to do, maybe base yourself on PSL1GHT work (PS3 native port). Also, EFL takes around 5mb by default, if you don't have that memory (flash, RAM) you'll have extra work to strip it. My take on this is: get Evas (pre-merge) and port only it, integrate it directly in coreboot. Base your UI in Expedite, as it looks okay using just Evas, no other EFL. If you need to strip down, consider using Evas before Eina, then you do not rely on other EFL. Yes, you'll end with a fork, but your project just need a simple way to show graphics on screen, the extra features of EFL are likely unneeded and will do more harm than good. Regards, -- Gustavo On Mon, Apr 29, 2013 at 6:55 PM, hYde hyde@gmail.com wrote: Hi all: I've been thinking porting elementary into my open source BIOS loader (coreboot), to beautify my BIOS setup menu, but I don't know how to start with. Because the BIOS loader are C code, build with Microsoft Visual C++ compiler, the first step I'm trying to do is to make elementary out of the box of MinGW, which is very hard. So I tried to build them with MinGW on my working machine (Windows 7) first, to observe the makefile and result, and to make a doable solution for MSVC10, but after following the instructions https://phab.enlightenment.org/w/windows/#windows-64-bits I keep failing on the autoconf section with errors like : configure: error: cannot find install-sh, install.sh, or shtool in . ./.. . /../.. make: *** [builddir/efl] Error 1 I'm a real newbie to linux toolchains, stucked here for about two weeks... please help me with some tutorials, I'm really hitting the wall, thanks. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Hi,
On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.comwrote:
On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said:
Since my BIOS has only about 8MB of space, I take Evas + Edje.
you'll need ecore, eet and eina too then. (well some of ecore).
that's why I explicitly removed Edje. Edje pulls too much, and will not
aggregate that much value for the BIOS case (show menu and similar). Of
course it would be nice to have a complete environment with Elementary and
all, but I don't think it's doable without LOTS of effort, so stick with
Evas first -- particularly pre-Eina Evas.
May I ask what is pre-merge?
efl 1.7.x ... from efl 1.8 we have a single build tree and we have upped
our
dependencies. 1.8 is not out yet.. but release is scheduled for end of may.
Yes, but I'd strongly encourage to find out the Evas version before Eina
was introduced. Then you don't need Eina, just Evas types that were built
in (saves a lib to care and some Kb in the final image).
With Evas all you need is to create an engine similar to FB, give Evas
the framebuffer (pixels) to paint and that's it. If you can configure your
FB, then it should be pretty simple to get it running. You can copy
Expedite's model, that is basically a loop:
while (1) {
event = get_event();
if (event) process_event(event);
evas_render_updates(evas);
}
from process_event() you can arrange your objects as you wish (create,
move, resize...), evas_render_updates() will take care to draw them to
output. Eventually you'd have to ask the FB to update itself, depends on
your setup.
If you need to strip the libraries, I'd recommend to remove the following
chunks from Evas:
- Gradients: it was removed in current Evas, but the pre-Eina still
contained it with lots of useless code;
- Textblock: if you don't need text markup or multi-line text, you can
remove this and lots of code.
And of course choose the minimum set of engines and options, I'm not sure
the bootloader can use MMX/SSE, then you can compile out those with
./configure flags.
NOTE: which hardware are you using this? It seems like a nice hobby project
I'd help on weekends, but I'd need to have a way to test :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Hi,
that's why I explicitly removed Edje. Edje pulls too much, and will not
aggregate that much value for the BIOS case (show menu and similar). Of
course it would be nice to have a complete environment with Elementary and
all, but I don't think it's doable without LOTS of effort, so stick with
Evas first -- particularly pre-Eina Evas.
Maybe I misunderstood about Edje, I thought that was some kind of C like
meta-language layer to seperate UI and code. I'll try to use pre-Eina Evas
though I still couldn't get my Win7 + MinGW right (lots of autotool error)
If you need to strip the libraries, I'd recommend to remove the following
chunks from Evas:
- Gradients: it was removed in current Evas, but the pre-Eina still
contained it with lots of useless code;
- Textblock: if you don't need text markup or multi-line text, you can
remove this and lots of code.
I'l need Textblock for further usage.
And of course choose the minimum set of engines and options, I'm not sure
the bootloader can use MMX/SSE, then you can compile out those with
./configure flags.
Yes, we have SSE2, which is for security check, grab them libs to use will
be okay.
In UEFI environment we have events and notify, basic Bit blit function to
access raw framebuffer, timers..etc. Not much like the OS but will do some
good.
NOTE: which hardware are you using this? It seems like a nice hobby
project I'd help on weekends, but I'd need to have a way to test :-)
I use coreboot or UDK2010 (
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UDK2010) ,
the later has some NT32 simulation, which can use as a basic test on host
machines.
But if you are talking about real platform, I almost have everything
because I work in a vendor.
Not familiar to all of this (toolchain, environment and I don't know how to
find E17's writing guide) I have to apologize :( , so t is hard for me to
catch up all the information. But my target is to port a open-sourced UI
lib for BIOS to use, not only in setup menus, but also some UEFI shell
applications, it will magically reduce a lot of working hour, for BIOS /
Driver developers to work only on the function, not to take care the
unawareness of the UI.
On Tue, Apr 30, 2013 at 8:31 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
Hi,
On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler ras...@rasterman.comwrote:
On Tue, 30 Apr 2013 18:03:21 +0800 hYde hyde@gmail.com said:
Since my BIOS has only about 8MB of space, I take Evas + Edje.
you'll need ecore, eet and eina too then. (well some of ecore).
that's why I explicitly removed Edje. Edje pulls too much, and will not
aggregate that much value for the BIOS case (show menu and similar). Of
course it would be nice to have a complete environment with Elementary and
all, but I don't think it's doable without LOTS of effort, so stick with
Evas first -- particularly pre-Eina Evas.
May I ask what is pre-merge?
efl 1.7.x ... from efl 1.8 we have a single build tree and we have upped
our
dependencies. 1.8 is not out yet.. but release is scheduled for end of
may.
Yes, but I'd strongly encourage to find out the Evas version before Eina
was introduced. Then you don't need Eina, just Evas types that were built
in (saves a lib to care and some Kb in the final image).
With Evas all you need is to create an engine similar to FB, give Evas
the framebuffer (pixels) to paint and that's it. If you can configure your
FB, then it should be pretty simple to get it running. You can copy
Expedite's model, that is basically a loop:
while (1) {
event = get_event();
if (event) process_event(event);
evas_render_updates(evas);
}
from process_event() you can arrange your objects as you wish (create,
move, resize...), evas_render_updates() will take care to draw them to
output. Eventually you'd have to ask the FB to update itself, depends on
your setup.
If you need to strip the libraries, I'd recommend to remove the following
chunks from Evas:
- Gradients: it was removed in current Evas, but the pre-Eina still
contained it with lots of useless code;
- Textblock: if you don't need text markup or multi-line text, you can
remove this and lots of code.
And of course choose the minimum set of engines and options, I'm not sure
the bootloader can use MMX/SSE, then you can compile out those with
./configure flags.
NOTE: which hardware are you using this? It seems like a nice hobby
project I'd help on weekends, but I'd need to have a way to test :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for
Re: [e-users] Really don't know how to start with
Hi Hyde, thanks for clarifying, comments below: On Tue, Apr 30, 2013 at 9:48 AM, hYde hyde@gmail.com wrote: Hi, that's why I explicitly removed Edje. Edje pulls too much, and will not aggregate that much value for the BIOS case (show menu and similar). Of course it would be nice to have a complete environment with Elementary and all, but I don't think it's doable without LOTS of effort, so stick with Evas first -- particularly pre-Eina Evas. Maybe I misunderstood about Edje, I thought that was some kind of C like meta-language layer to seperate UI and code. Indeed it is, and would be awesome if you could use it. However, being higher level, it depend on lots of other EFL, as Raster named Ecore (main loop, timers...), Evas (canvas), Eina (data types), Eet (binary file chunk reading lib, similar to zip). Of course you can port them, as was done for PSL1GHT (PS3 native engine), but it's more work. Maybe you can try this as a second step/milestone. I'll try to use pre-Eina Evas though I still couldn't get my Win7 + MinGW right (lots of autotool error) Did you look into Vincent's wiki page: https://trac.enlightenment.org/e/wiki/EFLWindowsXP He was the last one to care about such setup, and I basically removed most of the support in the current merged tree (the EFL git repo) as we could not get too broad interest from developers to guarantee it would work. Before some guys were doing some work to get it running now and then, it was not constant. If you need to strip the libraries, I'd recommend to remove the following chunks from Evas: - Gradients: it was removed in current Evas, but the pre-Eina still contained it with lots of useless code; - Textblock: if you don't need text markup or multi-line text, you can remove this and lots of code. I'l need Textblock for further usage. Ok. Just note that using Textblock from plain Evas is a PITA, I'd recommend getting to it via Edje, but then you need the other libraries as said before. And of course choose the minimum set of engines and options, I'm not sure the bootloader can use MMX/SSE, then you can compile out those with ./configure flags. Yes, we have SSE2, which is for security check, grab them libs to use will be okay. In UEFI environment we have events and notify, basic Bit blit function to access raw framebuffer, timers..etc. Not much like the OS but will do some good. That's basically what we need. You don't need to port everything, just what you need to make it work. For instance timers and framebuffer access should be enough, as well as file (fopen) if you need Edje/Eet. Edje may use Eio that in turn uses inotify on Linux, but you can leave that as empty stubs or just do not compile. Nowadays Evas also is starting to depend on Threads, thus it's good to plan such feature in the future. NOTE: which hardware are you using this? It seems like a nice hobby project I'd help on weekends, but I'd need to have a way to test :-) I use coreboot or UDK2010 ( http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UDK2010) , the later has some NT32 simulation, which can use as a basic test on host machines. But if you are talking about real platform, I almost have everything because I work in a vendor. Ah, vendor :-D Not familiar to all of this (toolchain, environment and I don't know how to find E17's writing guide) I have to apologize :( , so t is hard for me to catch up all the information. But my target is to port a open-sourced UI lib for BIOS to use, not only in setup menus, but also some UEFI shell applications, it will magically reduce a lot of working hour, for BIOS / Driver developers to work only on the function, not to take care the unawareness of the UI. Indeed, if you can get to Edje, Elementary is quite close... and with it all the associated high level tools. I'd still recommend to try Evas by itself before going further, but if your plan is to create an SDK, it's better to continue with upstream EFL on the long run. Regards, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Hi, I've read and followed every page which described how to build enlightenment using MinGW + Windows, MinGW / AutoConf / Pkg-config are all up-and-ready but it still refuses to work, still finding the answer why :( I will listen to you, start it all over just stick to evas, and make it work, second target is to port to the same toolchain where the BIOS codebase is using. Thanks. On Tue, Apr 30, 2013 at 10:37 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hi Hyde, thanks for clarifying, comments below: On Tue, Apr 30, 2013 at 9:48 AM, hYde hyde@gmail.com wrote: Hi, that's why I explicitly removed Edje. Edje pulls too much, and will not aggregate that much value for the BIOS case (show menu and similar). Of course it would be nice to have a complete environment with Elementary and all, but I don't think it's doable without LOTS of effort, so stick with Evas first -- particularly pre-Eina Evas. Maybe I misunderstood about Edje, I thought that was some kind of C like meta-language layer to seperate UI and code. Indeed it is, and would be awesome if you could use it. However, being higher level, it depend on lots of other EFL, as Raster named Ecore (main loop, timers...), Evas (canvas), Eina (data types), Eet (binary file chunk reading lib, similar to zip). Of course you can port them, as was done for PSL1GHT (PS3 native engine), but it's more work. Maybe you can try this as a second step/milestone. I'll try to use pre-Eina Evas though I still couldn't get my Win7 + MinGW right (lots of autotool error) Did you look into Vincent's wiki page: https://trac.enlightenment.org/e/wiki/EFLWindowsXP He was the last one to care about such setup, and I basically removed most of the support in the current merged tree (the EFL git repo) as we could not get too broad interest from developers to guarantee it would work. Before some guys were doing some work to get it running now and then, it was not constant. If you need to strip the libraries, I'd recommend to remove the following chunks from Evas: - Gradients: it was removed in current Evas, but the pre-Eina still contained it with lots of useless code; - Textblock: if you don't need text markup or multi-line text, you can remove this and lots of code. I'l need Textblock for further usage. Ok. Just note that using Textblock from plain Evas is a PITA, I'd recommend getting to it via Edje, but then you need the other libraries as said before. And of course choose the minimum set of engines and options, I'm not sure the bootloader can use MMX/SSE, then you can compile out those with ./configure flags. Yes, we have SSE2, which is for security check, grab them libs to use will be okay. In UEFI environment we have events and notify, basic Bit blit function to access raw framebuffer, timers..etc. Not much like the OS but will do some good. That's basically what we need. You don't need to port everything, just what you need to make it work. For instance timers and framebuffer access should be enough, as well as file (fopen) if you need Edje/Eet. Edje may use Eio that in turn uses inotify on Linux, but you can leave that as empty stubs or just do not compile. Nowadays Evas also is starting to depend on Threads, thus it's good to plan such feature in the future. NOTE: which hardware are you using this? It seems like a nice hobby project I'd help on weekends, but I'd need to have a way to test :-) I use coreboot or UDK2010 ( http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UDK2010) , the later has some NT32 simulation, which can use as a basic test on host machines. But if you are talking about real platform, I almost have everything because I work in a vendor. Ah, vendor :-D Not familiar to all of this (toolchain, environment and I don't know how to find E17's writing guide) I have to apologize :( , so t is hard for me to catch up all the information. But my target is to port a open-sourced UI lib for BIOS to use, not only in setup menus, but also some UEFI shell applications, it will magically reduce a lot of working hour, for BIOS / Driver developers to work only on the function, not to take care the unawareness of the UI. Indeed, if you can get to Edje, Elementary is quite close... and with it all the associated high level tools. I'd still recommend to try Evas by itself before going further, but if your plan is to create an SDK, it's better to continue with upstream EFL on the long run. Regards, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for
Re: [e-users] Really don't know how to start with
Hi, this is quite of a hard task and I'd request you to evaluate the requirements before digging much. How does coreboot behaves? How much space do you have? Having it to compile should be the simplest task, but then you need to implement the OS layers EFL expects in Ecore: main loop (timers, file descriptors, ...), I/O (wayland, fb, x11)... Unless coreboot already emulates a real OS, you'll have lots of work to do, maybe base yourself on PSL1GHT work (PS3 native port). Also, EFL takes around 5mb by default, if you don't have that memory (flash, RAM) you'll have extra work to strip it. My take on this is: get Evas (pre-merge) and port only it, integrate it directly in coreboot. Base your UI in Expedite, as it looks okay using just Evas, no other EFL. If you need to strip down, consider using Evas before Eina, then you do not rely on other EFL. Yes, you'll end with a fork, but your project just need a simple way to show graphics on screen, the extra features of EFL are likely unneeded and will do more harm than good. Regards, -- Gustavo On Mon, Apr 29, 2013 at 7:55 AM, hYde hyde@gmail.com wrote: Hi all: I've been thinking porting elementary into my open source BIOS loader (coreboot), to beautify my BIOS setup menu, but I don't know how to start with. Because the BIOS loader are C code, build with Microsoft Visual C++ compiler, the first step I'm trying to do is to make elementary out of the box of MinGW, which is very hard. So I tried to build them with MinGW on my working machine (Windows 7) first, to observe the makefile and result, and to make a doable solution for MSVC10, but after following the instructions https://phab.enlightenment.org/w/windows/#windows-64-bits I keep failing on the autoconf section with errors like : configure: error: cannot find install-sh, install.sh, or shtool in . ./.. . /../.. make: *** [builddir/efl] Error 1 I'm a real newbie to linux toolchains, stucked here for about two weeks... please help me with some tutorials, I'm really hitting the wall, thanks. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
