[EGIT] [core/efl] master 01/01: Win: fix modal feature during window closing

2016-11-16 Thread Daniel Zaoui 
jackdanielz pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=7d127c1d07eae22dddfffa527db2048dd665c12f

commit 7d127c1d07eae22dddfffa527db2048dd665c12f
Author: Daniel Zaoui 
Date:   Thu Nov 17 07:54:36 2016 +0200

Win: fix modal feature during window closing

During window deletion, decreasing modality depends on
the window visibility.
Because the visibility was set to false before treating the
modality, it was never decreased, leading to never have still
existing windows being reachable.
Now, we check window visibility before it is modified.

@fix
---
 src/lib/elementary/efl_ui_win.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/elementary/efl_ui_win.c b/src/lib/elementary/efl_ui_win.c
index 8f83f43..03e385d 100644
--- a/src/lib/elementary/efl_ui_win.c
+++ b/src/lib/elementary/efl_ui_win.c
@@ -2196,7 +2196,6 @@ _efl_ui_win_hide(Eo *obj, Efl_Ui_Win_Data *sd)
  }
 
_elm_win_state_eval_queue();
-   efl_gfx_visible_set(efl_super(obj, MY_CLASS), EINA_FALSE);
 
if ((sd->modal) && (evas_object_visible_get(obj)))
  {
@@ -2205,6 +2204,7 @@ _efl_ui_win_hide(Eo *obj, Efl_Ui_Win_Data *sd)
 DECREMENT_MODALITY()
  }
 
+   efl_gfx_visible_set(efl_super(obj, MY_CLASS), EINA_FALSE);
TRAP(sd, hide);
 
if (sd->frame_obj)

--

[E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-16 Thread Hermet Park 
Well...  If you argue only path should be an interface, 
I don't agree with you.

I think path is nothing more than data structure & utility functions.

If you say path is not a base data type, matrix, vector, curve and etc should 
not be in eina.
They will harm consistency.

I totally agree with raster that they are mostly used for graphics. and Path 
also.

-Original Message-
From: "Cedric BAIL" 
To: "Enlightenment developer list"; 
Cc: 
Sent: 2016-11-17 (목) 02:50:52
Subject: Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path
 
Hey Hermet,

On Tue, Nov 15, 2016 at 10:20 PM, Hermet Park  wrote:
> Cedric, I got your point.
>
> If you are worrying the bindings of path, then what about others?

Other structure don't need 20 functions to be created and populated.
Even matrix, most language come with a math package to do whatever you
want with them, the only thing really necessary is to be able to
convert those structure back to the C layout that we expect. They are
more part of the base data type you find everywhere like list, hash,
array and friends.



> I haven't planned the current eina structures bindings -  vector, matrix, 
> etc, etc.
>
> Do we have plans about it?

Do we need them in our API ? What API would be useful ? Vector, matrix
and rectangle can be treated just as a simple structure with existing
math package handling them, only C doesn't really provide that. Path
is not the same. Without this 20 API you really won't go far creating
your path. We are not talking about manipulating the path, but
filling/setting it. As you are pointing out, you plan to use this Path
information in more place in our API (Ector, Evas and Elementary),
this means exposing it as part of our core API. Either bindings have
to manually bind all the useful functions and keep track of them over
time, or it is an Eo object and the internal representation doesn't
matter to anyone. Which is actually the case.

Cedric

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-16 Thread The Rasterman 
On Wed, 16 Nov 2016 09:55:54 -0800 Cedric BAIL  said:

> On Tue, Nov 15, 2016 at 7:00 PM, Carsten Haitzler 
> wrote:
> > On Tue, 15 Nov 2016 14:59:30 -0800 Cedric BAIL  said:
> >> On Mon, Nov 14, 2016 at 10:51 PM, Carsten Haitzler 
> >> wrote:
> >> > On Tue, 15 Nov 2016 12:03:14 +0900 (KST) Hermet Park
> >> >  said:
> >> >> As considering further, we'd rather avoid path interface for the
> >> >> optimization point.
> >> >>
> >> >> Current downside of the evas_vg, it needs to copy the path data to the
> >> >> ector, since both ector and evas_vg inherit gfx_shape.
> >> >>
> >> >> But If the path is an independent instance,
> >> >> it's possible that evas_vg just pass the path instance to the ector with
> >> >> the ref count increase. Plus, ector and evas_vg track the path changes
> >> >> flexibly.
> >> >>
> >> >> Additionally, user just need to set one path data for several vg
> >> >> objects if those vg objects may need to have same path information.
> >> >>
> >> >> So, again, I aim to Eina again.
> >> >>
> >> >> What do you think?
> >> >
> >> > it already has rectangles, and "tile buffer" which is really a rectangle
> >> > "update region" system which are really just data structures. it has
> >> > matrix stuff which frankle is used 90% of the time for gfx. quadtrees
> >> > are data structs almost exclusively used for gfx (2d regions/arrays of
> >> > stuff). it has vectors. gfx. eina has a lot of "basic gfx related data
> >> > types" in it. i don't see another lib as being useful here. another lib
> >> > simply adds MORE problems. we have issues already where we have SO
> >> > MANY .so's on some systems efl fails because we cant dlopen more libs at
> >> > all. ran out of __thread slots. this is not an optimization. it's a real
> >> > bug that we cant solve without either:
> >> >
> >> > 1. telling people to upgrade.patch libc
> >> > or
> >> > 2. us reducing the number of .so's we have.
> >> >
> >> > forget optimizing. we need to do this just to stop having things fail
> >> > entirely. dont add another lib that then has to be merged anyway.
> >> >
> >> > now to naming... i dislike eina_path - like many i think of file path
> >> > first, not gfx path. if anything maybe call it eina_shape? or
> >> > eina_outline or eina_poly? (polygons, beziers - just be rough and call
> >> > them polyline/curve segments).
> >>
> >> As said before, if you want to have the structure defined in Eina as a
> >> data structure, maybe, but the entire API, the 20 functions that cover
> >> path in efl_gfx_shape.eo, should remain in an eo object due to
> >> bindings. It makes absolutely no sense to expose all this operation as
> >> just a C API when we are manipulating an object that needs to be
> >> accessible with no integration in every language. For once, this is
> >> right in Eo as it is a useful API in every binding that has no reason
> >> to be manually binded. Which get me back to my proposal, move them to
> >> efl_gfx_path.{eo,c} and use add a function to share the array between
> >> two instance of efl_gfx_path without any cost (This is something that
> >> can stay completely internal and the structure of the internal data
> >> doesn't need to be exposed).
> >
> > if you want to move all the other stuff form eina to efl_gfx - fine. well
> > that means duplicating it to keep abi. rects, matrixes, vectors etc. but
> > you still have the problem that apis are higher cost with eo so the c costs
> > of messing with paths beyond higher level (here is an array of points -
> > deal with it" will be there. if all the apis are very high level then this
> > cost is not such a bad thing. it depends on the api really.
> 
> Setting path data to efl_gfx_path won't ever be a performance problem
> or other use of Eo will seriously be a problem. efl_gfx_path API is
> about defining the path, not computing it. Computing it, is what
> actually take time and ressource, by a huge factor. The API we are
> talking here does line, bezier curve, parse SVG path and so on. There
> is nothing there that should ever be costly to "set" compared to
> computing the request. The computation will be always internal, as
> object in Ector, Evas and Elementary will inherit from efl_gfx_path.

that depends how u do it. like if you do:

count = path.point_count_get();
p = path.point_get(count - 1);
p.x = 10;
p.y = 20;
path.point_xy_set(count - 1, p.x, p.y);

i mean if the api is "get small value, set it, query, etc." then you will have
an apit hat is going in and out a lot for small amounts of transaction WORK per
in and out. then the in and out costs become high.

i didnt look at any api being proposed at this point (the details) other than
purpose and name.

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

[EGIT] [core/efl] master 01/02: eet: add NULL-check to eet_connection_empty API to avoid segfault

2016-11-16 Thread Artem Popov 
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=0b6e04d94fc3ff6447b6fbf0fcdbdd8b6958e621

commit 0b6e04d94fc3ff6447b6fbf0fcdbdd8b6958e621
Author: Artem Popov 
Date:   Wed Nov 16 15:30:29 2016 -0800

eet: add NULL-check to eet_connection_empty API to avoid segfault

@fix

Summary:
Only eet_connection_empty hasn't checking on NULL and try to read from 
field of object.
Add NULL-check for connection and return result of empty connection.

Reviewers: jpeg, cedric, myoungwoon

Subscribers: t.naumenko, NikaWhite

Differential Revision: https://phab.enlightenment.org/D4399

Signed-off-by: Cedric BAIL 
---
 src/lib/eet/eet_connection.c | 1 +
 src/lib/eet/eet_data.c   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/lib/eet/eet_connection.c b/src/lib/eet/eet_connection.c
index 7945692..735e112 100644
--- a/src/lib/eet/eet_connection.c
+++ b/src/lib/eet/eet_connection.c
@@ -157,6 +157,7 @@ _eet_connection_raw_send(Eet_Connection *conn,
 EAPI Eina_Bool
 eet_connection_empty(Eet_Connection *conn)
 {
+   EINA_SAFETY_ON_NULL_RETURN_VAL(conn, EINA_TRUE);
return conn->size ? EINA_FALSE : EINA_TRUE;
 }
 
diff --git a/src/lib/eet/eet_data.c b/src/lib/eet/eet_data.c
index cabafc3..d4ba25f 100644
--- a/src/lib/eet/eet_data.c
+++ b/src/lib/eet/eet_data.c
@@ -5281,6 +5281,7 @@ eet_data_descriptor_encode_cipher(Eet_Data_Descriptor 
*edd,
int size;
 
EINA_SAFETY_ON_NULL_RETURN_VAL(edd, NULL);
+   EINA_SAFETY_ON_NULL_RETURN_VAL(data_in, NULL);
 
ret = _eet_data_descriptor_encode(NULL, edd, data_in, );
if (cipher_key && ret)

--

[EGIT] [core/efl] master 02/02: evas: reduce usage of __thread directive.

2016-11-16 Thread Cedric BAIL 
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=53dd596f437ae53b96d746f0a5cf0963642f76ad

commit 53dd596f437ae53b96d746f0a5cf0963642f76ad
Author: Cedric BAIL 
Date:   Wed Nov 16 16:05:56 2016 -0800

evas: reduce usage of __thread directive.

Moved rects caching into draw context to avoid the use of __thread
slot. Draw context are defined per thread anyway and should be just
fine. This doesn't really change the picture regarding glibc problem
when to many __thread are needed, but slightly improve the global
picture. Also this patch doesn't affect our performance in expedite
benchmark as far as I can tell.
---
 src/lib/evas/common/evas_draw_main.c   |  5 
 src/lib/evas/common/evas_font_draw.c   | 24 +++
 src/lib/evas/common/evas_map_image.c   | 48 +-
 src/lib/evas/common/evas_rectangle_main.c  | 24 +++
 src/lib/evas/common/evas_scale_main.c  | 24 +++
 src/lib/evas/include/evas_common_private.h |  4 +++
 src/lib/evas/include/evas_inline.x | 12 
 7 files changed, 41 insertions(+), 100 deletions(-)

diff --git a/src/lib/evas/common/evas_draw_main.c 
b/src/lib/evas/common/evas_draw_main.c
index 289d6df..b87c473 100644
--- a/src/lib/evas/common/evas_draw_main.c
+++ b/src/lib/evas/common/evas_draw_main.c
@@ -122,6 +122,10 @@ evas_common_draw_context_dup(RGBA_Draw_Context *dc)
  pixman_image_ref(dc2->col.pixman_color_image);
 #endif
 #endif
+
+   dc2->cache.rects = NULL;
+   dc2->cache.used = 0;
+
return dc2;
 }
 
@@ -141,6 +145,7 @@ evas_common_draw_context_free(RGBA_Draw_Context *dc)
 #endif
 
evas_common_draw_context_apply_clean_cutouts(>cutout);
+   evas_common_draw_context_cutouts_real_free(dc->cache.rects);
free(dc);
 }
 
diff --git a/src/lib/evas/common/evas_font_draw.c 
b/src/lib/evas/common/evas_font_draw.c
index 79c8900..b4b0a99 100644
--- a/src/lib/evas/common/evas_font_draw.c
+++ b/src/lib/evas/common/evas_font_draw.c
@@ -348,12 +348,6 @@ error:
 EAPI Eina_Bool
 evas_common_font_draw_cb(RGBA_Image *dst, RGBA_Draw_Context *dc, int x, int y, 
Evas_Glyph_Array *glyphs, Evas_Common_Font_Draw_Cb cb)
 {
-#ifdef HAVE_THREAD_SPECIFIER
-   static __thread int rects_used = 0;
-   static __thread Cutout_Rects *rects = NULL;
-#else
-   Cutout_Rects *rects = NULL;
-#endif
int ext_x, ext_y, ext_w, ext_h;
int im_w, im_h;
RGBA_Gfx_Func func;
@@ -408,26 +402,16 @@ evas_common_font_draw_cb(RGBA_Image *dst, 
RGBA_Draw_Context *dc, int x, int y, E
 /* our clip is 0 size.. abort */
 if ((dc->clip.w > 0) && (dc->clip.h > 0))
   {
- rects = evas_common_draw_context_apply_cutouts(dc, rects);
- for (i = 0; i < rects->active; ++i)
+ dc->cache.rects = evas_common_draw_context_apply_cutouts(dc, 
dc->cache.rects);
+ for (i = 0; i < dc->cache.rects->active; ++i)
{
-  r = rects->rects + i;
+  r = dc->cache.rects->rects + i;
   evas_common_draw_context_set_clip(dc, r->x, r->y, r->w, 
r->h);
   ret |= cb(dst, dc, x, y, glyphs,
 func, r->x, r->y, r->w, r->h,
 im_w, im_h);
}
-#ifdef HAVE_THREAD_SPECIFIER
- rects_used++;
- if (rects_used >= 4096)
-   {
-  evas_common_draw_context_cutouts_real_free(rects);
-  rects = NULL;
-  rects_used = 0;
-   }
-#else
- evas_common_draw_context_cutouts_real_free(rects);
-#endif
+ evas_common_draw_context_cache_update(dc);
   }
 dc->clip.use = c; dc->clip.x = cx; dc->clip.y = cy; dc->clip.w = cw; 
dc->clip.h = ch;
 
diff --git a/src/lib/evas/common/evas_map_image.c 
b/src/lib/evas/common/evas_map_image.c
index 2a48b20..339db5a 100644
--- a/src/lib/evas/common/evas_map_image.c
+++ b/src/lib/evas/common/evas_map_image.c
@@ -752,12 +752,6 @@ evas_common_map_rgba_cb(RGBA_Image *src, RGBA_Image *dst,
 int smooth, int level,
 Evas_Common_Map_RGBA_Cb cb)
 {
-#ifdef HAVE_THREAD_SPECIFIER
-   static __thread int rects_used = 0;
-   static __thread Cutout_Rects *rects = NULL;
-#else
-   Cutout_Rects *rects = NULL;
-#endif
Cutout_Rect  *r;
int  c, cx, cy, cw, ch;
int  i;
@@ -789,24 +783,14 @@ evas_common_map_rgba_cb(RGBA_Image *src, RGBA_Image *dst,
 dc->clip.use = c; dc->clip.x = cx; dc->clip.y = cy; dc->clip.w = cw; 
dc->clip.h = ch;
 return;
  }
-   rects = evas_common_draw_context_apply_cutouts(dc, rects);
-   for (i = 0; i < rects->active; ++i)
+   dc->cache.rects = evas_common_draw_context_apply_cutouts(dc, 
dc->cache.rects);
+   for (i = 0; i < dc->cache.rects->active; ++i)
  {
-r = rects->rects + i;
+r =

[EGIT] [core/efl] master 01/03: evas/gl: Added support for stencil buffer creation while creating gl Surface.

2016-11-16 Thread Subhransu Mohanty 
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=16cb5f7af90ea8a47261d0ae48fbbaa4ad2a847f

commit 16cb5f7af90ea8a47261d0ae48fbbaa4ad2a847f
Author: Subhransu Mohanty 
Date:   Wed Nov 16 13:14:48 2016 -0800

evas/gl: Added support for stencil buffer creation while creating gl 
Surface.

Reviewers: jpeg, cedric

Reviewed By: jpeg, cedric

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4404

Signed-off-by: Cedric BAIL 
---
 .../evas/engines/gl_common/evas_gl_common.h|  6 +++---
 .../evas/engines/gl_common/evas_gl_context.c   |  2 +-
 src/modules/evas/engines/gl_common/evas_gl_image.c |  4 ++--
 .../evas/engines/gl_common/evas_gl_texture.c   | 22 ++
 src/modules/evas/engines/gl_generic/evas_engine.c  |  6 +++---
 5 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_common.h 
b/src/modules/evas/engines/gl_common/evas_gl_common.h
index d044c16..8b56abe 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_common.h
+++ b/src/modules/evas/engines/gl_common/evas_gl_common.h
@@ -351,7 +351,7 @@ struct _Evas_Engine_GL_Context
 struct _Evas_GL_Texture_Pool
 {
Evas_Engine_GL_Context *gc;
-   GLuint   texture, fb;
+   GLuint   texture, fb, stencil;
GLuint   intformat, format, dataformat;
int  w, h;
int  references;
@@ -650,7 +650,7 @@ void  
evas_gl_common_rect_draw(Evas_Engine_GL_Context *gc, int x, in
 void  evas_gl_texture_pool_empty(Evas_GL_Texture_Pool *pt);
 Evas_GL_Texture  *evas_gl_common_texture_new(Evas_Engine_GL_Context *gc, 
RGBA_Image *im, Eina_Bool disable_atlas);
 Evas_GL_Texture  *evas_gl_common_texture_native_new(Evas_Engine_GL_Context 
*gc, unsigned int w, unsigned int h, int alpha, Evas_GL_Image *im);
-Evas_GL_Texture  *evas_gl_common_texture_render_new(Evas_Engine_GL_Context 
*gc, unsigned int w, unsigned int h, int alpha);
+Evas_GL_Texture  *evas_gl_common_texture_render_new(Evas_Engine_GL_Context 
*gc, unsigned int w, unsigned int h, int alpha, int stencil);
 Evas_GL_Texture  *evas_gl_common_texture_dynamic_new(Evas_Engine_GL_Context 
*gc, Evas_GL_Image *im);
 void  evas_gl_common_texture_update(Evas_GL_Texture *tex, 
RGBA_Image *im);
 void  evas_gl_common_texture_upload(Evas_GL_Texture *tex, 
RGBA_Image *im, unsigned int bytes_count);
@@ -679,7 +679,7 @@ Evas_GL_Image
*evas_gl_common_image_alpha_set(Evas_GL_Image *im, int alpha);
 void  evas_gl_common_image_scale_hint_set(Evas_GL_Image *im, int 
hint);
 void  evas_gl_common_image_content_hint_set(Evas_GL_Image *im, int 
hint);
 void  evas_gl_common_image_cache_flush(Evas_Engine_GL_Context *gc);
-Evas_GL_Image*evas_gl_common_image_surface_new(Evas_Engine_GL_Context *gc, 
unsigned int w, unsigned int h, int alpha);
+Evas_GL_Image*evas_gl_common_image_surface_new(Evas_Engine_GL_Context *gc, 
unsigned int w, unsigned int h, int alpha, int stencil);
 void  evas_gl_common_image_dirty(Evas_GL_Image *im, unsigned int 
x, unsigned int y, unsigned int w, unsigned int h);
 void  evas_gl_common_image_update(Evas_Engine_GL_Context *gc, 
Evas_GL_Image *im);
 void  evas_gl_common_image_map_draw(Evas_Engine_GL_Context *gc, 
Evas_GL_Image *im, int npoints, RGBA_Map_Point *p, int smooth, int level);
diff --git a/src/modules/evas/engines/gl_common/evas_gl_context.c 
b/src/modules/evas/engines/gl_common/evas_gl_context.c
index df2cad2..fbe3b26 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_context.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_context.c
@@ -1050,7 +1050,7 @@ evas_gl_common_context_new(void)
gc->shared->references++;
_evas_gl_common_viewport_set(gc);
 
-   gc->def_surface = evas_gl_common_image_surface_new(gc, 1, 1, 1);
+   gc->def_surface = evas_gl_common_image_surface_new(gc, 1, 1, 1, EINA_FALSE);
 
return gc;
 
diff --git a/src/modules/evas/engines/gl_common/evas_gl_image.c 
b/src/modules/evas/engines/gl_common/evas_gl_image.c
index b863bce..99f75be 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_image.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_image.c
@@ -722,7 +722,7 @@ evas_gl_common_image_free(Evas_GL_Image *im)
 }
 
 Evas_GL_Image *
-evas_gl_common_image_surface_new(Evas_Engine_GL_Context *gc, unsigned int w, 
unsigned int h, int alpha)
+evas_gl_common_image_surface_new(Evas_Engine_GL_Context *gc, unsigned int w, 
unsigned int h, int alpha, int stencil)
 {
Evas_GL_Image *im;
 
@@ -738,7 +738,7 @@ evas_gl_common_image_surface_new(Evas_Engine_GL_Context 
*gc, unsigned int w, uns
im->alpha = alpha;
im->w = w;
im->h = h;
-   im->tex = evas_gl_common_texture_render_new(gc, w, h, alpha);
+   im->tex = evas_gl_common_texture_render_new(gc,

[EGIT] [core/efl] master 03/03: elmentary_test: test_entry4

2016-11-16 Thread Umesh Tanwar 
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=417871e19b0a278bf23adc6c3497c2ed3da17836

commit 417871e19b0a278bf23adc6c3497c2ed3da17836
Author: Umesh Tanwar 
Date:   Wed Nov 16 13:25:42 2016 -0800

elmentary_test: test_entry4

Summary:
If entry is set into layout, entry does not need to
be explicitly shown as layout is already show.

Though it does not lead any error, but it is not
necessary too.

@fix

Signed-off-by: Umesh Tanwar 

Test Plan: elementary_test->entry4

Reviewers: singh.amitesh

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4405

Signed-off-by: Cedric BAIL 
---
 src/bin/elementary/test_entry.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/bin/elementary/test_entry.c b/src/bin/elementary/test_entry.c
index e833cf8..9512978 100644
--- a/src/bin/elementary/test_entry.c
+++ b/src/bin/elementary/test_entry.c
@@ -1799,7 +1799,6 @@ test_entry4(void *data EINA_UNUSED, Evas_Object *obj 
EINA_UNUSED, void *event_in
elm_object_text_set(en, "This is a single line");
elm_entry_single_line_set(en, EINA_TRUE);
elm_object_part_content_set(ly, "element1", en);
-   evas_object_show(en);
 
en = elm_entry_add(win);
elm_entry_line_wrap_set(en, ELM_WRAP_NONE);
@@ -1812,7 +1811,6 @@ test_entry4(void *data EINA_UNUSED, Evas_Object *obj 
EINA_UNUSED, void *event_in
evas_object_size_hint_weight_set(en, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
evas_object_size_hint_align_set(en, EVAS_HINT_FILL, EVAS_HINT_FILL);
elm_object_part_content_set(ly, "element2", en);
-   evas_object_show(en);
 
en = elm_entry_add(win);
elm_entry_scrollable_set(en, EINA_TRUE);
@@ -1833,7 +1831,6 @@ test_entry4(void *data EINA_UNUSED, Evas_Object *obj 
EINA_UNUSED, void *event_in
   );
evas_object_smart_callback_add(en, "anchor,clicked", scrolled_anchor_test, 
en);
elm_object_part_content_set(ly, "element3", en);
-   evas_object_show(en);
 
evas_object_show(win);
 }

--

[EGIT] [core/efl] master 02/03: efl_ui_image: guarantee user's mouse up event callback is called.

2016-11-16 Thread Jaehyun Cho 
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=e64fa28284b4d00c90af260ea76dc3c9b7b541ec

commit e64fa28284b4d00c90af260ea76dc3c9b7b541ec
Author: Jaehyun Cho 
Date:   Wed Nov 16 13:22:44 2016 -0800

efl_ui_image: guarantee user's mouse up event callback is called.

Summary:
Without propagating event by hit_rect, user's mouse up event
callback may not be called if image file is replaced in user's mouse
down event callback.

Test Plan:
1. Register mouse up event callback for elm_image by calling
evas_object_event_callback_add() with EVAS_CALLBACK_MOUSE_UP.
2. Register mouse down event callback for elm_image by calling
evas_object_event_callback_add() with EVAS_CALLBACK_MOUSE_DOWN.
3. Replace image file of elm_image by calling elm_image_file_set() in
mouse down event callback.
4. Mouse down on elm_image.
5. Mouse up on elm_image.
6. Since image file object is newly created in mouse down event
callback, mouse up event is not triggered for the newly created image
file object. As a result, mouse up event is not propagated to elm_image
and user's mouse up callback for elm_image is not called.

Reviewers: cedric, woohyun, eunue, jpeg

Reviewed By: jpeg

Subscribers: jpeg

Differential Revision: https://phab.enlightenment.org/D4401

Signed-off-by: Cedric BAIL 
---
 src/lib/elementary/efl_ui_image.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/lib/elementary/efl_ui_image.c 
b/src/lib/elementary/efl_ui_image.c
index 409c4dd..f874020 100644
--- a/src/lib/elementary/efl_ui_image.c
+++ b/src/lib/elementary/efl_ui_image.c
@@ -520,7 +520,6 @@ _efl_ui_image_efl_canvas_group_group_add(Eo *obj, 
Efl_Ui_Image_Data *priv)
priv->hit_rect = evas_object_rectangle_add(evas_object_evas_get(obj));
evas_object_smart_member_add(priv->hit_rect, obj);
elm_widget_sub_object_add(obj, priv->hit_rect);
-   evas_object_propagate_events_set(priv->hit_rect, EINA_FALSE);
 
evas_object_color_set(priv->hit_rect, 0, 0, 0, 0);
evas_object_show(priv->hit_rect);

--

[EGIT] [core/efl] master 01/01: ecore_drm2: Make sure something's on screen after dpms wake

2016-11-16 Thread Derek Foreman 
derekf pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=168a127c8ccb209a60481ff95e44f9b5464fa890

commit 168a127c8ccb209a60481ff95e44f9b5464fa890
Author: Derek Foreman 
Date:   Wed Nov 16 15:05:40 2016 -0600

ecore_drm2: Make sure something's on screen after dpms wake

Flip to the previous buffer on dpms wake to make sure we show something
---
 src/lib/ecore_drm2/ecore_drm2_outputs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/lib/ecore_drm2/ecore_drm2_outputs.c 
b/src/lib/ecore_drm2/ecore_drm2_outputs.c
index b39c99f..3e97077 100644
--- a/src/lib/ecore_drm2/ecore_drm2_outputs.c
+++ b/src/lib/ecore_drm2/ecore_drm2_outputs.c
@@ -1028,6 +1028,9 @@ ecore_drm2_output_dpms_set(Ecore_Drm2_Output *output, int 
level)
 #endif
  sym_drmModeConnectorSetProperty(output->fd, output->conn_id,
  output->dpms->prop_id, level);
+
+   if (level == 0) /* DPMS on */
+ ecore_drm2_fb_flip(NULL, output);
 }
 
 EAPI char *

--

[EGIT] [core/efl] master 02/02: ecore_evas_drm: Stop errant page from flip handler

2016-11-16 Thread Derek Foreman 
derekf pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=24608d995084eb0f15dcb872c309dae235ad3069

commit 24608d995084eb0f15dcb872c309dae235ad3069
Author: Derek Foreman 
Date:   Wed Nov 16 14:26:18 2016 -0600

ecore_evas_drm: Stop errant page from flip handler

This was required due to bugs elsewhere, and could potentially cause
stutters in display.  Now that we don't need it we're better off without.
---
 src/modules/ecore_evas/engines/drm/ecore_evas_drm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c 
b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
index e86c4a3..5115b7d 100644
--- a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
+++ b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
@@ -658,8 +658,6 @@ _cb_pageflip(int fd EINA_UNUSED, unsigned int frame 
EINA_UNUSED, unsigned int se
 double t = (double)sec + ((double)usec / 100);
 
 ecore_evas_animator_tick(ee, NULL, t);
-edata->pending = EINA_TRUE;
-ecore_drm2_fb_flip(NULL, edata->output);
  }
else if (ret)
  {

--

[EGIT] [core/efl] master 01/02: ecore_evas_drm: Don't do a flip if we know a frame is coming

2016-11-16 Thread Derek Foreman 
derekf pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=8611aa83bc9c17932362ce142b7534bf50461d2c

commit 8611aa83bc9c17932362ce142b7534bf50461d2c
Author: Derek Foreman 
Date:   Wed Nov 16 14:23:19 2016 -0600

ecore_evas_drm: Don't do a flip if we know a frame is coming

If the async renderer is running then something's going to trigger a
pageflip naturally, and if we do one now we'll block it.
---
 src/modules/ecore_evas/engines/drm/ecore_evas_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c 
b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
index 5e34d13..e86c4a3 100644
--- a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
+++ b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
@@ -686,7 +686,7 @@ _drm_animator_register(Ecore_Evas *ee)
 
edata = ee->engine.data;
edata->ticking = EINA_TRUE;
-   if (!edata->pending) ecore_drm2_fb_flip(NULL, edata->output);
+   if (!edata->pending && !ee->in_async_render) ecore_drm2_fb_flip(NULL, 
edata->output);
edata->pending = EINA_TRUE;
 }
 

--

[EGIT] [core/efl] master 01/01: Ecore Wayland: Remove ECORE_WL2_SEAT_CAPABILITIES_NO_SEAT.

2016-11-16 Thread Guilherme Iscaro 
bdilly pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=9f8e2e0d9c9b4150cce2fc9bfb825d4f49ba7840

commit 9f8e2e0d9c9b4150cce2fc9bfb825d4f49ba7840
Author: Guilherme Iscaro 
Date:   Wed Nov 16 17:04:02 2016 -0200

Ecore Wayland: Remove ECORE_WL2_SEAT_CAPABILITIES_NO_SEAT.

Summary:
It's not possible to have an Ecore_Wl2_Input without a seat.

Ecore Evas Wayland: Remove seat existence check.

At this point every seat advertised is considered new, therefore
it will not be in the devices list.

Reviewers: barbieri, jpeg, cedric, bdilly

Reviewed By: bdilly

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4408
---
 src/lib/ecore_wl2/Ecore_Wl2.h  |  9 +++---
 src/lib/ecore_wl2/ecore_wl2_input.c|  4 +--
 .../engines/wayland/ecore_evas_wayland_common.c| 36 --
 3 files changed, 11 insertions(+), 38 deletions(-)

diff --git a/src/lib/ecore_wl2/Ecore_Wl2.h b/src/lib/ecore_wl2/Ecore_Wl2.h
index 2d3cc16..9dcae3a 100644
--- a/src/lib/ecore_wl2/Ecore_Wl2.h
+++ b/src/lib/ecore_wl2/Ecore_Wl2.h
@@ -56,11 +56,10 @@ typedef enum
 
 typedef enum
 {
-  ECORE_WL2_SEAT_CAPABILITIES_NO_SEAT = 0,
-  ECORE_WL2_SEAT_CAPABILITIES_NONE = 1,
-  ECORE_WL2_SEAT_CAPABILITIES_POINTER = 2,
-  ECORE_WL2_SEAT_CAPABILITIES_KEYBOARD = 4,
-  ECORE_WL2_SEAT_CAPABILITIES_TOUCH = 8
+  ECORE_WL2_SEAT_CAPABILITIES_NONE = 0,
+  ECORE_WL2_SEAT_CAPABILITIES_POINTER = 1,
+  ECORE_WL2_SEAT_CAPABILITIES_KEYBOARD = 2,
+  ECORE_WL2_SEAT_CAPABILITIES_TOUCH = 4
 } Ecore_Wl2_Seat_Capabilities;
 
 struct _Ecore_Wl2_Event_Connection
diff --git a/src/lib/ecore_wl2/ecore_wl2_input.c 
b/src/lib/ecore_wl2/ecore_wl2_input.c
index c7829f8..3df8f46 100644
--- a/src/lib/ecore_wl2/ecore_wl2_input.c
+++ b/src/lib/ecore_wl2/ecore_wl2_input.c
@@ -1589,10 +1589,8 @@ ecore_wl2_input_seat_capabilities_get(Ecore_Wl2_Input 
*input)
 
Ecore_Wl2_Seat_Capabilities cap = ECORE_WL2_SEAT_CAPABILITIES_NONE;
 
-   EINA_SAFETY_ON_NULL_RETURN_VAL(input, ECORE_WL2_SEAT_CAPABILITIES_NO_SEAT);
+   EINA_SAFETY_ON_NULL_RETURN_VAL(input, cap);
 
-   if (!input->wl.seat)
- return ECORE_WL2_SEAT_CAPABILITIES_NO_SEAT;
if (input->wl.keyboard)
  cap |= ECORE_WL2_SEAT_CAPABILITIES_KEYBOARD;
if (input->wl.pointer)
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c 
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
index 9184c6c..2053c21 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
+++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
@@ -518,17 +518,18 @@ _ecore_evas_wl_common_device_event_add(int event_type, 
Ecore_Wl2_Device_Type dev
 
 static EE_Wl_Device *
 _ecore_evas_wl_common_seat_add(Ecore_Evas *ee,
-   const char *seat_name,
unsigned int id)
 {
Ecore_Evas_Engine_Wl_Data *wdata;
EE_Wl_Device *device;
Evas_Device *dev;
+   char buf[32];
 
device = calloc(1, sizeof(EE_Wl_Device));
EINA_SAFETY_ON_NULL_RETURN_VAL(device, NULL);
 
-   dev = evas_device_add_full(ee->evas, seat_name, "Wayland seat",
+   snprintf(buf, sizeof(buf), "seat-%u", id);
+   dev = evas_device_add_full(ee->evas, buf, "Wayland seat",
   NULL, NULL,
   EVAS_DEVICE_CLASS_SEAT,
   EVAS_DEVICE_SUBCLASS_NONE);
@@ -555,37 +556,17 @@ _ecore_evas_wl_common_cb_global_added(void *d 
EINA_UNUSED, int t EINA_UNUSED, vo
Ecore_Wl2_Event_Global *ev = event;
Ecore_Evas *ee;
Eina_List *l;
-   char buf[32];
 
if ((!ev->interface) || (strcmp(ev->interface, "wl_seat")))
return ECORE_CALLBACK_PASS_ON;
 
-   snprintf(buf, sizeof(buf), "seat-%u", ev->id);
-
EINA_LIST_FOREACH(ee_list, l, ee)
  {
-Eina_List *ll;
-EE_Wl_Device *device;
-Ecore_Evas_Engine_Wl_Data *wdata = ee->engine.data;
-Eina_Bool already_present = EINA_FALSE;
-
-EINA_LIST_FOREACH(wdata->devices_list, ll, device)
-  {
- if (device->id == ev->id)
-   {
-  already_present = EINA_TRUE;
-  break;
-   }
-  }
-
-if (!already_present && !_ecore_evas_wl_common_seat_add(ee, buf, 
ev->id))
-  goto err_add;
+if (!_ecore_evas_wl_common_seat_add(ee, ev->id))
+  break;
  }
 
return ECORE_CALLBACK_PASS_ON;
-
-err_add:
-   return ECORE_CALLBACK_PASS_ON;
 }
 
 static void
@@ -2043,17 +2024,12 @@ _ecore_wl2_devices_setup(Ecore_Evas *ee, 
Ecore_Wl2_Display *display)
  {
 EE_Wl_Device *device;
 Ecore_Wl2_Seat_Capabilities cap;
-char buf[32];
 unsigned int id;
 
 id = ecore_wl2_input_seat_id_get(input);
 cap = ecore_wl2_input_seat_capabilities_get(input);
-

[EGIT] [core/efl] master 01/01: evas: make sync and async work in the same way and not trigger empty flush/clear.

2016-11-16 Thread Cedric BAIL 
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=55ab71bd67429114557fb62a0ae01378aa098469

commit 55ab71bd67429114557fb62a0ae01378aa098469
Author: Cedric BAIL 
Date:   Wed Nov 16 11:30:16 2016 -0800

evas: make sync and async work in the same way and not trigger empty 
flush/clear.
---
 src/lib/evas/canvas/evas_render.c | 46 ---
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/src/lib/evas/canvas/evas_render.c 
b/src/lib/evas/canvas/evas_render.c
index 2628de5..e1542fa 100644
--- a/src/lib/evas/canvas/evas_render.c
+++ b/src/lib/evas/canvas/evas_render.c
@@ -2852,37 +2852,39 @@ evas_render_updates_internal(Evas *eo_e,
}
   }
 
-if (do_async)
-  {
- eina_evlog("+render_output_async_flush", eo_e, 0.0, NULL);
- efl_ref(eo_e);
- e->rendering = EINA_TRUE;
- _rendering_evases = eina_list_append(_rendering_evases, e);
- if (haveup)
-   _cb_always_call(eo_e, EVAS_CALLBACK_RENDER_FLUSH_PRE, NULL);
- evas_thread_queue_flush((Evas_Thread_Command_Cb)done_func, 
done_data);
- eina_evlog("-render_output_async_flush", eo_e, 0.0, NULL);
-  }
-else if (haveup)
+if (haveup)
   {
- eina_evlog("+render_output_flush", eo_e, 0.0, NULL);
- EINA_LIST_FOREACH(e->video_objects, ll, eo_obj)
+ if (do_async)
{
-  _evas_object_image_video_overlay_do(eo_obj);
+  eina_evlog("+render_output_async_flush", eo_e, 0.0, NULL);
+  efl_ref(eo_e);
+  e->rendering = EINA_TRUE;
+  _rendering_evases = eina_list_append(_rendering_evases, e);
+  _cb_always_call(eo_e, EVAS_CALLBACK_RENDER_FLUSH_PRE, NULL);
+  evas_thread_queue_flush((Evas_Thread_Command_Cb)done_func, 
done_data);
+  eina_evlog("-render_output_async_flush", eo_e, 0.0, NULL);
+   }
+ else
+   {
+  eina_evlog("+render_output_flush", eo_e, 0.0, NULL);
+  EINA_LIST_FOREACH(e->video_objects, ll, eo_obj)
+{
+   _evas_object_image_video_overlay_do(eo_obj);
+}
+  _cb_always_call(eo_e, EVAS_CALLBACK_RENDER_FLUSH_PRE, NULL);
+  e->engine.func->output_flush(e->engine.data.output,
+   EVAS_RENDER_MODE_SYNC);
+  _cb_always_call(eo_e, EVAS_CALLBACK_RENDER_FLUSH_POST, NULL);
+  eina_evlog("-render_output_flush", eo_e, 0.0, NULL);
}
- _cb_always_call(eo_e, EVAS_CALLBACK_RENDER_FLUSH_PRE, NULL);
- e->engine.func->output_flush(e->engine.data.output,
-  EVAS_RENDER_MODE_SYNC);
- _cb_always_call(eo_e, EVAS_CALLBACK_RENDER_FLUSH_POST, NULL);
- eina_evlog("-render_output_flush", eo_e, 0.0, NULL);
   }
-rendering = EINA_TRUE;
+rendering = haveup;
 eina_evlog("-render_surface", eo_e, 0.0, NULL);
  }
eina_evlog("-render_phase6", eo_e, 0.0, NULL);
 
eina_evlog("+render_clear", eo_e, 0.0, NULL);
-   if (!do_async)
+   if (!do_async && rendering)
  {
 /* clear redraws */
 e->engine.func->output_redraws_clear(e->engine.data.output);

--

[EGIT] [core/efl] master 01/01: ecore_wl2: ref / unref evas devices on ecore events

2016-11-16 Thread Bruno Dilly 
bdilly pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=6f66c6e67696faa60e006d7f8ab41d804e799970

commit 6f66c6e67696faa60e006d7f8ab41d804e799970
Author: Bruno Dilly 
Date:   Wed Nov 16 17:00:55 2016 -0200

ecore_wl2: ref / unref evas devices on ecore events

Summary:
It should avoid issues when device is removed after the ecore
event addition but before listeners are called (so pointer
would be invalid).

Reviewers: iscaro

Reviewed By: iscaro

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4407
---
 src/lib/ecore_wl2/ecore_wl2_input.c | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/src/lib/ecore_wl2/ecore_wl2_input.c 
b/src/lib/ecore_wl2/ecore_wl2_input.c
index a17c665..c7829f8 100644
--- a/src/lib/ecore_wl2/ecore_wl2_input.c
+++ b/src/lib/ecore_wl2/ecore_wl2_input.c
@@ -86,13 +86,21 @@ _ecore_wl2_mouse_dev_get(Ecore_Wl2_Input *input, int 
window_id)
Ecore_Wl2_Input_Devices *devices;
 
devices = _ecore_wl2_devices_get(input, window_id);
-   if (devices)
- return devices->pointer_dev;
+   if (devices && devices->pointer_dev)
+ return efl_ref(devices->pointer_dev);
 
return NULL;
 }
 
 static void
+_input_event_cb_free(void *data, void *event)
+{
+   if (data)
+ efl_unref(data);
+   free(event);
+}
+
+static void
 _ecore_wl2_input_mouse_in_send(Ecore_Wl2_Input *input, Ecore_Wl2_Window 
*window)
 {
Ecore_Event_Mouse_IO *ev;
@@ -108,7 +116,7 @@ _ecore_wl2_input_mouse_in_send(Ecore_Wl2_Input *input, 
Ecore_Wl2_Window *window)
ev->modifiers = input->keyboard.modifiers;
ev->dev = _ecore_wl2_mouse_dev_get(input, window->id);
 
-   ecore_event_add(ECORE_EVENT_MOUSE_IN, ev, NULL, NULL);
+   ecore_event_add(ECORE_EVENT_MOUSE_IN, ev, _input_event_cb_free, ev->dev);
 }
 
 static void
@@ -127,7 +135,7 @@ _ecore_wl2_input_mouse_out_send(Ecore_Wl2_Input *input, 
Ecore_Wl2_Window *window
ev->modifiers = input->keyboard.modifiers;
ev->dev = _ecore_wl2_mouse_dev_get(input, window->id);
 
-   ecore_event_add(ECORE_EVENT_MOUSE_OUT, ev, NULL, NULL);
+   ecore_event_add(ECORE_EVENT_MOUSE_OUT, ev, _input_event_cb_free, ev->dev);
 }
 
 static void
@@ -166,7 +174,7 @@ _ecore_wl2_input_mouse_move_send(Ecore_Wl2_Input *input, 
Ecore_Wl2_Window *windo
 info->sy = input->pointer.sy;
  }
 
-   ecore_event_add(ECORE_EVENT_MOUSE_MOVE, ev, NULL, NULL);
+   ecore_event_add(ECORE_EVENT_MOUSE_MOVE, ev, _input_event_cb_free, ev->dev);
 }
 
 static void
@@ -205,7 +213,7 @@ _ecore_wl2_input_mouse_wheel_send(Ecore_Wl2_Input *input, 
unsigned int axis, int
  }
ev->dev = _ecore_wl2_mouse_dev_get(input, ev->window);
 
-   ecore_event_add(ECORE_EVENT_MOUSE_WHEEL, ev, NULL, NULL);
+   ecore_event_add(ECORE_EVENT_MOUSE_WHEEL, ev, _input_event_cb_free, ev->dev);
 }
 
 static void
@@ -296,7 +304,8 @@ _ecore_wl2_input_mouse_down_send(Ecore_Wl2_Input *input, 
Ecore_Wl2_Window *windo
 ev->dev = _ecore_wl2_mouse_dev_get(input, window->id);
  }
 
-   ecore_event_add(ECORE_EVENT_MOUSE_BUTTON_DOWN, ev, NULL, NULL);
+   ecore_event_add(ECORE_EVENT_MOUSE_BUTTON_DOWN, ev,
+   _input_event_cb_free, ev->dev);
 
if ((info) && (!info->triple_click))
  {
@@ -366,7 +375,8 @@ _ecore_wl2_input_mouse_up_send(Ecore_Wl2_Input *input, 
Ecore_Wl2_Window *window,
ev->event_window = window->id;
ev->dev = _ecore_wl2_mouse_dev_get(input, window->id);
 
-   ecore_event_add(ECORE_EVENT_MOUSE_BUTTON_UP, ev, NULL, NULL);
+   ecore_event_add(ECORE_EVENT_MOUSE_BUTTON_UP, ev,
+   _input_event_cb_free, ev->dev);
 }
 
 static void
@@ -479,8 +489,8 @@ _ecore_wl2_keyboard_dev_get(Ecore_Wl2_Input *input, int 
window_id)
Ecore_Wl2_Input_Devices *devices;
 
devices = _ecore_wl2_devices_get(input, window_id);
-   if (devices)
- return devices->keyboard_dev;
+   if (devices && devices->keyboard_dev)
+ return efl_ref(devices->keyboard_dev);
 
return NULL;
 }
@@ -524,9 +534,9 @@ _ecore_wl2_input_key_send(Ecore_Wl2_Input *input, 
Ecore_Wl2_Window *window, xkb_
/* DBG("Emitting Key event (%s,%s,%s,%s)\n", ev->keyname, ev->key, 
ev->compose, ev->string); */
 
if (state)
- ecore_event_add(ECORE_EVENT_KEY_DOWN, ev, NULL, NULL);
+ ecore_event_add(ECORE_EVENT_KEY_DOWN, ev, _input_event_cb_free, ev->dev);
else
- ecore_event_add(ECORE_EVENT_KEY_UP, ev, NULL, NULL);
+ ecore_event_add(ECORE_EVENT_KEY_UP, ev, _input_event_cb_free, ev->dev);
 }
 
 void

--

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-16 Thread Cedric BAIL 
On Tue, Nov 15, 2016 at 7:00 PM, Carsten Haitzler  wrote:
> On Tue, 15 Nov 2016 14:59:30 -0800 Cedric BAIL  said:
>> On Mon, Nov 14, 2016 at 10:51 PM, Carsten Haitzler 
>> wrote:
>> > On Tue, 15 Nov 2016 12:03:14 +0900 (KST) Hermet Park 
>> > said:
>> >> As considering further, we'd rather avoid path interface for the
>> >> optimization point.
>> >>
>> >> Current downside of the evas_vg, it needs to copy the path data to the
>> >> ector, since both ector and evas_vg inherit gfx_shape.
>> >>
>> >> But If the path is an independent instance,
>> >> it's possible that evas_vg just pass the path instance to the ector with
>> >> the ref count increase. Plus, ector and evas_vg track the path changes
>> >> flexibly.
>> >>
>> >> Additionally, user just need to set one path data for several vg objects 
>> >> if
>> >> those vg objects may need to have same path information.
>> >>
>> >> So, again, I aim to Eina again.
>> >>
>> >> What do you think?
>> >
>> > it already has rectangles, and "tile buffer" which is really a rectangle
>> > "update region" system which are really just data structures. it has matrix
>> > stuff which frankle is used 90% of the time for gfx. quadtrees are data
>> > structs almost exclusively used for gfx (2d regions/arrays of stuff). it
>> > has vectors. gfx. eina has a lot of "basic gfx related data types" in it. i
>> > don't see another lib as being useful here. another lib simply adds MORE
>> > problems. we have issues already where we have SO MANY .so's on some
>> > systems efl fails because we cant dlopen more libs at all. ran out of
>> > __thread slots. this is not an optimization. it's a real bug that we cant
>> > solve without either:
>> >
>> > 1. telling people to upgrade.patch libc
>> > or
>> > 2. us reducing the number of .so's we have.
>> >
>> > forget optimizing. we need to do this just to stop having things fail
>> > entirely. dont add another lib that then has to be merged anyway.
>> >
>> > now to naming... i dislike eina_path - like many i think of file path 
>> > first,
>> > not gfx path. if anything maybe call it eina_shape? or eina_outline or
>> > eina_poly? (polygons, beziers - just be rough and call them polyline/curve
>> > segments).
>>
>> As said before, if you want to have the structure defined in Eina as a
>> data structure, maybe, but the entire API, the 20 functions that cover
>> path in efl_gfx_shape.eo, should remain in an eo object due to
>> bindings. It makes absolutely no sense to expose all this operation as
>> just a C API when we are manipulating an object that needs to be
>> accessible with no integration in every language. For once, this is
>> right in Eo as it is a useful API in every binding that has no reason
>> to be manually binded. Which get me back to my proposal, move them to
>> efl_gfx_path.{eo,c} and use add a function to share the array between
>> two instance of efl_gfx_path without any cost (This is something that
>> can stay completely internal and the structure of the internal data
>> doesn't need to be exposed).
>
> if you want to move all the other stuff form eina to efl_gfx - fine. well that
> means duplicating it to keep abi. rects, matrixes, vectors etc. but you still
> have the problem that apis are higher cost with eo so the c costs of messing
> with paths beyond higher level (here is an array of points - deal with it" 
> will
> be there. if all the apis are very high level then this cost is not such a bad
> thing. it depends on the api really.

Setting path data to efl_gfx_path won't ever be a performance problem
or other use of Eo will seriously be a problem. efl_gfx_path API is
about defining the path, not computing it. Computing it, is what
actually take time and ressource, by a huge factor. The API we are
talking here does line, bezier curve, parse SVG path and so on. There
is nothing there that should ever be costly to "set" compared to
computing the request. The computation will be always internal, as
object in Ector, Evas and Elementary will inherit from efl_gfx_path.
-- 
Cedric BAIL

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path

2016-11-16 Thread Cedric BAIL 
Hey Hermet,

On Tue, Nov 15, 2016 at 10:20 PM, Hermet Park  wrote:
> Cedric, I got your point.
>
> If you are worrying the bindings of path, then what about others?

Other structure don't need 20 functions to be created and populated.
Even matrix, most language come with a math package to do whatever you
want with them, the only thing really necessary is to be able to
convert those structure back to the C layout that we expect. They are
more part of the base data type you find everywhere like list, hash,
array and friends.

> I haven't planned the current eina structures bindings -  vector, matrix, 
> etc, etc.
>
> Do we have plans about it?

Do we need them in our API ? What API would be useful ? Vector, matrix
and rectangle can be treated just as a simple structure with existing
math package handling them, only C doesn't really provide that. Path
is not the same. Without this 20 API you really won't go far creating
your path. We are not talking about manipulating the path, but
filling/setting it. As you are pointing out, you plan to use this Path
information in more place in our API (Ector, Evas and Elementary),
this means exposing it as part of our core API. Either bindings have
to manually bind all the useful functions and keep track of them over
time, or it is an Eo object and the internal representation doesn't
matter to anyone. Which is actually the case.

Cedric

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/enlightenment] master 01/01: fix missing definition of DRM_FORMAT_XRGB8888

2016-11-16 Thread Christopher Michael 
devilhorns pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=0a696f5fa3c38ba9a41083ff686a80268d6b4ccd

commit 0a696f5fa3c38ba9a41083ff686a80268d6b4ccd
Author: Chris Michael 
Date:   Wed Nov 16 09:15:12 2016 -0500

fix missing definition of DRM_FORMAT_XRGB

As we do not compile-time link with libdrm inside Ecore_Drm2 anymore,
we need to include relivant bits of drm_fourcc header here in order to
define DRM_FORMAT_XRGB else we fail to compile Enlightenment Wayland

Signed-off-by: Chris Michael 
---
 src/bin/e_alert_main.c | 54 --
 1 file changed, 43 insertions(+), 11 deletions(-)

diff --git a/src/bin/e_alert_main.c b/src/bin/e_alert_main.c
index 7317896..3cfcd6c 100644
--- a/src/bin/e_alert_main.c
+++ b/src/bin/e_alert_main.c
@@ -1,7 +1,7 @@
 #include "config.h"
 
 #ifdef HAVE_DRM2
-#  define EFL_BETA_API_SUPPORT
+# define EFL_BETA_API_SUPPORT
 #endif
 
 #include 
@@ -20,17 +20,49 @@
 #include 
 #include 
 
-# ifdef HAVE_WL_DRM
-#  include 
-#  ifdef HAVE_DRM2
-#   include 
-#   include 
-#  else
-#   include 
-#  endif
-#  include 
-#  include 
+#ifdef HAVE_WL_DRM
+# include 
+# ifdef HAVE_DRM2
+#  include 
+# else
+#  include 
 # endif
+# include 
+# include 
+#endif
+
+#ifdef HAVE_WL_DRM
+# ifdef HAVE_DRM2
+/* DRM_FORMAT_XRGB and fourcc_code borrowed from 
+ *
+ * Copyright 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+#  define fourcc_code(a, b, c, d) \
+   ((uint32_t)(a) | ((uint32_t)(b) << 8) | \
+   ((uint32_t)(c) << 16) | ((uint32_t)(d) << 24))
+#  define DRM_FORMAT_XRGB \
+   fourcc_code('X', 'R', '2', '4') /* [31:0] x:R:G:B 8:8:8:8 little endian */
+# endif
+#endif
 
 #define WINDOW_WIDTH   320
 #define WINDOW_HEIGHT  240

--

[EGIT] [core/efl] master 01/02: evas: Try to fix bad clipping of non-frame objects

2016-11-16 Thread Jean-Philippe ANDRÉ 
jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=ac5ca9281c5ea374fb6d77c867cf478f29e70a83

commit ac5ca9281c5ea374fb6d77c867cf478f29e70a83
Author: Jean-Philippe Andre 
Date:   Mon Nov 7 20:36:59 2016 +0900

evas: Try to fix bad clipping of non-frame objects

Test cases (in WL or X with client-side decorations on):

1. elementary_test -to Animation
  Resize the window to a small size (eg, 100x100) and observe the
  balls overflowing outside the window content part. This tests
  unclipped normal objects.

2. elementary_test "Window Plug" (requires also Window Socket)
  Drag the handles outside the window, observe overflow in the
  framespace area. This tests mapped images ('can_map').

3. elementary_test -to "Gesture Layer"
  Drag a photo around. This tests non-image mapped objects.
  NOTE: This test is badly broken!

This patch fixes both of those issues. I'm not sure what I'm
breaking, though.
---
 src/lib/evas/canvas/evas_render.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/src/lib/evas/canvas/evas_render.c 
b/src/lib/evas/canvas/evas_render.c
index 9fadd92..d75a84f 100644
--- a/src/lib/evas/canvas/evas_render.c
+++ b/src/lib/evas/canvas/evas_render.c
@@ -185,18 +185,14 @@ _accumulate_time(double before, Eina_Bool async)
 static int _render_busy = 0;
 
 static inline Eina_Bool
-_is_obj_in_framespace(Evas_Object_Protected_Data *obj, Evas_Public_Data *evas)
+_is_obj_in_framespace(Evas_Object_Protected_Data *obj, Evas_Public_Data *evas 
EINA_UNUSED)
 {
-   if (obj->is_frame) return EINA_TRUE;
-
-   return RECTS_INTERSECT(0, -evas->framespace.y,
-  evas->viewport.w, evas->viewport.h,
-  obj->cur->geometry.x, obj->cur->geometry.y,
-  obj->cur->geometry.w, obj->cur->geometry.h);
+   return obj->is_frame;
 }
 
 static inline void
-_evas_render_framespace_context_clip_clip(Evas_Public_Data *evas, void *ctx)
+_evas_render_framespace_context_clip_clip(Evas_Public_Data *evas, void *ctx,
+  int ox, int oy)
 {
int fx, fy, fw, fh;
 
@@ -205,7 +201,7 @@ _evas_render_framespace_context_clip_clip(Evas_Public_Data 
*evas, void *ctx)
fw = evas->viewport.w - evas->framespace.w;
fh = evas->viewport.h - evas->framespace.h;
 
-   ENFN->context_clip_clip(ENDT, ctx, fx, fy, fw, fh);
+   ENFN->context_clip_clip(ENDT, ctx, fx + ox, fy + oy, fw, fh);
 }
 
 static void
@@ -1663,8 +1659,6 @@ evas_render_mapped(Evas_Public_Data *evas, Evas_Object 
*eo_obj,
}
   }
 ENFN->context_clip_clip(ENDT, ctx, ecx, ecy, ecw, ech);
-if (!_is_obj_in_framespace(obj, evas))
-  _evas_render_framespace_context_clip_clip(evas, ctx);
 
 if (obj->cur->cache.clip.visible || !proxy_src_clip)
   {
@@ -1857,7 +1851,10 @@ evas_render_mapped(Evas_Public_Data *evas, Evas_Object 
*eo_obj,
   clipper->cur->cache.clip.h);
ENFN->context_clip_set(ENDT, ctx, x + off_x, y + off_y, 
w, h);
if (!_is_obj_in_framespace(obj, evas))
- _evas_render_framespace_context_clip_clip(evas, ctx);
+ {
+_evas_render_framespace_context_clip_clip
+  (evas, ctx, off_x - evas->framespace.x, 
off_y - evas->framespace.y);
+ }
 
if (proxy_src_clip)
  ENFN->context_clip_clip(ENDT, ctx, ecx, ecy, ecw, 
ech);
@@ -1871,6 +1868,11 @@ evas_render_mapped(Evas_Public_Data *evas, Evas_Object 
*eo_obj,
  }
 }
}
+ else if (!_is_obj_in_framespace(obj, evas))
+   {
+  _evas_render_framespace_context_clip_clip
+(evas, ctx, off_x - evas->framespace.x, off_y - 
evas->framespace.y);
+   }
 
 #ifdef REND_DBG
  int _c, _cx, _cy, _cw, _ch;
@@ -2444,9 +2446,6 @@ evas_render_updates_internal_loop(Evas *eo_e, 
Evas_Public_Data *e,
   e->engine.func->context_clip_set(e->engine.data.output,
context,
x, y, w, h);
-
-  if (!_is_obj_in_framespace(obj, e))
-_evas_render_framespace_context_clip_clip(e, context);
 
   /* Clipper masks */
   if (_evas_render_object_is_mask(obj->cur->clipper))

--

[EGIT] [core/efl] master 02/02: elm/evas: Fix disappearance of window icons with CSD

2016-11-16 Thread Jean-Philippe ANDRÉ 
jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f50b0fed133b63887e43686bf3410bec422c5025

commit f50b0fed133b63887e43686bf3410bec422c5025
Author: Jean-Philippe Andre 
Date:   Wed Nov 16 18:09:37 2016 +0900

elm/evas: Fix disappearance of window icons with CSD

After a few patches trying to fix clipping of frame or
non-frame objects the icon finally ended up invisible. Even
if the elm_icon was marked as is_frame, its internal evas
object image would not have the flag set, thus it would be
clipped out.

Solution: Propagate the is_frame flag to all smart children,
not only when setting it but also when adding new members.
A hack with the API indicates that the frame edje is a very
special object that does not propagate the flag.

See also:
7ce79be1a1748c32c4d0e58358ce2242902cf89b
0f6c33eff106f7235351dd51ce7835041f548cc1
9c9c8809a7d90a5ab61c2c930c4cdaeb1d8e8c6a
ac5ca9281c5ea374fb6d77c867cf478f29e70a83
---
 src/lib/elementary/efl_ui_win.c  | 18 +-
 src/lib/evas/canvas/efl_canvas_object.eo | 18 +++---
 src/lib/evas/canvas/evas_object_main.c   | 10 ++
 src/lib/evas/canvas/evas_object_smart.c  |  3 +++
 src/lib/evas/canvas/evas_render.c| 19 ++-
 src/lib/evas/include/evas_private.h  |  1 +
 6 files changed, 52 insertions(+), 17 deletions(-)

diff --git a/src/lib/elementary/efl_ui_win.c b/src/lib/elementary/efl_ui_win.c
index 3ad9322..8f83f43 100644
--- a/src/lib/elementary/efl_ui_win.c
+++ b/src/lib/elementary/efl_ui_win.c
@@ -3926,9 +3926,14 @@ _elm_win_frame_add(Efl_Ui_Win_Data *sd, const char 
*style)
 return;
  }
 
-   edje_object_part_swallow(sd->frame_obj, "elm.swallow.client", sd->edje);
+   /* Small hack: The special value 2 means this is the top frame object.
+* We propagate to the children now (the edc group contents), but subsequent
+* calls to smart_member_add will not propagate the flag further. Note that
+* this little hack will fall apart if edje creates and destroys objects on
+* the fly. */
+   efl_canvas_object_is_frame_object_set(sd->frame_obj, 2);
 
-   evas_object_is_frame_object_set(sd->frame_obj, EINA_TRUE);
+   edje_object_part_swallow(sd->frame_obj, "elm.swallow.client", sd->edje);
 
if (sd->icon)
  evas_object_show(sd->icon);
@@ -3952,8 +3957,8 @@ _elm_win_frame_add(Efl_Ui_Win_Data *sd, const char *style)
   }
  }
 
-   edje_object_part_swallow(sd->frame_obj, "elm.swallow.icon",
-sd->icon);
+   edje_object_part_swallow(sd->frame_obj, "elm.swallow.icon", sd->icon);
+   efl_canvas_object_is_frame_object_set(sd->icon, EINA_TRUE);
 
evas_object_event_callback_add
  (sd->frame_obj, EVAS_CALLBACK_MOVE, _elm_win_frame_obj_move, sd);
@@ -5201,7 +5206,10 @@ _efl_ui_win_icon_object_set(Eo *obj, Efl_Ui_Win_Data 
*sd, Evas_Object *icon)
 evas_object_event_callback_add(sd->icon, EVAS_CALLBACK_DEL,
   _elm_win_on_icon_del, obj);
 if (sd->frame_obj)
-  edje_object_part_swallow(sd->frame_obj, "elm.swallow.icon", 
sd->icon);
+  {
+ edje_object_part_swallow(sd->frame_obj, "elm.swallow.icon", 
sd->icon);
+ evas_object_is_frame_object_set(sd->icon, EINA_TRUE);
+  }
  }
 #ifdef HAVE_ELEMENTARY_X
_elm_win_xwin_update(sd);
diff --git a/src/lib/evas/canvas/efl_canvas_object.eo 
b/src/lib/evas/canvas/efl_canvas_object.eo
index 8d2cb41..aeb93e9 100644
--- a/src/lib/evas/canvas/efl_canvas_object.eo
+++ b/src/lib/evas/canvas/efl_canvas_object.eo
@@ -273,13 +273,17 @@ abstract Efl.Canvas.Object (Efl.Object, Efl.Gfx, 
Efl.Gfx.Stack, Efl.Animator,
  return: bool; [[$true if the seat was removed from the focus list or 
$false otherwise.]]
   }
   @property is_frame_object {
-[[Property to identify if an object is a frame]]
- set {
-[[@since 1.2]]
- }
- get {
-[[@since 1.2]]
- }
+ [[If $true the object belongs to the window border decorations.
+
+   This will be $false by default, and should be $false for all objects
+   created by the application, unless swallowed in some very specific
+   parts of the window.
+
+   It is very unlikely that an application needs to call this manually,
+   as the window will handle this feature automatically.
+
+   @since 1.2
+ ]]
  values {
 is_frame: bool; [[$true if the object is a frame, $false 
otherwise]]
  }
diff --git a/src/lib/evas/canvas/evas_object_main.c 
b/src/lib/evas/canvas/evas_object_main.c
index c74d01d..46e8266 100644
--- a/src/lib/evas/canvas/evas_object_main.c
+++ b/src/lib/evas/canvas/evas_object_main.c
@@ -2048,6 +2048,16 @@ _is_frame_flag_set(Evas_Object_Protected_Data *obj, 
Eina_Bool is_frame)
const Eina_Inlist *l;

[EGIT] [core/efl] master 01/02: Ecore Evas Wayland: Create the devices during Ecore_Evas setup.

2016-11-16 Thread Guilherme Iscaro 
jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=9ba11c5cd020b6ec5cb78dfaeda2d4c0472659ab

commit 9ba11c5cd020b6ec5cb78dfaeda2d4c0472659ab
Author: Guilherme Iscaro 
Date:   Mon Nov 14 11:03:56 2016 +0900

Ecore Evas Wayland: Create the devices during Ecore_Evas setup.

Summary:
When launching an Elementary App using Wayland the elm_config will
automatically connect to the Wayland's display server and all events
regarding seats are lost, since by the time that Ecore_Evas is created
the global events were already dispatched. To fix this problem,
everytime an Ecore_Evas is created, the code must check if there
are any seat capabilities available, if so, the devices will be created.

Reviewers: bdilly, barbieri, cedric, jpeg

Subscribers: devilhorns, cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4390
---
 src/lib/ecore_wl2/Ecore_Wl2.h  |  33 +
 src/lib/ecore_wl2/ecore_wl2_input.c|  26 
 src/lib/ecore_wl2/ecore_wl2_window.c   |   7 +
 .../engines/wayland/ecore_evas_wayland_common.c| 143 +
 4 files changed, 186 insertions(+), 23 deletions(-)

diff --git a/src/lib/ecore_wl2/Ecore_Wl2.h b/src/lib/ecore_wl2/Ecore_Wl2.h
index 402206c..2d3cc16 100644
--- a/src/lib/ecore_wl2/Ecore_Wl2.h
+++ b/src/lib/ecore_wl2/Ecore_Wl2.h
@@ -54,6 +54,15 @@ typedef enum
ECORE_WL2_DRAG_ACTION_LAST = 5,
 } Ecore_Wl2_Drag_Action;
 
+typedef enum
+{
+  ECORE_WL2_SEAT_CAPABILITIES_NO_SEAT = 0,
+  ECORE_WL2_SEAT_CAPABILITIES_NONE = 1,
+  ECORE_WL2_SEAT_CAPABILITIES_POINTER = 2,
+  ECORE_WL2_SEAT_CAPABILITIES_KEYBOARD = 4,
+  ECORE_WL2_SEAT_CAPABILITIES_TOUCH = 8
+} Ecore_Wl2_Seat_Capabilities;
+
 struct _Ecore_Wl2_Event_Connection
 {
Ecore_Wl2_Display *display;
@@ -440,6 +449,14 @@ EAPI Eina_Iterator 
*ecore_wl2_display_globals_get(Ecore_Wl2_Display *display);
 EAPI void ecore_wl2_display_screen_size_get(Ecore_Wl2_Display *display, int 
*w, int *h);
 
 /**
+ * Get all the Ecore_Wl2_Input from the display.
+ * @param display The display
+ * @return A Eina_Iterator of Ecore_Wl2_Input or @c NULL on error
+ * @since 1.19
+ */
+EAPI Eina_Iterator *ecore_wl2_display_inputs_get(Ecore_Wl2_Display *display);
+
+/**
  * Find an Ecore_Wl2_Window based on id
  *
  * @param display The display to search for the window
@@ -887,6 +904,22 @@ EAPI void ecore_wl2_input_ungrab(Ecore_Wl2_Input *input);
 EAPI struct wl_seat *ecore_wl2_input_seat_get(Ecore_Wl2_Input *input);
 
 /**
+ * Get the seat capabilities for a given input.
+ *
+ * @param input The input
+ * @since 1.19
+ */
+EAPI Ecore_Wl2_Seat_Capabilities 
ecore_wl2_input_seat_capabilities_get(Ecore_Wl2_Input *input);
+
+/**
+ * Get the wayland's seat id from an input.
+ * @param input The input
+ * @return The seat id
+ * @since 1.19
+ */
+EAPI unsigned int ecore_wl2_input_seat_id_get(Ecore_Wl2_Input *input);
+
+/**
  * @defgroup Ecore_Wl2_Dnd_Group Wayland Library Drag-n-Drop Functions
  * @ingroup Ecore_Wl2_Group
  *
diff --git a/src/lib/ecore_wl2/ecore_wl2_input.c 
b/src/lib/ecore_wl2/ecore_wl2_input.c
index 830c6ad..a17c665 100644
--- a/src/lib/ecore_wl2/ecore_wl2_input.c
+++ b/src/lib/ecore_wl2/ecore_wl2_input.c
@@ -1572,3 +1572,29 @@ ecore_wl2_input_seat_get(Ecore_Wl2_Input *input)
 
return input->wl.seat;
 }
+
+EAPI Ecore_Wl2_Seat_Capabilities
+ecore_wl2_input_seat_capabilities_get(Ecore_Wl2_Input *input)
+{
+
+   Ecore_Wl2_Seat_Capabilities cap = ECORE_WL2_SEAT_CAPABILITIES_NONE;
+
+   EINA_SAFETY_ON_NULL_RETURN_VAL(input, ECORE_WL2_SEAT_CAPABILITIES_NO_SEAT);
+
+   if (!input->wl.seat)
+ return ECORE_WL2_SEAT_CAPABILITIES_NO_SEAT;
+   if (input->wl.keyboard)
+ cap |= ECORE_WL2_SEAT_CAPABILITIES_KEYBOARD;
+   if (input->wl.pointer)
+ cap |= ECORE_WL2_SEAT_CAPABILITIES_POINTER;
+   if (input->wl.touch)
+ cap |= ECORE_WL2_SEAT_CAPABILITIES_TOUCH;
+   return cap;
+}
+
+EAPI unsigned int
+ecore_wl2_input_seat_id_get(Ecore_Wl2_Input *input)
+{
+   EINA_SAFETY_ON_NULL_RETURN_VAL(input, 0);
+   return input->id;
+}
diff --git a/src/lib/ecore_wl2/ecore_wl2_window.c 
b/src/lib/ecore_wl2/ecore_wl2_window.c
index b2aa63f..2c19f05 100644
--- a/src/lib/ecore_wl2/ecore_wl2_window.c
+++ b/src/lib/ecore_wl2/ecore_wl2_window.c
@@ -993,6 +993,13 @@ ecore_wl2_window_input_get(Ecore_Wl2_Window *window)
return NULL;
 }
 
+EAPI Eina_Iterator *
+ecore_wl2_display_inputs_get(Ecore_Wl2_Display *display)
+{
+   EINA_SAFETY_ON_NULL_RETURN_VAL(display, NULL);
+   return eina_inlist_iterator_new(display->inputs);
+}
+
 EAPI Eina_Bool
 ecore_wl2_window_has_shell_surface(Ecore_Wl2_Window *window)
 {
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c 
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
index db60d98..9184c6c 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
+++

[EGIT] [core/efl] master 02/02: ecore_con: correctly include sys/ioctl.h

2016-11-16 Thread Vincent Torri 
jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=c0d8f1cc3763570b20b90c024cfad01c11db273d

commit c0d8f1cc3763570b20b90c024cfad01c11db273d
Author: Vincent Torri 
Date:   Wed Nov 16 18:26:56 2016 +0900

ecore_con: correctly include sys/ioctl.h

I had to make distclean for this patch to work.

Differential Revision: https://phab.enlightenment.org/D4402
---
 configure.ac  | 1 +
 src/lib/ecore_con/ecore_con.c | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3c4eb48..ca58fff 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1777,6 +1777,7 @@ netinet/in.h \
 netinet/tcp.h \
 netinet/udp.h \
 sys/prctl.h \
+sys/ioctl.h \
 sys/resource.h \
 sys/timerfd.h \
 sys/un.h \
diff --git a/src/lib/ecore_con/ecore_con.c b/src/lib/ecore_con/ecore_con.c
index 56a5f89..48b1d1c 100644
--- a/src/lib/ecore_con/ecore_con.c
+++ b/src/lib/ecore_con/ecore_con.c
@@ -26,6 +26,10 @@
 # include 
 #endif
 
+#ifdef HAVE_SYS_IOCTL_H
+# include 
+#endif
+
 #ifdef HAVE_SYSTEMD
 # include 
 #endif
@@ -38,8 +42,6 @@
 # include 
 #endif
 
-#include 
-
 #include "Ecore.h"
 #include "ecore_private.h"
 #include "Ecore_Con.h"

--

Re: [E-devel] [EGIT] [core/enlightenment] master 02/03: Merge branch 'master' of git+ssh://git.enlightenment.org/core/enlightenment

2016-11-16 Thread Tom Hacohen 
I was away, so the reply is a bit late, but: you should "git log" or 
better yet: "git log --graph" before you push to make sure it does what 
you intended.

Furthermore, always do "git pull --rebase", not "git pull". You can 
change this as a setting.

--
Tom.

On 02/11/16 11:50, Stephen Houston wrote:
> Bahhh. Thought I did rebase. My bad. Git and I are still working on our
> relationship.
>
> On Wed, Nov 2, 2016, 3:41 AM Stefan Schmidt  wrote:
>
>> Hello.
>>
>> On 01/11/16 20:21, Stephen okra Houston wrote:
>>> okra pushed a commit to branch master.
>>>
>>>
>> http://git.enlightenment.org/core/enlightenment.git/commit/?id=722ef6442630a5598bec8ec55bb3d309518f7440
>>>
>>> commit 722ef6442630a5598bec8ec55bb3d309518f7440
>>> Merge: 7304758 4d86c98
>>> Author: Stephen okra Houston 
>>> Date:   Tue Nov 1 13:28:33 2016 -0500
>>>
>>> Merge branch 'master' of git+ssh://
>> git.enlightenment.org/core/enlightenment
>>
>> Let me remind you that we do not do merges. The only exception is fast
>> forward merge commits for a bigger patch series. This merge commit needs
>> to have a good commit message describing the whole series though.
>>
>> To me this looks more as if you merge a branch you worked in into master
>> without rebasing. Please avoid this in the future.
>>
>> regards
>> Stefan Schmidt
>>
>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel