this code is mostly copied from weston:
78d4bf9a3ec990dceee23fd53962a69891352a0e
9c93179023fe894e417ccd20533d72d672d976fc
b288988e831cee3deb7f8bb1a3f440c86230dd9f
4061e2b67e62d5d2a635f0b87098f331082e8145
credit to Carlos Garnacho <carlosg@gnome.org> as original author
ref T3455
these files were created containing code which was very obviously copied from
weston. when copying code, copyright headers must also be copied in order to
comply with licenses.
- remove (wrong) global variables which tracked client-specific resources
- start ping upon creating a shell surface
- track client-specific shell resources on a per-client basis
this allows different display protocols to start their applications at
different times to ensure that any initialization has completed prior to
starting anything requiring a window
fix T3475
these are traditionally compositor-only actions which may filter through
many different objects but are not meant to activate on window contents
resolves issues where some related mouse bindings were blocking input on windows
under x11
#thingsthatneeddocs
Summary:
There is an edge case that results in SIGFAULT in Enlightenment when
"Keyboard Settings" dialog is closed prior to "Add New Configuration"
dialog and "OK" button is pressed in the latter one.
This makes sure that closing the dialogs follows the parent/child logic.
@fix
Test Plan:
1. Go to Settings -> All -> Input -> Keyboard and press "Add"
2. Observe that "Add New Configuration" dialog is opened
3. Select/highlight any new layout
4. Go back to "Keyboard Settings" dialog and close it
5. Press "OK" in "Keyboard Settings" dialog
6. Observe that Enlightenment sigfaults
Reviewers: zmike, raster
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3901
while it technically wuld work, this memcpy here is fragile and the
moment some struct members changed it'd fall apart and have fields all
misaligned etc. in fact using offsetof means it might over-copy a bit
extra due to alignment of the connect_cb vs method in Connman_Service.
so manually aissgne the fields in the func instead to be far safer.
if anything this should become a sub-struct with a type that can then
be properly copied even if things change.
@fix
for the case the default sink was removed the gadget will get a new
default sink again, for the case of pa there is the possibility that
at this time the sink is still the default one, but the sink gets
removed. so we better set the default index to -1 and return just some
sink for the case the default is deleted.
if csd exists in only one of (before || after) a maximize/fullscreen,
this provides info so that the right size can be used when restoring
geometry
...again
Summary:
the new_keyboard event is now used to restore the known layouts out of
the config, if the state is changedthe new group is safed in the config
which will be safed later.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3877
maximize is client-initiated and compositor-enforced in wayland, meaning that a
maximize should only be acted upon in the compositor after the client has
acknowledged that it has transitioned into the maximized state (likely removing
part of its csd region) and has resized itself to match the expected maximize
size
fix T3297
Including certain headers in the wrong order can cause problems if
we're configured to use beta api (right now wayland forces this).
In most cases we should just be including e.h and not the individual
EFL headers anyway. This fixes some of that.
fix T3426, T3428
xdg shell configure states (maximize, fullscreen) return a client ack when the
client has applied the state. the ack, followed by the next surface commit,
indicates that the surface is ready to be transitioned into the configured state
so i was profiling today .. leak hunting .. and i noticed. if you have
enough appss open - eg terminology, e uses a huge amount of memory...
for icons. terminology is 128x128 ... thats 64k per icon. open up a
lot of terminology windows and we duplicate that 64k per every window
on the wm sside because we get the data. it would apply for any app
that sets a netwm icon. this can be come rather silly if you have like
100 terminals. it's worse with larger icons (eg 256x256 - 256k per
icon).
this puts in a simply list for shared icons and a lookup on fetch to
de-duplicate and share icon data. this should drop memory usage
nicely.
@improvement
Clipboard fds from clients are regular files, which shouldn't be passed
to fd_handler_add. Using the wrong add function causes epoll to return
immediately and we end up running idle handlers and burning cpu.
Reviewed-by: Mike Blumenkrantz <zmike@osg.samsung.com>
this ensures that notification text reaching the module can be considered
"usable" without forcing multiple escape passes onto the same notification
fix T2757
in the case where a mouse binding is active and a signal binding is triggered
by the same mouse-up event which also ends the mouse binding, the deferred
nature of edje emissions will result in the signal being received by the
corresponding callback some time after the mouse-up event has been handled by
the client and the mouse binding has ended
to accurately handle these cases, signal bindings triggered in the same event
loop in which a mouse binding has ended after a mouse-up must be rejected in
order to enforce the compositor's mouse grab
fix T3347
wayland clients were previously set as ignored until they obtained
a shell surface in order to avoid early execution of things like placement.
this had no effect.
the ignore must last until the first commit, at which point surfaces have been
sized and can be placed accurately without needing to move the surface around
a lot of times due to resize/frame adjust/birthdays
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.
bindings enforce compositor grabs, which will result in stuck canvas buttons and
break internal windows which have already received button presses
fix T3347
As the block which uses this parameter is #if 0'd out, we end up not
using this param, which generates a compiler warning
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
Summary:
- Change mouse button mapping for left handed mode
- Change a mouse_hand config and save
Currently e_mouse had e_mouse_update() API for support left_handed mode.
But that API only for Xorg not support wayland and only for update mapping not change mapping.
So I added new support for change mouse mapping for left handed mode and support wayland backend system.
Test Plan:
After set left handed mode,
mouse button mapping is changed for left handed people.
Reviewers: raster, devilhorns, zmike
Subscribers: ohduna, input.hacker, cedric
Differential Revision: https://phab.enlightenment.org/D3433
in many cases where a zone's useful geometry is marked dirty, the resulting
recalc ends up having the same useful geometry as before: this is the case
for things like tasks gadgets, which continually expand and contract along
a single axis and thus will never affect useful geometry while still forcing
a recalc
by ignoring these cases, a huge amount of compositor thrashing is avoided and
a number of related bugs can also be fixed
if we are setting the group or the set of groups in e we will receive a
XkbNotifyState Event from x, which will result in a
ECORE_X_EVENT_XKB_STATE_NOTIFY event. We are setting there again our
settings, since we need to reset the settings from a potential external
application. So we should only reset our settings when the event is not
expected by e.
If someone plugs in a external monitor, the notify event is set AND the
group is changed externally. This means enlightenment cannot configure a
new keyboard anymore. So we are flushing in our new config all the time,
setting the old group-index again.
an agent object can be used when a client should be represented on the
canvas solely by its window geometry and not including any csd
this creates and manages a mutable object which maintains the same geom
as ec->x/y/w/h and can be operated upon to modify those values
in the case where a client is at 0,0 relative to a zone, changing the coords
in this case will result in the client moving out of the zone by the size of the
csd
this does not trigger any efreet cache rebuilds and will result in the user
being forced to sit through the full duration of the wait timer: currently 7.0s
this gets triggered multiple times throughout the wizard.
embarrassing.jpg
this is a default feature of enlightenment which is not obvious to all new
users and, with the default modifier being Alt, may interfere with some
application behavior. this informs users of the feature's existence and
allows for easily changing the modifier(s)
If enlightenment is built with support for wayland, then previously
the WBOD would not work if we were running the same binary with X11.
This was because the alert system would try to connect via drm by
default (due to wayland build option). We fix that by checking for the
existance of $DISPLAY (as this will not be present under drm), and
running the X11 codepath if it is found, running the drm codepath if
it is not found.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
assume that an object is where it's supposed to be in order to avoid failing
to correctly animate objects which modify set geometries, such as e clients
We need to make sure we drop reference on all exit paths through the
hide callback - somehow this only seemed to break internal windows.
ref 65166c5a36
==22088== Invalid read of size 1
==22088== at 0x2C9FE7B1: _evry_cb_show (evry.c:3046)
==22088== by 0x5BE9918: _eo_evas_object_cb (evas_callbacks.c:65)
==22088== by 0x69A16F4: _eo_base_event_callback_call (eo_base_class.c:715)
==22088== by 0x69A3041: eo_event_callback_call (in /usr/lib/libeo.so.1.17.99)
==22088== by 0x5BEA0B3: evas_object_event_callback_call (evas_callbacks.c:240)
==22088== by 0x5C2577C: evas_object_inform_call_show (evas_object_inform.c:12)
==22088== by 0x5C1ED24: _show (evas_object_main.c:1360)
==22088== by 0x5C1EADA: _evas_object_efl_gfx_base_visible_set (evas_object_main.c:1313)
==22088== by 0x575D80A: efl_gfx_visible_set (in /usr/lib/libefl.so.1.17.99)
==22088== by 0x5C1EA58: evas_object_show (evas_object_main.c:1291)
==22088== by 0x479FCF: _e_comp_intercept_show_helper (e_comp_object.c:1616)
==22088== by 0x47A02A: _e_comp_intercept_show (e_comp_object.c:1630)
==22088== Address 0x17621591 is 81 bytes inside a block of size 120 free'd
==22088== at 0x4C2AE6B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22088== by 0x2C9F95A8: _evry_window_free (evry.c:993)
==22088== by 0x2C9F8065: evry_hide (evry.c:366)
==22088== by 0x2C9FB9A2: _evry_cb_key_down (evry.c:1926)
==22088== by 0x8F6ED4A: _ecore_call_handler_cb (ecore_private.h:316)
==22088== by 0x8F6FC92: _ecore_event_call (ecore_events.c:518)
==22088== by 0x8F7A15A: _ecore_main_loop_iterate_internal (ecore_main.c:2339)
==22088== by 0x8F784A8: ecore_main_loop_begin (ecore_main.c:1284)
==22088== by 0x4403F6: main (e_main.c:1087)
==22088== Block was alloc'd at
==22088== at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22088== by 0x2C9F8D7D: _evry_window_new (evry.c:758)
==22088== by 0x2C9F772D: evry_show (evry.c:177)
==22088== by 0x2C9F711C: _e_mod_run_defer_cb (e_mod_main.c:537)
==22088== by 0x8F75267: _ecore_call_task_cb (ecore_private.h:282)
==22088== by 0x8F7574E: _ecore_idle_enterer_call (ecore_idle_enterer.c:174)
==22088== by 0x8F7A05B: _ecore_main_loop_iterate_internal (ecore_main.c:2261)
==22088== by 0x8F784A8: ecore_main_loop_begin (ecore_main.c:1284)
==22088== by 0x4403F6: main (e_main.c:1087)
this function is only called when screen geometry (or useful geometry) has
changed, and so all clients should have their geometries checked at this point
to ensure that they update for any new zone obstacle changes which have occurred
Wayland buffers are currently either ARGB or XRGB - we don't need to
convert either of these, we just need to set alpha appropriately - which
we now do.
This code is similar to code in weston, but doesn't really work properly
for us in E, since this can blow up buffers behind the async renderer's
back.
The rest of the reference code has been pushed into e_pixmap, so we can
kill this all now.
We need to keep wayland buffers around even if they'll never be written
to again. This is part of Buffer_Reference's task in weston, but we
already have our pixmap abstraction which can serve mostly the same
purpose.
Remove the "buffer reference" stuff from e_pixmap and replace it with a
kept buffer for the last commit.
Add shared memory pool references to keep pools from going away on us.
We need to make sure wayland clients aren't deleted while the scene
graph has their data pointers, so we take an extra reference when creating
them.
We drop that reference by clearing the client's image data and putting it
in the render post_updates list.
In wayland we can be presented with a new frame before being deleted. If
we've never displayed that frame we should (since we released all pointers
to the old frame when we got the new one)
we free the instance layout even though tthis is never duplicated but
jhust set to point to the current_layout. don't free it as this causes
a double-free. this fixes a crash here.
@fix
if multiple x11 clients receive focus during the same mainloop iteration,
an almost unbreakable cycle of window focus chaining will occur, resulting in
both windows being focused simultaneously--or so it appears--which results in
no window being able to receive input. to avoid this, ensure that only one x11
client can receive focus in a given loop iteration
due to event bursts, it's possible for multiple x11 clients to receive
mouse in events on during the same main loop iteration. in this scenario,
only the last client has received an actionable mouse in, and applying this
event after the dispatch has completed ensures that multiple clients do not
all receive mouse in+out events during the same loop
this greatly improves mouse-based focus reliability in a number of cases
mousing over a window for an x11 client should always yield x11 mouse events
in cases where mouse eventing is required; any events occurring on the comp
object in other cases inside the xwindow region are able to be ignored
the current security policy for this is based on two points:
1) don't add gadgets to your lockscreen that you don't want on your lockscreen
2) see #1
future improvements here will probably add gadget info to show what risks a gadget
may incur when placed on the lockscreen
Mike Blumenkrantz
Carsten Haitzler
Shuhrat Dehkanov
Marcel Hollerbach
Derek Foreman
Chris Michael
JengHyun Kang