ecore_con_dns.c is using EAGAIN. On linux, errno.h is certainly
indirectly included by other header files, it's not the case
on Windows.
SVN revision: 72489
Ecore_Wayland: Drop the unused timestamp from the configure event
Ecore_Wayland: Port to updated Wayland API
The cursor on the pointer is now a Wayland surface rather than a buffer.
SVN revision: 72381
answer is truncated and the resolver switches to TCP, causing the pollfd
descriptor will change. Any poll on this old descriptor will either
timeout or continually poll as ready
SVN revision: 71776
enhance keyboard input handling.
* Associate the keymap with the input device rather than the display
since you could could have different keymaps associated with different
devices.
* Increase the size of character arrays used for the string
representations of
the keyname, keysym and for the string representing the key.
* Re-enable the code that converts the keysym to a printable
definition - this
is required where the keysym is not the same as the printable definition
SVN revision: 71750
& modifier change(s). Also, add patches from Rob Bradford
<rob@linux.intel.com> for basic support for setting wayland cursor:
From c5d9094f4792bf7375c216682947de334002cdad Mon Sep 17 00:00:00 2001
From: Rob Bradford <rob@linux.intel.com>
Date: Tue, 29 May 2012 16:35:01 +0100
Subject: [PATCH] Ecore_Wayland: Add basic support for setting the cursor
* Add api to the ecore_wl_input_ namespace to allow setting the buffer
to use
for the pointer and for loading a named cursor from a cursor theme.
Under the
Wayland protocol the cursor is associated with the input device.
* Add helper functions to ecore_wl_window to set the cursor based on the
active pointer input device for the window.
* Load the cursor theme when the SHM interface is ready and provide an
API
call to provide a wl_cursor for a given name.
* Add API to restore to the default cursor and then use that when the
pointer
enters the surface to ensure compliance with the Wayland protocol.
Cheers :)
SVN revision: 71734
dns.c is the work of William Ahern (http://25thandclement.com/~william/projects/dns.c.html) and has been in development for ~4 years.
it has zero documentation, no examples, and no comments: I'm pretty sure he's an EFL developer in disguise.
this new resolver is roughly 10-12% faster than c-ares, will never randomly break, requires no external libraries, and is much simpler on the efl side.
by default, dns.c resolution is enabled any time ipv6 support is detected and c-ares support is not requested;
it should work on all platforms (wink wink vtorri), but it has no way of disabling ipv6 (someone can go through dns.c/h and do that if they feel so inclined)
SVN revision: 71690
ecore_x is calling XKeycodeToKeysym from xlib, but this function has issues. It
has been deprecated 6 months ago in X.org and it is suggested to use
XkbKeycodeToKeysym instead: https://bugs.freedesktop.org/show_bug.cgi?id=25732
This commit makes a wrapper function that makes use of XkbKeycodeToKeysym when
possible or fallback to XKeycodeToKeysym otherwise.
SVN revision: 71677
pthread_create can fail if to much pthread are pending. As pthread_join
is only called when the main loop can flush the async call list, there was
a possibility for edje_cc to run out of thread due to that. We know
force the flush of the async call list and so call pthread_join when
pthread_create fail.
SVN revision: 71555
Subject: [E-devel] Ecore: Save proper evas engine buffer depth when
_ecore_evas_resize is done
I have found bug in ecore evas buffer. It is created by default as RGB32,
and then it can be changed by ecore_evas_alpha_set function, but when resize
is done it is always created as ARGB32.
Patch in attachment checks in resize if alpha channel is set, and then set
appropriate buffer depth.
SVN revision: 71537
The challenge here is that the native window representation is stored
in Ecore_Evas's prop.window. But currently there is no checking of
what driver the Ecore_Evas is for when calls are made to e.g.
ecore_evas_software_x11_window_get.
The attached change to Ecore makes the appropriate functions return 0
or NULL if the driver for the Ecore doesn't match as expected. This
can then be used to identify if an Ecore_Evas is e.g. from X11 or from
Wayland.
SVN revision: 71453
Vincent Torri
Christopher Michael
Carsten Haitzler
Stefan Schmidt
Mike Blumenkrantz
Cedric BAIL
Rob Bradford
Jihoon Kim
Jerome Pinot
ChunEon Park
Leif Middelschulte
Mariusz Grzegorczyk