It seems that when things go wrong it does happen that we start with i == 0. It
will then have been walking into info[-1] 'happily'. Changing the test, to first
decrement and then compare should stop that issue.
This should @fix T1467.
this uses a thread to collect vsync input events and filter them
before forwarding them to the mainloop (as a double timestamp). this
means wakeups only happen for the actual vsync and thus animator and
not for other screens we are filtering out anyway. this should fix the
continual animator wakeups that happen if you have a dri/drm based
driver and > 1 screen.
due to mesa changes to hide dri2 symbols, i have had to work on a fix
that makes this work again by going right to drm. now it works and
animators shoudl be vsynced on drm drivers if possible (only 1 card -
use card 0). already existing nvidia solution that uses a lot more
memory is there. others - no support. timers only
this adds a slave process that is useful on nvidia drivers as there
isn't another way to get vsync evenys (that i know about). i need to
make another slave process to that includes a dri2 protocol
implementation since mesa has now hidden its dri2 symbols.
bugfix@: As we have support in the Ecore_Event structure for storing
keycode on key press/release, let's utilize it. This will simplify
wayland compositor code as we won't have to parse key names to get the
keycode.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
this technically adds a feature - it adds non-mitshm support for
ecore_x image grabbing, but that fixes a bug. it doesn't touch xcb
support though.
this fixes T1127 andshould probably be backported.
@fix: Fix building Enlightenment without X support
These changes are needed so that we can build Enlightenment without X
support. Many places in the E code reference
Ecore_X_Atom/Ecore_X_Icon. If we build E without X support, these end
up being undefined, causing build to fail, so we need to predefine them.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
The window auxiliary hint is the value which is used to decide
which actions should be made available to the user by the WM. If you
want to set specific hint to your window, then you should check whether
it exists in the supported auxiliary hints that are registered in the
root window by the window manager.
Once you've added an auxiliary hint, you can get a new ID which is used
to change value and delete hint. The window manager sends the response
message to the application on receiving auxiliary hint change event.
A list of auxiliary hint within the Ecore_Evas has this format:
ID:HINT:VALUE,ID:HINT:VALUE,...
Reviewers: raster, cedric, seoz, Hermet
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D543
This fixes valgrind reporting lost bytes when selecting text (e.g. in entry).
Can be reproduced in any program that has entry:
Simply run it with valgrind, select any text, and then exit.
Fixed by properly freeing the selection data, since it is either cleared or replaced.
Also, changed argument in sizeof since it didn't match the type of selections[in].
Summary: The window manager rotation allows the WM to controls the rotation of application windows. It is designed to support synchronized rotation for the multiple application windows at same time.
Reviewers: raster, seoz, cedric, Hermet
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D529
apparently I read the commit order wrong and this fix went in for 1.4.0, not 1.3.2, which means anyone who has 1.3.2 has been having lots of fun crashes for the past 24 hours
this was a fixme which was likely written sometime before July 2010 when the bug was fixed, just prior to the 1.3.1 release. I think it's probably okay to require that release since it's been 3+ years.
Summary:
If the property was successfully fetched the number of items stored in
val is returned, otherwise -1 is returned.
Note: Return value 0 means that the property exists but has no elements.
Reviewers: seoz
Reviewed By: seoz
CC: cedric
Differential Revision: https://phab.enlightenment.org/D457
Summary: Add data set case of selection event for XDND selection if selection atom is XDND
Reviewers: raster
Reviewed By: raster
CC: JackDanielZ, woohyun, Hermet, seoz, cedric
Differential Revision: https://phab.enlightenment.org/D446
this makes efl ignore certain env vars for thnigs and entirely removes
user modules (that no one ever used) etc. etc. to ensure that *IF* an
app is setuid, there isn't a priv escalation path that is easy.
- No need for a separate xcb_connection here as we already have a
connection at this point so let's use that.
- Fix up formatting.
Signed-off-by: Chris Michael <devilhorns@comcast.net>
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
size_ret is used later as an argument for malloc, so it should be
positive. In addition this should ensure that
ecore_x_window_porp_property_get returns a positive value and is true if
we malloc data.
Hopefully also fixes CID 1135636
As bounds is a pointer, bounds + num will always be postive, so this is
an eternal loop. In addition, XFixesInvertRegion only accepts one
region, so num must be 1.
Fixes CID 1039469
Data returned from ecore_x_window_prop_property_get are malloced, so use
free, not XFree. Which also is consistent, as free was used on other
occasions.
I give up. people continually complain about these and submit them as crashes, so now they're only visible if you set ECORE_X_SYNC. the next step is an #ifdef ISCOMFITOR.
NB: Cannot really happen for 1.8 (as --disable-ecore-x-randr has no
effect), but really these should have been ifdef'd from the start.
NB: IMO, Don't think a ChangeLog is really needed for this....
Signed-off-by: Chris Michael <cp.michael@samsung.com>
the ECORE_X_SYNC environment variable exists to make ecore-x debugging synchronous.
printing X errors as they occur is useful for application developers; errors should not
be silenced just because they are inconvenient or plentiful.
because an error with no idea where it came from since its async is
pretty much usless noise. if you want this to be useful you literally
need to do an xsync every x call and be able to get backtraces... the
xsync then would be inside ecore-x. and of course this would be so
nastily slow that you need to make it an option at build...