we have some visual glitches i'm on a mission to fix... and the above
is one of those. timeout for lock should begin after screen has gone
black first.
This reverts commit 7bc179da5a.
this now totally broke the glitch fix and it now animates in reverse
on suspend and does nothng on resume... testing might be a good idea
beforehand...
this requires we have to force dpms on to reduce power. to avoid
glitches with the pointer staying around in x we need to support
suspending it too so it hides cleanly like the screen dims or undims.
also use the new powersave freeze mode to do this.
note that i've tested this on s3 supporting laptops and non-s3 and it
"works for me". it may require more testing and work. there is more to
power saving than just this as well but for now that's out of scope as
you have to mess with linux device autosuspend timeouts and a bunch
more (wowlan ... blahblah).
i need to find the source of the intermittent wakeups too in e. there
is a long lived timeout (8-ish seconds?) but more specifically e keeps
waking up from fd's and then reading /sys stuff about battery - some
event is causing us to do this... maybe to suspend this or make
battery checking very rare when in freeze mode (or screen off) etc.
so this fixes some glitches as well as supports a new way of sleeping
"alive" when hardware literally doesnt support normal s3 sleep... so
kind of a fix with a feature.
resizing objects triggers clip resizes and further event feeding which
can propagate mouse events such that clients try to resize themselves
during the update phase, resulting in illegal compositor behavior
So yeah, I've literally used sed to replace every occurrence of
ecore_time_add() with ecore_timer_loop_add() because I'm reasonably
confident that no part of E has a legitimate need for timer based on the
exact current time.
It would be really nice if I'm not wrong. :)
The reason for this is the incredible spew of clock_gettime() calls I'm
seeing on an ARM system (that should have a vdso for gettime, but...)
This can amount to thousands of system calls per second.
#YOLO
This reverts commit a4a2f6b09e.
No. you broke dnd AGAIN. try:
1. in X11 dnd to something that DOEs NOT accept xdnd. try xev. what e
will do is ignore the window and drop ONTO THe DESKTOP BG underneath
because it skips the window as if it were not there at all. this
involves losing files and finding them clustered on your desktop bg
where drops "diod nothing"
2. this seems to lead the the dnd hanging and not stopping on mouse
release. i need to right clikc to convince it to stop.
3. there's the case for xdnd clients that refuse the drop too - test
that!
this fixes this. try the above tests before working on this.
so getting top object was broken. it didnt account for repeat event
objects that would be included. so get the full l,ist and walk them
top to bottom for the first one thats a client. THAT is the correct
thing to do. this would affect both x11 and wayland.
@fix
for the case e_xkb gets initialized, we need to init it before ecore_drm
is called, otherwise ecore_drm will create his own context and keymap,
which will be overriden a few moment later when e_xkb is initializied.
So by calling e_comp_wl_input_keymap_set before ecore_drm_init the
correct context and keymap is set and no useless elements are created.
The mainproblem is that the comp_type is set when the compositor is
already running, so we have to pass the type at the init to the e_xkb
to tell for which kind of compositor we are running.
This reverts commit 26a7ba3a58.
this can only occur if something forces an event flush during shutdown.
in this case, whatever is triggering the event flush is a bug, not the
dereferencing of a pointer which is guaranteed to exist for the normal
lifetime of the process
When VT switching away and back, the kernel uses SIGUSR1 and SIGUSR2
to notify us of a vt switch event. That same signal was being trapped
here to toggle display of the 'fps' window. If we check the signal's
si_code, we can tell if this signal came from the kernel (as in vt
switch) or from the user (as is sent in 'kill'). This fixes the issue
of VT-switching back and forth under DRM would cause the compositor
'fps' display to appear.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
elm win intercepts this callback in order to maintain internal sizing
for use with elm widgets on the compositor canvas, so it's necessary to
get the callback from this object in order to accurately update the canvas
during resizes
e backlight was accessing e_comp implicitly during shutdown and comp
is shut down before backlight (that is correct as comp relies on
backlight). this fixes that
@fix
previous behavior would result in the nocomp window becoming stuck at a fullscreen
layer when ending nocomp, even if the client was no longer fullscreen
fix T2827
Carsten Haitzler
Mike Blumenkrantz
Derek Foreman
Marcel Hollerbach
Chris Michael