[E-devel] [PATCH] e17: add thinkpad to temperature module
This adds thinkpad support to the temperature module. The temperature is accessible through the thinkpad_acpi kernel module. Signed-off-by: Lars Munch --- src/modules/temperature/e_mod_main_private.h |3 ++- src/modules/temperature/tempget.c|9 + 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/src/modules/temperature/e_mod_main_private.h b/src/modules/temperature/e_mod_main_private.h index 626b9bd..7159292 100644 --- a/src/modules/temperature/e_mod_main_private.h +++ b/src/modules/temperature/e_mod_main_private.h @@ -11,7 +11,8 @@ typedef enum _Sensor_Type SENSOR_TYPE_LINUX_ACPI, SENSOR_TYPE_LINUX_PCI, SENSOR_TYPE_LINUX_PBOOK, - SENSOR_TYPE_LINUX_INTELCORETEMP + SENSOR_TYPE_LINUX_INTELCORETEMP, + SENSOR_TYPE_LINUX_THINKPAD } Sensor_Type; #endif diff --git a/src/modules/temperature/tempget.c b/src/modules/temperature/tempget.c index b98b6ab..99495a3 100644 --- a/src/modules/temperature/tempget.c +++ b/src/modules/temperature/tempget.c @@ -125,6 +125,11 @@ init(void) sensor_type = SENSOR_TYPE_LINUX_INTELCORETEMP; sensor_name = strdup("dummy"); } + else if (ecore_file_exists("/sys/devices/platform/thinkpad_hwmon/temp1_input")) + { + sensor_type = SENSOR_TYPE_LINUX_THINKPAD; + sensor_name = strdup("dummy"); + } else { // try the i2c bus @@ -217,6 +222,9 @@ init(void) case SENSOR_TYPE_LINUX_INTELCORETEMP: sensor_path = strdup("/sys/devices/platform/coretemp.0/temp1_input"); break; + case SENSOR_TYPE_LINUX_THINKPAD: +sensor_path = strdup("/sys/devices/platform/thinkpad_hwmon/temp1_input"); +break; case SENSOR_TYPE_LINUX_I2C: therms = ecore_file_ls("/sys/bus/i2c/devices"); @@ -330,6 +338,7 @@ check(void) break; case SENSOR_TYPE_LINUX_INTELCORETEMP: case SENSOR_TYPE_LINUX_I2C: + case SENSOR_TYPE_LINUX_THINKPAD: f = fopen(sensor_path, "r"); if (f) { -- 1.7.2.3 -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] ecore: fix tslib touchscreen detection
Applied. Thanks. On Tue, Sep 22, 2009 at 08:20:25AM +0200, Marc Andre Tanner wrote: > Hi, > > I am trying to compile just the minimum requirements for elementary > with framebuffer support. > > During this I found some problems in ecore's tslib detection code. > > The following patches should fix them. > > [ Note: I am in no way an expert - and don't want to become one - > in configure and autohell teritory. The patches were > created by looking around for similar constructs in the > rest of the code. I hope they are ok, at least they seem > to work for me. ] > > Marc > > -- > Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 > > > -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] eina patch for cygwin-1.7
On Thu, Jun 18, 2009 at 11:35:29PM +0900, booleanla...@gmail.com wrote: > Hi, lipens...@email.cz > > >> +AC_DEFINE_UNQUOTED(SHARED_LIB_SUFFIX, "$shrext_cmds", [Suffix for > shared objects]) > >> #define MODULE_EXTENSION SHARED_LIB_SUFFIX > > Sorry, I had completely forgotten it (better solution in your previous > post). > Sorry, I did not see that post. Vincent is currently checking if this is the best approach to set the module extension. Regards Lars Munch -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] eina patch for cygwin-1.7
On Wed, Jun 17, 2009 at 06:11:43PM +0200, Vincent Torri wrote: > > > On Thu, 18 Jun 2009, booleanla...@gmail.com wrote: > > > Hi, E-devel > > > > > > Sorry, my previous eina patch (for cygwin-1.7) was incomplete. > > what ? cygwin does not define _WIN32 No, since Cygwin is a unix emulation environment you have to explicetely compile with -mwin32 if you want _WIN32 defined and you don't want that unless you really have to. So the patch is good. In svn, thanks. Lars Munch -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL on framebuffer VNC support
On Tue, Jun 16, 2009 at 03:53:15PM +0200, Daniele Venzano wrote: > Hello, > In the coming months I'm going to start a new project for my company based on > evas + ecore (no widget library). It will use the Linux framebuffer driver > and > run on an ARM embedded system. > For various reasons we will have to offer the possibility to remote the > display > through the net via the VNC protocol. > > In the past we had hacked microwindows/nano-X with libvncserver to add said > support. I'm willing to do something similar again, if it has not already > been > done, and share back the patch for an eventual inclusion in mainstream. > > So, did someone already thought or wrote some code about VNC support ? > If not, how would you go about it ? The library basically needs a copy in > memory of the framebuffer. Then every area that is modified needs to be > passed > to the library. There are pointer and keyboard events coming in from the > other > side that should be passed as if they where generated locally. > Probably ecore should be modified, but before starting to dig inside ecore > and > evas sources I prefer to ask to people with better understanding of EFL. > > Thank you. > > (Sorry if you receive this mail twice, my wrong) I am using a modified version of http://fbvncserver.sourceforge.net/ on my arm system running in framebuffer. It is useable, but slow. Writing an real vnc engine for evas *will* make it much faster as you dont have to monitor the whole framebuffer for changes. I am unsure on how you can render to a vnc engine *and* the fb engine (or some other backend) at the same time. You still want to be able to use the framebuffer while device it's being remoted, right? Regards Lars Munch -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Evas module move to Eina module API
On Wed, Jun 10, 2009 at 02:06:52PM +0200, Cedric BAIL wrote: > On Tue, Jun 9, 2009 at 11:29 PM, Lars Munch wrote: > > On Mon, Jun 08, 2009 at 02:52:20PM +0200, Cedric BAIL wrote: > >> Hi, > >> > >> Attached is a patch that move all evas module to eina module. The > >> move introduce one new feature, the possibility to build module inside > >> libevas directly leading the way to an all in one binary for an efl > >> application. > > > > This is indeed a very nice feature (which also makes it possible to port > > efl to ecos and rtems :-) but static linking efl can be a little tricky > > license wise, given that some libraries (e.g EINA) are LGPL without any > > exceptions. Sorry for being slightly off topic and maybe even beating a > > dead horse, but have the authors of EINA and other LGPL based libraries > > in efl considered adding a static linking exceptions to the LGPL > > license, like FLTK, mini-xml and many other LGPL based libraries has? > > > > The wording could be something like: > > > > "Static linking of applications to the XYZ library does not constitute a > > derivative work and does not require the author to provide source code > > for the application, use the shared XYZ libraries, or link their > > applications against a user-supplied version of library XYZ." > > I would like to state that this is only relevant for system without > dynamic linking and it make sense in my opinion. So what do people > think of : > > "Static linking of applications to eina library does not constitute a > derivative work on system that does not provide dynamic linking and > does not require the author to provide source code for the > application, use the shared eina libraries or link their applications > against a user-supplied version of library eina". Just curious: why don't you want to allow static linking on systems that supports dynamic linking? I can see many uses of a static all-in-one binary on for example linux. An example could be a static linked exquisite used in an initrd. > This change to the licence could also be added to elementary. > > > (not sure if inline functions, macros and templates needs to be covered > > as well in the above, but you get my point) > > They are already covered by the LGPL and doesn't make an application > using a LGPL library GPL. > > > Anyway, please consider the above suggestion as this new feature opens > > up for porting efl to some interesting and "more embedded" operating > > systems and adding this exception will IMHO not violate the spirit of > > the LGPL. > > If this change sounds good to every one on this ML, I will contact all > 12 authors of eina and check with them if they agree on this change. Thanks a lot for doing that :-) Lars Munch -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Evas module move to Eina module API
On Mon, Jun 08, 2009 at 02:52:20PM +0200, Cedric BAIL wrote: > Hi, > > Attached is a patch that move all evas module to eina module. The > move introduce one new feature, the possibility to build module inside > libevas directly leading the way to an all in one binary for an efl > application. This is indeed a very nice feature (which also makes it possible to port efl to ecos and rtems :-) but static linking efl can be a little tricky license wise, given that some libraries (e.g EINA) are LGPL without any exceptions. Sorry for being slightly off topic and maybe even beating a dead horse, but have the authors of EINA and other LGPL based libraries in efl considered adding a static linking exceptions to the LGPL license, like FLTK, mini-xml and many other LGPL based libraries has? The wording could be something like: "Static linking of applications to the XYZ library does not constitute a derivative work and does not require the author to provide source code for the application, use the shared XYZ libraries, or link their applications against a user-supplied version of library XYZ." (not sure if inline functions, macros and templates needs to be covered as well in the above, but you get my point) Anyway, please consider the above suggestion as this new feature opens up for porting efl to some interesting and "more embedded" operating systems and adding this exception will IMHO not violate the spirit of the LGPL. Best regards Lars Munch -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] ecore_evas_fb.c fix input
Hi Should someone please apply this patch before the monday snapshot? Thanks Lars Munch On Fri, Mar 27, 2009 at 04:28:16PM +0100, Lars Munch wrote: > > This patch fixes a bug in ecore_evas_fb.c introduced by the big eina > list conversion. The bug resulted in no input devices where added when > using framebuffer. This patch also cleans up some related NULL > checks that are not needed any more. > > Signed-off-by: Lars Munch > --- > src/lib/ecore_evas/ecore_evas_fb.c | 75 +++ > 1 files changed, 32 insertions(+), 43 deletions(-) > > diff --git a/src/lib/ecore_evas/ecore_evas_fb.c > b/src/lib/ecore_evas/ecore_evas_fb.c > index 074f2ed..39c4af4 100644 > --- a/src/lib/ecore_evas/ecore_evas_fb.c > +++ b/src/lib/ecore_evas/ecore_evas_fb.c > @@ -87,11 +87,9 @@ _ecore_evas_fb_lose(void *data __UNUSED__) > ee = (Ecore_Evas *)l; > ee->visible = 0; > } > - if (ecore_evas_input_devices) > - { > - EINA_LIST_FOREACH(ecore_evas_input_devices, ll, dev) > - ecore_fb_input_device_listen(dev, 0); > - } > + > + EINA_LIST_FOREACH(ecore_evas_input_devices, ll, dev) > + ecore_fb_input_device_listen(dev, 0); > } > > static void > @@ -112,11 +110,9 @@ _ecore_evas_fb_gain(void *data __UNUSED__) > else > evas_damage_rectangle_add(ee->evas, 0, 0, ee->w, ee->h); > } > - if (ecore_evas_input_devices) > - { > - EINA_LIST_FOREACH(ecore_evas_input_devices, ll, dev) > - ecore_fb_input_device_listen(dev, 1); > - } > + > + EINA_LIST_FOREACH(ecore_evas_input_devices, ll, dev) > + ecore_fb_input_device_listen(dev, 1); > } > > static int > @@ -289,38 +285,35 @@ _ecore_evas_fb_init(int w, int h) > > caps = ecore_fb_input_device_cap_get(device); > > - if (ecore_evas_input_devices) > - { > - /* Mouse */ > + /* Mouse */ > #ifdef HAVE_TSLIB > - if (caps & ECORE_FB_INPUT_DEVICE_CAP_RELATIVE) > + if (caps & ECORE_FB_INPUT_DEVICE_CAP_RELATIVE) > #else > - if ((caps & ECORE_FB_INPUT_DEVICE_CAP_RELATIVE) || (caps & > ECORE_FB_INPUT_DEVICE_CAP_ABSOLUTE)) > + if ((caps & ECORE_FB_INPUT_DEVICE_CAP_RELATIVE) || (caps & > ECORE_FB_INPUT_DEVICE_CAP_ABSOLUTE)) > #endif > + { > + ecore_fb_input_device_axis_size_set(device, w, h); > + ecore_fb_input_device_listen(device,1); > + ecore_evas_input_devices = > eina_list_append(ecore_evas_input_devices, device); > + if (!mouse_handled) > { > - ecore_fb_input_device_axis_size_set(device, w, h); > - ecore_fb_input_device_listen(device,1); > - ecore_evas_input_devices = > eina_list_append(ecore_evas_input_devices, device); > - if (!mouse_handled) > - { > -ecore_evas_event_handlers[2] = > ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_BUTTON_DOWN, > _ecore_evas_event_mouse_button_down, NULL); > -ecore_evas_event_handlers[3] = > ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_BUTTON_UP, > _ecore_evas_event_mouse_button_up, NULL); > -ecore_evas_event_handlers[4] = > ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_MOVE, > _ecore_evas_event_mouse_move, NULL); > -ecore_evas_event_handlers[5] = > ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_WHEEL, > _ecore_evas_event_mouse_wheel, NULL); > -mouse_handled = 1; > - } > + ecore_evas_event_handlers[2] = > ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_BUTTON_DOWN, > _ecore_evas_event_mouse_button_down, NULL); > + ecore_evas_event_handlers[3] = > ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_BUTTON_UP, > _ecore_evas_event_mouse_button_up, NULL); > + ecore_evas_event_handlers[4] = > ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_MOVE, > _ecore_evas_event_mouse_move, NULL); > + ecore_evas_event_handlers[5] = > ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_WHEEL, > _ecore_evas_event_mouse_wheel, NULL); > + mouse_handled = 1; > } > - /* Keyboard */ > - else if ((caps & ECORE_FB_INPUT_DEVICE_CAP_KEYS_OR_BUTTONS) && > !(caps & ECORE_FB_INPUT_DEVICE_CAP_ABSOLUTE)) > + } > + /* Keyboard */ > + else if ((caps & ECORE_FB_INPUT_DEVICE_CAP_KEYS_OR_BUTTONS) && !(caps & > ECORE_FB_INPUT_DEVICE_CAP_ABSOLUTE)) > + { > + ecore_fb_input_device_listen(device,1); > + ecore_evas_input_devices =
Re: [E-devel] [PATH] add build theme option in configure.in
On Sun, Mar 22, 2009 at 03:07:20PM +1100, Carsten Haitzler wrote: > On Sat, 21 Mar 2009 13:11:46 +0100 Nicolas Aguirre > said: > > > Hi, > > This patch add an option in configure to enable/disable theme build. It's > > usefull when you cross compile elementary and your host doesn't have > > edje_cc. (it's the case in GeexBox toolchain) > > Default behaviour build the theme. > > as gustavo said - > export EDJE_CC=path/to/edje_cc > or > ./configure --with-edje-cc=/path/to/edje_cc > > as such... elementary wont work without its default theme - unless you have a > complete replacement for it that is 100% complete - it's a good idea not to > disable it or the build - changes in elm's code will also be accompanied by > changes in default theme - so by doing what you do.. you are setting yourself > up for pain and bugs (when as such there aren't any as you simply removed > parts > of changes done). :) i don't think what you are doing is a good idea, so i am > not sure the patch is a good idea either. :) I tried to cross build today using --with-edje-cc=/opt/e17/bin/edje_cc option, but I got some very strange errors from edje_cc: /opt/e17/bin/edje_cc: Wrote 858 bytes ( 1Kb) for "collections/51" collection entry /opt/e17/bin/edje_cc: Wrote 860 bytes ( 1Kb) for "collections/52" collection entry /opt/e17/bin/edje_cc: Wrote 862 bytes ( 1Kb) for "collections/53" collection entry /opt/e17/bin/edje_cc: Wrote 1195 bytes ( 1Kb) for "collections/54" collection entry /opt/e17/bin/edje_cc: Wrote 1136 bytes ( 1Kb) for "collections/55" collection entry /opt/e17/bin/edje_cc: Wrote 1201 bytes ( 1Kb) for "collections/56" collection entry /opt/e17/bin/edje_cc: Wrote 1133 bytes ( 1Kb) for "collections/57" collection entry /opt/e17/bin/edje_cc: Wrote 2085 bytes ( 2Kb) for "collections/58" collection entry /opt/e17/bin/edje_cc: Wrote 2101 bytes ( 2Kb) for "collections/59" collection entry /opt/e17/bin/edje_cc: Wrote 1372 bytes ( 1Kb) for "collections/60" collection entry /opt/e17/bin/edje_cc: Wrote 1321 bytes ( 1Kb) for "collections/61" collection entry /opt/e17/bin/edje_cc: Wrote 1512 bytes ( 1Kb) for "collections/62" collection entry /opt/e17/bin/edje_cc: Wrote 1460 bytes ( 1Kb) for "collections/63" collection entry /opt/e17/bin/edje_cc: Wrote 1076 bytes ( 1Kb) for "collections/64" collection entry /opt/e17/bin/edje_cc: Wrote 1058 bytes ( 1Kb) for "collections/65" collection entry /opt/e17/bin/edje_cc: Wrote 1087 bytes ( 1Kb) for "collections/66" collection entry /opt/e17/share/edje/include/edje.inc(190) : error 070: rational number support was not enabled /tmp/edje_cc.sma-tmp-og6F98(336) : error 070: rational number support was not enabled /tmp/edje_cc.sma-tmp-og6F98(337) : error 070: rational number support was not enabled /tmp/edje_cc.sma-tmp-og6F98(406) : error 070: rational number support was not enabled 4 Errors. /opt/e17/bin/edje_cc: Error. Compiling script code not clean. make[2]: *** [default.edj] Error 255 I tried setting the PATH and EMBRYO_PREFIX, but nothing worked. Any idea why this happens? Thanks Lars Munch -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] ecore_evas_fb.c fix input
This patch fixes a bug in ecore_evas_fb.c introduced by the big eina list conversion. The bug resulted in no input devices where added when using framebuffer. This patch also cleans up some related NULL checks that are not needed any more. Signed-off-by: Lars Munch --- src/lib/ecore_evas/ecore_evas_fb.c | 75 +++ 1 files changed, 32 insertions(+), 43 deletions(-) diff --git a/src/lib/ecore_evas/ecore_evas_fb.c b/src/lib/ecore_evas/ecore_evas_fb.c index 074f2ed..39c4af4 100644 --- a/src/lib/ecore_evas/ecore_evas_fb.c +++ b/src/lib/ecore_evas/ecore_evas_fb.c @@ -87,11 +87,9 @@ _ecore_evas_fb_lose(void *data __UNUSED__) ee = (Ecore_Evas *)l; ee->visible = 0; } - if (ecore_evas_input_devices) - { - EINA_LIST_FOREACH(ecore_evas_input_devices, ll, dev) - ecore_fb_input_device_listen(dev, 0); - } + + EINA_LIST_FOREACH(ecore_evas_input_devices, ll, dev) + ecore_fb_input_device_listen(dev, 0); } static void @@ -112,11 +110,9 @@ _ecore_evas_fb_gain(void *data __UNUSED__) else evas_damage_rectangle_add(ee->evas, 0, 0, ee->w, ee->h); } - if (ecore_evas_input_devices) - { - EINA_LIST_FOREACH(ecore_evas_input_devices, ll, dev) - ecore_fb_input_device_listen(dev, 1); - } + + EINA_LIST_FOREACH(ecore_evas_input_devices, ll, dev) + ecore_fb_input_device_listen(dev, 1); } static int @@ -289,38 +285,35 @@ _ecore_evas_fb_init(int w, int h) caps = ecore_fb_input_device_cap_get(device); - if (ecore_evas_input_devices) - { -/* Mouse */ + /* Mouse */ #ifdef HAVE_TSLIB -if (caps & ECORE_FB_INPUT_DEVICE_CAP_RELATIVE) + if (caps & ECORE_FB_INPUT_DEVICE_CAP_RELATIVE) #else -if ((caps & ECORE_FB_INPUT_DEVICE_CAP_RELATIVE) || (caps & ECORE_FB_INPUT_DEVICE_CAP_ABSOLUTE)) + if ((caps & ECORE_FB_INPUT_DEVICE_CAP_RELATIVE) || (caps & ECORE_FB_INPUT_DEVICE_CAP_ABSOLUTE)) #endif + { +ecore_fb_input_device_axis_size_set(device, w, h); +ecore_fb_input_device_listen(device,1); +ecore_evas_input_devices = eina_list_append(ecore_evas_input_devices, device); +if (!mouse_handled) { - ecore_fb_input_device_axis_size_set(device, w, h); - ecore_fb_input_device_listen(device,1); - ecore_evas_input_devices = eina_list_append(ecore_evas_input_devices, device); - if (!mouse_handled) - { - ecore_evas_event_handlers[2] = ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_BUTTON_DOWN, _ecore_evas_event_mouse_button_down, NULL); - ecore_evas_event_handlers[3] = ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_BUTTON_UP, _ecore_evas_event_mouse_button_up, NULL); - ecore_evas_event_handlers[4] = ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_MOVE, _ecore_evas_event_mouse_move, NULL); - ecore_evas_event_handlers[5] = ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_WHEEL, _ecore_evas_event_mouse_wheel, NULL); - mouse_handled = 1; - } + ecore_evas_event_handlers[2] = ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_BUTTON_DOWN, _ecore_evas_event_mouse_button_down, NULL); + ecore_evas_event_handlers[3] = ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_BUTTON_UP, _ecore_evas_event_mouse_button_up, NULL); + ecore_evas_event_handlers[4] = ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_MOVE, _ecore_evas_event_mouse_move, NULL); + ecore_evas_event_handlers[5] = ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_WHEEL, _ecore_evas_event_mouse_wheel, NULL); + mouse_handled = 1; } -/* Keyboard */ -else if ((caps & ECORE_FB_INPUT_DEVICE_CAP_KEYS_OR_BUTTONS) && !(caps & ECORE_FB_INPUT_DEVICE_CAP_ABSOLUTE)) + } + /* Keyboard */ + else if ((caps & ECORE_FB_INPUT_DEVICE_CAP_KEYS_OR_BUTTONS) && !(caps & ECORE_FB_INPUT_DEVICE_CAP_ABSOLUTE)) + { +ecore_fb_input_device_listen(device,1); +ecore_evas_input_devices = eina_list_append(ecore_evas_input_devices, device); +if (!keyboard_handled) { - ecore_fb_input_device_listen(device,1); - ecore_evas_input_devices = eina_list_append(ecore_evas_input_devices, device); - if (!keyboard_handled) - { - ecore_evas_event_handlers[0] = ecore_event_handler_add(ECORE_FB_EVENT_KEY_DOWN, _ecore_evas_event_key_down, NULL); - ecore_evas_event_handlers[1] = ecore_event_handler_add(ECORE_FB_EVENT_KEY_UP, _ecore_e
Re: [E-devel] [PATCH] ecore pipe add close functions
On Wed, Mar 25, 2009 at 09:08:53AM +0100, Peter Wehrfritz wrote: > Lars Munch schrieb: > >Hi > > > >This patch adds two new functions, ecore_pipe_close_read and > >ecore_pipe_close_write, to ecore_pipe. The purpose it to enable > >ecore_pipe to be used together with fork (see example below). > > > >The patch also handles if the read or write end of the pipe closes. > > > > I think the names don't fit in to the efl-naming schema, very well. That > means that the verb is at the end of the function name, here this would > be "close". So ecore_pipe_write_close, or ecore_pipe_write_end_close > would be better. Yes, you are right. Updated patch below. This patch adds two new functions, ecore_pipe_read_close and ecore_pipe_write_close, to ecore_pipe. The purpose it to enable ecore_pipe to be used together with fork. The patch also handles if the read or write end of the pipe closes. Signed-off-by: Lars Munch --- src/lib/ecore/Ecore.h |4 +- src/lib/ecore/ecore_pipe.c | 101 +++- 2 files changed, 93 insertions(+), 12 deletions(-) diff --git a/src/lib/ecore/Ecore.h b/src/lib/ecore/Ecore.h index 0a1969d..b001ded 100644 --- a/src/lib/ecore/Ecore.h +++ b/src/lib/ecore/Ecore.h @@ -290,10 +290,12 @@ extern "C" { EAPI Ecore_Pipe *ecore_pipe_add(void (*handler) (void *data, void *buffer, unsigned int nbyte), const void *data); EAPI void*ecore_pipe_del(Ecore_Pipe *p); EAPI int ecore_pipe_write(Ecore_Pipe *p, const void *buffer, unsigned int nbytes); + EAPI void ecore_pipe_write_close(Ecore_Pipe *p); + EAPI void ecore_pipe_read_close(Ecore_Pipe *p); EAPI double ecore_time_get(void); EAPI double ecore_loop_time_get(void); - + EAPI Ecore_Timer *ecore_timer_add(double in, int (*func) (void *data), const void *data); EAPI Ecore_Timer *ecore_timer_loop_add(double in, int (*func) (void *data), const void *data); EAPI void*ecore_timer_del(Ecore_Timer *timer); diff --git a/src/lib/ecore/ecore_pipe.c b/src/lib/ecore/ecore_pipe.c index f6e4778..84fded0 100644 --- a/src/lib/ecore/ecore_pipe.c +++ b/src/lib/ecore/ecore_pipe.c @@ -332,20 +332,68 @@ ecore_pipe_del(Ecore_Pipe *p) "ecore_pipe_del"); return NULL; } - ecore_main_fd_handler_del(p->fd_handler); - close(p->fd_read); - close(p->fd_write); + if(p->fd_handler != NULL) + ecore_main_fd_handler_del(p->fd_handler); + if(p->fd_read != -1) + close(p->fd_read); + if(p->fd_write != -1) + close(p->fd_write); data = (void *)p->data; free (p); return data; } /** + * Close the read end of an Ecore_Pipe object created with ecore_pipe_add(). + * + * @param p The Ecore_Pipe object. + * @ingroup Ecore_Pipe_Group + */ +EAPI void +ecore_pipe_read_close(Ecore_Pipe *p) +{ + void *data; + + if (!ECORE_MAGIC_CHECK(p, ECORE_MAGIC_PIPE)) + { + ECORE_MAGIC_FAIL(p, ECORE_MAGIC_PIPE, + "ecore_pipe_close_read"); + return; + } + ecore_main_fd_handler_del(p->fd_handler); + p->fd_handler = NULL; + close(p->fd_read); + p->fd_read = -1; +} + +/** + * Close the write end of an Ecore_Pipe object created with ecore_pipe_add(). + * + * @param p The Ecore_Pipe object. + * @ingroup Ecore_Pipe_Group + */ +EAPI void +ecore_pipe_write_close(Ecore_Pipe *p) +{ + void *data; + + if (!ECORE_MAGIC_CHECK(p, ECORE_MAGIC_PIPE)) + { + ECORE_MAGIC_FAIL(p, ECORE_MAGIC_PIPE, + "ecore_pipe_close_write"); + return; + } + close(p->fd_write); + p->fd_write = -1; +} + +/** * Write on the file descriptor the data passed as parameter. * * @param p The Ecore_Pipe object. * @param buffer The data to write into the pipe. * @param nbytes The size of the @p buffer in bytes + * @return Returns TRUE on a successful write, FALSE on an error * @ingroup Ecore_Pipe_Group */ EAPI int @@ -359,9 +407,13 @@ ecore_pipe_write(Ecore_Pipe *p, const void *buffer, unsigned int nbytes) { ECORE_MAGIC_FAIL(p, ECORE_MAGIC_PIPE, "ecore_pipe_write"); - return 0; + return FALSE; } - /* first write the len into the pipe */ + + if(p->fd_write == -1) + return FALSE; + + /* First write the len into the pipe */ do { ret = pipe_write(p->fd_write, &nbytes, sizeof(nbytes)); @@ -375,7 +427,13 @@ ecore_pipe_write(Ecore_Pipe *p, const void *buffer, unsigned int nbytes) /* XXX What should we do here? */ fprintf(stderr, "The length of the data was not written complete" " to the pipe\n"); -return 0; +return FALSE; + } + else if (ret == -1 && errno == EPIPE) + { +close
[E-devel] [PATCH] ecore pipe add close functions
Hi This patch adds two new functions, ecore_pipe_close_read and ecore_pipe_close_write, to ecore_pipe. The purpose it to enable ecore_pipe to be used together with fork (see example below). The patch also handles if the read or write end of the pipe closes. /* Test example gcc -Wall `pkg-config --libs --cflags ecore` tstpipe.c -o tstpipe */ void handler(void *data, void *buffer, unsigned int nbyte) { char *s; fprintf(stderr, "length %d\n", nbyte); if(nbyte > 0 || buffer != NULL) { s = strndup((char*) buffer, nbyte); fprintf(stderr, "%s\n", s); free(s); } else ecore_main_loop_quit(); } int main(int argc, char *argv[]) { Ecore_Pipe *p; pid_t cpid; ecore_init(); p = ecore_pipe_add(handler, NULL); cpid = fork(); if (cpid == -1) { perror("fork"); exit(EXIT_FAILURE); } if (cpid == 0) { int i; /* Child */ ecore_pipe_close_read(p); for(i=0; i<4; i++) { if(!ecore_pipe_write(p, "0123456789", 10)) exit(EXIT_SUCCESS); sleep(1); } exit(EXIT_SUCCESS); } else { /* Parent */ ecore_pipe_close_write(p); ecore_main_loop_begin(); exit(EXIT_SUCCESS); } ecore_shutdown(); } Signed-off-by: Lars Munch --- src/lib/ecore/Ecore.h |4 +- src/lib/ecore/ecore_pipe.c | 101 +++- 2 files changed, 93 insertions(+), 12 deletions(-) diff --git a/src/lib/ecore/Ecore.h b/src/lib/ecore/Ecore.h index 0a1969d..0277852 100644 --- a/src/lib/ecore/Ecore.h +++ b/src/lib/ecore/Ecore.h @@ -290,10 +290,12 @@ extern "C" { EAPI Ecore_Pipe *ecore_pipe_add(void (*handler) (void *data, void *buffer, unsigned int nbyte), const void *data); EAPI void*ecore_pipe_del(Ecore_Pipe *p); EAPI int ecore_pipe_write(Ecore_Pipe *p, const void *buffer, unsigned int nbytes); + EAPI void ecore_pipe_close_write(Ecore_Pipe *p); + EAPI void ecore_pipe_close_read(Ecore_Pipe *p); EAPI double ecore_time_get(void); EAPI double ecore_loop_time_get(void); - + EAPI Ecore_Timer *ecore_timer_add(double in, int (*func) (void *data), const void *data); EAPI Ecore_Timer *ecore_timer_loop_add(double in, int (*func) (void *data), const void *data); EAPI void*ecore_timer_del(Ecore_Timer *timer); diff --git a/src/lib/ecore/ecore_pipe.c b/src/lib/ecore/ecore_pipe.c index f6e4778..5608eda 100644 --- a/src/lib/ecore/ecore_pipe.c +++ b/src/lib/ecore/ecore_pipe.c @@ -332,20 +332,68 @@ ecore_pipe_del(Ecore_Pipe *p) "ecore_pipe_del"); return NULL; } - ecore_main_fd_handler_del(p->fd_handler); - close(p->fd_read); - close(p->fd_write); + if(p->fd_handler != NULL) + ecore_main_fd_handler_del(p->fd_handler); + if(p->fd_read != -1) + close(p->fd_read); + if(p->fd_write != -1) + close(p->fd_write); data = (void *)p->data; free (p); return data; } /** + * Close the read end of an Ecore_Pipe object created with ecore_pipe_add(). + * + * @param p The Ecore_Pipe object. + * @ingroup Ecore_Pipe_Group + */ +EAPI void +ecore_pipe_close_read(Ecore_Pipe *p) +{ + void *data; + + if (!ECORE_MAGIC_CHECK(p, ECORE_MAGIC_PIPE)) + { + ECORE_MAGIC_FAIL(p, ECORE_MAGIC_PIPE, + "ecore_pipe_close_read"); + return; + } + ecore_main_fd_handler_del(p->fd_handler); + p->fd_handler = NULL; + close(p->fd_read); + p->fd_read = -1; +} + +/** + * Close the write end of an Ecore_Pipe object created with ecore_pipe_add(). + * + * @param p The Ecore_Pipe object. + * @ingroup Ecore_Pipe_Group + */ +EAPI void +ecore_pipe_close_write(Ecore_Pipe *p) +{ + void *data; + + if (!ECORE_MAGIC_CHECK(p, ECORE_MAGIC_PIPE)) + { + ECORE_MAGIC_FAIL(p, ECORE_MAGIC_PIPE, + "ecore_pipe_close_write"); + return; + } + close(p->fd_write); + p->fd_write = -1; +} + +/** * Write on the file descriptor the data passed as parameter. * * @param p The Ecore_Pipe object. * @param buffer The data to write into the pipe. * @param nbytes The size of the @p buffer in bytes + * @return Returns TRUE on a successful write, FALSE on an error * @ingroup Ecore_Pipe_Group */ EAPI int @@ -359,9 +407,13 @@ ecore_pipe_write(Ecore_Pipe *p, const void *buffer, unsigned int nbytes) { ECORE_MAGIC_FAIL(p, ECORE_MAGIC_PIPE, "ecore_pipe_write"); - return 0; + return FALSE; } - /* first write the len into the pipe */ + + if(p->fd_write == -1) + return FALSE; + + /* First write the len into the pipe */ do { ret = pipe_write(p->fd_write, &nbytes, sizeof(nbytes)); @@ -375,7 +427,13 @@ ecore_pipe_wri
[E-devel] [PATCH] emotion gstreamer fixes
Hi Three patches attached. The most important one is 0003-Emotion-fix-after-eina-list-changes.patch that fixes emotion gstreamer breakage that was introduced in r39195. The two other patches is just very minor stuff that I had in my local git. Please apply Regards Lars Munch >From ba797a60f47232f3a9a463d80ad18212d47e073a Mon Sep 17 00:00:00 2001 From: Lars Munch Date: Fri, 27 Feb 2009 22:24:15 +0100 Subject: [PATCH 3/3] Emotion fix after eina list changes Fix emotion after eina list changes in commit r39195 Signed-off-by: Lars Munch --- src/modules/gstreamer/emotion_gstreamer.c | 27 +-- 1 files changed, 5 insertions(+), 22 deletions(-) diff --git a/src/modules/gstreamer/emotion_gstreamer.c b/src/modules/gstreamer/emotion_gstreamer.c index 888b202..1449819 100644 --- a/src/modules/gstreamer/emotion_gstreamer.c +++ b/src/modules/gstreamer/emotion_gstreamer.c @@ -240,8 +240,6 @@ em_init(Evas_Object *obj, Emotion_Module_Options *opt) { Emotion_Gstreamer_Video *ev; - Emotion_Audio_Sink *asink; - Emotion_Video_Sink *vsink; GError *error; int fds[2]; @@ -256,15 +254,7 @@ em_init(Evas_Object *obj, /* Initialization of gstreamer */ if (!gst_init_check(NULL, NULL, &error)) - goto failure_gstreamer; - - /* We allocate the sinks lists */ - if (!ev->video_sinks) - goto failure_video_sinks; - if (!ev->audio_sinks) - goto failure_audio_sinks; - - *emotion_video = ev; + goto failure; /* Default values */ ev->ratio = 1.0; @@ -276,18 +266,13 @@ em_init(Evas_Object *obj, /* Create the file descriptors */ ev->pipe = ecore_pipe_add (_em_buffer_read, ev); if (!ev->pipe) - goto failure_pipe; + goto failure; + + *emotion_video = ev; return 1; -failure_pipe: - EINA_LIST_FREE(ev->audio_sinks, asink) - free(asink); -failure_audio_sinks: - EINA_LIST_FREE(ev->video_sinks, vsink) - free(vsink); -failure_video_sinks: -failure_gstreamer: +failure: free(ev); return 0; @@ -627,8 +612,6 @@ em_len_get(void *video) return val / 10.0; fallback: - fputs("Gstreamer reported no length, try existing sinks...\n", stderr); - EINA_LIST_FOREACH(ev->audio_sinks, l, asink) if (asink->length_time >= 0) return asink->length_time; -- 1.6.1.3 >From d99263eb77159fbdfd5574f783a4c50b284da540 Mon Sep 17 00:00:00 2001 From: Lars Munch Date: Mon, 23 Feb 2009 14:56:50 +0100 Subject: [PATCH 1/3] emotion vlc disable fix When vlc was disable HAVE_VLC was undefined Signed-off-by: Lars Munch --- configure.ac |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index a424c8f..8ba3355 100644 --- a/configure.ac +++ b/configure.ac @@ -41,6 +41,7 @@ CPPFLAGS=$save_CPPFLAGS AC_ARG_ENABLE(vlc, AC_HELP_STRING([--disable-vlc],[disable vlc support @<:@default=auto@:>@]), [enable_vlc=$enableval],[enable_vlc=auto]) +HAVE_VLC="no" if test "$enable_vlc" != "no" ; then PKG_CHECK_MODULES(VLC, [libvlc >= 0.9], [HAVE_VLC="yes"], [HAVE_VLC="no"]) fi -- 1.6.1.3 >From e540bcf32213dcb6be19652eae8ad85ba1aeacba Mon Sep 17 00:00:00 2001 From: Lars Munch Date: Thu, 26 Feb 2009 13:05:16 +0100 Subject: [PATCH 2/3] White space fixes Signed-off-by: Lars Munch --- src/lib/Emotion.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/lib/Emotion.h b/src/lib/Emotion.h index 04bd444..1a2ec9e 100644 --- a/src/lib/Emotion.h +++ b/src/lib/Emotion.h @@ -109,7 +109,7 @@ typedef enum _Emotion_Vis Emotion_Vis; #ifdef __cplusplus extern "C" { #endif - + /* api calls available */ EAPI Evas_Object *emotion_object_add (Evas *evas); EAPI void emotion_object_module_option_set (Evas_Object *obj, const char *opt, const char *val); @@ -172,5 +172,5 @@ EAPI Evas_Boolemotion_object_vis_supported (Evas_Object *obj, Emotio #ifdef __cplusplus } #endif - + #endif -- 1.6.1.3 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore and Enlightenment compilation
On Wed, Feb 25, 2009 at 11:17:17PM +0100, Cédric Tabin wrote: > Hello all, > > I'm new to this mailing-list, so sorry if it is not the right place to speak > about my little compilation failure. You came to the right place :-) > Since the last revision (39219) of the > Ecore and Enlightenment ebuilds (I'm on gentoo), it seems that there is some > bugs into ecore_evas_fb.c, line 100 : These issues has just been fixed in svn. Please update and give it another go. Regards Lars Munch -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] gstreamer v4l support for emotion
On Sat, Feb 21, 2009 at 09:50:55PM -0300, Gustavo Sverzut Barbieri wrote: > On Thu, Feb 19, 2009 at 3:09 PM, Lars Munch wrote: > > This patch adds gstreamer v4l support to emotion. If you got a webcam it can > > be tested by doing: > > > > emotion_test -gstreamer v4l:// > > > > This will use the first video device /dev/video0. > > > > If you do not have a webcam, you can also try it using the Virtual Video > > driver > > (modprobe vivi). If you got more that one video device you can also use > > > > emotion_test -gstreamer v4l://0 v4l://1 > > > > to play from both /dev/video0 and /dev/video1. > > Lars, sorry taking so review it, but here it is: Thanks for the review! [snip] > > so very minor stuff, send a new patch and I'll commit. > Three new patches attached - please apply Thanks Lars Munch Use calloc instead of malloc Use calloc instead of malloc. This will ensure that length in set to zero if no length is provided from gstreamer. --- src/modules/gstreamer/emotion_gstreamer_pipeline.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/modules/gstreamer/emotion_gstreamer_pipeline.c b/src/modules/gstreamer/emotion_gstreamer_pipeline.c index cf1e28b..5fcd742 100644 --- a/src/modules/gstreamer/emotion_gstreamer_pipeline.c +++ b/src/modules/gstreamer/emotion_gstreamer_pipeline.c @@ -93,7 +93,7 @@ file_new_decoded_pad_cb(GstElement *decodebin, GstElement *queue; GstPad *videopad; - vsink = (Emotion_Video_Sink *)malloc(sizeof(Emotion_Video_Sink)); + vsink = (Emotion_Video_Sink *)calloc(1, sizeof(Emotion_Video_Sink)); if (!vsink) return; if (!ecore_list_append(ev->video_sinks, vsink)) { @@ -121,7 +121,7 @@ file_new_decoded_pad_cb(GstElement *decodebin, Emotion_Audio_Sink *asink; GstPad *audiopad; - asink = (Emotion_Audio_Sink *)malloc(sizeof(Emotion_Audio_Sink)); + asink = (Emotion_Audio_Sink *)calloc(1, sizeof(Emotion_Audio_Sink)); if (!asink) return; if (!ecore_list_append(ev->audio_sinks, asink)) { @@ -146,7 +146,7 @@ emotion_video_sink_new(Emotion_Gstreamer_Video *ev) if (!ev) return NULL; - vsink = (Emotion_Video_Sink *)malloc(sizeof(Emotion_Video_Sink)); + vsink = (Emotion_Video_Sink *)calloc(1, sizeof(Emotion_Video_Sink)); if (!vsink) return NULL; if (!ecore_list_append(ev->video_sinks, vsink)) -- 1.6.1.3 Do not spam the user if no length available Do not spam the user if no length available from gstreamer. This is the case for webcams, streaming audio and video etc. --- src/modules/gstreamer/emotion_gstreamer.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/modules/gstreamer/emotion_gstreamer.c b/src/modules/gstreamer/emotion_gstreamer.c index d528dea..b76eb25 100644 --- a/src/modules/gstreamer/emotion_gstreamer.c +++ b/src/modules/gstreamer/emotion_gstreamer.c @@ -605,8 +605,6 @@ em_len_get(void *video) return val / 10.0; fallback: - fputs("Gstreamer reported no length, try existing sinks...\n", stderr); - ecore_list_first_goto(ev->audio_sinks); while ((asink = ecore_list_next(ev->audio_sinks)) != NULL) if (asink->length_time >= 0) -- 1.6.1.3 gstreamer v4l support to emotion This patch adds gstreamer v4l support to emotion. If you got a webcam it can be tested by doing: emotion_test -gstreamer v4l:// This will use the first video device /dev/video0. If you do not have a webcam, you can also try it using the Virtual Video driver (modprobe vivi). If you got more that one video device you can also use emotion_test -gstreamer v4l://0 v4l://1 to play from /dev/video0 and /dev/video1 --- src/modules/gstreamer/Makefile.am |5 +- src/modules/gstreamer/emotion_gstreamer.c | 11 +++ src/modules/gstreamer/emotion_gstreamer_pipeline.h |1 + .../gstreamer/emotion_gstreamer_pipeline_v4l.c | 87 4 files changed, 102 insertions(+), 2 deletions(-) create mode 100644 src/modules/gstreamer/emotion_gstreamer_pipeline_v4l.c diff --git a/src/modules/gstreamer/Makefile.am b/src/modules/gstreamer/Makefile.am index f3519af..6aee2e3 100644 --- a/src/modules/gstreamer/Makefile.am +++ b/src/modules/gstreamer/Makefile.am @@ -24,10 +24,11 @@ emotion_gstreamer_pipeline.h \ emotion_gstreamer_pipeline_cdda.c \ emotion_gstreamer_pipeline_dvd.c \ emotion_gstreamer_pipeline_file.c \ -emotion_gstreamer_pipeline_uri.c +emotion_gstreamer_pipeline_uri.c \ +emotion_gstreamer_pipeline_v4l.c gstreamer_la_LIBADD = @EVAS_LIBS@ @ECORE_LIBS@ @GST_LIBS@ $(top_builddir)/src/lib/libemotion.la gstreamer_la_LDFLAGS = -module -avoid-version gstreamer_la_LIBTOOLFLAGS = --tag=disable-static gstreamer_la_DEPENDENCIES = $(top_builddir)/config.h -endif \ No newline at end of file +endif diff --git a/src/modules/gstreamer/emotion_gstreamer.c b/src/modul
[E-devel] [PATCH] gstreamer v4l support for emotion
This patch adds gstreamer v4l support to emotion. If you got a webcam it can be tested by doing: emotion_test -gstreamer v4l:// This will use the first video device /dev/video0. If you do not have a webcam, you can also try it using the Virtual Video driver (modprobe vivi). If you got more that one video device you can also use emotion_test -gstreamer v4l://0 v4l://1 to play from both /dev/video0 and /dev/video1. Regards Lars Munch --- src/modules/gstreamer/Makefile.am |5 +- src/modules/gstreamer/emotion_gstreamer.c | 13 +++- src/modules/gstreamer/emotion_gstreamer_pipeline.c |6 +- src/modules/gstreamer/emotion_gstreamer_pipeline.h |1 + .../gstreamer/emotion_gstreamer_pipeline_v4l.c | 85 5 files changed, 103 insertions(+), 7 deletions(-) create mode 100644 src/modules/gstreamer/emotion_gstreamer_pipeline_v4l.c diff --git a/src/modules/gstreamer/Makefile.am b/src/modules/gstreamer/Makefile.am index f3519af..6aee2e3 100644 --- a/src/modules/gstreamer/Makefile.am +++ b/src/modules/gstreamer/Makefile.am @@ -24,10 +24,11 @@ emotion_gstreamer_pipeline.h \ emotion_gstreamer_pipeline_cdda.c \ emotion_gstreamer_pipeline_dvd.c \ emotion_gstreamer_pipeline_file.c \ -emotion_gstreamer_pipeline_uri.c +emotion_gstreamer_pipeline_uri.c \ +emotion_gstreamer_pipeline_v4l.c gstreamer_la_LIBADD = @EVAS_LIBS@ @ECORE_LIBS@ @GST_LIBS@ $(top_builddir)/src/lib/libemotion.la gstreamer_la_LDFLAGS = -module -avoid-version gstreamer_la_LIBTOOLFLAGS = --tag=disable-static gstreamer_la_DEPENDENCIES = $(top_builddir)/config.h -endif \ No newline at end of file +endif diff --git a/src/modules/gstreamer/emotion_gstreamer.c b/src/modules/gstreamer/emotion_gstreamer.c index d528dea..1516bd3 100644 --- a/src/modules/gstreamer/emotion_gstreamer.c +++ b/src/modules/gstreamer/emotion_gstreamer.c @@ -390,6 +390,17 @@ em_file_open(const char *file, return 0; } } + /* v4l */ + else if (strstr(file, "v4l://")) + { + fprintf(stderr, "[Emotion] [gst] build V4L pipeline\n"); + if (!(emotion_pipeline_v4l_build(ev, file))) + { +fprintf(stderr, "[Emotion] [gst] error while building V4L pipeline\n"); +gst_object_unref(ev->pipeline); +return 0; + } + } /* Normal media file */ else { @@ -605,8 +616,6 @@ em_len_get(void *video) return val / 10.0; fallback: - fputs("Gstreamer reported no length, try existing sinks...\n", stderr); - ecore_list_first_goto(ev->audio_sinks); while ((asink = ecore_list_next(ev->audio_sinks)) != NULL) if (asink->length_time >= 0) diff --git a/src/modules/gstreamer/emotion_gstreamer_pipeline.c b/src/modules/gstreamer/emotion_gstreamer_pipeline.c index cf1e28b..5fcd742 100644 --- a/src/modules/gstreamer/emotion_gstreamer_pipeline.c +++ b/src/modules/gstreamer/emotion_gstreamer_pipeline.c @@ -93,7 +93,7 @@ file_new_decoded_pad_cb(GstElement *decodebin, GstElement *queue; GstPad *videopad; - vsink = (Emotion_Video_Sink *)malloc(sizeof(Emotion_Video_Sink)); + vsink = (Emotion_Video_Sink *)calloc(1, sizeof(Emotion_Video_Sink)); if (!vsink) return; if (!ecore_list_append(ev->video_sinks, vsink)) { @@ -121,7 +121,7 @@ file_new_decoded_pad_cb(GstElement *decodebin, Emotion_Audio_Sink *asink; GstPad *audiopad; - asink = (Emotion_Audio_Sink *)malloc(sizeof(Emotion_Audio_Sink)); + asink = (Emotion_Audio_Sink *)calloc(1, sizeof(Emotion_Audio_Sink)); if (!asink) return; if (!ecore_list_append(ev->audio_sinks, asink)) { @@ -146,7 +146,7 @@ emotion_video_sink_new(Emotion_Gstreamer_Video *ev) if (!ev) return NULL; - vsink = (Emotion_Video_Sink *)malloc(sizeof(Emotion_Video_Sink)); + vsink = (Emotion_Video_Sink *)calloc(1, sizeof(Emotion_Video_Sink)); if (!vsink) return NULL; if (!ecore_list_append(ev->video_sinks, vsink)) diff --git a/src/modules/gstreamer/emotion_gstreamer_pipeline.h b/src/modules/gstreamer/emotion_gstreamer_pipeline.h index 2e8a703..3a8b849 100644 --- a/src/modules/gstreamer/emotion_gstreamer_pipeline.h +++ b/src/modules/gstreamer/emotion_gstreamer_pipeline.h @@ -14,6 +14,7 @@ int emotion_pipeline_cdda_build (void *video, const char * device, uns int emotion_pipeline_file_build (void *video, const char *file); int emotion_pipeline_uri_build(void *video, const char *uri); int emotion_pipeline_dvd_build(void *video, const char *device); +int emotion_pipeline_v4l_build(void *video, const char *device); int emotion_pipeline_cdda_track_count_get (void *video); GstElement *emotion_audio_sink_create (Emotion_Gstreamer_Video *ev, int index); diff --git a/src/modules/gst
Re: [E-devel] [PATCH] ecore_fb absolute coordinate support
On Tue, Dec 16, 2008 at 02:59:59PM +0100, Michael 'Mickey' Lauer wrote: > Am Tuesday 16 December 2008 11:23:37 schrieb Lars Munch: > > On Mon, Dec 15, 2008 at 08:56:18PM +0100, Michael 'Mickey' Lauer wrote: > > > Am Monday 15 December 2008 11:24:07 schrieb Lars Munch: > > > > This patch adds absolute coordinate support to ecore_fb, e.g. > > > > touchscreen support. There is no calibration support yet, it just uses > > > > the values it gets from the kernel. > > > > > > Why don't you use tslib? > > > > One less dependency and if the touchscreen driver is already calibrated > > then it "just works". > > I don't think that justifies adding that code to ecore_fb. Everyone and their > brother is using tslib these days. Anyways, if you want that patch to go in, > keep the tslib functionality around and only add on top. Apparently not everyone :-) Yes, we should definitely keep the tslib functionality! my intension was not to replace it but apparently I was missing a HAVE_TSLIB guard in ecore_evas_fb.c. Now it will use TSLIB lib if you have it installed and fallback to ecore_fb_li if not. Updated patch below. --- Index: src/lib/ecore_fb/ecore_fb_private.h === --- src/lib/ecore_fb/ecore_fb_private.h (revision 38149) +++ src/lib/ecore_fb/ecore_fb_private.h (working copy) @@ -19,8 +19,8 @@ #define kernel_ulong_t unsigned long #define BITS_PER_LONG 32 #include - #undef kernel_ulong_t <-added - #undef BITS_PER_LONG <-added + #undef kernel_ulong_t + #undef BITS_PER_LONG #else #include #endif @@ -52,7 +52,7 @@ /* absolute axis */ int min_w, min_h; double rel_w, rel_h; - + int event; } mouse; struct { Index: src/lib/ecore_fb/ecore_fb_li.c === --- src/lib/ecore_fb/ecore_fb_li.c (revision 38149) +++ src/lib/ecore_fb/ecore_fb_li.c (working copy) @@ -250,52 +250,110 @@ static void _ecore_fb_li_device_event_abs(Ecore_Fb_Input_Device *dev, struct input_event *iev) { + static int prev_x = 0, prev_y = 0, prev_pressure = 0; + int v = 0; + int pressure; + int num; + char *ptr; + double t; + if(!dev->listen) return; + switch(iev->code) { case ABS_X: - case ABS_Y: - { - Ecore_Fb_Event_Mouse_Move *ev; - if((iev->code == ABS_X) && (dev->mouse.w != 0)) + if(dev->mouse.w != 0) { int tmp; tmp = (int)((double)(iev->value - dev->mouse.min_w) / dev->mouse.rel_w); - if(tmp < 0) + if(tmp < 0) { dev->mouse.x = 0; - else if(tmp > dev->mouse.w) + } + else if(tmp > dev->mouse.w) { dev->mouse.x = dev->mouse.w; - else + } + else { dev->mouse.x = tmp; + } + dev->mouse.event = ECORE_FB_EVENT_MOUSE_MOVE; } - else if((iev->code == ABS_Y) && (dev->mouse.h != 0)) + break; + + case ABS_Y: + if(dev->mouse.h != 0) { int tmp; tmp = (int)((double)(iev->value - dev->mouse.min_h) / dev->mouse.rel_h); - if(tmp < 0) + if(tmp < 0) { dev->mouse.y = 0; - else if(tmp > dev->mouse.h) + } + else if(tmp > dev->mouse.h) { dev->mouse.y = dev->mouse.h; - else + } + else { dev->mouse.y = tmp; + } + dev->mouse.event = ECORE_FB_EVENT_MOUSE_MOVE; } - ev = calloc(1,sizeof(Ecore_Fb_Event_Mouse_Move)); - ev->x = dev->mouse.x; - ev->y = dev->mouse.y; -
Re: [E-devel] [PATCH] ecore_fb absolute coordinate support
On Mon, Dec 15, 2008 at 08:56:18PM +0100, Michael 'Mickey' Lauer wrote: > Am Monday 15 December 2008 11:24:07 schrieb Lars Munch: > > This patch adds absolute coordinate support to ecore_fb, e.g. > > touchscreen support. There is no calibration support yet, it just uses > > the values it gets from the kernel. > > Why don't you use tslib? > One less dependency and if the touchscreen driver is already calibrated then it "just works". Regards Lars Munch -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] ecore_fb absolute coordinate support
This patch adds absolute coordinate support to ecore_fb, e.g. touchscreen support. There is no calibration support yet, it just uses the values it gets from the kernel. Lars Munch --- Index: src/lib/ecore_fb/ecore_fb_private.h === --- src/lib/ecore_fb/ecore_fb_private.h (revision 38149) +++ src/lib/ecore_fb/ecore_fb_private.h (working copy) @@ -19,8 +19,8 @@ #define kernel_ulong_t unsigned long #define BITS_PER_LONG 32 #include - #undef kernel_ulong_t <-added - #undef BITS_PER_LONG <-added + #undef kernel_ulong_t + #undef BITS_PER_LONG #else #include #endif @@ -52,7 +52,7 @@ /* absolute axis */ int min_w, min_h; double rel_w, rel_h; - + int event; } mouse; struct { Index: src/lib/ecore_fb/ecore_fb_li.c === --- src/lib/ecore_fb/ecore_fb_li.c (revision 38149) +++ src/lib/ecore_fb/ecore_fb_li.c (working copy) @@ -250,52 +250,110 @@ static void _ecore_fb_li_device_event_abs(Ecore_Fb_Input_Device *dev, struct input_event *iev) { + static int prev_x = 0, prev_y = 0, prev_pressure = 0; + int v = 0; + int pressure; + int num; + char *ptr; + double t; + if(!dev->listen) return; + switch(iev->code) { case ABS_X: - case ABS_Y: - { - Ecore_Fb_Event_Mouse_Move *ev; - if((iev->code == ABS_X) && (dev->mouse.w != 0)) + if(dev->mouse.w != 0) { int tmp; tmp = (int)((double)(iev->value - dev->mouse.min_w) / dev->mouse.rel_w); - if(tmp < 0) + if(tmp < 0) { dev->mouse.x = 0; - else if(tmp > dev->mouse.w) + } + else if(tmp > dev->mouse.w) { dev->mouse.x = dev->mouse.w; - else + } + else { dev->mouse.x = tmp; + } + dev->mouse.event = ECORE_FB_EVENT_MOUSE_MOVE; } - else if((iev->code == ABS_Y) && (dev->mouse.h != 0)) + break; + + case ABS_Y: + if(dev->mouse.h != 0) { int tmp; tmp = (int)((double)(iev->value - dev->mouse.min_h) / dev->mouse.rel_h); - if(tmp < 0) + if(tmp < 0) { dev->mouse.y = 0; - else if(tmp > dev->mouse.h) + } + else if(tmp > dev->mouse.h) { dev->mouse.y = dev->mouse.h; - else + } + else { dev->mouse.y = tmp; + } + dev->mouse.event = ECORE_FB_EVENT_MOUSE_MOVE; } - ev = calloc(1,sizeof(Ecore_Fb_Event_Mouse_Move)); - ev->x = dev->mouse.x; - ev->y = dev->mouse.y; - ev->dev = dev; + break; - ecore_event_add(ECORE_FB_EVENT_MOUSE_MOVE, ev, NULL, NULL); - break; - } case ABS_PRESSURE: - /* TODO emulate a button press */ + pressure = iev->value; + if ((pressure) && (!prev_pressure)) + { + /* DOWN: mouse is down, but was not now */ + dev->mouse.event = ECORE_FB_EVENT_MOUSE_BUTTON_DOWN; + } + else if ((!pressure) && (prev_pressure)) + { + /* UP: mouse was down, but is not now */ + dev->mouse.event = ECORE_FB_EVENT_MOUSE_BUTTON_UP; + } + + prev_pressure = pressure; + break; } } +static void +_ecore_fb_li_device_event_syn(Ecore_Fb_Input_Device *dev, struct input_event *ie
Re: [E-devel] evil trouble
On Mon, Oct 27, 2008 at 01:27:12AM +0100, Vincent Torri wrote: > I had to compile the link code with g++, hence putting IID_PersistFile was > not possible (at least, i didn't succeed). So I put the code in a separate > file like Lars did. > > I've attached a patch. Please test it. It compiles correctly on my system. Just tested your patch. Compiles fine here using linux->mingw cross toolchain. Thanks Lars Munch - 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=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, Oct 26, 2008 at 04:59:19PM +0100, Vincent Torri wrote: > > > On Sun, 26 Oct 2008, Lars Munch wrote: > > >IMHO it is not a libtool problem, but the problem is that evil.dll tries > >to link to at static library (uuid in this case), which is generally > >considered bad. > > it is a libtool problem, in a manner or another. Your remark: > > + * This file defines all the windows UUID used in evil. This is here > + * since uuid.lib is a static only library and libtool does not allow > + * you to link a DLL against a static library. > > is wrong. We can link a lib against a static lib to produce a dll. Check > when I link against libm.a, libws2_32.a, etc... in evil or other efl lib. > There is no dll for those lib. But libtool detects that it is an import > lib (look at the function func_win32_libid() in ltmain.sh or libtool > scripts) and accepts to create the dll. But there are dll's for those libs: libws2_32.a is an import library for windows\system32\ws2_32.dll. libole32.a is an import library for windows\system32\ole32.dll. libsecur32.a is an import library for windows\system32\secur32.dll. libuuid.a on the other hand is not an import library but a real static library, hence the error when not detected as an import library. > about the 'file' program, i didn't know. The func_win32_libid function is different if you got the file utility on your system (as most people do on linux). This version is actually better at identifying a static library vs. import library. See for instance: http://www.cygwin.com/ml/cygwin/2003-02/msg01464.html I went for a modified version of point 1) in my patch. -- Lars Munch - 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=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, Oct 26, 2008 at 06:26:01PM +1030, Samuel Nicholas wrote: > hay guise > > cause eina has recently been added as a dependancy i was updating my > libs and ran into trouble... so i decided to start from scratch again. > now i have a problem I didn't have before > > when compiling evil: > ... > /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -no-undefined > -Wl,--enable-auto-import -version-info 0:1:0 -L/usr/local/lib -o > libevil.la -rpath /usr/local/lib libevil_la-evil_errno.lo > libevil_la-evil_fcntl.lo libevil_la-evil_fnmatch.lo > libevil_la-evil_fnmatch_list_of_states.lo libevil_la-evil_langinfo.lo > libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo > libevil_la-evil_stdio.lo libevil_la-evil_string.lo > libevil_la-evil_time.lo libevil_la-evil_unistd.lo > libevil_la-evil_util.lo -lole32 -luuid -lws2_32 -lsecur32 > libtool: link: rm -fr .libs/libevil.a .libs/libevil.la .libs/libevil.lai > > *** Warning: linker path does not have real file for library -luuid. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have > *** because I did check the linker path looking for a file starting > *** with libuuid and none of the candidates passed a file format test > *** using a file magic. Last file checked: /mingw/lib//libuuid.a > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it. > > *** Since this library must not contain undefined symbols, > *** because either the platform does not support them or > *** it was explicitly requested with -no-undefined, > *** libtool will only create a static version of it. > ... > > which then, later on, fails completely when it goes to make the shared lib. > > libuuid.a exists at c:/msys/1.0/mingw/lib/ Do you have the "file" utility installed in mingw? Having this utility will make libtool fail in this manor, because it will detect libraries differently, since "file" can tell the difference between a static library and a dll. The above also happens if you try to cross compile evil linux->mingw. IMHO it is not a libtool problem, but the problem is that evil.dll tries to link to at static library (uuid in this case), which is generally considered bad. I currently use the attached patch to get around this problem. Regards Lars Munch Index: src/lib/evil_uuid.c === --- src/lib/evil_uuid.c (revision 0) +++ src/lib/evil_uuid.c (revision 0) @@ -0,0 +1,12 @@ +/* + * This file defines all the windows UUID used in evil. This is here + * since uuid.lib is a static only library and libtool does not allow + * you to link a DLL against a static library. + */ +#ifndef __CEGCC__ + +#define INITGUID +#include +DEFINE_OLEGUID(IID_IPersistFile, 0x010BL, 0, 0); + +#endif Index: src/lib/Makefile.am === --- src/lib/Makefile.am (revision 37141) +++ src/lib/Makefile.am (working copy) @@ -36,7 +36,8 @@ evil_string.c \ evil_time.c \ evil_unistd.c \ -evil_util.c +evil_util.c \ +evil_uuid.c libevil_la_CPPFLAGS = @win32_cppflags@ libevil_la_CFLAGS = @win32_cflags@ Index: configure.ac === --- configure.ac (revision 37141) +++ configure.ac (working copy) @@ -35,7 +35,7 @@ win32_libs="" case "$host_os" in mingw | mingw32 | mingw32msvc) -win32_libs="-lole32 -luuid -lws2_32 -lsecur32" +win32_libs="-lole32 -lws2_32 -lsecur32" ;; cegcc*) win32_libs="-lws2" - 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=100&url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Exquisite clear text fix
Hi In exquisite: if the textblock has not been used and the CLEAR command is called, it will enable the textblock and then clear it. This causes the textblock to appear and then quickly disappear again. Attached patch makes sure that the CLEAR command does not enable the text block before clearing it. Please apply Regards Lars Munch Index: src/bin/theme.c === --- src/bin/theme.c (revision 36407) +++ src/bin/theme.c (working copy) @@ -58,8 +58,6 @@ edje_object_signal_emit(o_bg, "exquisite", "text_set"); else if(signal == 2) edje_object_signal_emit(o_bg, "exquisite", "status_set"); -else if(signal == 3) - edje_object_signal_emit(o_bg, "exquisite", "text_clear"); edje_object_part_text_set(o_bg, "textarea", buf); edje_object_part_text_set(o_bg, "statusarea", buf2); @@ -242,9 +240,14 @@ evas_list_free(messages); messages = NULL; } - - /*A 3 means a text clear signal will be sent*/ - theme_update_text(3); + + if (edje_object_part_exists(o_bg, "textarea") && + edje_object_part_exists(o_bg, "statusarea")) + { + edje_object_signal_emit(o_bg, "exquisite", "text_clear"); + edje_object_part_text_set(o_bg, "textarea", ""); + edje_object_part_text_set(o_bg, "statusarea", ""); + } } static void - 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=100&url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] edje: add get_mouse_buttons to embryo scripts
Attached patch adds a get_mouse_buttons function to edje embryo scripts. The function returns the button mask. -- Lars Munch Index: data/include/edje.inc === RCS file: /var/cvs/e/e17/libs/edje/data/include/edje.inc,v retrieving revision 1.24 diff -u -r1.24 edje.inc --- data/include/edje.inc 11 Apr 2008 23:36:35 - 1.24 +++ data/include/edje.inc 14 Apr 2008 19:17:25 - @@ -104,6 +104,7 @@ native get_text_class (class[], font[], &Float:size); native get_geometry (part_id, &x, &y, &w, &h); native get_mouse(&x, &y); +native get_mouse_buttons(); native stop_program (program_id); native stop_programs_on (part_id); native set_min_size (Float:w, Float:h); Index: src/lib/edje_embryo.c === RCS file: /var/cvs/e/e17/libs/edje/src/lib/edje_embryo.c,v retrieving revision 1.60 diff -u -r1.60 edje_embryo.c --- src/lib/edje_embryo.c 11 Apr 2008 23:36:35 - 1.60 +++ src/lib/edje_embryo.c 14 Apr 2008 19:17:27 - @@ -795,6 +795,17 @@ return 0; } +/* get_mouse_buttons() */ +static Embryo_Cell +_edje_embryo_fn_get_mouse_buttons(Embryo_Program *ep, Embryo_Cell *params) +{ + Edje *ed; + + CHKPARAM(0); + ed = embryo_program_data_get(ep); + return evas_pointer_button_down_mask_get(ed->evas); +} + /* emit(sig[], src[]) */ static Embryo_Cell _edje_embryo_fn_emit(Embryo_Program *ep, Embryo_Cell *params) @@ -2229,6 +2240,7 @@ embryo_program_native_call_add(ep, "get_drag_page", _edje_embryo_fn_get_drag_page); embryo_program_native_call_add(ep, "set_drag_page", _edje_embryo_fn_set_drag_page); embryo_program_native_call_add(ep, "get_mouse", _edje_embryo_fn_get_mouse); + embryo_program_native_call_add(ep, "get_mouse_buttons", _edje_embryo_fn_get_mouse_buttons); embryo_program_native_call_add(ep, "stop_program", _edje_embryo_fn_stop_program); embryo_program_native_call_add(ep, "stop_programs_on", _edje_embryo_fn_stop_programs_on); embryo_program_native_call_add(ep, "set_min_size", _edje_embryo_fn_set_min_size); - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] updated: three new edje embryo functions
On Mon, Apr 14, 2008 at 02:29:06PM -0300, Gustavo Sverzut Barbieri wrote: > On Sun, Apr 13, 2008 at 7:42 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > > Gustavo Sverzut Barbieri schrieb: > > > > > Maybe it will not impact things. The problem with these calls is that > > > they would collide with Edje internal states, getting these > > > inconsistent. But since Edje does not handle any layer/stack-related > > > information in their states, maybe this is no problem, in this case > > > just add the call to edje C api (edje_object_part_{raise,lower}()) and > > > expose it from embryo. > > > > > I don't think it is a good idea to have those functions in the edje c > > api. The application should change directly the theme. That's why there > > isn't a edje_object_part_state_set() function. > > While I'm unsure whenever to have or not this function exported, this > is different from what you said: part_state_set() can be done with > signals, while there are no means to reorder the objects from edje, > neither from states or code. Maybe the reason to not have this known > by someone (raster?), maybe it was just left out due out-of-time, in > that case we could add this to Edje states and use signals to trigger > changes. > > Lars: what's your motivation to use this? maybe this can give us some light. I have a set of buttons with a small overlap, all made with edje. On "mouse,in" event I want the active button to become the topmost part. I first thought about just emitting a signal from edje on "mouse,in" to an event handler in C that would use edje_object_part_object_get and then evas_object_raise, but I really wanted the part raising in edje so I only had to take care of the actual event handling in C (the actual button click). The part_lower was mostly added for completion :) It would be very nice to have some way to reorder the objects from edje. Regards Lars Munch - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] updated: three new edje embryo functions
On Sun, Apr 13, 2008 at 01:03:35PM -0300, Gustavo Sverzut Barbieri wrote: > On Sun, Apr 13, 2008 at 7:17 AM, Lars Munch <[EMAIL PROTECTED]> wrote: > > Hi > > > > Attached patch adds three new functions to edje/embryo, namely > > part_raise, part_lower and get_mouse_buttons. > > I'd separate get_mouse_buttons() from the others. First of all, they > have nothing to do Your right, I will split the patch up in two. > second part_*() might be dangerous to use in Edje > parts, I can't see any problem, but I never thought about it too much, > let's wait for raster or someone else to opine here. By having them > separated, the mouse_buttons get in ASAP and the rest will wait for > revision and might not be applied. > > As for the implementation, it's not good: > 1) lacks get_mouse_buttons() in "docs" Do you mean in the long list of exported functions at the top of edje_embryo.c? In that case get_mouse_buttons() is already there. I guess someone meant to implement it, but never got around to do it. > 2) part_*() does not operate on the given part_id: > > +static Embryo_Cell > +_edje_embryo_fn_part_raise(Embryo_Program *ep, Embryo_Cell *params) > +{ > + int part_id = 0; > > no initialization should be done here. > > + ed = embryo_program_data_get(ep); > + > + evas_object_raise(ed->obj); > > where do you use part_id? no where. Maybe you tried to base your code > on other calls that get part_id and they use just like that. But > notice that they use "edje_object_*()" functions, that get an Edje > object and a part name, so they use part_id to get a rp->part->name. > Since the function you want have no edje_object_*() equivalent, then > you must get the object itself. And not having the > edje_object_part_raise() or edje_object_part_lower() is what make me > wonder if this would break things or not. If they won't break things, > then we should add these and use them from embryo. Yes, it might break things. I just found this comment in the docs for edje_object_part_object_get() "You should never modify the state of the returned object (with evas_object_move() or evas_object_hide() for example)". I will dig a little deaper and see what I can find. Thanks for the review. -- Lars Munch - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] updated: three new edje embryo functions
Hi Attached patch adds three new functions to edje/embryo, namely part_raise, part_lower and get_mouse_buttons. The patch has been updated to apply cleanly against latest cvs. Regrads Lars Munch Index: data/include/edje.inc === RCS file: /var/cvs/e/e17/libs/edje/data/include/edje.inc,v retrieving revision 1.24 diff -u -r1.24 edje.inc --- data/include/edje.inc 11 Apr 2008 23:36:35 - 1.24 +++ data/include/edje.inc 13 Apr 2008 10:11:05 - @@ -104,10 +104,13 @@ native get_text_class (class[], font[], &Float:size); native get_geometry (part_id, &x, &y, &w, &h); native get_mouse(&x, &y); +native get_mouse_buttons(); native stop_program (program_id); native stop_programs_on (part_id); native set_min_size (Float:w, Float:h); native set_max_size (Float:w, Float:h); +native part_raise (part_id); +native part_lower (part_id); native part_swallow (part_id, GROUP:str[]); enum Msg_Type Index: src/lib/edje_embryo.c === RCS file: /var/cvs/e/e17/libs/edje/src/lib/edje_embryo.c,v retrieving revision 1.60 diff -u -r1.60 edje_embryo.c --- src/lib/edje_embryo.c 11 Apr 2008 23:36:35 - 1.60 +++ src/lib/edje_embryo.c 13 Apr 2008 10:11:07 - @@ -174,6 +174,8 @@ * set_clip(part_id, clip_part_id) * get_clip(part_id) * + * part_raise(part_id) + * part_lower(part_id) * part_swallow(part_id, group_name) * * ADD/DEL CUSTOM OBJECTS UNDER SOLE EMBRYO SCRIPT CONTROL @@ -795,6 +797,17 @@ return 0; } +/* get_mouse_buttons() */ +static Embryo_Cell +_edje_embryo_fn_get_mouse_buttons(Embryo_Program *ep, Embryo_Cell *params) +{ + Edje *ed; + + CHKPARAM(0); + ed = embryo_program_data_get(ep); + return evas_pointer_button_down_mask_get(ed->evas); +} + /* emit(sig[], src[]) */ static Embryo_Cell _edje_embryo_fn_emit(Embryo_Program *ep, Embryo_Cell *params) @@ -2130,6 +2143,44 @@ return 0; } +/* part_raise(part_id) */ +static Embryo_Cell +_edje_embryo_fn_part_raise(Embryo_Program *ep, Embryo_Cell *params) +{ + int part_id = 0; + Edje *ed; + + CHKPARAM(1); + + part_id = params[1]; + if (part_id < 0) return 0; + + ed = embryo_program_data_get(ep); + + evas_object_raise(ed->obj); + + return 0; +} + +/* part_lower(part_id) */ +static Embryo_Cell +_edje_embryo_fn_part_lower(Embryo_Program *ep, Embryo_Cell *params) +{ + int part_id = 0; + Edje *ed; + + CHKPARAM(1); + + part_id = params[1]; + if (part_id < 0) return 0; + + ed = embryo_program_data_get(ep); + + evas_object_lower(ed->obj); + + return 0; +} + /* part_swallow(part_id, group_name) */ static Embryo_Cell _edje_embryo_fn_part_swallow(Embryo_Program *ep, Embryo_Cell *params) @@ -2229,6 +2280,7 @@ embryo_program_native_call_add(ep, "get_drag_page", _edje_embryo_fn_get_drag_page); embryo_program_native_call_add(ep, "set_drag_page", _edje_embryo_fn_set_drag_page); embryo_program_native_call_add(ep, "get_mouse", _edje_embryo_fn_get_mouse); + embryo_program_native_call_add(ep, "get_mouse_buttons", _edje_embryo_fn_get_mouse_buttons); embryo_program_native_call_add(ep, "stop_program", _edje_embryo_fn_stop_program); embryo_program_native_call_add(ep, "stop_programs_on", _edje_embryo_fn_stop_programs_on); embryo_program_native_call_add(ep, "set_min_size", _edje_embryo_fn_set_min_size); @@ -2240,6 +2292,8 @@ embryo_program_native_call_add(ep, "set_state_val", _edje_embryo_fn_set_state_val); embryo_program_native_call_add(ep, "get_state_val", _edje_embryo_fn_get_state_val); + embryo_program_native_call_add(ep, "part_raise", _edje_embryo_fn_part_raise); + embryo_program_native_call_add(ep, "part_lower", _edje_embryo_fn_part_lower); embryo_program_native_call_add(ep, "part_swallow", _edje_embryo_fn_part_swallow); // embryo_program_vm_push(ed->collection->script); - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] evas-framebuffer.pc.in rename
On Fri, Apr 11, 2008 at 04:27:18PM +0200, Vincent Torri wrote: > > > On Mon, 7 Apr 2008, Lars Munch wrote: > > >Hi > > > >Unfortunately the addition off expedite_check_engine.m4 in expedite > >broke the detection of the framebuffer engine in expedite. The course of > >this is an inconsistent naming of the file "evas-framebuffer.pc.in" > >which should be named "evas-fb.pc.in" to be consistent with the other > >engine names. > > can't we just modify what is checked in expedite ? That is configure.in, a > Makefile.am and 1 or 2 files. > yes, that's the easy solution, but IMHO consistent naming is better in the long run. Regards Lars Munch - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] edje: remove unused fnmatch.h include
fnmatch is not used in edje anymore. Attached trivial patch removes the last traces of its existence in edje. Index: INSTALL === RCS file: /var/cvs/e/e17/libs/edje/INSTALL,v retrieving revision 1.2 diff -u -r1.2 INSTALL --- INSTALL 26 Aug 2007 12:54:51 - 1.2 +++ INSTALL 11 Apr 2008 11:32:46 - @@ -12,8 +12,3 @@ make install NOTE: You MUST make install Edje for it to run properly. - -NOTE: for compilation with MinGW, fnmatch.h is probably missing. - That file can be found here: -http://www.koders.com/c/fid2B518462CB1EED3D4E31E271DB83CD1582F6EEBE.aspx - It should be installed in the mingw include directory. Index: src/bin/edje_prefix.c === RCS file: /var/cvs/e/e17/libs/edje/src/bin/edje_prefix.c,v retrieving revision 1.6 diff -u -r1.6 edje_prefix.c --- src/bin/edje_prefix.c 27 Aug 2007 09:32:17 - 1.6 +++ src/bin/edje_prefix.c 11 Apr 2008 11:32:49 - @@ -12,7 +12,6 @@ #include #include #include -#include #include #include #include - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] The big cache patch.
On Thu, Apr 10, 2008 at 10:47:44AM +0200, Cedric BAIL wrote: > On Thu, Apr 10, 2008 at 1:06 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > >Cedric wrote: > > >> That's a pretty hefty patch. :) Do you think you could write > > >> down some of the design/structure/etc, and what you're aiming for > > >> here.. for the sake of posterity and mere mortals with little time > > >> to look it all over. :) > > > > > > Yes of course. So it's basically an improvement of the current cache > > system. > > > > > As the code base of the cache is cleaner, it should be easier to add > > > new functionality. For example, I think adding the background loading > > > of an image surface should be really easy with this code base. > > > > > > I know that this code change is huge, and it's difficult for me to > > > split it as I started to do the work the old way (without git). If you > > > have more questions or if I am not really clear on some change, don't > > > hesitate to ask more question ! > > > > Thanks. :) Actually, I do have several things I was thinking > > about on this, but let me just mention a kind of 'peripheral' thing > > you brought up - namely, that of "background loading of an image > > surface". > > I'm not sure I see what you mean by this - in evas. For local > > files, the images are loaded only when rendering is called and it's > > not clear to me what one could gain by having the loading done by > > a separate process (if that's what you meant)? > > If the files are not local, then I'd say those cases should be > > handled by other libs.. have the loading done to tmp local files and > > update those files with more data as need be (or something like that). > > In fact on slow computer decoding file can take some time and during > this time nothing will move. > > So I am thinking about the idea of adding something like > evas_object_image_preload, that will just send the request to a > background thread. This thread will do the decompression and send an > event to the object when it is ready. If during this time you need to > access the data of the image, it will lock. This feature is needed in > my opinion if you want to do anything with many image like an image > viewer. Or like raster proposed a while back: evas_object_image_load_policy_set(obj, EVAS_LOAD_POLICY_ASYNC); http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg14217.html -- Lars Munch - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] evas-framebuffer.pc.in rename
Hi Unfortunately the addition off expedite_check_engine.m4 in expedite broke the detection of the framebuffer engine in expedite. The course of this is an inconsistent naming of the file "evas-framebuffer.pc.in" which should be named "evas-fb.pc.in" to be consistent with the other engine names. The attached patch renames this file an changes Configure.in and Makefile.am in ecore and evas accordingly. A quick grep in the cvs repository indicates that expedite is the only project that actually uses evas-framebuffer.pc, so the breakage of applying this patch should be minimal. Regards Lars Munch diff -urN e17-orig/libs/ecore/configure.in e17/libs/ecore/configure.in --- e17-orig/libs/ecore/configure.in 2008-03-28 15:38:35.0 +0100 +++ e17/libs/ecore/configure.in 2008-04-07 17:32:33.0 +0200 @@ -606,7 +606,7 @@ AC_MSG_RESULT($want_ecore_evas_fb) if test "x$want_ecore_evas_fb" = "xyes"; then -PKG_CHECK_MODULES(EVAS_FRAMEBUFFER, evas-framebuffer, +PKG_CHECK_MODULES(EVAS_FB, evas-fb, [ AC_DEFINE(BUILD_ECORE_EVAS_FB, 1, [Support for Linux FB in Ecore_Evas]) have_ecore_evas_fb="yes" diff -urN e17-orig/libs/evas/configure.in e17/libs/evas/configure.in --- e17-orig/libs/evas/configure.in 2008-03-14 17:49:47.0 +0100 +++ e17/libs/evas/configure.in 2008-04-07 17:31:04.0 +0200 @@ -1560,7 +1560,7 @@ Makefile evas-cairo-x11.pc evas-directfb.pc -evas-framebuffer.pc +evas-fb.pc evas-glitz-x11.pc evas-opengl-glew.pc evas-opengl-x11.pc diff -urN e17-orig/libs/evas/evas-fb.pc.in e17/libs/evas/evas-fb.pc.in --- e17-orig/libs/evas/evas-fb.pc.in 1970-01-01 01:00:00.0 +0100 +++ e17/libs/evas/evas-fb.pc.in 2008-04-07 17:27:53.0 +0200 @@ -0,0 +1,3 @@ +Name: evas-fb +Description: Evas framebuffer engine +Version: @VERSION@ diff -urN e17-orig/libs/evas/evas-framebuffer.pc.in e17/libs/evas/evas-framebuffer.pc.in --- e17-orig/libs/evas/evas-framebuffer.pc.in 2007-03-31 18:07:43.0 +0200 +++ e17/libs/evas/evas-framebuffer.pc.in 1970-01-01 01:00:00.0 +0100 @@ -1,3 +0,0 @@ -Name: evas-framebuffer -Description: Evas framebuffer engine -Version: @VERSION@ diff -urN e17-orig/libs/evas/Makefile.am e17/libs/evas/Makefile.am --- e17-orig/libs/evas/Makefile.am 2008-02-18 08:20:50.0 +0100 +++ e17/libs/evas/Makefile.am 2008-04-07 17:30:25.0 +0200 @@ -10,7 +10,7 @@ README \ evas-cairo-x11.pc \ evas-directfb.pc \ - evas-framebuffer.pc \ + evas-fb.pc \ evas-glitz-x11.pc \ evas-opengl-x11.pc \ evas-opengl-glew.pc \ @@ -36,7 +36,7 @@ evas.pc.in \ evas-cairo-x11.pc \ evas-directfb.pc \ - evas-framebuffer.pc \ + evas-fb.pc \ evas-glitz-x11.pc \ evas-opengl-x11.pc \ evas-opengl-glew.pc \ @@ -72,7 +72,7 @@ endif if BUILD_ENGINE_FB -pframebuffer = evas-framebuffer.pc +pfb = evas-fb.pc endif if BUILD_ENGINE_GLITZ_X11 @@ -125,7 +125,7 @@ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = \ - evas.pc $(psoftwarex11) $(psoftwarexcb) $(pdirectfb) $(pframebuffer) \ + evas.pc $(psoftwarex11) $(psoftwarexcb) $(pdirectfb) $(pfb) \ $(psoftwarebuffer) $(psoftwareqtopia) $(popenglx11) $(pcairox11) \ $(pxrenderx11) $(pxrenderxcb) $(pglitzx11) $(psoftwareddraw) $(psoftwaresdl) \ $(psoftware16x11) $(pdirect3d) $(psoftwared16draw) $(popenglglew) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] three new edje embryo functions
Hi Attached patch adds three new functions to edje/embryo, namely part_raise, part_lower and get_mouse_buttons. Comments? Regrads Lars Munch Index: data/include/edje.inc === RCS file: /var/cvs/e/e17/libs/edje/data/include/edje.inc,v retrieving revision 1.23 diff -u -u -r1.23 edje.inc --- data/include/edje.inc 11 Aug 2007 13:20:33 - 1.23 +++ data/include/edje.inc 5 Apr 2008 18:48:14 - @@ -104,10 +104,13 @@ native get_text_class (class[], font[], &Float:size); native get_geometry (part_id, &x, &y, &w, &h); native get_mouse(&x, &y); +native get_mouse_buttons(); native stop_program (program_id); native stop_programs_on (part_id); native set_min_size (Float:w, Float:h); native set_max_size (Float:w, Float:h); +native part_raise (part_id); +native part_lower (part_id); enum Msg_Type { Index: src/lib/edje_embryo.c === RCS file: /var/cvs/e/e17/libs/edje/src/lib/edje_embryo.c,v retrieving revision 1.59 diff -u -u -r1.59 edje_embryo.c --- src/lib/edje_embryo.c 6 Mar 2008 17:52:58 - 1.59 +++ src/lib/edje_embryo.c 5 Apr 2008 18:48:15 - @@ -794,6 +794,17 @@ return 0; } +/* get_mouse_buttons() */ +static Embryo_Cell +_edje_embryo_fn_get_mouse_buttons(Embryo_Program *ep, Embryo_Cell *params) +{ + Edje *ed; + + CHKPARAM(0); + ed = embryo_program_data_get(ep); + return evas_pointer_button_down_mask_get(ed->evas); +} + /* emit(sig[], src[]) */ static Embryo_Cell _edje_embryo_fn_emit(Embryo_Program *ep, Embryo_Cell *params) @@ -2129,6 +2140,44 @@ return 0; } +/* part_raise(part_id) */ +static Embryo_Cell +_edje_embryo_fn_part_raise(Embryo_Program *ep, Embryo_Cell *params) +{ + int part_id = 0; + Edje *ed; + + CHKPARAM(1); + + part_id = params[1]; + if (part_id < 0) return 0; + + ed = embryo_program_data_get(ep); + + evas_object_raise(ed->obj); + + return 0; +} + +/* part_lower(part_id) */ +static Embryo_Cell +_edje_embryo_fn_part_lower(Embryo_Program *ep, Embryo_Cell *params) +{ + int part_id = 0; + Edje *ed; + + CHKPARAM(1); + + part_id = params[1]; + if (part_id < 0) return 0; + + ed = embryo_program_data_get(ep); + + evas_object_lower(ed->obj); + + return 0; +} + void _edje_embryo_script_init(Edje *ed) { @@ -2192,6 +2241,7 @@ embryo_program_native_call_add(ep, "get_drag_page", _edje_embryo_fn_get_drag_page); embryo_program_native_call_add(ep, "set_drag_page", _edje_embryo_fn_set_drag_page); embryo_program_native_call_add(ep, "get_mouse", _edje_embryo_fn_get_mouse); + embryo_program_native_call_add(ep, "get_mouse_buttons", _edje_embryo_fn_get_mouse_buttons); embryo_program_native_call_add(ep, "stop_program", _edje_embryo_fn_stop_program); embryo_program_native_call_add(ep, "stop_programs_on", _edje_embryo_fn_stop_programs_on); embryo_program_native_call_add(ep, "set_min_size", _edje_embryo_fn_set_min_size); @@ -2203,6 +2253,9 @@ embryo_program_native_call_add(ep, "set_state_val", _edje_embryo_fn_set_state_val); embryo_program_native_call_add(ep, "get_state_val", _edje_embryo_fn_get_state_val); + embryo_program_native_call_add(ep, "part_raise", _edje_embryo_fn_part_raise); + embryo_program_native_call_add(ep, "part_lower", _edje_embryo_fn_part_lower); + // embryo_program_vm_push(ed->collection->script); // _edje_embryo_globals_init(ed); } - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] expedite cross build fix
The attached patch fixes expedite cross build. Without this patch it will look in /usr/include for include files when cross building. Please apply. Regards Lars Munch Index: src/bin/Makefile.am === RCS file: /var/cvs/e/e17/apps/expedite/src/bin/Makefile.am,v retrieving revision 1.12 diff -u -r1.12 Makefile.am --- src/bin/Makefile.am 25 Feb 2008 06:08:34 - 1.12 +++ src/bin/Makefile.am 17 Mar 2008 21:39:29 - @@ -1,6 +1,5 @@ MAINTAINERCLEANFILES = Makefile.in -INCLUDES = -I$(includedir) \ - -I$(top_srcdir) \ +INCLUDES = -I$(top_srcdir) \ -I$(top_srcdir)/src/bin \ @EVAS_CFLAGS@ @x_cflags@ @SDL_CFLAGS@ @DIRECTFB_CFLAGS@ \ -DPACKAGE_BIN_DIR=\"@[EMAIL PROTECTED]" \ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Ecore_Con_Url patch
Almost :) The function _ecore_file_download_abort is still enclosed in the HAVE_CURL ifdef. The attached patch fixes the ramaining issue. Regards Lars Munch On Tue, Mar 11, 2008 at 02:38:07PM +1100, Carsten Haitzler wrote: > On Mon, 10 Mar 2008 17:28:55 +0100 [EMAIL PROTECTED] (Lars Munch) babbled: > > fixed :) > > > On Mon, Mar 10, 2008 at 03:43:04AM +1100, Carsten Haitzler wrote: > > > On Fri, 7 Mar 2008 15:30:07 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> > > > babbled: > > > > > > > As I previously discussed, I did have some issue with evas_render not > > > > being called when my computer receive data too fast. The problem was > > > > the handling of the download prevented ecore to go into idle and call > > > > evas_render. > > > > > > > > To fix this, this patch change the way the fd handler is used. When > > > > some curl data are received, I stop all curl fd handler and setup an > > > > idle handler. This force ecore to go in idle mode and call evas_render > > > > before reading pending data. > > > > > > > > As ecore_file_download suffer the same problem and did want to > > > > maintain two different user of curl library. I added a new interface > > > > to ecore_con_url so that if it can directly write some data to any fd > > > > and used this to reimplement ecore_file_download. This change should > > > > not have a big impact on file download speed but the interface should > > > > stay responsive what ever your computer and your download speed is ! > > > > > > in cvs :) > > > > This patch seems to break linking againts libecore_file.so for me. I am > > building ecore without curl support and after the latest changes in > > ecore_file_download.c I get the following linking errors: > > > > arm-iwmmx-linux-gnueabi/usr/lib/libecore_file.so: undefined reference to > > `_ecore_file_download_abort' > > > > To me it looks like the _ecore_file_download_abort function just needs > > to be moved out of the HAVE_CURL ifdef's. > > > > Regards > > Lars Munch > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] > Index: ./src/lib/ecore_file/ecore_file_download.c === RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore_file/ecore_file_download.c,v retrieving revision 1.20 diff -u -r1.20 ecore_file_download.c --- ./src/lib/ecore_file/ecore_file_download.c 11 Mar 2008 03:38:22 - 1.20 +++ ./src/lib/ecore_file/ecore_file_download.c 11 Mar 2008 06:18:59 - @@ -177,6 +177,17 @@ return 0; } +static void +_ecore_file_download_abort(Ecore_File_Download_Job *job) +{ +#ifdef HAVE_CURL + ecore_con_url_destroy(job->url_con); +#endif + fclose(job->file); + free(job->dst); + free(job); +} + #ifdef HAVE_CURL static int _ecore_file_download_url_compare_job(const void *data1, const void *data2) @@ -230,17 +241,6 @@ return 0; } -static void -_ecore_file_download_abort(Ecore_File_Download_Job *job) -{ -#ifdef HAVE_CURL - ecore_con_url_destroy(job->url_con); -#endif - fclose(job->file); - free(job->dst); - free(job); -} - Ecore_File_Download_Job * _ecore_file_download_curl(const char *url, const char *dst, void (*completion_cb)(void *data, const char *file, - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Ecore_Con_Url patch
On Mon, Mar 10, 2008 at 03:43:04AM +1100, Carsten Haitzler wrote: > On Fri, 7 Mar 2008 15:30:07 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled: > > > As I previously discussed, I did have some issue with evas_render not > > being called when my computer receive data too fast. The problem was > > the handling of the download prevented ecore to go into idle and call > > evas_render. > > > > To fix this, this patch change the way the fd handler is used. When > > some curl data are received, I stop all curl fd handler and setup an > > idle handler. This force ecore to go in idle mode and call evas_render > > before reading pending data. > > > > As ecore_file_download suffer the same problem and did want to > > maintain two different user of curl library. I added a new interface > > to ecore_con_url so that if it can directly write some data to any fd > > and used this to reimplement ecore_file_download. This change should > > not have a big impact on file download speed but the interface should > > stay responsive what ever your computer and your download speed is ! > > in cvs :) This patch seems to break linking againts libecore_file.so for me. I am building ecore without curl support and after the latest changes in ecore_file_download.c I get the following linking errors: arm-iwmmx-linux-gnueabi/usr/lib/libecore_file.so: undefined reference to `_ecore_file_download_abort' To me it looks like the _ecore_file_download_abort function just needs to be moved out of the HAVE_CURL ifdef's. Regards Lars Munch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DirectFB, Intel GDL, Overlays and more
On Sun, Feb 24, 2008 at 10:41:59PM -0300, Gustavo Sverzut Barbieri wrote: > If you have any knowledge of this topic, please help. I'm still a bit > confused about this overlay thing, maybe it's very helpful, as if you > can have a ARGB overlay with my GUI so I port Evas to it, run it as > ARGB surface and play the video on the background from another place. > But maybe it's not like that and it's just a way to get hardware to > output to some region directly (like h264/mpeg2 decoders writing to > it) and I'd have to draw my surface on top of it using colorkey or > retrieving the pixels (possible slow) to do alpha blend, making things > more difficult. On the device I'm working on (PXA270 based) I have 2 overlays, one overlay is an yuv with direct feed from my camera, the other overlay is a RGB 5:5:5 which I'm using for my OSD. Right now I'm rendering my OSD in an evas_buffer and convert/copy the buffer into the overlay when an update is needed. This works pretty well if you don't have to many updates and no edje animations etc on the OSD. -- Lars Munch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC] signal/select race problem in ecore_main
On Sun, Feb 24, 2008 at 07:48:03PM +1100, Carsten Haitzler wrote: > On Sun, 24 Feb 2008 15:43:18 +1100 Carsten Haitzler (The Rasterman) > <[EMAIL PROTECTED]> babbled: > > actually - found a problem. breaks entrance it seems and enlightenment when > init is enabled! :) back! Thanks for testing, too bad it didn't work out as expected. I do not use entrance and have init disabled in enlightenment, so everything was working flawlessly here :/ Anyway, I just did some more testing. It seems that using pselect we have a bigger chance of losing signals. If we get the same signal twice, while not waiting in the pselect call, then only one signal will be handled at the time pselect is called. I guess this could cause the breakage. Do you think that's the issue (I don't know the entrance nor the init code) ? I have no idea how to solve this, except for going back to the pipe solution. -- Lars Munch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC] signal/select race problem in ecore_main
On Tue, Jan 29, 2008 at 09:28:11AM -0600, Nathan Ingersoll wrote: > On Jan 29, 2008 9:14 AM, Lars Munch <[EMAIL PROTECTED]> wrote: > > > > Ok, I might have asked the question wrongly. My current patch already > > calls pselect with an empty set of signals, so signals will only be > > handled when pselect is called. As an alternative we could do: > > > > _ecore_main_select() > > > > 1. block signals > > 2. check signals > > 3. call pselect with an empty set > > 4. unblock signals > > > > that way we can receive/handle signals at (almost) any time (like we do > > now). > > > > The first method has the benefit that we always handle signals at the > > same place and that we can remove a lot of the signal checking stuff > > from the main loop. > > > > The second method has the benefit that the signal handler is called > > almost immediately. > > Ah, I understand your question now. When we receive the signals now, > don't we defer the delivery of those signals anyways? I lean towards > simplifying the code if we can, since signals are asynchronous and > shouldn't be counted on to be delivered in a timely manner, just > in-order. Ok, I will stick with the simple solution and clean up all the signaling checks in the main loop. > > > > > > 2. pselect breaks the win32 port. what is the best way to handle this? > > > > implement our own pselect for win32 using select or use "#ifdef's" ? > > > > > > I believe Vincent is working on a library of win32 work-arounds, maybe > > > he can propose an alternative call for that case. If not, then the > > > pipe method described previously may need to be implemented for win32, > > > or we live with a race condition by emulating pselect like glibc does. > > > > Signals do not exists on windows, so there is no race. The question is > > only if we could use #ifdefs or make a pselect windows function without > > the signal stuff using select. > > Oh, even better. I would probably just add a check to the configure.in > for pselect, and then ifdef to select without the signal mask. Ok, I will try that. Thanks Lars Munch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC] signal/select race problem in ecore_main
On Tue, Jan 29, 2008 at 08:48:42AM -0600, Nathan Ingersoll wrote: > On Jan 29, 2008 8:03 AM, Lars Munch <[EMAIL PROTECTED]> wrote: > > On Sat, Jan 26, 2008 at 01:16:24PM -0600, Nathan Ingersoll wrote: > > > I checked the man page for Mac OS X as well. Looks like pselect() > > > comes from FreeBSD in that case. > > > > Ok, you got me convinced. Attached is a pselect version of the race fix. > > > > Two questions remain: > > > > 1. Do we want to keep all signals blocked except in the pselect call or > > do we want to unblock signals after the pselect call? > > You don't want to maintain the block through the pselect call because > signals should cause it to return before it's expiration time is > reached, so I would block except when inside pselect. Ok, I might have asked the question wrongly. My current patch already calls pselect with an empty set of signals, so signals will only be handled when pselect is called. As an alternative we could do: _ecore_main_select() 1. block signals 2. check signals 3. call pselect with an empty set 4. unblock signals that way we can receive/handle signals at (almost) any time (like we do now). The first method has the benefit that we always handle signals at the same place and that we can remove a lot of the signal checking stuff from the main loop. The second method has the benefit that the signal handler is called almost immediately. > > 2. pselect breaks the win32 port. what is the best way to handle this? > > implement our own pselect for win32 using select or use "#ifdef's" ? > > I believe Vincent is working on a library of win32 work-arounds, maybe > he can propose an alternative call for that case. If not, then the > pipe method described previously may need to be implemented for win32, > or we live with a race condition by emulating pselect like glibc does. Signals do not exists on windows, so there is no race. The question is only if we could use #ifdefs or make a pselect windows function without the signal stuff using select. Thanks for your fast feedback Lars Munch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC] signal/select race problem in ecore_main
On Sat, Jan 26, 2008 at 01:16:24PM -0600, Nathan Ingersoll wrote: > I checked the man page for Mac OS X as well. Looks like pselect() > comes from FreeBSD in that case. Ok, you got me convinced. Attached is a pselect version of the race fix. Two questions remain: 1. Do we want to keep all signals blocked except in the pselect call or do we want to unblock signals after the pselect call? 2. pselect breaks the win32 port. what is the best way to handle this? implement our own pselect for win32 using select or use "#ifdef's" ? Thanks Lars Munch Index: src/lib/ecore/ecore_main.c === RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore/ecore_main.c,v retrieving revision 1.33 diff -u -r1.33 ecore_main.c --- src/lib/ecore/ecore_main.c 26 Jan 2008 10:11:48 - 1.33 +++ src/lib/ecore/ecore_main.c 29 Jan 2008 13:39:27 - @@ -284,34 +284,35 @@ static int _ecore_main_select(double timeout) { - struct timeval tv, *t; - fd_set rfds, wfds, exfds; - intmax_fd; - intret; - Ecore_List2*l; + sigset_temptyset; + struct timespec ts, *t; + fd_set rfds, wfds, exfds; + int max_fd; + int ret; + Ecore_List2 *l; t = NULL; if ((!finite(timeout)) || (timeout == 0.0)) /* finite() tests for NaN, too big, too small, and infinity. */ { - tv.tv_sec = 0; - tv.tv_usec = 0; - t = &tv; + ts.tv_sec = 0; + ts.tv_nsec = 0; + t = &ts; } else if (timeout > 0.0) { - int sec, usec; + int sec, nsec; #ifdef FIX_HZ timeout += (0.5 / HZ); sec = (int)timeout; - usec = (int)((timeout - (double)sec) * 100); + nsec = (int)((timeout - (double)sec) * 10); #else sec = (int)timeout; - usec = (int)((timeout - (double)sec) * 100); + nsec = (int)((timeout - (double)sec) * 10); #endif - tv.tv_sec = sec; - tv.tv_usec = usec; - t = &tv; + ts.tv_sec = sec; + ts.tv_nsec = nsec; + t = &ts; } max_fd = 0; FD_ZERO(&rfds); @@ -350,7 +351,9 @@ } } if (_ecore_signal_count_get()) return -1; - ret = select(max_fd + 1, &rfds, &wfds, &exfds, t); + sigemptyset(&emptyset); + ret = pselect(max_fd + 1, &rfds, &wfds, &exfds, t, &emptyset); + if (ret < 0) { if (errno == EINTR) return -1; Index: src/lib/ecore/ecore_signal.c === RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore/ecore_signal.c,v retrieving revision 1.35 diff -u -r1.35 ecore_signal.c --- src/lib/ecore/ecore_signal.c 26 Aug 2007 11:17:21 - 1.35 +++ src/lib/ecore/ecore_signal.c 29 Jan 2008 13:39:27 - @@ -113,10 +113,37 @@ void _ecore_signal_init(void) { + sigset_t blockset; + int ret; #ifdef SIGRTMIN int i, num = SIGRTMAX - SIGRTMIN; #endif + sigemptyset(&blockset); + sigaddset(&blockset, SIGPIPE); + sigaddset(&blockset, SIGALRM); + sigaddset(&blockset, SIGCHLD); + sigaddset(&blockset, SIGUSR1); + sigaddset(&blockset, SIGUSR2); + sigaddset(&blockset, SIGHUP); + sigaddset(&blockset, SIGQUIT); + sigaddset(&blockset, SIGINT); + sigaddset(&blockset, SIGTERM); +#ifdef SIGPWR + sigaddset(&blockset, SIGPWR); +#endif + +#ifdef SIGRTMIN + for (i = 0; i < num; i++) + sigaddset(&blockset, SIGRTMIN + i); +#endif + + sigprocmask(SIG_BLOCK, &blockset, NULL); + _ecore_signal_callback_set(SIGPIPE, _ecore_signal_callback_ignore); _ecore_signal_callback_set(SIGALRM, _ecore_signal_callback_ignore); _ecore_signal_callback_set(SIGCHLD, _ecore_signal_callback_sigchld); - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] keyboard - emodule idea.
Hi You can also use the linux "uinput" driver to generate key input. Nice article about uinput: http://www.einfochips.com/download/dash_jan_tip.pdf Regards Lars Munch On Sun, Jan 27, 2008 at 01:41:19PM +0100, Thomas Gstädtner wrote: > I'm trying to do a on screen keyboad for mobile phones (not suitable for > tablet pcs) in edje. > Raster said he'd want to write a qwerty-keyboard, too, don't know if he > still has that plan. > As a hint, there is a lib named "libfakekey" that could be usable if you > write your own, it's part of the matchbox project by OpenedHand. > > On 1/27/08, Grzegorz And <[EMAIL PROTECTED]> wrote: > > > > Hello. > > > > Recently I'm playing with some Tablet PC. With touchscreen of course. E17 > > of course. And I figured out that module with pop up touch keyboard could be > > very usefull on such system. > > > > Maybe somebody could write something like that? Maybe sombody is writing > > it already? If not where I should start? Which EFL use? > > > > -- > > GAndrel > > -- > > Pt! Schon vom neuen GMX MultiMessenger gehört? > > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger > > > > - > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC] signal/select race problem in ecore_main
On Fri, Jan 25, 2008 at 07:43:47AM -0300, Gustavo Sverzut Barbieri wrote: > On Jan 25, 2008 12:40 AM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > On Fri, 25 Jan 2008 00:11:41 -0300 "Gustavo Sverzut Barbieri" > > <[EMAIL PROTECTED]> babbled: > > > > > > > On Jan 24, 2008 11:42 PM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > > > > On Jan 24, 2008 7:18 PM, The Rasterman Carsten Haitzler > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > now i think this is a bit more generic a solution - but it adds > > > > > overhead. > > > > > so what about the pselect() method? anyone got input on that? > > > > > > > > Basically, pselect() is designed for exactly this situation. You block > > > > all of the signals you're going to handle during init or some other > > > > very early point, then you pass a mask of the signals you're going to > > > > unblock to pselect(). At this point, pselect() will atomically unblock > > > > the specified signals and call select() with the specified fd's, it > > > > also re-instates the original signal blocks after select() returns. > > > > Since this sequence is atomic, it prevents the race condition we > > > > currently have. > > > > > > > > Now the problem, this is a good solution on BSD and Solaris, but > > > > unfortunately Linux only fakes support for pselect() (unless this was > > > > fixed recently). On Linux pselect() is actually a wrapper exactly > > > > around the sequence sigprocmask(), select() sigprocmask(). So we still > > > > end up with a race condition between the first sigprocmask() call and > > > > the select() call. > > > > > > man page says: > > > > > > BUGS: > > > Since version 2.1, glibc has provided an emulation of pselect() > > > that is implemented using sigprocmask(2) and select(). > > >This implementation remains vulnerable to the very race > > > condition that pselect() was designed to prevent. On systems > > >that lack pselect() reliable (and more portable) signal > > > trapping can be achieved using the self-pipe trick (where a > > >signal handler writes a byte to a pipe whose other end is > > > monitored by select() in the main program.) > > > > > > > > > however a bit earlier it says Linux has pselect(), and at least 2.6.23 > > > implements it... so maybe this wrapper is just used as a fallback? > > > > that is the question - is it implemented kernel-wise widely enough to use > > it? > > or do we just stick to the old-fashioned self-pipe trick? > > I have not audited the Linux or GlibC code to check if that's the case > (well implemented), but I truly believe that we can rely on this call > for newer (> 2.6) kernels. > Thanks for your comments and suggestions. I thinks I'll go with the pipe solution as I think there are too many unknowns with pselect: will it work if we build againts uclibc, newlib or klibc? or build on BSD or Solaris systems etc? Regards -- Lars Munch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH][RFC] signal/select race problem in ecore_main
Hi While working on suspend/resume on my embedded system I ran into to the race problem between select and signals. See this link for a description of the problem: http://www.xs4all.nl/~evbergen/unix-signals.html The problem is that the following code in ecore_main_select is not an atomic operation and could end up in select waiting forever even though there is a signal to be served and put in the event queue: if (_ecore_signal_count_get()) return -1; ret = select(max_fd + 1, &rfds, &wfds, &exfds, t); My proposed solution (see attached patch) is something similar to that described in above link, namely to create a pipe to flag a signal arrival to select. NOTE: the attached patch currently only handles sigusr1 and sigusr2 and has almost no error checking. As far as I can tell, the attached patch still have a race around sig_count and sigXXX_count. I thought about adding the signal number to the signal pipe to avoid this race, but that solution could result in pipe buffer overflow and then signals would get lost. Before I continue working on this patch, I really like your comments and suggestions. Thanks -- Lars Munch Index: src/lib/ecore/ecore_signal.c === RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore/ecore_signal.c,v retrieving revision 1.35 diff -u -r1.35 ecore_signal.c --- src/lib/ecore/ecore_signal.c 26 Aug 2007 11:17:21 - 1.35 +++ src/lib/ecore/ecore_signal.c 23 Jan 2008 15:53:28 - @@ -60,6 +60,9 @@ static volatile siginfo_t *sigrt_info = NULL; #endif +static int pipe_fd[2]; +static Ecore_Fd_Handler *pipe_handler; + void _ecore_signal_shutdown(void) { @@ -110,13 +113,52 @@ #endif } +static void +_ecore_signal_pipe_fd_flag() +{ + int count; + char f = 1; + + /* Empty signal pipe completely */ + for(count = 0; read(pipe_fd[0], &f, sizeof(f)) > 0; count++) ; + + /* Put one flag into signal pipe */ + write(pipe_fd[1], &f, sizeof(f)); +} + +static int +_ecore_signal_pipe_fb_callback(void *data, Ecore_Fd_Handler *fdh) +{ + int count; + char f; + + /* Empty signal pipe completely */ + for(count = 0; read(fdh->fd, &f, sizeof(f)) > 0; count++) ; + + if(count) + _ecore_signal_call(); + + return 1; +} + void _ecore_signal_init(void) { + int ret; #ifdef SIGRTMIN int i, num = SIGRTMAX - SIGRTMIN; #endif + ret = pipe(pipe_fd); + assert(!ret); + + fcntl(pipe_fd[0], F_SETFL, O_NONBLOCK); + fcntl(pipe_fd[1], F_SETFL, O_NONBLOCK); + + pipe_handler = ecore_main_fd_handler_add(pipe_fd[0], ECORE_FD_READ, + _ecore_signal_pipe_fb_callback, + NULL, NULL, NULL); + _ecore_signal_callback_set(SIGPIPE, _ecore_signal_callback_ignore); _ecore_signal_callback_set(SIGALRM, _ecore_signal_callback_ignore); _ecore_signal_callback_set(SIGCHLD, _ecore_signal_callback_sigchld); @@ -401,6 +443,8 @@ else sigusr1_info.si_signo = 0; + _ecore_signal_pipe_fd_flag(); + sigusr1_count++; sig_count++; } @@ -413,6 +457,8 @@ else sigusr2_info.si_signo = 0; + _ecore_signal_pipe_fd_flag(); + sigusr2_count++; sig_count++; } - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] ecore_evas_fb crash fix
Hi This small patch fixes a crash in ecore_evas_fb when there are no input devices in /dev/input. Please apply -- Lars Munch Index: src/lib/ecore_evas/ecore_evas_fb.c === RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore_evas/ecore_evas_fb.c,v retrieving revision 1.29 diff -u -r1.29 ecore_evas_fb.c --- src/lib/ecore_evas/ecore_evas_fb.c 26 Sep 2007 15:41:50 - 1.29 +++ src/lib/ecore_evas/ecore_evas_fb.c 17 Nov 2007 16:16:06 - @@ -74,6 +74,7 @@ ee = (Ecore_Evas *)l; ee->visible = 0; } + if(!ecore_evas_input_devices) return; ecore_list_first_goto(ecore_evas_input_devices); dev = ecore_list_current(ecore_evas_input_devices); do @@ -99,6 +100,7 @@ else evas_damage_rectangle_add(ee->evas, 0, 0, ee->w, ee->h); } + if(!ecore_evas_input_devices) return; ecore_list_first_goto(ecore_evas_input_devices); dev = ecore_list_current(ecore_evas_input_devices); do - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: > On 7/14/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > Ok, it turned out to be easy to extend this with mouse_grab idea, I'd > like some review on these patches, but I've tested them together with > an etk application (edje_viewer) and it seems to work fine. > > Patches are attached as TXT so gmail recognizes them as text/plain and > avoid them being stripped by e-devel mail list. > > Notice that edje property is no_mouse_grab, because then we can keep > compatibility with existent .edj files. Can't you just call it mouse_grab and default it to 1 to keep compatibility? Regards Lars Munch - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
Hi Gustavo On Fri, Jul 13, 2007 at 07:53:58PM -0300, Gustavo Sverzut Barbieri wrote: > Ok, reading evas docs it's really the expected behavior, at least it's > documented: > > * EVAS_CALLBACK_MOUSE_OUT: event_info = pointer to > Evas_Event_Mouse_Out * * ... Note that no out events will be * > reported if the mouse pointer is implicitly grabbed to an object (the > * mouse buttons are down at all and any were pressed on that object). > An * out event will be reported as soon as the mouse is no longer > grabbed (no * mouse buttons are depressed). Out events will be > reported once all buttons * are released, if the mouse has left the > object. > > > So, how to solve it without brake every existent thing that depends on > this? As you can see from this post I had a similar problem some months ago: http://article.gmane.org/gmane.comp.window-managers.enlightenment.devel/12444/match= I was also creating a virtual keyboard for a touchscreen and it was also highly inspirred by the iPhone keyboard. I think the current behaviour are good for some parts like sliders, but for other pars like push buttons I would like to be able to get an out event as soon at the mouse leaves the part (clicked or not). Maybe we could add an ungrab or regrab function? Regards Lars Munch - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] ecore tslib configure.in fix
Hi If I build ecore with fb engine enabled on a system with tslib installed I get a linker error because it tries to link against "tslib" instead of "ts". The attached patch fixes this. I thought about removing tslib from configure.in since it is currently not used, but I have a feeling that support for tslib will appear sometime in the near future. Please apply. -- Lars Munch Index: ecore/configure.in === RCS file: /var/cvs/e/e17/libs/ecore/configure.in,v retrieving revision 1.191 diff -u -r1.191 configure.in --- ecore/configure.in 4 Apr 2007 12:28:16 - 1.191 +++ ecore/configure.in 4 Apr 2007 13:44:30 - @@ -238,7 +238,7 @@ if test "x$have_ecore_fb" = "xyes" ; then AC_CHECK_HEADER(tslib.h, [ - tslib_libs="-ltslib" + tslib_libs="-lts" AC_DEFINE(HAVE_TSLIB, 1, [Build Ecore_FB Touchscreen Code]) ] ) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
On Wed, Apr 04, 2007 at 10:46:41AM -0500, Brian Mattern wrote: > On Wed, Apr 04, 2007 at 02:39:12PM +0200, Massimiliano Calamelli wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Wed, 04 Apr 2007 14:29:06 +0200 > > Sebastian Dransfeld <[EMAIL PROTECTED]> wrote: > > > > > It is possible to disable abstract sockets now. It is only used in > > > ecore_dbus, and I think ecore_dbus will die soon. > > > > > > Sebastian > > > > Already disabled with --disable-ecore-dbus, but configure check it > > again. > > > > I added the abstract socket code and the macro to check for it. I have > no experience with cross-compiling, so didn't know that it would be an > issue. > > Disabling ecore_dbus won't help because the feature is in ecore_con. > Someone just needs to add a configure option to explicitly disable (thus > avoiding the check) or determine another means of checking that also > works when cross compiling. > > If no one else gets to it, I'll try to look in the next few days. Sebastian already added an --disable-abstract-sockets option that does the trick. Thanks Sebastian. -- Lars Munch - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
Hi Massi On Wed, Apr 04, 2007 at 01:03:56PM +0200, Massimiliano Calamelli wrote: > Hi all, i'm try to crosscompile ecore for my arm device, but configure > stops with this error: > checking abstract sockets... > configure: error: cannot run test program while cross compiling > > I looked into config.log, but i can't find any useful info. What's the > requirement for abstract sockets? I need ecore only for evas, > evas-framebuffer and events capabilities (at this moment), there's a > way to disable this check? I have the same problem and I simply removed the abstract sockets stuff from configure.in because I dont need it (yet). But what we really need is a --with-abstract-sockets or similar option. See previous discussion about this: http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg11743.html Perhaps we could bribe some skilled autoconf person to add this configure option for us? -- Lars Munch - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] More changes to Ecore_Fb
Hi turran On Tue, Mar 27, 2007 at 02:39:12PM +0200, Jorge Luis Zapata Muga wrote: > Hi all, i have coded several things to ecore_fb, but before doing a > commit i prefer your opinion or whishlist =) > > 1. Modules for input devices. Instead of having the input devices > exclusive (linux_input or ps2/keyboard/tslib combo), ive made an > abstraction to support input "modules" (for now they are just > statically linked - its a similar approach to what evas had on the > beginning with engines). For now we don't need real modules because > the input modules is the only module type we have. > > 2. More Input Devices: A while ago i coded the linux_input (event > devices) support and replace the input devices that were on ecore_fb > (tslib, keyboard, ps2) to support multiple devices (i.e two mice, > three keyboards, whatever). I've re-enabled the replaced ones, > following the module approach. > > 3. Support for keyboard layouts, in ecore_fb the keyboard layout was > hard coded to english layout (ascii values only), with this code we > can use different layouts (spanish, french, or your own), it was coded > following the keymaps(5) idea. Ive also made a parser for keymaps (the > files you have under /usr/share/keymaps/) which will export a c source > file for now, i want to also export an eet file, but it wont be done > until my eet patch gets in. btw, where's a good place to put this > application? under /src/bin of ecore? on tests dir in cvs? > > 4. Support for not allocating a virtual terminal (in case there's no > console attached to the fb) and code to specify which fb device to > use. > > I still have one doubt with all of this, ecore_fb will have a lot of > flexibility (input devices, fb to use, vt to allocate, etc) so it will > fit very well for embedded/specific platforms. But we need a way to > set up the configuration for libs/apps working with ecore_fb like > ecore_evas or etk, does it makes sense to also create some kind of > configuration file with a fallback in case none exists? if so, eet, > plain text? IMHO a plain text config is preferable since the configuration will be platform specific and not library/application specific and therefore must be editable without some special tool. I have one wish: I have been working on support for absolute coordinates for my touchscreen and have the basics working but without calibration. We need some way of calibrating a specific input device as this is not possible with current framework. I am looking forward to seeing the code. -- Lars Munch - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Mouse in/out behaviour
Hi All I have noticed that no mouse in/out events will be reported while a mouse button is down, but I need a different behaviour on certain objects in a small application that I am writing. What I really like to do is: press the mouse button down on one object and while the mouse button is down I move the mouse over another object. As soon as the mouse leaves the first object I would like to have a "mouse,out" event and as soon as the mouse enters the second object I like to have a "mouse,in" event, even thought my mouse button is never released. How can I achieve this behaviour? Is there some way of moving mouse grab from one object to another? Thanks Lars Munch - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Strange (for me) issue on evas/fb app
Hi What color space are you using? If evas do not have the right color convertion function it will seg. fault without warning. -- Lars Munch On Wed, Mar 14, 2007 at 05:17:26PM +0100, Massimiliano Calamelli wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, finally i'm able to test my EFL code under my ARM-based devel > board. My target is to be able to have a crosscc edje, therefore i've > started at the bottom, in order eet, evas, ecore and finally edje. > cross-eet works well, my problem is evas. I wrote a simple app (see > main.c attached) with a lot of printf for debugging (at this moment i > haven't gdbserver working on target, damn), and here's a cut&paste from > my target console when i run my app. > > /sbin # sb_evas1 > Evas inizializzato. > Evas canvas istanziato. > Engine disponibili: > fb > buffer > Framebuffer disponibile. > Output method: 1 > Step1 ! > Segmentation fault > > Looking in the code, it seems that the segfault happens at > evas_output_method_set(evas, output_method) > > Can anyone help me? > > TIA > > Massi > - -- > Massimiliano Calamelli > http://mcalamelli.netsons.org > [EMAIL PROTECTED] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.4 (MingW32) > > iD8DBQFF+CAWleGEL56NNP4RAgcOAKC5vjVmBQr7zIgDVAFiU186rhoEZACfaEnp > lep70T9fCn+ZOu8rEpvCe7g= > =Ik3L > -END PGP SIGNATURE- > #include > #include > #include > #include > > int main (int argc, char **argv) { > Evas *evas; > Evas_List *engine_list, *l; > Evas_Object *line1, *line2, *line3, *line4; > > int rot = 0; > int output_method = 0; > > if (!evas_init()) { > printf("Impossibile inizializzare Evas.\n"); > return -1; > } > printf("Evas inizializzato.\n"); > > evas = evas_new(); > if (!evas) { > printf("Impossibile istanziare Evas canvas.\n"); > return -1; > } > printf("Evas canvas istanziato.\n"); > > engine_list = evas_render_method_list(); > if (!engine_list) { > fprintf(stderr, "Nessun engines supportato.\n"); > exit(-1); > } > printf("Engine disponibili:\n"); > for (l = engine_list; l; l = l->next) { > char *engine_name; > > engine_name = l->data; > printf("%s\n", engine_name); > } > evas_render_method_list_free(engine_list); > > output_method = evas_render_method_lookup("fb"); > > if (output_method == 0) { > printf("Framebuffer non disponibile.\n"); > return -1; > } > printf("Framebuffer disponibile.\n"); > > printf("Output method: %d\n", output_method); > printf("Step1 !\n"); > evas_output_method_set(evas, output_method); > printf("Step2 !\n"); > evas_output_size_set(evas, 640, 480); > printf("Step3 !\n"); > evas_output_viewport_set(evas, 0, 0, 640, 480); > printf("Step4 !\n"); > > Evas_Engine_Info_FB *einfo; > einfo = (Evas_Engine_Info_FB *) evas_engine_info_get(evas); > if (!einfo) { > printf("Errore nelle info dell'engine.\n"); > return -1; > } > printf("Info sull'engine OK.\n"); > einfo->info.virtual_terminal = 0; > einfo->info.device_number = 0; > einfo->info.refresh = 0; > einfo->info.rotation = rot; > evas_engine_info_set(evas, (Evas_Engine_Info *) einfo); > > line1 = evas_object_line_add(evas); > evas_object_color_set(line1, 255, 255, 0, 0); > line2 = evas_object_line_add(evas); > evas_object_color_set(line2, 255, 255, 0, 0); > line3 = evas_object_line_add(evas); > evas_object_color_set(line3, 255, 255, 0, 0); > line4 = evas_object_line_add(evas); > evas_object_color_set(line4, 255, 255, 0, 0); > > evas_object_line_xy_set(line1, 10, 10, 630, 10); > evas_object_line_xy_set(line2, 630, 10, 630, 470); > evas_object_line_xy_set(line3, 10, 470, 630, 470); > evas_object_line_xy_set(line4, 10, 10, 10, 470); > > evas_object_show(line1); > evas_object_show(line2); > evas_object_show(line3); > evas_object_show(line4); > > evas_render(evas); > > evas_shutdown(); > return 0; > } > - > Take Surveys. Earn Cash. Influence the Future of IT > Joi
[E-devel] [PATCH] Add 16bpp and 32bpp Rotation 180 Converter Code
Hi The attached patch adds 16bpp and 32bpp Rotation 180 Converter Code to evas. I did not add the 180 degrees rotation to the software_qtopia engine as I cannot test it at the moment. Please apply. -- Lars Munch Index: configure.in === RCS file: /var/cvs/e/e17/libs/evas/configure.in,v retrieving revision 1.200 diff -p -u -r1.200 configure.in --- configure.in 10 Feb 2007 17:23:05 - 1.200 +++ configure.in 17 Feb 2007 20:28:48 - @@ -1602,6 +1602,29 @@ AC_ARG_ENABLE(convert-16-rgb-rot-0, ) ### +## Convert to 16bpp RGB with rotation of 180 +conv_16_rgb_rot_180="no" +conv_16_rgb_rot_180="yes" +AC_MSG_CHECKING(whether to build 16bpp rotation 180 converter code) +AC_ARG_ENABLE(convert-16-rgb-rot-180, + [ --enable-convert-16-rgb-rot-180 enable 16bpp rotation 180 converter code], [ + if test x"$enableval" = x"yes" ; then +AC_MSG_RESULT(yes) +AC_DEFINE(BUILD_CONVERT_16_RGB_ROT180, 1, [16bpp Rotation 180 Converter Code]) +conv_16_rgb_rot_180="yes" + else +AC_MSG_RESULT(no) +conv_16_rgb_rot_180="no" + fi + ], [ + AC_MSG_RESULT($conv_16_rgb_rot_180) + if test x"$conv_16_rgb_rot_180" = x"yes" ; then +AC_DEFINE(BUILD_CONVERT_16_RGB_ROT180, 1, [16bpp Rotation 180 Converter Code]) + fi + ] +) + +### ## Convert to 16bpp RGB with rotation of 270 conv_16_rgb_rot_270="no" conv_16_rgb_rot_270="yes" @@ -1809,6 +1832,29 @@ AC_ARG_ENABLE(convert-32-rgb-rot-0, ) ### +## Convert to 32bpp RGB with rotation of 180 +conv_32_rgb_rot_180="no" +conv_32_rgb_rot_180="yes" +AC_MSG_CHECKING(whether to build 32bpp rotation 180 converter code) +AC_ARG_ENABLE(convert-32-rgb-rot-180, + [ --enable-convert-32-rgb-rot-180 enable 32bpp rotation 180 converter code], [ + if test x"$enableval" = x"yes" ; then +AC_MSG_RESULT(yes) +AC_DEFINE(BUILD_CONVERT_32_RGB_ROT180, 1, [32bpp Rotation 180 Converter Support]) +conv_32_rgb_rot_180="yes" + else +AC_MSG_RESULT(no) +conv_32_rgb_rot_180="no" + fi + ], [ + AC_MSG_RESULT($conv_32_rgb_rot_180) + if test x"$conv_32_rgb_rot_180" = x"yes" ; then +AC_DEFINE(BUILD_CONVERT_32_RGB_ROT180, 1, [32bpp Rotation 180 Converter Support]) + fi + ] +) + +### ## Convert to 32bpp RGB with rotation of 270 conv_32_rgb_rot_270="no" conv_32_rgb_rot_270="yes" @@ -2078,8 +2124,8 @@ echo " 16bpp RGB 565 (444 ipaq): $conv_ # FIXME: add 8bpp and below rotation echo " 16bpp Rotation 0: $conv_16_rgb_rot_0" echo " 16bpp Rotation 90...: $conv_16_rgb_rot_90" +echo " 16bpp Rotation 180..: $conv_16_rgb_rot_180" echo " 16bpp Rotation 270..: $conv_16_rgb_rot_270" -# FIXME: add 180 rotation echo " 24bpp RGB 888...: $conv_24_rgb_888" echo " 24bpp BGR 888...: $conv_24_bgr_888" # FIXME: add 24bpp rotation @@ -2089,8 +2135,8 @@ echo " 32bpp BGR ..: $conv_ echo " 32bpp BGRX .: $conv_32_bgrx_" echo " 32bpp Rotation 0: $conv_32_rgb_rot_0" echo " 32bpp Rotation 90...: $conv_32_rgb_rot_90" +echo " 32bpp Rotation 180..: $conv_32_rgb_rot_180" echo " 32bpp Rotation 270..: $conv_32_rgb_rot_270" -# FIXME: add 180 rotation echo echo "" echo Index: src/lib/engines/common/evas_convert_main.c === RCS file: /var/cvs/e/e17/libs/evas/src/lib/engines/common/evas_convert_main.c,v retrieving revision 1.7 diff -p -u -r1.7 evas_convert_main.c --- src/lib/engines/common/evas_convert_main.c 10 Feb 2007 17:23:06 - 1.7 +++ src/lib/engines/common/evas_convert_main.c 17 Feb 2007 20:28:50 - @@ -208,6 +208,15 @@ evas_common_convert_func_get(DATA8 *dest return evas_common_convert_rgba_to_16bpp_rgb_565_dith; } #endif +#ifdef BUILD_CONVERT_16_RGB_ROT180 + if (rotation == 180) + { + if ((!(w & 0x1)) && (!((int)dest & 0x3))) + return evas_common_convert_rgba2_to_16bpp_rgb_565_dith_rot_180; + else + return evas_common_convert_rgba_to_16bpp_rgb_565_dith_rot_180; + } +#endif #ifdef BUILD_CONVERT_16_RGB_ROT270 if (rotation == 270) { @@ -240,6 +249,15 @@ evas_common_convert_func_get(DATA8 *dest return evas_common_convert_rgba_to_16bpp_bgr_565_dith; } #endif +#ifdef BUILD_CONVERT_16_RGB_ROT180 + if (rotation == 180) + { +
[E-devel] [PATCH] Fix fb rotation in ecore
Hi The attached patch fixes framebuffer rotation in ecore_evas_fb.c. The correct output/viewport size was not set in the init and resize functions of the ecore_evas when the rotation was 90 or 270 degrees. Please apply. -- Lars Munch Index: ./src/lib/ecore_evas/ecore_evas_fb.c === RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore_evas/ecore_evas_fb.c,v retrieving revision 1.23 diff -p -u -r1.23 ecore_evas_fb.c --- ./src/lib/ecore_evas/ecore_evas_fb.c 16 Jan 2007 10:17:46 - 1.23 +++ ./src/lib/ecore_evas/ecore_evas_fb.c 11 Feb 2007 11:36:15 - @@ -105,7 +105,10 @@ _ecore_evas_fb_gain(void *data __UNUSED_ ee = (Ecore_Evas *)l; ee->visible = 1; - evas_damage_rectangle_add(ee->evas, 0, 0, ee->w, ee->h); + if ((ee->rotation == 90) || (ee->rotation == 270)) + evas_damage_rectangle_add(ee->evas, 0, 0, ee->h, ee->w); + else + evas_damage_rectangle_add(ee->evas, 0, 0, ee->w, ee->h); } ecore_list_goto_first(ecore_evas_input_devices); dev = ecore_list_current(ecore_evas_input_devices); @@ -325,9 +328,18 @@ _ecore_evas_resize(Ecore_Evas *ee, int w if ((w == ee->w) && (h == ee->h)) return; ee->w = w; ee->h = h; - evas_output_size_set(ee->evas, ee->w, ee->h); - evas_output_viewport_set(ee->evas, 0, 0, ee->w, ee->h); - evas_damage_rectangle_add(ee->evas, 0, 0, ee->w, ee->h); + if ((ee->rotation == 90) || (ee->rotation == 270)) + { + evas_output_size_set(ee->evas, ee->h, ee->w); + evas_output_viewport_set(ee->evas, 0, 0, ee->h, ee->w); + evas_damage_rectangle_add(ee->evas, 0, 0, ee->h, ee->w); + } + else + { + evas_output_size_set(ee->evas, ee->w, ee->h); + evas_output_viewport_set(ee->evas, 0, 0, ee->w, ee->h); + evas_damage_rectangle_add(ee->evas, 0, 0, ee->w, ee->h); + } if (ee->func.fn_resize) ee->func.fn_resize(ee); } @@ -337,9 +349,18 @@ _ecore_evas_move_resize(Ecore_Evas *ee, if ((w == ee->w) && (h == ee->h)) return; ee->w = w; ee->h = h; - evas_output_size_set(ee->evas, ee->w, ee->h); - evas_output_viewport_set(ee->evas, 0, 0, ee->w, ee->h); - evas_damage_rectangle_add(ee->evas, 0, 0, ee->w, ee->h); + if ((ee->rotation == 90) || (ee->rotation == 270)) + { + evas_output_size_set(ee->evas, ee->h, ee->w); + evas_output_viewport_set(ee->evas, 0, 0, ee->h, ee->w); + evas_damage_rectangle_add(ee->evas, 0, 0, ee->h, ee->w); + } + else + { + evas_output_size_set(ee->evas, ee->w, ee->h); + evas_output_viewport_set(ee->evas, 0, 0, ee->w, ee->h); + evas_damage_rectangle_add(ee->evas, 0, 0, ee->w, ee->h); + } if (ee->func.fn_resize) ee->func.fn_resize(ee); } @@ -611,9 +632,18 @@ ecore_evas_fb_new(char *disp_name, int r ee->evas = evas_new(); evas_data_attach_set(ee->evas, ee); evas_output_method_set(ee->evas, rmethod); - evas_output_size_set(ee->evas, w, h); - evas_output_viewport_set(ee->evas, 0, 0, w, h); - + + if ((rotation == 90) || (rotation == 270)) + { + evas_output_size_set(ee->evas, h, w); + evas_output_viewport_set(ee->evas, 0, 0, h, w); + } + else + { + evas_output_size_set(ee->evas, w, h); + evas_output_viewport_set(ee->evas, 0, 0, w, h); + } + einfo = (Evas_Engine_Info_FB *)evas_engine_info_get(ee->evas); if (einfo) { - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Add bgr 565 convert support to evas
On Sun, Feb 11, 2007 at 02:03:54AM +0900, Carsten Haitzler wrote: > On Sat, 10 Feb 2007 15:02:18 +0100 [EMAIL PROTECTED] (Lars Munch) babbled: > > > On Sat, Feb 10, 2007 at 06:12:38AM +0900, Carsten Haitzler wrote: > > > On Sun, 4 Feb 2007 20:10:32 +0100 [EMAIL PROTECTED] (Lars Munch) babbled: > > > > > > > Hi > > > > > > > > The attached patch adds "16bpp BGR 565 Converter Support" to evas. > > > > > > > > Please apply. > > > > > > what hardware did you find that does bgr565? > > > > > > > The ARM PrimeCell PL110 Color LCD Controller which is found on some > > systems. Qemu's arm system emulation is based on this chip, so I need > > this patch when doing EFL framebuffer development in Qemu's arm system > > emulation. > > oooh - how interesting. all the other arm based 16bpp 565 displays i've seen > are RGB565 nor BGR565. The PL110 can actually run in both modes. --- Lars Munch - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Add bgr 565 convert support to evas
On Sat, Feb 10, 2007 at 06:12:38AM +0900, Carsten Haitzler wrote: > On Sun, 4 Feb 2007 20:10:32 +0100 [EMAIL PROTECTED] (Lars Munch) babbled: > > > Hi > > > > The attached patch adds "16bpp BGR 565 Converter Support" to evas. > > > > Please apply. > > what hardware did you find that does bgr565? > The ARM PrimeCell PL110 Color LCD Controller which is found on some systems. Qemu's arm system emulation is based on this chip, so I need this patch when doing EFL framebuffer development in Qemu's arm system emulation. -- Lars Munch - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Add bgr 565 convert support to evas
Hi The attached patch adds "16bpp BGR 565 Converter Support" to evas. Please apply. -- Lars Munch Index: configure.in === RCS file: /var/cvs/e/e17/libs/evas/configure.in,v retrieving revision 1.199 diff -p -u -r1.199 configure.in --- configure.in 4 Dec 2006 20:34:29 - 1.199 +++ configure.in 4 Feb 2007 20:09:29 - @@ -1444,12 +1444,12 @@ AC_ARG_ENABLE(convert-8-rgb-111, ## Convert to 16bpp RGB 565 conv_16_rgb_565="no" conv_16_rgb_565="yes" -AC_MSG_CHECKING(whether to build 16bpp 565 converter code) +AC_MSG_CHECKING(whether to build 16bpp 565 rgb converter code) AC_ARG_ENABLE(convert-16-rgb-565, - [ --enable-convert-16-rgb-565 enable 16bpp 565 converter code], [ + [ --enable-convert-16-rgb-565 enable 16bpp rgb 565 converter code], [ if test x"$enableval" = x"yes" ; then AC_MSG_RESULT(yes) -AC_DEFINE(BUILD_CONVERT_16_RGB_565, 1, [16bpp 565 Converter Support]) +AC_DEFINE(BUILD_CONVERT_16_RGB_565, 1, [16bpp RGB 565 Converter Support]) conv_16_rgb_565="yes" else AC_MSG_RESULT(no) @@ -1458,7 +1458,30 @@ AC_ARG_ENABLE(convert-16-rgb-565, ], [ AC_MSG_RESULT($conv_16_rgb_565) if test x"$conv_16_rgb_565" = x"yes" ; then -AC_DEFINE(BUILD_CONVERT_16_RGB_565, 1, [16bpp 565 Converter Support]) +AC_DEFINE(BUILD_CONVERT_16_RGB_565, 1, [16bpp RGB 565 Converter Support]) + fi + ] +) + +### +## Convert to 16bpp BGR 565 +conv_16_bgr_565="no" +conv_16_bgr_565="yes" +AC_MSG_CHECKING(whether to build 16bpp 565 bgr converter code) +AC_ARG_ENABLE(convert-16-bgr-565, + [ --enable-convert-16-bgr-565 enable 16bpp bgr 565 converter code], [ + if test x"$enableval" = x"yes" ; then +AC_MSG_RESULT(yes) +AC_DEFINE(BUILD_CONVERT_16_BGR_565, 1, [16bpp BGR 565 Converter Support]) +conv_16_bgr_565="yes" + else +AC_MSG_RESULT(no) + conv_16_bgr_565="no" + fi + ], [ + AC_MSG_RESULT($conv_16_bgr_565) + if test x"$conv_16_bgr_565" = x"yes" ; then +AC_DEFINE(BUILD_CONVERT_16_BGR_565, 1, [16bpp BGR 565 Converter Support]) fi ] ) @@ -2020,6 +2043,7 @@ echo " 8bpp RGB 121: $conv_ echo " 8bpp RGB 111: $conv_8_rgb_111" # FIXME: add grayscale and B&W support echo " 16bpp RGB 565...: $conv_16_rgb_565" +echo " 16bpp BGR 565...: $conv_16_bgr_565" echo " 16bpp RGB 555...: $conv_16_rgb_555" echo " 16bpp RGB 444...: $conv_16_rgb_444" echo " 16bpp RGB 565 (444 ipaq): $conv_16_rgb_ipq" Index: src/lib/engines/common/evas_convert_main.c === RCS file: /var/cvs/e/e17/libs/evas/src/lib/engines/common/evas_convert_main.c,v retrieving revision 1.6 diff -p -u -r1.6 evas_convert_main.c --- src/lib/engines/common/evas_convert_main.c 6 Sep 2006 07:33:39 - 1.6 +++ src/lib/engines/common/evas_convert_main.c 4 Feb 2007 20:09:31 - @@ -228,6 +228,38 @@ evas_common_convert_func_get(DATA8 *dest #endif } #endif +#ifdef BUILD_CONVERT_16_BGR_565 + if ((rmask == 0x001f) && (gmask == 0x07e0) && (bmask == 0xf800)) + { +#ifdef BUILD_CONVERT_16_RGB_ROT0 + if (rotation == 0) + { + if ((!(w & 0x1)) && (!((int)dest & 0x3))) + return evas_common_convert_rgba2_to_16bpp_bgr_565_dith; + else + return evas_common_convert_rgba_to_16bpp_bgr_565_dith; + } +#endif +#ifdef BUILD_CONVERT_16_RGB_ROT270 + if (rotation == 270) + { + if ((!(w & 0x1)) && (!((int)dest & 0x3))) + return evas_common_convert_rgba2_to_16bpp_bgr_565_dith_rot_270; + else + return evas_common_convert_rgba_to_16bpp_bgr_565_dith_rot_270; + } +#endif +#ifdef BUILD_CONVERT_16_RGB_ROT90 + if (rotation == 90) + { + if ((!(w & 0x1)) && (!((int)dest & 0x3))) + return evas_common_convert_rgba2_to_16bpp_bgr_565_dith_rot_90; + else + return evas_common_convert_rgba_to_16bpp_bgr_565_dith_rot_90; + } +#endif + } +#endif #ifdef BUILD_CONVERT_16_RGB_555 if ((rmask == 0x7c00) && (gmask == 0x03e0) && (bmask == 0x001f)) { Index: src/lib/engines/common/evas_convert_rgb_16.c === RCS file: /var/cvs/e/e17/libs/evas/src/lib/engines/common/evas_convert_rgb_16.c,v retrieving revision 1.4 diff -p -u -r1.4 evas_convert_rgb_16.c --- src/lib/engines/common/evas_convert_rgb_16.c 22 May 2005 02:49:48 - 1.4 +++ src/lib/engines/common/evas_convert_rgb_16.c 4 Feb 2007 20:09:31 -0