Re: [E-devel] Porting E to an ARM based embedded system.
Gustavo wrote: On Sat, Jul 26, 2008 at 9:08 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Sat, Jul 26, 2008 at 10:10 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Wed, 23 Jul 2008 17:27:35 -0300 imx31cpu . [EMAIL PROTECTED] babbled: Hi, I am new to the enlightment world and I will soon (tomorrow) start trying to port it to an embedded system (Freescale i.MX31 PDK - http://www.freescale.com/imx31pdk). Since I am not an experient developer on the linux environment I will probably have a hard time doing that so I would like to know if any of you have already tryed to do this porting or if you have any suggestion that might help me to have enlightment running on this system. in fact.. you have to do almost no work... get openembedded up and working. openmoko uses it 0 for am arm based phone. mamona uses it for a fully open build for the nokia n8xx (arm based).. etc. etc. 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. 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 :-) A bit off-topic, but bear with me :) Well the i965 driver is actually quite shitty atm. They are working more on render acceleration then 3D acceleration at this point from what I've seen. I just tested expedite on my NVIDIA 6600gt and it pretty much creamed the software engine in almost every test. The only ones that the software really pulled out ahead where some of the simpler blending tests near the end. Text rendering was even much faster which is something that I've never seen till I tested on this card. So there may still be hope for the GL engine :) I know, but I just want to alert people that being HW or GL is not always good or better than sw implementation, some hardware is crappy, some lack good texture upload bandwidth, some have very small texture size and some, like i965, supposed to be great, are just bad and even having all those things are still slower than sw implementation. This is as subjective and convoluted a topic at times as licensing issues. In time, it's possible that the current differences between 'hw' vs 'sw' will be less clear, and similarly that 'gpu' vs 'cpu' will also be less obvious. Who knows.. especially when one can consider different kinds of architectures with lots of processors and could conceivably direct some towards given tasks. Few models are solid enough that they can represent some other. It could be that really good, open, ubiquitous xrender or gl drivers will emerge and make the software engine less attractive, and it could be that multiple cpu architectures could better utilize the software engine for most 2D gui needs. Either way, there's no reason why all of those engine backends shouldn't be replaced or improved -- again, given enough resources. Spend time in gorgeous Hong Kong. Click now for great vacation packages! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mnn2ZYmy1L4kxytfffYe9kQNeEEfUfSOicYHknqZoD94jyk/ - This SF.Net email is sponsored by the Moblin Your Move Developer's
[E-devel] Nightly build log for E17 on 2008-07-30 07:10:23 -0700
Build log for Enlightenment DR 0.17 on 2008-07-30 07:10:23 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, skel, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [RFC] EET signature support
Hi guys,
So here is a little patch that signature support to eet. It append
at the end of a classic eet file a signature and the public x509
certificate in der format. This change doesn't break file
compatibility as the signature is automatically detected based on the
file content against it's size. But this means, that eet_open first
make an attempt to load the file structure (directory and dictionnary)
before checking the signature. It use openssl library and the test
provided in eet_suite.c work well with openssl version 0.9.8e.
Before I start adding crypto support every where in eet, plese
review this patch and give me your feedback. Have fun !
--
Cedric BAIL
diff --git a/configure.in b/configure.in
index ebf301e..e2eba51 100644
--- a/configure.in
+++ b/configure.in
@@ -117,6 +117,22 @@ int main (int argc, char **argv) {
], AC_MSG_WARN([Cannot check when cross-compiling -- assuming null is okay])
)
+dnl Disable support for old eet file format.
+old_eet_file_format=yes
+AC_ARG_ENABLE(old-eet-file-format,
+ AC_HELP_STRING(
+[--disable-old-eet-file-format],
+[disable old eet file format support. [[default=enabled]]]
+ ),
+ [ old_eet_file_format=$enableval ]
+)
+AM_CONDITIONAL(EET_OLD_EET_FILE_FORMAT, test x$old_eet_file_format = xyes)
+if test x$old_eet_file_format = xyes; then
+ AC_DEFINE(EET_OLD_EET_FILE_FORMAT, 1, [support old eet file format])
+else
+ AC_DEFINE(EET_OLD_EET_FILE_FORMAT, 0, [support old eet file format])
+fi
+
dnl Unit Tests
AC_ARG_ENABLE(tests,
@@ -143,6 +159,54 @@ fi
AM_CONDITIONAL(EET_ENABLE_TESTS, test x${enable_tests} = xyes)
+dnl Openssl support
+want_openssl=auto
+have_openssl=no
+AC_ARG_ENABLE(openssl,
+ [AC_HELP_STRING([--disable-openssl], [disable openssl eet support])],
+ [ want_openssl=$enableval ]
+)
+if test x$want_openssl = xyes -o x$want_openssl = xauto; then
+ PKG_CHECK_MODULES(OPENSSL, openssl,
+[
+ have_openssl=yes
+ AC_DEFINE(HAVE_OPENSSL, 1, [Have Openssl support])
+],
+[
+ if test x$use_strict = xyes; then
+AC_MSG_ERROR([Openssl not found (strict dependencies checking)])
+ fi
+])
+fi
+
+dnl Crypto option
+want_cypher=yes
+have_cypher=yes
+want_signature=yes
+have_signature=yes
+
+AC_MSG_CHECKING(whether to activate cypher support in eet)
+AC_ARG_ENABLE(cypher,
+ [AC_HELP_STRING([--disable-cypher], [disable cypher support for eet API])],
+ [ want_cypher=$enableval ]
+)
+if test x$have_openssl = xyes -a x$want_cypher = xyes; then
+ have_cypher=yes
+ AC_DEFINE(HAVE_CYPHER, 1, [Have cypher support built in eet])
+fi
+AC_MSG_RESULT($have_cypher)
+
+AC_MSG_CHECKING(whether to activate signature support in eet)
+AC_ARG_ENABLE(signature,
+ [AC_HELP_STRING([--disable-signature], [disable signature file support for eet])],
+ [ want_signature=$enableval ]
+)
+if test x$have_signature = xyes -a x$want_signature = xyes; then
+ have_signature=yes
+ AC_DEFINE(HAVE_SIGNATURE, 1, [Have signature support for eet file])
+fi
+AC_MSG_RESULT($have_signature)
+
dnl Coverage
AC_ARG_ENABLE(coverage,
@@ -241,6 +305,12 @@ echo
echo
echo Configuration Options Summary:
echo
+echo Openssl..: ${have_openssl}
+echo Cypher support.: ${have_cypher}
+echo Signature..: ${have_signature}
+
+echo Old eet file format..: ${old_eet_file_format}
+echo
echo Tests: ${enable_tests}
echo Coverage.: ${enable_coverage}
echo
diff --git a/src/lib/Eet.h b/src/lib/Eet.h
index dc7a383..35ad69b 100644
--- a/src/lib/Eet.h
+++ b/src/lib/Eet.h
@@ -86,12 +86,19 @@ extern C {
EET_ERROR_WRITE_ERROR_FILE_TOO_BIG,
EET_ERROR_WRITE_ERROR_IO_ERROR,
EET_ERROR_WRITE_ERROR_OUT_OF_SPACE,
- EET_ERROR_WRITE_ERROR_FILE_CLOSED
+ EET_ERROR_WRITE_ERROR_FILE_CLOSED,
+ EET_ERROR_MMAP_FAILED,
+ EET_ERROR_X509_ENCODING_FAILED,
+ EET_ERROR_SIGNATURE_FAILED,
+ EET_ERROR_INVALID_SIGNATURE,
+ EET_ERROR_NOT_SIGNED,
+ EET_ERROR_NOT_IMPLEMENTED
} Eet_Error;
typedef struct _Eet_File Eet_File;
typedef struct _Eet_DictionaryEet_Dictionary;
typedef struct _Eet_Data_Descriptor Eet_Data_Descriptor;
+ typedef struct _Eet_Key Eet_Key;
typedef struct _Eet_Data_Descriptor_Class Eet_Data_Descriptor_Class;
@@ -237,6 +244,39 @@ extern C {
*/
EAPI Eet_Error eet_close(Eet_File *ef);
+ /**
+* Create an Eet_Key needed for signing an eet file.
+*
+* The certificate should provide the public that match the private key.
+* No verification is done to ensure that.
+*
+* @since 2.0.0
+*/
+ EAPI Eet_Key* eet_identity_open(const char *certificate_file, const char *private_key_file);
+
+/**
+ * Close and release all ressource used by an Eet_Key.
+ * An reference counter prevent it from being freed until all file using it are
+ * also closed.
+ *
+ * @since 2.0.0
+ */
+ EAPI void
Re: [E-devel] E CVS: proto/eina doursse
Should we now use eina instead of evas_data and ecore_data in EFL projects ? Why ? Have you benchmarks ? Unit Tests :P ? In case of ecore_file for example, functions return Ecore_List. Do you plan to move gradually to eina ? I think that's a good plan to unify lists and hashs in EFL :) Regards, Nico 2008/7/30 Enlightenment CVS [EMAIL PROTECTED] Enlightenment CVS committal Author : doursse Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: Makefile.am configure.in Log Message: add unit test and coverage support in configure.in and Makefile.am. Now let's encourage Cedric for writing the unit tests :) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina doursse
On Wed, Jul 30, 2008 at 5:04 PM, Nicolas Aguirre [EMAIL PROTECTED] wrote: Should we now use eina instead of evas_data and ecore_data in EFL projects ? Why ? Have you benchmarks ? Unit Tests :P ? You are too quick :) We need to work a little bit more before switching. But that's the plan. In case of ecore_file for example, functions return Ecore_List. Do you plan to move gradually to eina ? When we believe that eina is ready for prime time, we will move it too libs and then start moving all library away from Evas_Data and Ecore_Data. We are no there yet, so first code I think that's a good plan to unify lists and hashs in EFL :) Yep that's the plan, and now that's eina is in cvs, any one can review it, and help us improve it. 2008/7/30 Enlightenment CVS [EMAIL PROTECTED] Enlightenment CVS committal Author : doursse Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: Makefile.am configure.in Log Message: add unit test and coverage support in configure.in and Makefile.am. Now let's encourage Cedric for writing the unit tests :) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina doursse
One 'alarming' question. Does the name mean anything? Why not pick a simple and descriptive name, that most people will understand (like edata, or something a bit more shocking and provokative, without a leading 'e') On Wed, 2008-07-30 at 17:04 +0200, Nicolas Aguirre wrote: Should we now use eina instead of evas_data and ecore_data in EFL projects ? Why ? Have you benchmarks ? Unit Tests :P ? In case of ecore_file for example, functions return Ecore_List. Do you plan to move gradually to eina ? I think that's a good plan to unify lists and hashs in EFL :) Regards, Nico 2008/7/30 Enlightenment CVS [EMAIL PROTECTED] Enlightenment CVS committal Author : doursse Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: Makefile.am configure.in Log Message: add unit test and coverage support in configure.in and Makefile.am. Now let's encourage Cedric for writing the unit tests :) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
On 30/07/2008, Jose Gonzalez [EMAIL PROTECTED] wrote: Vincent wrote: Quoting Nathan Ingersoll [EMAIL PROTECTED]: One idea I discussed with Vincent today is that our lack of releases has caused many users to lose interest and stop taking notice of the project. I realize that there is a lot of talk surrounding changes to core infrastructure (data lib, graphics, scripting language, etc), but has there been any thought recently put into how our release process should be structured? There used to be a TODO list for e17, and that has been moved to Trac, but has anyone took a hard look at what is necessary for cutting a stable release? Even if we don't release e17 1.0, we may be able to move the core libs towards releases like eet. Some ideas I and others have: 1) We must release the core libs (evas, ecore, embryo, edje, efreet and e_dbus, that is what is needed by e17). So we must discuss to what must be done for each of them before a release. Here what I think. You can add other things I have forgotten. * embryo: is in a very good shape. raster wanted to release it later because he wants to look at lua for scripting. I think that it is a very bad idea, and should be delayed for the next version. What may lack is documentation. * evas: also in a very good shape, but several things wanted to be done: api changes in polygons, gradient and data types (see below). Documentation must be improved too. Although polygons can be done in a rather short amount of time, gradient stuff can take a long time and maybe can be done (with other things like vgfx) in the next evas major release. Note that Nathan and me agreed on the fact that, today, we should have an evas 3.*, and not 0.9... * ecore: Cedric wants to reorganize some stuff in ecore_evas. Also data types. See next point * evas and ecore: data types. The problem is that it will break abi if we change the data types. See below for a solution * edje: except the problem of data types, I don't see any major flaw. * efreet and e_dbus: I don't know much about them. They are used with e17 without problem. Cedric told me that he wanted to speed up efreet. There is the problem of data types, though. The problem with data types is that it will break ABI and API. So we must decide if we release with or without the change in data types. A solution is to release with number version 0.10 (current version number is 0.9.9) without data type changes and warns that there will be big changes for 1.0. 2) A release manager must be named. What he should do: * decide which library may be released because of a certain amount of important bugs have been fixed. Of course, this should be discussed in the ML for example. * sent mails to warn about pre-releases (in that period, only bug fixes and doc changes are allowed. Maybe other things i can't think of.) and releases * of course, provide the tar balls for pre-releases and releases * maybe add news on some sites like osnews, /., freshmeat or phoronix Even if there are 0.10 releases before a 1.0, the fact that we announce such release is a good thing. As an example, Kim is doing e16 releases periodically. Each time one is done, a user announce that on osnews. And i often read in those news that people are happy to see that e16 is still maintained. Comments, ideas ? Vincent It's good to see such attempts and I hope they continue. I'd also like to applaud Carsten for taking the high-road, and I hope that E can become a more inclusive project able to honestly embrace differences, attract developers, and work with others. As to the above mentioned steps.. I disagree with some of the arguments, but they are also not unreasonable - so long as everyone realizes that the state of many things in E is still rather basic and are willing to 'break' apis on major releases when they bring good improvements.. E is still small enough that it can be fluid if it wants to. But, one very important thing to consider here is: What exactly is it that E wants to achieve? What are the basic 'large' goals? Thats a funny one, because a lot of people say Oh, E17 isnt as good as Gnome... or KDE when its not completely a desktop environmant like those 2. It has a lot of the mechanics of a full DE and being so modular, could fill the things needed to become a full DE from that point. (And then you ask, whats the difference between what E17 is now and a full DE?!? I dont know. Ask wikipedia or something.) If it was competeing souly against WMs like fluxbox and friends, then thats already done and kicking ass. If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply
