add some infra to be able to get and set device properties (as well
as know if devices changed to we can refersh a gui or re-apply saved
settings etc.). it doesn't do everything but... it adds enough to
build on in e.
Summary:
block calls to XSelectInput with the root window if the root window is
currently being "managed" in-process in order to avoid breaking the
running wm
Depends on D10013
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10014
Summary:
this is just a shortcut for watching properties in the case where no wm is
active in the process
Depends on D10012
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10013
Summary:
when ecore_x_window_manage is called, this is probably only for the case of
managing the root window, i.e., running a window manager. store this state
internally so that we can avoid calling additional XSelectInput later and
fucking up the expected eventing
Depends on D9899
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10012
Summary:
this handles the case of reinitializing a component, but it's totally
broken in the case of doing a full ecore restart
Depends on D9253
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9254
so i've been wondering what is going on for a few days... and i've
figured it out finally... my mouse seems ot like to generate 1000
events per second. not your usual 100 or 200. it only happened on this
one machine so i was wondering what on earth was up. this machine was
different in other ways like an arm cpu, differing gpu (rx550),
different distro and so on. this is creating a storm of motion events..
and this is causing all sorts of overhead in just trying to deal with
them all like generate more internal events, emit signals for every
one of them and so on. there is no attempt to play catch-up or
anything - just build up a bigger and bigger queue of them to deal
with. this is NOT GOOD. this restores our old commented out event
skipper that got commented out during some xcb work actually -
not on its own. it was a huge xcb patch that commented it out.
this restores it and makes it a little cleaner with a bool and now the
perf issues i was seeing are gone. this is such a major performance
fix that this deserves a backport.
@fix @optimize
Summary:
meson and autotools were a bit out of sync with this, resulting in
unexpected behavior
Reviewers: billiob
Reviewed By: billiob
Subscribers: billiob, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8641
A New entry is added to _ecore_key_grabs even when no key was grabbed.
Summary: The key grab and ungrab functions should return which keycode was used. Proposed by pascal@ordissimo.com
Reviewers: zmike
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7923
This build was never complete and also was not maintained probebly.
It is also dropped in favour of meson which is cool, merged, works & is fast.
Differential Revision: https://phab.enlightenment.org/D7010
it was a lot of if cases before now it's an array with min version
parameters and globs for matching drivers etc. - much cleaner and
neater to afdd things to the whtielist now.
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
This fixes cycles of init/shutdown/init where ecore event types would
become invalid, since they are now stored in a dynamic array rather than
a statically stored array.
The risk here is that if a module of EFL tends to init/shutdown in a
"normal" scenario then the event type array will grow in a leaking
manner. This could be fixed by resetting those event ID's only when the
loop actually exits (EFL_EVENT_DEL on the main loop). I'm not using
EFL_EVENT_DEL in this patch as this would add too many event callbacks
to the main loop object, which may result in slightly slower event calls
to it, affecting the overall performance.
Summary: assignment to local variable "ret" has no meaning as it is not used after assignment. So, removing assignment operation to avoid warning.
Reviewers: raster, cedric
Subscribers: jpeg, rajeshps
Differential Revision: https://phab.enlightenment.org/D5303
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
in some cases loading an xmodmap on enlightenment startup can trigger an infinite
number of identical events which hard locks the xserver for a very, very long time
@fix
This happens in E with software compositing, since E's commit
5702f0975e890f07cfb. E should be fixed shortly but segv is not
acceptable. Without segv E is still massively broken so it's
not like the bug would be hidden (large black areas in windows,
after switch vdesks with enough windows).
it turns out that xlib is going to copy the complete struct into
something internal. This might lead to the condition that a uninitalized
value might be part of the struct, and when later the struct is read
again the code might do wrong stuff since that value could be set now to
a randomly other meaningfull value.
This turned out on me in e as i could not write any letters like ßöäü,
since that lead to a not returning call to _XReply internal of xlib.
Dugging that showed that xlib was waiting on a reply of a call that
never got executed, and the XEvent it is waiting on just contians a
randomly correct value.
@fix
ECORE_X_ATOM_E_ILLUME_SLIDING_WIN_STATE
ECORE_X_ATOM_E_ILLUME_SLIDING_WIN_GEOMETRY
ECORE_X_ATOM_E_KEYROUTER_SUPPORTED
ECORE_X_ATOM_E_KEYROUTER_WINDOW_KEYTABLE
all had no atom fetches! fix..
@fix
as per mailing list discussion about dropping xcb support now. it
hasn't been complete for a long time, thus not recommented for being
turned on. as we are moving to a wayland world xcbmakes even less
sense. as agreed, time to clean up a bit and remove a distraction as
well as not well tested code. this also updates po's too.
@feature
prctl allows us on some platforms to request a thread be woken up more
agressively e.g. due to a timeout bu setting timerslack. since we use
a dedicated thread just for vsync events, this is a very good idea to
ask the kernel to be as exact as possible for this thread as it only
wakes up once per frame (or should only) and accuracy is important. so
use this.
also improve prctl checks to be more explicit in configure.ac and use
these ifdefs in ecore exe too where prctl is used as well.
@feature
Carsten Haitzler
Mike Blumenkrantz
Xavi Artigas
Thierry
Marcel Hollerbach
Marcel Hollerbach
Mike Blumenkrantz
Vincent Torri
Jean-Philippe Andre
Prince Kumar Dubey
Marcel Hollerbach
Chris Michael
Cedric BAIL
Stefan Schmidt
Hannes Janetzek
Gustavo Sverzut Barbieri