va_list may be typedef'ed not only to array and pointer but also to a
plain struct. It could be made to work this way, but it's a lot simpler
a safer to not depend on it. To deal with the array corner case we copy
the va_list from the function arguments to the stack and call the "real"
function passing it.
SVN revision: 82017
it's useful to copy file from one place to another and this will be
used in eio' s implementation.
NOTE: did not use mmap here as mmap faults may be cumbersome to handle
(Eina_File itself does that, but in a nasty way) and the
implementation would be severely different as there is no Eina_File
from FD, and there is no way to inject custom memory/fd into the
Eina_File's fault handling. The performance would not be that
different anyways and the splice() is already in there for systems
with good performance (read: Linux).
SVN revision: 81942
* fix eina_xattr_value_ls() and eina_xattr_value_fd_ls() to not loop
infinitely.
* NULL terminate the retrieved xattr values, at least they'll be
easier to handle in our programs and less error prone.
SVN revision: 81940
- fchmod() was isolated by HAVE_CHMOD, which was always present
before... then fchmod() is also present as no errors were reported
since its introduction.
- fchmod() is POSIX for a while now.
- lstat() is POSIX for a while now.
- setxattr is supported by EFL_CHECK_FUNCS() as is used by eina.
- splice() check added to EFL_CHECK_FUNCS()
SVN revision: 81938
eina_thread_join() is nasty and didn't report errors :-(
I'm using Eina_Error here, but it's global to the application and not
thread-local. Maybe we should make eina_error_get() and
eina_error_set() thread-local storage?
SVN revision: 81936
some functions were being checked but their IFDEF not being handled,
others (getpwnam and getgrnam) were isolated in a code that is now
Windows, then no need to check them as well as these are POSIX.
SVN revision: 81934
although we force them to be fixed to static, we left the automake to
make it possible and they were wrong:
- missed the proper directory prefix for .la files (were being generated at src/)
- had typos due copy & paste, with chained being used in some places.
SVN revision: 81933
seems that automake will parse LDFLAGS for -module and if it's not
present it will complain about name not starting with 'lib'.
seems my last try was without NOCONFIGURE=1 and autogen continued to
the old ./configure, that printed lots of messages and the error went
unnoticed
SVN revision: 81917
- remove EFL_LIBS and EFL_CFLAGS, use per-lib values that inherit
from EFL (general)
- add NAME_LDFLAGS and EFL_LDFLAGS for linker flags.
- LDADD (binaries) now use NAME_LDFLAGS instead of NAME_LIBS, as they
link to libname.la and that will pull in the libtool dependencies
SVN revision: 81915
NOTE: There is still an issue with text rendering, that
is still 4 times slower and impact all text object (text,
textblock and textgrid).
SVN revision: 81912
weird enough to build with memcheck.h you just need valgrind's CFLAGS,
not its libraries as they are not supposed to be used like that,
throwing many bgPlain_ errors (vgPlain_tl_pre_clo_init,
vgPlain_free...) from libcoregrind-x86-linux.a
SVN revision: 81901
many distros deprecate libexec and it's better to keep our stuff
together inside /usr/lib/evas.
cserve2 binaries now lives in /usr/lib/evas/cserve2/bin
SVN revision: 81897
Make sure the next signal handler for the connection is always known and
not vanish under us.
Patch by: Ulisses Furquim <ulisses@profusion.mobi>
SVN revision: 81847
Also postpone marking the rendering flag until we know we will have
the draw thread do its work. This way we avoid waiting forever at
evas_render_rendering_wait() when the draw thread is also blocked.
Patch by: Ulisses Furquim <ulisses@profusion.mobi>
SVN revision: 81798
The _request_failed() function is called by error responses from slaves,
and iterating over references of a entry and removing each of them must
be done with EINA_LIST_FOREACH_SAFE(), since _entry_free_cb() calls
_entry_reference_del() which then removes the reference that is used in
the next iteration in for-loop from _request_failed().
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 81580
This function was basically never working correctly. Everything was
fixed by simulating the evas_object_image_render() workflow, but
instead of actually draw we just check the pixel transparency.
Bugs fixed:
* fails when image is scaled up (could segv) or down (incorrect values);
* fails when image is moved to negative x,y;
* fails when border was being used.
Now everything is fixed and seems to work properly, except I'm not
handling the map and get_pixels() cases, these are marked with ERR()
so we can fix them if someone needs.
SVN revision: 81410
Whenever we copy an image, making it write-able
(evas_object_image_data_get(o, 1)) or just start painting a pristine
buffer (evas_object_image_size_set(o, w, h)), we must mark the image
as loaded to avoid trying to load it (and failing, marking the whole
thing as EVAS_LOAD_ERROR_GENERIC).
SVN revision: 81409
In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE
flag make CPU usage 100%. The proper way to monitor the ECORE_FD_WRITE
is when the wl_display_flush() return value < 0 and errno == EAGAIN.
And if wl_display_flush() return, we remove ECORE_FD_WRITE flag from
the display fd.
Change from v1:
Add idle enterer destroy code into _ecore_wl_shutdown() to avoid
using freed wl_display.
SVN revision: 81360
- EVAS_CALLBACK_FREE and EVAS_CALLBACK_DEL were doing the same thing
at different stages, causing a segv due double free.
- extn->file.updates and its Ipc_Data_Update were leaking.
PS: I can't backport this to 1.7, but the problem is still
there. Could someone look into those?
SVN revision: 81304
tree simply is broken and doesnt compile. error here:
...
src/Makefile_Evas.am:1809: unterminated conditionals: HAVE_WINDOWS_TRUE
src/Makefile.am:24: src/Makefile_Evas.am' included from here
src/Makefile.am:128: unterminated conditionals: HAVE_WINDOWS_TRUE
src/Makefile.am: installing ./depcomp'
automake: ####################
automake: ## Internal Error ##
automake: ####################
automake: undefined condition TRUE' for RECURSIVE_TARGETS'
automake: RECURSIVE_TARGETS:
automake: {
automake: HAVE_WINDOWS => {
automake: type: +=
automake: where: /usr/share/automake-1.11/am/texinfos.am:
automake: comment:
automake: value: dvi-recursive html-recursive info-recursive
pdf-recursive ps-recursive \
automake: install-dvi-recursive \
automake: install-html-recursive \
automake: install-info-recursive \
automake: install-pdf-recursive \
automake: install-ps-recursive all-recursive check-recursive
installcheck-recursive
automake: owner: Automake
automake: }
automake: }
automake:
automake: Please contact <bug-automake@gnu.org>.
at /usr/share/automake-1.11/Automake/Channels.pm line 657
Automake::Channels::msg('automake', '', 'undefined condition
TRUE\' for RECURSIVE_TARGETS\'\x{a}RECURSIV...') called at
/usr/share/automake-1.11/Automake/ChannelDefs.pm line 208
Automake::ChannelDefs::prog_error('undefined condition TRUE\'
for RECURSIVE_TARGETS\'\x{a}RECURSIV...') called at
/usr/share/automake-1.11/Automake/Item.pm line 94
Automake::Item::rdef('Automake::Variable=HASH(0x38cbe20)',
'Automake::Condition=HASH(0x2832a48)') called at /usr/bin/automake
line 4102
Automake::handle_subdirs() called at /usr/bin/automake line 8305
Automake::generate_makefile('src/Makefile.am',
'src/Makefile.in') called at /usr/bin/automake line 8602
Automake::handle_makefile('src/Makefile.in') called at
/usr/bin/automake line 8616
Automake::handle_makefiles_serial() called at
/usr/bin/automake line 8769
autoreconf: automake failed with exit status: 255
...
i looked at the HAVE_WINDOWS if's and it seems fine to me - i couldnt
find what was missing, so i had to resort to a revert instead of fix :(
sorry :(
SVN revision: 81267
This is in preparation for threaded render landing: the render thread will
hold a reference to a text object's glyphs while it hasn't been rendered
yet (and will drop that reference after drawing). This changes the internal
API a little bit (evas_common_font_rgba_draw() now takes an Evas_Glyph_Array
instead of an Evas_Text_Props).
SVN revision: 81183
line position is slightly different between gl drivers.
I have no idea why it is. So added to work differently based on the manufacturers.
This work may be based on the renderer. If you can test it with much drivers then please test and fix.
Also changed the ENV name from EVAS_GL_LINE_NO_OFFSET_HACK to EVAS_GL_LINE_OFFSET_HACK_DISABLE.
SVN revision: 81016
Give it sound files (ogg, wav, not mp3) as parameter or
"tone:freq=<f>,duration=<dur_in_s>" to play a lovely sine wave
* '<' and '>' seek forward and backward
* '+' and '-' change the volume
* Space toggles pause
* Shows information for the song (remaining, %)
* (Un)loop a song with 'l'
* 'n' - Next song
* 'm' - Next song simultaneous to current
* Volume can be set from 0 - 150%
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 81001
Disabled by default, enable with --enable-audio
ALSA support is disabled as it is not there yet. Pulseaudio should work
though.
Support for .ogg and .wav is there as well (.mp3 is not)
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 81000
By rudimentary I mean I barely got it to work. For my particular test
case. It will not work for you and needs lots of love until it can be
used.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80999
Very hackish implementation and probably not needed as libsndfile
virtual IO can be used instead, though it's a little more complicated
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80998
Allows reading from and writing to wav, ogg, etc. files. Support for
virtual IO as well to allow playing sounds from eet, which will be
needed in edje multisense.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80996
This is still very much a work in progress, so expect some issues. The
signalling is using ecore events for now - that will change to callbacks
you can register callbacks for events on specific Ecore_Audio_Objects.
EO wasn't there when Ecore_Audio started, but it will probably move to
that in the future.
Otherwise have fun, don't break it (too much) and please send bug
reports and feedback to me.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80994
collateral damages that need further investigation. All programs running with
wayland engines are consuming 100% CPU.
ecore-wayland: Fix monitoring ECORE_FD_WRITE defaultly on
wayland display fd lead to 100% cpu usage
In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE
flag make CPU usage 100%. The proper way to monitor the ECORE_FD_WRITE
is when the wl_display_flush() return value < 0 and errno == EAGAIN.
And if wl_display_flush() return, we remove ECORE_FD_WRITE flag from
the display fd.
Patch by: Alex Wu <zhiwen.wu@linux.intel.com>
SVN revision: 80981
Report from Klocwork. I checked that the actual max size of the name is
13 bytes. Now we allocate one more to hold the terminating NULL byte and
not write into unallocated memory.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80773
I tested gl line drawing on a few devices and found the x line start position was 1.
On the other hand, our evas draws the line on start position 0.
So it needs to shift by 1 pixel if evas is working on gl backcned.
SVN revision: 80734
Thanks to PrinceAMD (Deon Thomas) for bugging me to implement this,
then test and add a fix, now we can implement something similar to
"xterm -e" in terminology.
ECORE_GETOPT_ACTION_BREAK will allow generic options to behave the
same as GNU's --, breaking out of argument parsing logic.
SVN revision: 80619
Subject: [E-devel] [PATCH][Ecore] Fixes for invalid memory read issues
discovered by cppcheck
One more patch to fix issues discovered by cppcheck.
SVN revision: 80559
instead of -DHAVE_ECORE_X_XCB in the pc, which is a super-hack, add a
proper compile-time generated ecore_x_version.h that is included by
Ecore_X.h
This file contains HAVE_ECORE_X_XLIB or HAVE_ECORE_X_XCB defined and
will also define ECORE_X_VERSION_MAJOR and ECORE_X_VERSION_MINOR as
per other EFL (Ecore), also defining the runtime version in
Ecore_X_Version.
SVN revision: 80524
wayland display fd lead to 100% cpu usage
In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE
flag make CPU usage 100%. The proper way to monitor the ECORE_FD_WRITE
is when the wl_display_flush() return value < 0 and errno == EAGAIN.
And if wl_display_flush() return, we remove ECORE_FD_WRITE flag from
the display fd.
Patch by: Alex Wu <zhiwen.wu@linux.intel.com>
SVN revision: 80476
still lots to do, but some improvements:
- ecore_evas does not inherit pkg-config from modules since modules are SO
- renamed internal ecore evas define from SOFTWARE_BUFFER to BUFFER,
to make consistent.
SVN revision: 80473
* a single option --with-evas-dither-mask=TYPE (big, small, line or none).
* make a wise decision to fallback to small dither mask for
conversions that do not support "no-dither" or "line". Before if
you did not specify it would fallback to big (128x128).
SVN revision: 80383
instead of the previous mess, just define the functions with common
names and call the backend that was compiled in, similar to what eio
does.
also do not be silent on errors, use eina_safety_checks to issue warnings.
SVN revision: 80360
Another try to make inotify checks more common.
This time uses AC_CHECK_HEADERS() as for others, that already define
HAVE_SYS_INOTIFY_H, then uses that.
I still kept AM_CONDITIONAL([HAVE_INOTIFY]) because I plan to convert
ecore_file to the same, smarter, method that is used in eio (compiling
the file depending on the backend.
SVN revision: 80358
* remove the option, as it shouldn't really exist.
* keep code, as requested by Cedric, someone may fix it someday. And
the default is the DISABLED, as the enable was broken.
* Add instructions on how to solve the problem, if a brave folk is up
to it.
SVN revision: 80352
* rename USE_GNUTLS and USE_OPENSSL to HAVE_GNUTLS and HAVE_OPENSSL
in ecore_con, to match other modules such as Eet.
* define requirements_pc_crypto, requirements_pc_deps_crypto and
requirements_libs_crypto so modules can use that.
* move to a common check section.
SVN revision: 80288
* remove EVAS_ prefix as it may be used by other libs some day.
* SSE3 is detected at runtime if x86.
* remove AC_SUBST([altivec_cflags]) as it was not being used anywhere.
* moved to top of file (maybe position is not optimal, let's wait
vtorri to review)
* simplified single-line summary that is as informative as before.
SVN revision: 80284
Implementing support for loadables modules. It makes the engines been
loaded when they are needed. It not breakes the api, so each engine
still has its own api.
The implementation basically is:
* Functions that creates Ecore_Evas, for example
ecore_evas_software_x11_new, request to load its module and then get
the module's function to create the Ecore_Evas.
* The other functions such as \(.*\)_window_get from the Ecore_Evas
its interface and then call the appropriate method.
* As there is no unified interface to communicate with the engines
(not break api problem), all interfaces were declared in
ecore_evas_private.h
* Now the data necessary for each module is not declared in the
Ecore_Evas_Engine structure, instead of this, the struct has a void
pointer that is used by the modules.
* In this first moment engines as software_x11 and gl_x11 were put
together in the same module, but obviously exporting all the things
necessary.
SVN revision: 80280
Including ECORE_LIBS in LDADD is not enough, we have to include the
relevant libs from efl as well (eina, evas, ...)
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80260
After agreement in the mail list, core developers agree to remove this
engine that was not being supported for a long time.
Given that most operations Evas uses are not accelerated in DirectFB,
or at least hardware that exclusively supports DirectFB, it's better
for those people to just use Evas/Ecore software (buffer) rendering
and expose DirectFB's framebuffer as destination surface.
SVN revision: 80232
Subject: Re: Re: Re: [E-devel] [RFC] Virtual desktop window profile
I've attached 4th patch. May the 4th be with you.
ecore patch has been merged with efl and all files are based on r80123.
Thanks & Regards,
Gwanglim
------- Original Message -------
Sender : Daniel Juyung Seo<seojuyung2@gmail.com>
Date : 2012-12-04 01:55 (GMT+09:00)
Title : Re: Re: [E-devel] [RFC] Virtual desktop window profile
It looks ok to me.
Sorry but can you re-generate the patch according to the recent ecore
merge to efl single tree?
Daniel Juyung Seo (SeoZ)
On Thu, Nov 29, 2012 at 12:29 AM, Gwanglim Lee <gl77.lee@samsung.com>
wrote:
Dear Raster and Daniel Juyung Seo,
I've attached 3rd patches and test_config according to your reviews.
These are based on r79782.
[elementary & ecore]
1. "profile,set" -> "profile,changed" - done
2. spaces after EINA_LIST_FOREACH - done
3. variable type - keep
4. author - done
5. removing deprecated marking in patch - done
6. add elm_win_available_profiles_get to test_config for the debugging
purpose - done
7. check whether a given profile is present in an available profiles.
otherwise window profile will be one of the item
in available profiles. - newly added thing to the elm_win
8. merge with EO - done. :(
Any comments would be appreciated.
SVN revision: 80214
I've tested it and I can confirm that it's working fine with the new
scalecache support on Cserve2. So, let's use it again.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 80177
If information like size, scale down, dpi or region is set to any object,
or even if reload of that object is required, evas_object_image_load() is
called and Evas needs to pass scaling information through load_opts as
evas_object_image_file_set() does to Cserve2 as well.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 80176