[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 l...@segv.dk
---
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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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 Munchl...@segv.dk 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] [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 aguirre.nico...@gmail.com 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 l...@segv.dk
---
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_evas_event_key_up, NULL);
- keyboard_handled = 1;
- }
+ ecore_evas_event_handlers[0
[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; i4; 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 l...@segv.dk
---
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_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
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 l...@segv.dk
---
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(p-fd_write);
+p-fd_write = -1;
+return FALSE;
}
else if (ret == -1 errno == EINTR)
/* try it again */
@@ -390,7 +448,7 @@ ecore_pipe_write(Ecore_Pipe *p, const void *buffer,
unsigned int nbytes)
while
[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 l...@segv.dk
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 l...@segv.dk
---
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 l...@segv.dk
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 l...@segv.dk
---
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 l...@segv.dk
Date: Thu, 26 Feb 2009 13:05:16 +0100
Subject: [PATCH 2/3] White space fixes
Signed-off-by: Lars Munch l...@segv.dk
---
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 l...@segv.dk 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/modules/gstreamer/emotion_gstreamer.c
index b76eb25..1516bd3 100644
--- a/src/modules/gstreamer/emotion_gstreamer.c
+++ b/src/modules/gstreamer/emotion_gstreamer.c
@@ -390,6
[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/gstreamer/emotion_gstreamer_pipeline_v4l.c
b/src/modules/gstreamer
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 linux/input.h
- #undef kernel_ulong_t -added
- #undef BITS_PER_LONG -added
+ #undef kernel_ulong_t
+ #undef BITS_PER_LONG
#else
#include linux/input.h
#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
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 linux/input.h
- #undef kernel_ulong_t -added
- #undef BITS_PER_LONG -added
+ #undef kernel_ulong_t
+ #undef BITS_PER_LONG
#else
#include linux/input.h
#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
*iev)
+{
+ if(!dev-listen)
+ return;
+
+ if(dev-mouse.event == ECORE_FB_EVENT_MOUSE_MOVE)
+ {
+ Ecore_Fb_Event_Mouse_Move *ev;
+ ev = calloc(1
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 basetyps.h +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=100url=/___ 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=100url=/ ___ 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=100url=/___
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
[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] 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] 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 sys/time.h #include sys/param.h #include math.h -#include fnmatch.h #include limits.h #include ctype.h #include time.h - 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] 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
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] [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] 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 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 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] [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] 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
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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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 cutpaste 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 stdlib.h
#include stdio.h
#include Evas.h
#include Evas_Engine_FB.h
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
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
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.phpp=sourceforgeCID=DEVDEV
[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 = xyes ; 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 = xyes ; 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 = xyes ; 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 = xyes ; 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)
+ {
+ if ((!(w 0x1)) (!((int)dest 0x3)))
+ return evas_common_convert_rgba2_to_16bpp_bgr_565_dith_rot_180;
+ else
+ return evas_common_convert_rgba_to_16bpp_bgr_565_dith_rot_180;
+ }
+#endif
#ifdef BUILD_CONVERT_16_RGB_ROT270
if (rotation == 270)
{
@@ -272,6 +290,15 @@ evas_common_convert_func_get(DATA8 *dest
return evas_common_convert_rgba_to_16bpp_rgb_555_dith
[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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=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 = xyes ; 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 = xyes ; 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 = xyes ; 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 = xyes ; 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 BW 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 -
@@ -264,6 +264,263 @@ evas_common_convert_rgba_to_16bpp_rgb_56
#endif
#endif
+#ifdef BUILD_CONVERT_16_BGR_565
+#ifdef BUILD_CONVERT_16_RGB_ROT0
+void
+evas_common_convert_rgba2_to_16bpp_bgr_565_dith (DATA32 *src, DATA8 *dst, int src_jump, int dst_jump, int w, int h, int dith_x, int dith_y, DATA8 *pal)
+{
+ DATA32 *src_ptr;
+ DATA16 *dst_ptr;
+ int x, y
