Re: [E-devel] GL_CLAMP error in EFL
I build EFL for Enlightenment on Wayland as the following: ./autogen.sh --enable-wayland --enable-drm --enable-gl-drm --enable-systemd --enable-egl --with-opengl=es --prefix=$WLD Yan Wang > Seems so. Patch pushed. Which backend where you building ? Something with > GLES ? > > On Thu, Sep 4, 2014 at 4:38 AM, wrote: >> Should use GL_CLAMP_TO_EDGE instead of GL_CLAMP? >> >> Yan Wang >> >>> Hi, All, >>> Just try the latest upstream of efl and meet the following error: >>> error: 'GL_CLAMP' undeclared in e3d_drawable_new()[evas_gl_3d.c] >>> The enum should be deprecated in the new OpenGL. >>> Thanks. >>> >>> Yan Wang >>> >>> -- >>> Slashdot TV. >>> Video for Nerds. Stuff that matters. >>> http://tv.slashdot.org/ >>> ___ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >> >> >> -- >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > > -- > Cedric BAIL > > -- > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] GL_CLAMP error in EFL
Should use GL_CLAMP_TO_EDGE instead of GL_CLAMP? Yan Wang > Hi, All, > Just try the latest upstream of efl and meet the following error: > error: 'GL_CLAMP' undeclared in e3d_drawable_new()[evas_gl_3d.c] > The enum should be deprecated in the new OpenGL. > Thanks. > > Yan Wang > > -- > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] GL_CLAMP error in EFL
Hi, All, Just try the latest upstream of efl and meet the following error: error: 'GL_CLAMP' undeclared in e3d_drawable_new()[evas_gl_3d.c] The enum should be deprecated in the new OpenGL. Thanks. Yan Wang -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [E_DEVEL]enlightenment support wayland
Hi, Dh and Gwanglim, Thanks for your clarifying this. Just study the code of Enlightenment and want your confirmation. Thanks again. Yan Wang > Hi, Yan Wang, > > Yes, we are trying to support GLES/EGL wayland client. :) > > We will add texture from pixmap (actually wl buffer not pixmap) into the > evas gl drm engine. > It needs more testing and then e_pixmap of e should be changed to support > egl wayland client as you said. > But for wl shm buffer, raster is right. It is rendered by using classic gl > texture uploading. > > BR, > Gwanglim > > --- Original Message --- > Sender : Carsten Haitzler > Date : 2014-09-03 14:49 (GMT+09:00) > Title : Re: [E-devel] [E_DEVEL]enlightenment support wayland > > On Tue, 2 Sep 2014 22:44:46 -0700 (PDT) yan.w...@linux.intel.com said: > >> Hi, Dh, >>I don't know whether you have a plan to support EGL/GLES based >> Wayland >> compositor currently? > > yes - it is planned. just getting solid without worrying about that is > more > important. > >>I read some code of Enlightenment. Besides using Ecore Evas GL drm in >> wl_drm module, e_pixmap may need be changed to process wl_buffer based >> on EGL. And for composting wl_buffer from Wayland EGL client by EGL >> image/GL texture, need use evas_object_image_native_surface_set() >> instead of evas_object_image_pixels_set() in e_comp_object >> implementation. >>wl_buffer from Wayland SHM client could also use GL Texture to >> compositing like Weston. > > shm clients just provide a shm segment. if the compositor were to use gl, > then > it would be uploading that shm buffer to a texture on each update and > using > that texture to render. > >>Do you think so? Or you may have the better idea for this. >>Thanks. >> >> Yan Wang >> >> > On 08/29/2014 05:35 AM, yan.w...@linux.intel.com wrote: >> >> Hi, Dh, >> >>Thanks for your information. >> > >> > No worries :) >> > >> >>I found e_modapi_init() in >> >> enlightenemnt/src/modules/wl_drm/e_mod_main.c >> >> fallback to use ecore_evas_drm_new(). >> >>I don't know whether Ecore_evas/Evas GL Drm engine is ready now? >> May >> >> only need add Evas GL engine code into e_comp_wl branch? >> >> >> > The e_comp_wl branch has been merged with master now, so everything is >> > already in master. The Evas GL Drm engine is Very new and Not very >> > tested. I would suggest not building EFL with support for GL Drm at >> the >> > moment. Normal Evas drm engine works tho. >> > >> > Cheers, >> > dh >> > >> >> Best regards >> >> Yan Wang >> >> >> >>> On 08/28/2014 04:58 AM, yan.w...@linux.intel.com wrote: >> >>>> Hi, All, >> >>>> Just I tried e_comp_wl based on README.wayland in >> Enlightenment >> >>>> upstream on my Fedora 20. >> >>>> We could run enlightenment by ./enlightenment_start and found >> >>>> wayland >> >>>> socket in /run/user/1000/e-yanwang@XXX. And some applications (e.g. >> >>>> calculator of Fedora 20 but terminal not) could run. >> >>>> And I tried weston (1.5.0) sample clients and seems only shm >> >>>> samples >> >>>> could be run. Currently e_comp_wl should haven't support Wayland >> drm >> >>>> EGL so far. >> >>>> Is it right? I have added the following: >> >>>> export E_WL_FORCE=drm >> >>>> export ELM_DISPLAY=wl >> >>>> export ELM_ACCEL=opengl >> >>>> >> >>>> The following is my test sample list: >> >>>> weston-simple-shm success >> >>>> weston-simple-egl eglInitialize() is failed >> >>>> weston-editor segment-fault >> >>>> weston-resizor could run but crash when try to close by >> >>>> press X button >> >>>> weston-scaler success >> >>>> weston-dnd success >> >>>> weston-flower success >> >>>> weston-smoke failed, no smoke >> >>>> weston-subsurface failed, egl_state_create() >> >>>> weston-terminalsuccess >> >>>> >> >>>> Thanks. >> >>>> Yan Wang >
Re: [E-devel] [E_DEVEL]enlightenment support wayland
Hi, Dh, I don't know whether you have a plan to support EGL/GLES based Wayland compositor currently? I read some code of Enlightenment. Besides using Ecore Evas GL drm in wl_drm module, e_pixmap may need be changed to process wl_buffer based on EGL. And for composting wl_buffer from Wayland EGL client by EGL image/GL texture, need use evas_object_image_native_surface_set() instead of evas_object_image_pixels_set() in e_comp_object implementation. wl_buffer from Wayland SHM client could also use GL Texture to compositing like Weston. Do you think so? Or you may have the better idea for this. Thanks. Yan Wang > On 08/29/2014 05:35 AM, yan.w...@linux.intel.com wrote: >> Hi, Dh, >>Thanks for your information. > > No worries :) > >>I found e_modapi_init() in >> enlightenemnt/src/modules/wl_drm/e_mod_main.c >> fallback to use ecore_evas_drm_new(). >>I don't know whether Ecore_evas/Evas GL Drm engine is ready now? May >> only need add Evas GL engine code into e_comp_wl branch? >> > The e_comp_wl branch has been merged with master now, so everything is > already in master. The Evas GL Drm engine is Very new and Not very > tested. I would suggest not building EFL with support for GL Drm at the > moment. Normal Evas drm engine works tho. > > Cheers, > dh > >> Best regards >> Yan Wang >> >>> On 08/28/2014 04:58 AM, yan.w...@linux.intel.com wrote: >>>> Hi, All, >>>> Just I tried e_comp_wl based on README.wayland in Enlightenment >>>> upstream on my Fedora 20. >>>> We could run enlightenment by ./enlightenment_start and found >>>> wayland >>>> socket in /run/user/1000/e-yanwang@XXX. And some applications (e.g. >>>> calculator of Fedora 20 but terminal not) could run. >>>> And I tried weston (1.5.0) sample clients and seems only shm >>>> samples >>>> could be run. Currently e_comp_wl should haven't support Wayland drm >>>> EGL so far. >>>> Is it right? I have added the following: >>>> export E_WL_FORCE=drm >>>> export ELM_DISPLAY=wl >>>> export ELM_ACCEL=opengl >>>> >>>> The following is my test sample list: >>>> weston-simple-shm success >>>> weston-simple-egl eglInitialize() is failed >>>> weston-editor segment-fault >>>> weston-resizorcould run but crash when try to close by press X >>>> button >>>> weston-scaler success >>>> weston-dndsuccess >>>> weston-flower success >>>> weston-smoke failed, no smoke >>>> weston-subsurface failed, egl_state_create() >>>> weston-terminal success >>>> >>>> Thanks. >>>> Yan Wang >>>> >>>> >>> >>> There is no support for running X applications yet in a wayland-only >>> enlightenment. I have code for that, but its not ready yet. >>> >>> The current compositor does not initialize egl yet, so only shm clients >>> will work. >>> >>> The existing gl-drm code has not been completely tested yet, so I am >>> unsure how well it works (if at all). I would recommend exporting >>> ELM_ACCEL=none for now. >>> >>> dh >>> > > > > -- > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [E_DEVEL]enlightenment support wayland
Hi, Dh, Thanks for your information. I found e_modapi_init() in enlightenemnt/src/modules/wl_drm/e_mod_main.c fallback to use ecore_evas_drm_new(). I don't know whether Ecore_evas/Evas GL Drm engine is ready now? May only need add Evas GL engine code into e_comp_wl branch? Best regards Yan Wang > On 08/28/2014 04:58 AM, yan.w...@linux.intel.com wrote: >> Hi, All, >> Just I tried e_comp_wl based on README.wayland in Enlightenment >> upstream on my Fedora 20. >> We could run enlightenment by ./enlightenment_start and found >> wayland >> socket in /run/user/1000/e-yanwang@XXX. And some applications (e.g. >> calculator of Fedora 20 but terminal not) could run. >> And I tried weston (1.5.0) sample clients and seems only shm samples >> could be run. Currently e_comp_wl should haven't support Wayland drm >> EGL so far. >> Is it right? I have added the following: >> export E_WL_FORCE=drm >> export ELM_DISPLAY=wl >> export ELM_ACCEL=opengl >> >> The following is my test sample list: >> weston-simple-shmsuccess >> weston-simple-egleglInitialize() is failed >> weston-editorsegment-fault >> weston-resizor could run but crash when try to close by press X >> button >> weston-scalersuccess >> weston-dnd success >> weston-flowersuccess >> weston-smoke failed, no smoke >> weston-subsurfacefailed, egl_state_create() >> weston-terminal success >> >> Thanks. >> Yan Wang >> >> > > There is no support for running X applications yet in a wayland-only > enlightenment. I have code for that, but its not ready yet. > > The current compositor does not initialize egl yet, so only shm clients > will work. > > The existing gl-drm code has not been completely tested yet, so I am > unsure how well it works (if at all). I would recommend exporting > ELM_ACCEL=none for now. > > dh > > > -- > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [E_DEVEL]enlightenment support wayland
Hi, All, Just I tried e_comp_wl based on README.wayland in Enlightenment upstream on my Fedora 20. We could run enlightenment by ./enlightenment_start and found wayland socket in /run/user/1000/e-yanwang@XXX. And some applications (e.g. calculator of Fedora 20 but terminal not) could run. And I tried weston (1.5.0) sample clients and seems only shm samples could be run. Currently e_comp_wl should haven't support Wayland drm EGL so far. Is it right? I have added the following: export E_WL_FORCE=drm export ELM_DISPLAY=wl export ELM_ACCEL=opengl The following is my test sample list: weston-simple-shmsuccess weston-simple-egleglInitialize() is failed weston-editorsegment-fault weston-resizor could run but crash when try to close by press X button weston-scalersuccess weston-dnd success weston-flowersuccess weston-smoke failed, no smoke weston-subsurfacefailed, egl_state_create() weston-terminal success Thanks. Yan Wang -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] FIx wrong frame calculation in evas_object_resize()
Hi,
I found some bugs which come from the difference of frame processing
between X and Wayland:
http://trac.enlightenment.org/e/ticket/1024
http://trac.enlightenment.org/e/ticket/1193
As you know, window client area is smaller in Wayland engine because
elementary has to keep frame space. But evas_object_resize() reduces frame
space for every widget. This is wrong. It causes widget height is
subtracted
to negative and couldn't be display because its condition isn't enough
only by checking obj->smart->parent. So I add one condition
strcmp(obj->type, "elm_win") == 0 for making sure only elm_win do frame
calculation. Please review evas_object_resize_frame.patch.
It also need calling evas_object_move() once for re-calculating widget
position based on frame space. (label_example_moving.patch)
But because smaller window client area couldn't keep all content (e.g.
text of all labels in label_example_01) of window like X. Otherwise, it is
also OK to enlarge elm_win size for wayland engine specially in
label_example_01.c. But this will make application code different
between X and Wayland. it may not make sense because platform engine
dependency.
It may be better to enlarge (not reduce) window size in elm_win
construction/layout/rendering and keep the same size of window client area
with X. Frame will be drawn on additional area. But it means modify
current elm_win construction/layout/rendering mechanism. So we may have to
convince community and need more time to implement it because it is a big
change.
Which path is better choice? At least, evas_object_resize_frame.patch
may be temp solution for workaround.
Thanks.
Yan Wang
Index: src/lib/canvas/evas_object_main.c
===
--- src/lib/canvas/evas_object_main.c (revision 74333)
+++ src/lib/canvas/evas_object_main.c (working copy)
@@ -683,7 +683,7 @@ evas_object_resize(Evas_Object *obj, Evas_Coord w,
int fw, fh;
evas_output_framespace_get(obj->layer->evas, NULL, NULL, &fw, &fh);
-if (!obj->smart.parent)
+if (!obj->smart.parent && strcmp(obj->type, "elm_win") == 0)
{
nw = w - fw;
nh = h - fh;Index: src/examples/label_example_01.c
===
--- src/examples/label_example_01.c (revision 74333)
+++ src/examples/label_example_01.c (working copy)
@@ -25,6 +25,7 @@ elm_main(int argc, char **argv)
elm_label_slide_set(label, EINA_TRUE);
elm_object_style_set(label, "slide_bounce");
evas_object_resize(label, 200, 15);
+ evas_object_move(label, 0, 0);
evas_object_show(label);
label2 = elm_label_add(win);--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] The location calculation of invisible field in elm_datetime
Hi, When I tried elementary/example/datetime_example, I found it will display redundant month and hour on the top of window. For X engine, it locates on the top of client area; and for Wayland engine, it locates on the top of window title bar. (http://trac.enlightenment.org/e/ticket/1174) It comes from _field_list_arrange() couldn't hide invisible fields because the filed has different location value when it is visible and invisible. _parse_format() refuse to calculate the location value of invisible field and it is put value in _reload_format() [line 416 in elm_datetime.c]. So I remove invisible condition in _parse_format() [line 342 in elm_datetime.c] to get the same location value of the field whatever it is visible and invisible. Could you please review my attached patch for this issue? Thanks. Yan Wang Index: src/lib/elm_datetime.c === --- src/lib/elm_datetime.c (revision 74049) +++ src/lib/elm_datetime.c (working copy) @@ -339,7 +339,7 @@ _parse_format(Evas_Object *obj, /* ignore the fields already have or disabled * valid formats, means already parsed & * repeated, ignore. */ - if (!field->visible || field->location != -1) break; + if (field->location != -1) break; field->fmt[1] = cur; field->fmt_exist = EINA_TRUE; field->location = location++;-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Add frame size when calculating minimized elm_win size
Hi, I found frame size including width and height isn't counted in _elm_win_resize_objects_eval() when calculating minimized elm_window size. It is OK for X engine because elementary only draw client area and X provides widow frame. So both the width and height from evas_output_framespace_get are 0. But it cause bug for wayland engine because elementary need draw window frame by itself. So real client area size is smaller than window size. If frame size isn't counted into minimized window size, there isn't enough client area to layout widgets. So it is bug for any engine in which elementary draws window frame by itself. It is the reason of http://trac.enlightenment.org/e/ticket/1064. Could you please my attached patch for this issue? Thanks. Yan WangIndex: src/lib/elm_win.c === --- src/lib/elm_win.c (revision 74029) +++ src/lib/elm_win.c (working copy) @@ -1498,6 +1498,9 @@ _elm_win_resize_objects_eval(Evas_Object *obj) else if ((h > 0) && (h < maxh)) maxh = h; } + evas_output_framespace_get(sd->evas, NULL, NULL, &w, &h); + minw += w; + minh += h; if (!xx) maxw = minw; else maxw = 32767; if (!xy) maxh = minh;-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
