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
this fixes some issues in the new randr2 code that made it not work
right with plug/unplug and lid close/open. now it does work right and
plugging/unplugging displays is seamless (if your driver does not give
plug/unplug events bind a key to update screen config acvtion and e
will figure it out when you hit the key).
there is only one E_Comp which can now be accessed by the e_comp global.
if you're editing a file with some uses of these deprecated functions, replace their usages with appropriate references to this variable
pass -Wno-deprecated-declarations to ignore these warnings during build
according to the shape extension protocol, the number of rectangles returned should be checked to determine a client's shape. if 0 is returned, the client has no shape, meaning that it either should not be drawn or should have no input region. this improves behavior with various client window types such as tooltips
ref T1820
Summary:
this patch allows to enable wl_drm module(if it's exsited) without setting E_WL_FORCE as a wl_drm under HAVE_WAYLAND_ONLY.
this patch also prevent a crash under below condition. running enlightenment with HAVE_WAYLAND_ONLY option and without set E_WL_FORCE occurs crash where try to refer E_Manager because E_Manager is created in wl_drm module.
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1549
Carsten Haitzler
Mike Blumenkrantz
Marcel Hollerbach
Chris Michael
Nicolas Aguirre
Florent Revest
Chris Michael
Tom Hacohen
Seunghun Lee
Chris Michael
Mike Blumenkrantz