Summary:
OSX only support named semaphores. Eina_Semaphore was actually broken on OSX.
Since OSX 10.10 sem_init() and sem_destroy() (were not implemented) are also marked as
"deprecated", which adds huge pollution to the output when compiling.
Reviewers: cedric, raster, stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1576
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
DND does not work in X11 because we cannot set type.
The f8e036d5af causes this.
Since the xdnd type list does not exists at the beginning,
if we always return without setting new property, we cannot set dnd type.
This patch brings dnd work again by correcting the type set operation.
@fix
Test Plan: Try dnd tests in elementary_test.
Reviewers: raster, woohyun, JackDanielZ
Reviewed By: JackDanielZ
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1578
so this is a re-try at the evas gl destination alpha fix. this is what
cedric tried, but done RIGHT. it required adding an ecore_x call to
create a window with correct visual/colormap. it requires doing
visuals totally correctly all the way from ecore_evas to the evas
gl_x11 core. nvidia drivers are very picky about visuals. i also had
to vid the egl/gles code too to do the same thing. nvidia gles/egl
drivers are also picky, mesa is not. this all requires a lot of code
changes. it's far from trivial
this isn't backported for a few reasons:
1. verify this fix doesn't break for anyone.
i tested:
nvidia glx + egl/gles
intel glx + egl/gles
radeon glx
it needs wider testing. nouveau, fglrx for starters and maybe
some other gles/egl drivers.
2. have some review time
3. time to settle before blasting to stable branches
@fix
CreateProcess() has a flags parameter which is being passed
"run_pri | CREATE_SUSPENDED".
The issue lies in the value of run_pri. It is best explained by the
following code somewhere else in the file:
switch (run_pri)
{
case IDLE_PRIORITY_CLASS:
return ECORE_EXE_WIN32_PRIORITY_IDLE;
The run_pri variable is supposed to store a value from the win32 API while
it was used to store one from the ecore API.
If I recall correctly, the windows one is equal to 32 and the ecore one to
9999. Meaning 9999 ended up used as flags so let's have a look at what that
actually enabled; the reference is "Process Creation Flags" from MSDN
http://msdn.microsoft.com/en-us/library/ms684863%28v=vs.85%29.aspx .
9999 gives 0x0000270F and this matches
DEBUG_PROCESS | DETACHED_PROCESS | DEBUG_ONLY_THIS_PROCESS
| CREATE_SUSPENDED | CREATE_NEW_PROCESS_GROUP | CREATE_SEPARATE_WOW_VDM
| CREATE_UNICODE_ENVIRONMENT | <0x00002000 matches nothing>
Matches nothing? Weird. Well, maybe. Except that I stumbled upon this define
in the mingw-w64 headers:
#define CREATE_FORCEDOS 0x2000
Mingw-w64 only has a #define, Wine has nothing (they don't do DOS anyway),
but ReactOS has some code about it:
https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/kernel32/client/proc.c;hb=f60941f8dc775427af04eb0a3c3e4d38160c7641#l3007
Overall the actual set of flags probably made very little sense and wasn't
working very well. :)
I also noticed the following in the mingw-w64 headers:
#define INHERIT_CALLER_PRIORITY 0x20000
This should be a better match for what seemed to be the original intent of
inheriting the priority. I haven't tested it and it's only documented on
MSDN for Windows CE and similar so I'm really not sure about what it does.
MSDN however mentions that the child processes will have at most the
"normal" priority by default (same as its parent if the parent has less
than the default one) but I'm under the impression a process can raise its
own priority level... Anyway, "NORMAL_PRIORITY_CLASS" will do for now.
With this change and a couple others, elementary's theme builds properly
on Windows (_on_ Windows). I'll assess the usefulness of the other changes
in my tree over the next few days.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: The function prototype for eng_context_create has recently
changed in gl_common, however nobody thought it wise to update all
engines using it, so this commit fixes the function for the gl_drm
engine.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
_ecore_wl_shutdown should return int instead of EINA_BOOL. So changing the function prototype.
@fix
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1574
init
Summary: If someone calls ecore_wayland_shutdown without first calling
ecore_wl_init, then the init count is wrong. Warn the caller.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
first.
Summary: If someone calls ecore_drm_shutdown without first calling
ecore_drm_init, then the init count is wrong. Warn the caller.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Not ready yet as it uses _eina_time_get which is internal only right now. Compiling
works fine for efl alone as the private header is in teh include search part but it
blows up when compiling elementary.
Need to think a bit more about this. Maybe exposing _eina_time_get as API but that
should wait until after the release.
This reverts commit f0a02a92be.
Summary:
If _ecore_drm_init_count goes below zero, then when next time ecore_drm_init is called, it won't do the initializations which it is supposed to do. So preventing this scenario by not making it go
below zero in _ecore_wl_shutdown function.
@fix
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1573
Summary:
If _ecore_wl_init_count goes below zero, then there would be problem if someone calls ecore_wl_shutdown 1st and then ecore_wl_init later. So fixing this issue in ecore_wl_shutdown.
@fix
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1571
I have not been able to reproduce this myself but I have seen a build log where
the binary tries to link to libeo and fails due to the missing file.
A similar problem was "fixed" in 0e4b847deb, but
this really makes me wonder where the linking against eo comes from for cserve2
which is not using eo as far as I can see.
Summary:
Added code to cleanup backlight structure and to close the drm device and
delete it.
@fix
Signed-off-by: vivek <vivek.ellur@samsung.com>
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1566
The pthread man page clearly states that pthread_cond_timedwait() takes an
absolute time parameter. So far we always passed it epoch plus timeout in
seconds. This would never trigger the timeout.
Making sure we fill out timespec struct with the current time before adding
the timeout as offset now. Also handling the t < 0 error case.
Various version worked up together with Jean-Philippe Andre <jp.andre@samsung.com>
Fixes T1701
Summary: We cannot call drmModeFreeCrtc with an invalid crtc, so check
that it is set inside the output structure before trying to make this
call
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: There is no point in having different code in each output
free function (internal one and API exposed one), so let's unify the
code here.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Added _ecore_drm_output_device_is_hotplug API to check if the
drm device is hotplug device. It returns EINA_TRUE if device is
hotplug else returns EINA_FALSE
@feature
Signed-off-by: vivek <vivek.ellur@samsung.com>
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1559
In some cases, invalid object ids (e.g 0x1) would pass validation and
represent completely different objects (0x80...01). This happened because
we weren't properly checking a given object id is actually an object id.
@fix.
As pointed out by Cedric, the memory usage of basic evas objects
has increased a lot in recent versions of EFL, in part due
to this excessive use of filters data.
This is a partial fix for ticket 1725.
Not sure if this is very relevant, since GLX does not support
GL-ES as such, anyways... We should be using the extension
GLX_EXT_create_context_es_profile to create proper contexts.
Note: GLX + OpenGL-ES 1.1 crashes at any function call on my
machine (binary bloc driver), while EGL + GLES1.1 is fine.