Re: [E-devel] [EGIT] [apps/ephoto] master 01/01: EPhoto: Remove all toolbars in favor of context menus and key bindings.

[Davide Andreoli]

2016-04-02 4:25 GMT+02:00 Carsten Haitzler :

> On Fri, 1 Apr 2016 19:01:31 +0200 Davide Andreoli 
> said:
>
> > 2016-04-01 1:06 GMT+02:00 Carsten Haitzler :
> >
> > > On Thu, 31 Mar 2016 19:36:54 +0200 Davide Andreoli <
> d...@gurumeditation.it
> > > >
> > > said:
> > >
> > > > 2016-03-31 3:19 GMT+02:00 Carsten Haitzler :
> > > >
> > > > > On Wed, 30 Mar 2016 13:31:23 -0500 Stephen Houston <
> > > smhousto...@gmail.com>
> > > > > said:
> > > > >
> > > > > > Good point, thanks.  See attached.
> > > > >
> > > > > that is nicer... now nuke that status bar at the bottom... make
> > > something
> > > > > that
> > > > > overlays so my photo can fill my entire window/screen :)
> > > > >
> > > >
> > > > seems you need eluminance here :D
> > > > https://github.com/DaveMDS/eluminance
> > >
> > > oh. that's actually quite nice.
> > >
> > > but wait.. we decided to nuke the slideshow widget from eo
> interfaces...
> > > (and
> > > future efl) because no one used it!
> > >
> >
> > no one used it? how did you tell that? I'm using the slidshow widget in
> > eluminance
> > and in epymc!
> >
> > NO, PLEASE, DON'T REMOVE IT
>
> never saw it being used... :) it has to stay in legacy c api's - but we
> don't
> have it in eo.
>
> at least for efl 1.18 it wont be in eo api. just dont have the time to do
> that
> in addition to everything else.
>

well, I don't need it for 1.18 but for 2.0, when we will need to port
existing
apps to efl2. So I think there will be the time to implement Slideshow in
the Eo API. Indeed the Slideshow widget need a rewrite, it has some
problems as it is implemented now.



>
> > > > > > On Wed, Mar 30, 2016 at 1:20 PM, Mike Blumenkrantz <
> > > > > > michael.blumenkra...@gmail.com> wrote:
> > > > > >
> > > > > > > On Wed, Mar 30, 2016 at 2:18 PM Stephen okra Houston <
> > > > > > > smhousto...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > okra pushed a commit to branch master.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> http://git.enlightenment.org/apps/ephoto.git/commit/?id=02343df6d9bf844112e90b3dae86e29f718a9b16
> > > > > > > >
> > > > > > > > commit 02343df6d9bf844112e90b3dae86e29f718a9b16
> > > > > > > > Author: Stephen okra Houston 
> > > > > > > > Date:   Wed Mar 30 13:17:31 2016 -0500
> > > > > > > >
> > > > > > > > EPhoto: Remove all toolbars in favor of context menus
> and key
> > > > > > > bindings.
> > > > > > > > ---
> > > > > > > >  src/bin/ephoto_single_browser.c | 278
> > > > > > > > 
> > > > > > > >
> > > > > > > >
> > > > > > > Would be neat to see before->after screenshots when big changes
> > > happen
> > > > > like
> > > > > > > this in applications.
> > > > > > >
> > > > > > >
> > > > >
> > >
> --
> > > > > > > Transform Data into Opportunity.
> > > > > > > Accelerate data analysis in your applications with
> > > > > > > Intel Data Analytics Acceleration Library.
> > > > > > > Click to learn more.
> > > > > > >
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> > > > > > > ___
> > > > > > > enlightenment-devel mailing list
> > > > > > > enlightenment-devel@lists.sourceforge.net
> > > > > > >
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > - Codito, ergo sum - "I code, therefore I am"
> > > --
> > > > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> --
> > > > > Transform Data into Opportunity.
> > > > > Accelerate data analysis in your applications with
> > > > > Intel Data Analytics Acceleration Library.
> > > > > Click to learn more.
> > > > > http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> > > > > ___
> > > > > enlightenment-devel mailing list
> > > > > enlightenment-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > > >
> > > >
> > >
> --
> > > > Transform Data into Opportunity.
> > > > Accelerate data analysis in your applications with
> > > > Intel Data Analytics Acceleration Library.
> > > > Click to learn more.
> > > > http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> > > > ___
> > > > enlightenment-devel mailing list
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >
> > >
> > >
> > > --
> > > - Codito, ergo sum - "I code, therefore I am"
> --
> > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > >
> > >
>
>
> --
> - Codito, e

Re: [E-devel] e20 on Raspberry Pi

[Davide Andreoli]

2016-04-02 1:31 GMT+02:00 Cedric BAIL :

> Hello,
>
> On Fri, Apr 1, 2016 at 3:19 PM, Andreas Volz  wrote:
> > I compiled e20 on Raspberry Pi 2 with latest Raspbian and it works. I
> > had to deactivate Composite Effects and switch to Software renderer
> > because it says there's no OpenGL support.
>

The latests rasbian images for rpi2 include the experimental VideoCore
open source drivers :)

https://www.raspberrypi.org/blog/another-new-raspbian-release/

I successfully built efl+gl on rpi2 using this driver and efl applications
run quite fast. There is still (at least) one issue i faced: the driver
seems
not able to load big textures (something like 1000x1000px or more),
and it slow down a lot when it fails. This for example make e20 unusable
because it cannot load the e background texture.

I did not investigate further, maybe it is just a stupid problem.

Please  let me know if you do some progress in this area, I really
would like to see my emotion media center run smoothly on raspy :)




>
> Yes, RPi have still today a proprietary driver that is not following
> standard integration with X requiring a custom backend to make it
> work. I was hoping to see the open source driver sooner, but it is not
> there yet. We do have in master a backend, eglfs, which will support
> this kind of proprietary driver in the near future. Hopefully for
> 1.18. It is currently done around hwcomposer, but should also be able
> to support RPi and others. This backend will also allow the use of
> Enlightenment Wayland only mode.
>
> The RPi even has something close to hardware layer. So if someone does
> spend the time to optimize our backend for it, it should become quite
> usable. I say quite, because there will still be some major slowness.
> Even with wayland, there won't be support for Wayland EGL, so you will
> fallback to Wayland SHM. Wayland SHM allocate at the moment the buffer
> on the client side. This means that we can't give it a hardware memory
> pointer that the hardware layer infrastructure could reuse. So we will
> always need the CPU to do a useless memcpy from the client buffer to
> the hardware layer buffer... Making it less useful, except maybe for
> mouse cursor... So until there is an open source Open GL driver on the
> RPi, it will lack behind on what we can do with it.
>
> > The reason because I did this is that like to run the Raspi with a
> > 800x480 display and several fullscreen EFL applications which are
> > stacked one over the other and the above one with alpha and shaped
> > window.
> >
> > I use E20 only as layer manager and deactivated all other elements.
> > Maybe E20 is oversized for that reason.
> >
> > I experienced now that the CPU load of the E process is really high
> > even if nothing much happens. In idle the load is >10%, but if I render
> > some edje content in my application the E process goes fast up >60-100%
> > CPU. My application itself has very low CPU usage.
>
> Any change on the screen, should trigger a software rendering of just
> the area that did change on screen. Note that shaped windows and alpha
> are usually more complex to handle and require more ressource to be
> drawn. With an anemic hardware like the RPi, it doesn't suprise me to
> much that this is that slow/ressource intensive.
>
> > I tried to start my application with the default Gtk based window
> > manager, but it's strange. As long as I activate alpha and shaped
> > window support in my application the application is somehow broken and
> > hangs in the beginning. I didn't yet trace it out where it hangs.
> >
> > Do you have any ideas or explanations?
>
> Not for the last problem.
> --
> Cedric BAIL
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e20 on Raspberry Pi

[Andreas Volz]

Am Sat, 2 Apr 2016 12:31:09 +0200 schrieb Davide Andreoli:

> 2016-04-02 1:31 GMT+02:00 Cedric BAIL :
> 
> > Hello,
> >
> > On Fri, Apr 1, 2016 at 3:19 PM, Andreas Volz 
> > wrote:
> > > I compiled e20 on Raspberry Pi 2 with latest Raspbian and it
> > > works. I had to deactivate Composite Effects and switch to
> > > Software renderer because it says there's no OpenGL support.
> >
> 
> The latests rasbian images for rpi2 include the experimental VideoCore
> open source drivers :)
> 
> https://www.raspberrypi.org/blog/another-new-raspbian-release/
> 
> I successfully built efl+gl on rpi2 using this driver and efl
> applications run quite fast. There is still (at least) one issue i
> faced: the driver seems
> not able to load big textures (something like 1000x1000px or more),
> and it slow down a lot when it fails. This for example make e20
> unusable because it cannot load the e background texture.
> 
> I did not investigate further, maybe it is just a stupid problem.
> 
> Please  let me know if you do some progress in this area, I really
> would like to see my emotion media center run smoothly on raspy :)
> 
> 
> 
> 
> >
> > Yes, RPi have still today a proprietary driver that is not following
> > standard integration with X requiring a custom backend to make it
> > work. I was hoping to see the open source driver sooner, but it is
> > not there yet. We do have in master a backend, eglfs, which will
> > support this kind of proprietary driver in the near future.
> > Hopefully for 1.18. It is currently done around hwcomposer, but
> > should also be able to support RPi and others. This backend will
> > also allow the use of Enlightenment Wayland only mode.
> >
> > The RPi even has something close to hardware layer. So if someone
> > does spend the time to optimize our backend for it, it should
> > become quite usable. I say quite, because there will still be some
> > major slowness. Even with wayland, there won't be support for
> > Wayland EGL, so you will fallback to Wayland SHM. Wayland SHM
> > allocate at the moment the buffer on the client side. This means
> > that we can't give it a hardware memory pointer that the hardware
> > layer infrastructure could reuse. So we will always need the CPU to
> > do a useless memcpy from the client buffer to the hardware layer
> > buffer... Making it less useful, except maybe for mouse cursor...
> > So until there is an open source Open GL driver on the RPi, it will
> > lack behind on what we can do with it.
> >
> > > The reason because I did this is that like to run the Raspi with a
> > > 800x480 display and several fullscreen EFL applications which are
> > > stacked one over the other and the above one with alpha and shaped
> > > window.
> > >
> > > I use E20 only as layer manager and deactivated all other
> > > elements. Maybe E20 is oversized for that reason.
> > >
> > > I experienced now that the CPU load of the E process is really
> > > high even if nothing much happens. In idle the load is >10%, but
> > > if I render some edje content in my application the E process
> > > goes fast up >60-100% CPU. My application itself has very low CPU
> > > usage.
> >
> > Any change on the screen, should trigger a software rendering of
> > just the area that did change on screen. Note that shaped windows
> > and alpha are usually more complex to handle and require more
> > ressource to be drawn. With an anemic hardware like the RPi, it
> > doesn't suprise me to much that this is that slow/ressource
> > intensive.

I followed the tutorial and installed all components and restarted. It
works everything as before. Glxgears doesn't feel as hw accelerated. In
fullscreen very slow. Do I've to change any X configuration?

> > > I tried to start my application with the default Gtk based window
> > > manager, but it's strange. As long as I activate alpha and shaped
> > > window support in my application the application is somehow
> > > broken and hangs in the beginning. I didn't yet trace it out
> > > where it hangs.
> > >
> > > Do you have any ideas or explanations?
> >
> > Not for the last problem.

I'll for sure debug some more and report here.

regards
  Andreas

-- 
Technical Blog 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e20 on Raspberry Pi

[Andreas Volz]

Am Sat, 2 Apr 2016 11:37:27 +0900 schrieb Carsten Haitzler (The
Rasterman):

> On Sat, 2 Apr 2016 00:19:35 +0200 Andreas Volz 
> said:
> 
> > Hello,
> > 
> > I compiled e20 on Raspberry Pi 2 with latest Raspbian and it works.
> > I had to deactivate Composite Effects and switch to Software
> > renderer because it says there's no OpenGL support.
> > 
> > The reason because I did this is that like to run the Raspi with a
> > 800x480 display and several fullscreen EFL applications which are
> > stacked one over the other and the above one with alpha and shaped
> > window.
> > 
> > I use E20 only as layer manager and deactivated all other elements.
> > Maybe E20 is oversized for that reason.
> > 
> > I experienced now that the CPU load of the E process is really high
> > even if nothing much happens. In idle the load is >10%, but if I
> > render some edje content in my application the E process goes fast
> > up >60-100% CPU. My application itself has very low CPU usage.
> 
> software will have lots of overhead in x11. wayland actually will  be
> quite a lot better (wayland_shm). the reason i - any update - a
> blinking curor needs to ask x to copy pixels from the update
> region(s) into a shm buffer, then depending maybe copy again to a
> destination buffer, THEN render the canvas (updating objects withint
> the render update region) and again copying/scaling/blending to an
> update region shm buffer... THEN this shm buffer is copied to the
> actual fraembuffer by the xserver.
> 
> with gl and a decent driver , texture from pixmap, the render/blend
> is done by gpu and the rest is zero-copy.
> 
> in wayland same for gl and wayland_shm makes it zero-copy for clients
> to send updates to compositor. if compositor is also sw, it's just
> the rendering cot, then the buffer swap which is zero-copy.
> 
> so yes - you'll have overhead. several copies of updates everywhere.
> even a tiny blinking cursor causes all of the above.
> 
> oh if your app uses a shaped window things can be even worse as e ha
> to merge shape rects into the alpha values of the pixel data it just
> copied... :)
> 
> maybe you might want to try e in wayland mode? it doesn't NEED
> egl/gles. just kms/drm ...

The wayland on the system seems to be to old (<1.8?). At least E
reports a configure check problem.

regards
  Andreas

-- 
Technical Blog 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e20 on Raspberry Pi

[The Rasterman]

On Sat, 2 Apr 2016 14:25:48 +0200 Andreas Volz  said:

> Am Sat, 2 Apr 2016 11:37:27 +0900 schrieb Carsten Haitzler (The
> Rasterman):
> 
> > On Sat, 2 Apr 2016 00:19:35 +0200 Andreas Volz 
> > said:
> > 
> > > Hello,
> > > 
> > > I compiled e20 on Raspberry Pi 2 with latest Raspbian and it works.
> > > I had to deactivate Composite Effects and switch to Software
> > > renderer because it says there's no OpenGL support.
> > > 
> > > The reason because I did this is that like to run the Raspi with a
> > > 800x480 display and several fullscreen EFL applications which are
> > > stacked one over the other and the above one with alpha and shaped
> > > window.
> > > 
> > > I use E20 only as layer manager and deactivated all other elements.
> > > Maybe E20 is oversized for that reason.
> > > 
> > > I experienced now that the CPU load of the E process is really high
> > > even if nothing much happens. In idle the load is >10%, but if I
> > > render some edje content in my application the E process goes fast
> > > up >60-100% CPU. My application itself has very low CPU usage.
> > 
> > software will have lots of overhead in x11. wayland actually will  be
> > quite a lot better (wayland_shm). the reason i - any update - a
> > blinking curor needs to ask x to copy pixels from the update
> > region(s) into a shm buffer, then depending maybe copy again to a
> > destination buffer, THEN render the canvas (updating objects withint
> > the render update region) and again copying/scaling/blending to an
> > update region shm buffer... THEN this shm buffer is copied to the
> > actual fraembuffer by the xserver.
> > 
> > with gl and a decent driver , texture from pixmap, the render/blend
> > is done by gpu and the rest is zero-copy.
> > 
> > in wayland same for gl and wayland_shm makes it zero-copy for clients
> > to send updates to compositor. if compositor is also sw, it's just
> > the rendering cot, then the buffer swap which is zero-copy.
> > 
> > so yes - you'll have overhead. several copies of updates everywhere.
> > even a tiny blinking cursor causes all of the above.
> > 
> > oh if your app uses a shaped window things can be even worse as e ha
> > to merge shape rects into the alpha values of the pixel data it just
> > copied... :)
> > 
> > maybe you might want to try e in wayland mode? it doesn't NEED
> > egl/gles. just kms/drm ...
> 
> The wayland on the system seems to be to old (<1.8?). At least E
> reports a configure check problem.

:( you could look for updated wl packages - or try something else like arch?


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


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [apps/ephoto] master 01/01: EPhoto: Remove all toolbars in favor of context menus and key bindings.

[The Rasterman]

On Sat, 2 Apr 2016 12:06:43 +0200 Davide Andreoli  said:


> well, I don't need it for 1.18 but for 2.0, when we will need to port
> existing
> apps to efl2. So I think there will be the time to implement Slideshow in
> the Eo API. Indeed the Slideshow widget need a rewrite, it has some
> problems as it is implemented now.

perhaps really complex ui components like slideshop should belong in some
separate collection of "useful but not core/necessary" widgets?


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


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [apps/ephoto] master 01/01: EPhoto: Remove all toolbars in favor of context menus and key bindings.

[Stephen Houston]

I think the necessary tools are already there to do a slideshow.  Image
widget, button widget, layout widget, timer, etc... I think a toolkit
should provide all of the basic elements, but not be worried with
maintaining, as you said, complex widgets.  It's obviously a question of
where to draw the line as to how high level to make widgets... I'm of the
philosophy of keeping it low level and super refined and stable.  The
higher level we go, the less diversity we will have among applications.
Some may like that, some may not.  Also, the higher level we go, the more
generic those widgets will become, not fitting specific needs, and causing
people to just rewrite their own versions anyway.  I think retiring
slideshow is a good idea, and Ephoto uses it at the moment.  I've been
intending to write my own version anyway.  Just my two cents.
On Apr 2, 2016 8:33 AM, "Carsten Haitzler"  wrote:

> On Sat, 2 Apr 2016 12:06:43 +0200 Davide Andreoli 
> said:
>
>
> > well, I don't need it for 1.18 but for 2.0, when we will need to port
> > existing
> > apps to efl2. So I think there will be the time to implement Slideshow in
> > the Eo API. Indeed the Slideshow widget need a rewrite, it has some
> > problems as it is implemented now.
>
> perhaps really complex ui components like slideshop should belong in some
> separate collection of "useful but not core/necessary" widgets?
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] E21 Freeze Has Begun

[Mike Blumenkrantz]

If you have any large features to merge which do not fall into either
Wayland or Gadgets, they should probably wait a few weeks until E22
development has begun.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] gif: fix oob reads w/bad colormaps

[Mike Frysinger]

From: Bernhard Übelacker 

Verify the color map is inbounds before indexing with it.

https://bugs.debian.org/785369
---
 src/modules/loaders/loader_gif.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/modules/loaders/loader_gif.c b/src/modules/loaders/loader_gif.c
index 638df59..7bdf29c 100644
--- a/src/modules/loaders/loader_gif.c
+++ b/src/modules/loaders/loader_gif.c
@@ -170,9 +170,16 @@ load(ImlibImage * im, ImlibProgressFunction progress, char 
progress_granularity,
 }
   else
 {
-   r = cmap->Colors[rows[i][j]].Red;
-   g = cmap->Colors[rows[i][j]].Green;
-   b = cmap->Colors[rows[i][j]].Blue;
+   if (rows[i][j] < cmap->ColorCount)
+ {
+r = cmap->Colors[rows[i][j]].Red;
+g = cmap->Colors[rows[i][j]].Green;
+b = cmap->Colors[rows[i][j]].Blue;
+ }
+   else
+ {
+r = g = b = 0;
+ }
*ptr++ = (0xff << 24) | (r << 16) | (g << 8) | b;
 }
   per += per_inc;
-- 
2.7.4


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] gif: fix oob reads w/bad colormaps

[Yuriy M. Kaminskiy]

Mike Frysinger  writes:

This does not cover out-of-bound SBackGroundColor (giflib does not
verify if it is less than ColorCount).
I've just sent *better* patch that fixes this problem:
http://permalink.gmane.org/gmane.comp.window-managers.enlightenment.devel/64001
(with wrong bug link)

> From: Bernhard Übelacker 
>
> Verify the color map is inbounds before indexing with it.
>
> https://bugs.debian.org/785369
> ---
>  src/modules/loaders/loader_gif.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/modules/loaders/loader_gif.c 
> b/src/modules/loaders/loader_gif.c
> index 638df59..7bdf29c 100644
> --- a/src/modules/loaders/loader_gif.c
> +++ b/src/modules/loaders/loader_gif.c
> @@ -170,9 +170,16 @@ load(ImlibImage * im, ImlibProgressFunction progress, 
> char progress_granularity,
>  }
>else
>  {
> -   r = cmap->Colors[rows[i][j]].Red;
> -   g = cmap->Colors[rows[i][j]].Green;
> -   b = cmap->Colors[rows[i][j]].Blue;
> +   if (rows[i][j] < cmap->ColorCount)
> + {
> +r = cmap->Colors[rows[i][j]].Red;
> +g = cmap->Colors[rows[i][j]].Green;
> +b = cmap->Colors[rows[i][j]].Blue;
> + }
> +   else
> + {
> +r = g = b = 0;
> + }
> *ptr++ = (0xff << 24) | (r << 16) | (g << 8) | b;
>  }
>per += per_inc;


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [imlib2] [PATCH] off-by-one OOB read in __imlib_MergeUpdate

[Yuriy M. Kaminskiy]

Run `valgrind imlib2_test`, move mouse to right lower corner, got
==16086== Invalid read of size 1
==16086==at 0x4E79C4E: __imlib_MergeUpdate (in 
/usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6)
==16086==by 0x401773: main (in /usr/bin/imlib2_test)
==16086==  Address 0x9d20360 is 0 bytes after a block of size 1,200
alloc'd
==16086==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16086==by 0x4E798E3: __imlib_MergeUpdate (in 
/usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6)
==16086==by 0x401773: main (in /usr/bin/imlib2_test)

It is at src/lib/updates.c:
   |113|   for (xx = x + 1, ww = 1; 
|
  >|114|(T(xx, y).used & T_USED) && (xx < tw); 
xx++,|
   |115|   for (yy = y + 1, hh = 1, ok = 1; 
|

xx is 20 and tw is 20, so T(xx, y) addresses one byte out of buffer.

Two *alternative* patches attached (apply only *one* of them).
TODO: I have not tried to search for similar pattern over codebase (yet).

Debian-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819818

Description: off-by-one out-of-bound read due to reversed condtion
Author: Yuriy M. Kaminksiy 
Debian-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819818

Note: you need *either* off-by-one-alternative.patch, *or* this patch;
DO NOT APPLY BOTH! (it won't break, but would unnecessarily clutter code)

Index: imlib2-1.4.6/src/lib/updates.c
===
--- imlib2-1.4.6.orig/src/lib/updates.c
+++ imlib2-1.4.6/src/lib/updates.c
@@ -111,7 +111,7 @@ __imlib_MergeUpdate(ImlibUpdate * u, int
   int xx, yy, ww, hh, ok;
 
   for (xx = x + 1, ww = 1;
-   (T(xx, y).used & T_USED) && (xx < tw); xx++, ww++);
+   (xx < tw) && (T(xx, y).used & T_USED); xx++, ww++);
   for (yy = y + 1, hh = 1, ok = 1;
(yy < th) && (ok); yy++, hh++)
 {
Description: off-by-one out-of-bound read due to reversed condtion, alternative solution (allocates one more guard cell).
Author: Yuriy M. Kaminksiy 
Debian-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819818

Note: you need *either* off-by-one-reversed-condition.patch, *or* this patch;
DO NOT APPLY BOTH! (it won't break, but would unnecessarily clutter code)

Index: imlib2-1.4.6/src/lib/updates.c
===
--- imlib2-1.4.6.orig/src/lib/updates.c
+++ imlib2-1.4.6/src/lib/updates.c
@@ -34,13 +34,14 @@ __imlib_MergeUpdate(ImlibUpdate * u, int
th = h >> TB;
if (h & TM)
   th++;
-   t = malloc(tw * th * sizeof(struct _tile));
+   t = malloc((tw * th + 1) * sizeof(struct _tile));
/* fill in tiles to be all not used */
for (i = 0, y = 0; y < th; y++)
  {
 for (x = 0; x < tw; x++)
t[i++].used = T_UNUSED;
  }
+   t[i].used = T_UNUSED;
/* fill in all tiles */
for (uu = u; uu; uu = uu->next)
  {
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [apps/ephoto] master 01/01: EPhoto: Remove all toolbars in favor of context menus and key bindings.

[Davide Andreoli]

2016-04-02 15:59 GMT+02:00 Stephen Houston :

> I think the necessary tools are already there to do a slideshow.  Image
> widget, button widget, layout widget, timer, etc... I think a toolkit
> should provide all of the basic elements, but not be worried with
> maintaining, as you said, complex widgets.  It's obviously a question of
> where to draw the line as to how high level to make widgets... I'm of the
> philosophy of keeping it low level and super refined and stable.  The
> higher level we go, the less diversity we will have among applications.
> Some may like that, some may not.  Also, the higher level we go, the more
> generic those widgets will become, not fitting specific needs, and causing
> people to just rewrite their own versions anyway.  I think retiring
> slideshow is a good idea, and Ephoto uses it at the moment.  I've been
> intending to write my own version anyway.  Just my two cents.
>

I disagree here, building a slideshow in app code is not that easy and it
require the developer to write some edc for the animations, thus requiring
and edje file installation and thus making the app harder to theme.
I consider the slideshow widget simple and useful.



> On Apr 2, 2016 8:33 AM, "Carsten Haitzler"  wrote:
>
> > On Sat, 2 Apr 2016 12:06:43 +0200 Davide Andreoli <
> d...@gurumeditation.it>
> > said:
> >
> >
> > > well, I don't need it for 1.18 but for 2.0, when we will need to port
> > > existing
> > > apps to efl2. So I think there will be the time to implement Slideshow
> in
> > > the Eo API. Indeed the Slideshow widget need a rewrite, it has some
> > > problems as it is implemented now.
> >
> > perhaps really complex ui components like slideshop should belong in some
> > separate collection of "useful but not core/necessary" widgets?
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >
> >
> >
> --
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e20 on Raspberry Pi

[Andreas Volz]

Am Sat, 2 Apr 2016 22:31:49 +0900 schrieb Carsten Haitzler (The
Rasterman):

> > > oh if your app uses a shaped window things can be even worse as e
> > > ha to merge shape rects into the alpha values of the pixel data
> > > it just copied... :)
> > > 
> > > maybe you might want to try e in wayland mode? it doesn't NEED
> > > egl/gles. just kms/drm ...
> > 
> > The wayland on the system seems to be to old (<1.8?). At least E
> > reports a configure check problem.
> 
> :( you could look for updated wl packages - or try something else
> like arch?

I managed to update wayland on my Ubuntu 14.04 system. But now next
point.

./configure --prefix=/opt/e20 --enable-wayland --enable-egl
--with-opengl=es --enable-drm --enable-systemd
...
configure: error: systemd support wanted, but systemd was not found.

Is a recent systemd really needed to get wayland in E20 working as
written here?

https://git.enlightenment.org/core/enlightenment.git/tree/README.wayland

regards
  Andreas

-- 
Technical Blog 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e20 on Raspberry Pi

[The Rasterman]

On Sat, 2 Apr 2016 23:30:27 +0200 Andreas Volz  said:

> Am Sat, 2 Apr 2016 22:31:49 +0900 schrieb Carsten Haitzler (The
> Rasterman):
> 
> > > > oh if your app uses a shaped window things can be even worse as e
> > > > ha to merge shape rects into the alpha values of the pixel data
> > > > it just copied... :)
> > > > 
> > > > maybe you might want to try e in wayland mode? it doesn't NEED
> > > > egl/gles. just kms/drm ...
> > > 
> > > The wayland on the system seems to be to old (<1.8?). At least E
> > > reports a configure check problem.
> > 
> > :( you could look for updated wl packages - or try something else
> > like arch?
> 
> I managed to update wayland on my Ubuntu 14.04 system. But now next
> point.
> 
> ./configure --prefix=/opt/e20 --enable-wayland --enable-egl
> --with-opengl=es --enable-drm --enable-systemd
> ...
> configure: error: systemd support wanted, but systemd was not found.
> 
> Is a recent systemd really needed to get wayland in E20 working as
> written here?
> 
> https://git.enlightenment.org/core/enlightenment.git/tree/README.wayland

i've never run it without systemd... :)

> regards
>   Andreas
> 
> -- 
> Technical Blog 
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e20 on Raspberry Pi

[Simon Lees]

On 04/03/2016 07:00 AM, Andreas Volz wrote:
> Am Sat, 2 Apr 2016 22:31:49 +0900 schrieb Carsten Haitzler (The
> Rasterman):
> 
 oh if your app uses a shaped window things can be even worse as e
 ha to merge shape rects into the alpha values of the pixel data
 it just copied... :)

 maybe you might want to try e in wayland mode? it doesn't NEED
 egl/gles. just kms/drm ...
>>>
>>> The wayland on the system seems to be to old (<1.8?). At least E
>>> reports a configure check problem.
>>
>> :( you could look for updated wl packages - or try something else
>> like arch?
> 
> I managed to update wayland on my Ubuntu 14.04 system. But now next
> point.
> 
> ./configure --prefix=/opt/e20 --enable-wayland --enable-egl
> --with-opengl=es --enable-drm --enable-systemd
> ...
> configure: error: systemd support wanted, but systemd was not found.
> 
> Is a recent systemd really needed to get wayland in E20 working as
> written here?
> 
From memory its probably logind rather then systemd thats strictly
required which some ubuntu versions do package without systemd, I don't
remember which ones though. The requirement is based off needing to
provide user access to display and input devices.

> https://git.enlightenment.org/core/enlightenment.git/tree/README.wayland
> 
> regards
>   Andreas
> 

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adeliade Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel