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
in some cases, it's possible for a client which expects to render on
the next frame to actually render on the frame after. in these cases,
the compositor must not clear the pixmap image until after the render
has occurred in order to avoid inaccuracies. for this reason, the best
place to flag a client for post-render work is at the time of the client's
render
ref T2762
ref D3120
in the case where a window is fullscreen without having the 'fullscreen'
flag set, the previously-used layer must be reapplied upon nocomp end
in order to avoid breaking the compositor
if windows set to "Always on Top" exist while the option to allow
windows over fullscreen windows is enabled, enabling nocomp will
result in the above windows being stuck over the nocomp window
instead, force the nocomp window to be the top-most window in all cases,
and then put it back if another object appears on the screen over it
fix T2703
it's conceivable that, were there a bug in client refcounting,
this could become an infinite loop and prevent shutdown/restart.
since, at this point, we don't really care about deleting anything,
ensure that the loop will end
this follows 56cabf59c6 then
4e5521b4d8 where i have been trying to
fix a crash with e client and comp win references etc. i have gone
over all referencing with a fine tooth comb and found all the nigglies
i can., no leaks now, no crashes, no valgrind complaints etc. so i
call this fixed now. as best i know this is new in e20, so not a
backport fix
Mike Blumenkrantz
Carsten Haitzler
Derek Foreman
Marcel Hollerbach
Chris Michael
Nicolas Aguirre
Florent Revest
Chris Michael