Summary: This option Was added originally so that software drm and
hardware drm could be done in the same 'engine'. Since we have drm and
gl_drm now as separate engines, this option is no longer needed.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Made http and ftp url configurable via configure and also added test cases for ftp upload and http post.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: Sergeant_Whitespace, cedric
Subscribers: Sergeant_Whitespace, cedric
Differential Revision: https://phab.enlightenment.org/D2226
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Idea for this library is to become a retained mode drawing library that use
Eo/Eolian for its API and take a lot of the good design from Enesim by
Jorge Zapata and Jose Gonzalez (http://enesim.org/).
Cedric, our dear b0rker, introduced changes in the CFLAGS
generation when merging Emile. While the changes seem to make sense
at first sight (add the -I flags for the lib our new package depends on),
they were actually a terribly bad workaround.
The number of CFLAGS args would grow exponentially, slowing down libtool
a lot, which is known to be slow when it has a lot of arguments.
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
this patch adds an implementation of eio_monitor based on FSEvent
for OSX. This implentation has some limitations compared to inotify
implementation. Folowing events are not detected:
- EIO_MONITOR_FILE_CLOSED
- EIO_MONITOR_SELF_RENAME
- EIO_MONITOR_SELF_DELETED
It should be noted that some events that happend before the call
to eio_monitor_add can be catched. This is why sleep timers have
been added in the test suite.
Tests have been added to check uncovered scenarios.
some things might still be improved:
- self_deleted events for files might be handled by checking the
file_name manually
- self_deleted events for directories might be handled by setting
kFSEventStreamCreateFlagWatchRoot. I've noticed by doing so that
a lot more unwanted event are raised
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Add eina_test_xattr.c file for testing eina xattr functions and added test
cases for eina_xattr_set and eina_xattr_fd_set functions. Those tests need
a directory where the underlying file system allow xattr. Usually /tmp is
running on tmpfs that doesn't support today xattr. This test won't be run
if we are not provided with an existing proper directory.
Signed-off-by: vivek <vivek.ellur@samsung.com>
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2090
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: Added cmake config files for Eio
Test Plan: install it and test it with a app with needs eio
Reviewers: cedric, tasn
Reviewed By: tasn
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2079
This was the only user of xcb-xprint and we already have a fallback in place for
it. I talked to Chris about it and he was fine with it before his morning coffee.
More serious this should be ok and we can get rid of this part which starts to
make trouble in distros by now. E.g. gentoo is disabling it completely and many
others just ship upstream which means no pc file. Arch seems to patch it in but
we are on the safe side with just using the fallback.
xcb no longer ships the xcp-print.pc file and thus pkg-config is not able to
detect it. Some distros might patch over it as the source files seem still to
be shipped but we cannot rely on this.
http://lists.freedesktop.org/archives/xcb/2013-November/008907.html
As the above commit mentions the xprint support was actually removed from the
Xorg server in 2008 (1.11 release) which means none of our code actually has
any server side it can talk to for some years now. :) Our xcb-xprint code is
actually ifdef'ed already so we might want to remove it alltogether.
We check for libinput 06 or higher. In version 0.8 they got an API break
(hopefully the last one before 1.0) which we did not support so far. I have
seen libinput 0.9 used on gentoo and newer ubuntu systems so we should
definitely support them.
Adding a LIBINPUT_HIGHER_08 define to check for this. So far we have only one
location where we need it. Once there is a libinput 1.0 we should remove the
support for older versions.
http://lists.freedesktop.org/archives/wayland-devel/2015-January/019383.html
In previous version of this commit we checked if the _WIN32 macro was
defined. But now I am using EXEEXT from autotools to get
eolian_gen extension.
@fix
Summary: ecore-drm will now require libinput for handling input
devices, so this commit adds a configure check for libinput
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
- allow to launch drm backend without systemd-logind with root privilege.
- allow to open drm device node via logind, not directly open it, in case exist systemd-logind.
- fixes issue that couldn't switch session, because ecore-drm couldn't drop master to drm device with no permission. (allow to switch session appropriate.)
Reviewers: gwanglim, devilhorns
Subscribers: torori, cedric
Differential Revision: https://phab.enlightenment.org/D1704
Summary:
This was needed to install example on purposes
The problem is that the install_sh* variables
in generated makefiles are expanding to ~/install-sh
which is wrong and should be the one in root source tree
Change-Id: I5311298864a5f042de90071cb6dfaefbefdf001a
Bug: https://phab.enlightenment.org/T1889
Bug-Tizen: TC-2177
Signed-off-by: Philippe Coval <philippe.coval@open.eurogiciel.org>
Reviewers: seoz
Subscribers: stefan_schmidt, cedric
Maniphest Tasks: T1889
Differential Revision: https://phab.enlightenment.org/D1724
Summary:
Until now, it was necessary to set global LDFLAGS and CFLAGS to allow
compiling (and linking) engines using OpenGL.
gl_generic used to complained about missing headers or unkown libraries.
A problem on OSX is that there is CGL (Apple's Core OpenGL) on which the whole system
relies on and GLX, when X11 is installed; and they cohabit together.
When gl_cocoa is enabled, gl_generic is now linked against CGL.
When it is not, gl_generic is compiled with and linked against GLX as a fallback.
@fix
Test Plan:
With --enable-cocoa: software_x11, opengl_x11 and opengl_cocoa are working as expected.
With --disable-cocoa: software_x11 and opengl_x11 are also working as expected.
No compiling nor linking problems have been issued.
Reviewers: cedric, raster, raoulh
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1723
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Elocation is meant as a convenience library to ease application developers
the usage of geo information in their apps. Adding a geo tag to a picture or
translating an address to a GPS position and show it on a map widget are just
some of the use cases.
In the beginning elocation will rely on the GeoClue1 DBus service. Supporting
the new GeoClue2 DBus service is planned and worked on. GeoClue offers
providers for various techniques to get hold off the current position. Ranging
from GeoIP over wifi and GSM cell location to GPS.
This has been developed a while ago and was living in my private dev space.
It is about time to move this into EFL and bring it forward.
The detection of the GeoClue service is being handled on runtime and no new
dependency is added due to this library.
@feature
When adding xz as third compression format in May 2014 I mentioned that I'm
going to remove bzip2 in favor of xz in 1.12.
I heard no complains but I left it in for 1.12. With 1.13 starting its time
to remove it. From now on it will be only gz and xz compressed tarballs.