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>
a cursor client should be shown/hidden as needed despite its lack of a
shell interface, and having a special flag to identify these types of
surfaces makes it easier to do that
in some cases it might be desirable to remap a mouse button to a key.
this is not very user-friendly since it requires device-specific key names
which need to be translated to/from files such as /usr/share/X11/xkb/keycodes/evdev
#SamsungFeatures
in automated testing scenarios, being able to generate input events is useful
for detecting regressions related to keyboard actions
this depends on an xkbcommon function which is expected to be in the 0.6.0
release, so dlsym here in order to make that a runtime dependency for now
since this is not going to be a widely-used feature
#SamsungFeatures
When running under DRM, this patch adds support for getting the
supported rotations of an output, listing them in the Screen Setup
dialog, and adds the ability to set a rotation on a given screen
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
take_focus will only be handled if the new_client flag is set. in all
other casees, focus_set should be called directly
new_client flag implies changed flag
in this case, mouse events which are not originating from the internal
window are for the screen, and these coords can be used for determining
"mouse out". if the mouse event comes from the window, it is inside the window.
ref 7c661b54a9
these was a workaround for handling early internal windows which is
no longer necessary now that they will handle their map states more
effectively
now, any wayland surface (not xwayland) requires a shell to map the
surface as intended
these types of surfaces should grab focus as early as possible, and
setting the flag at this time ensures that it will be handled during
the next client eval
if windows are created during startup, they will attempt to show themselves
before xdg surface operations are available, leading to a scenario where they
will never successfully map themselves. if the elm win object is visible, this
indicates a mapped internal window, so directly call the map function at this
time to make the window visible
This reverts commit 67170f40a1.
this was changed intentionally to use the resource pointer in order to fix an
issue where external clients would reuse the same surface id,
thereby breaking the compositor with duplicate entries in the pixmap hash.
note, however, that internal windows in wayland DO use an int type pixmap id.
this is easily detected by checking the pid of the client for a window before doing
checks. this is necessary in order to be able to flag internal clients as internal
while still being able to match them with their surface id
also, uintptr_t is NOT indicative of an int type being used, it's an
int type which has the same size as a pointer, allowing casts between ints
and pointer.
Previously, we were passing in the wl window id into the
pixmap_find_client function. This is improper as the e_pixmap_new
functions take the surface resource id. To solve this, we will get the
Ecore_Wl2_window from the Evas_Object, fetch the surface id from that,
then pass those into e_pixmap_find_client.
This resolves an issue where the everything module was not working
properly.
ref T3058
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
e_pixmap_new function
e_pixmap_new (when creating wayland windows) is expecting to get a
uintptr_t type passed into it (surface id). Previously we were passing
the entire wl_resource.
ref T3058
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
icccm provides conflicting spec info regarding how this property should be set.
according to 4.1.3.1:
When the window is withdrawn, the window manager will either change the state
field's value to WithdrawnState or it will remove the WM_STATE property entirely.
however, 4.1.4 states:
Only the client can effect a transition into or out of the Withdrawn state
so to be on the safe(r) side, deleting the property seems to be the best choice here
ref 41daddeacc
fix T3011
it's possible for damage to occur before the show interceptor is triggered,
and in this case damages would be lost despite it being a valid usage
ref T3011
Summary:
currently there is ecore_x_current_time passed, which is the time of the
last event. if this is passed to ecore_x_window_focus_at_time the request can be
ignored because the last event can be in the past. Instead using
ecore_x_window_focus fixes this, because current time is passed, which
means that x is just using this event at the time it is called.
@fix T2948
Test Plan: Try to run spotify and try to trigger the bug, I cannot anymore.
Reviewers: zmike, raster
Subscribers: raster, abyomi0, cedric, billiob
Maniphest Tasks: T2948
Differential Revision: https://phab.enlightenment.org/D3471
shelf overlap can only take effect based on the state of this option:
specifically, overlap can only be enabled if border_fix_on_shelf_toggle
is enabled
these are generic objects which can be added to indicate that there
is something blocking window placement at the edge of a screen/desk.
this replaces the traditional method of watching shelves to calculate
useful geometry with a managed object which will automatically trigger
a recalc whenever it is updated, and it allows non-shelf objects to
more easily register themselves as obstacles for window placement
remove menu object from autoclose (if set) and ensure that only the
intended menu is deactivated in the autoclose callback
this fixes some cases where the wrong menu could be closed (or not closed)
due to race conditions with ecore and evas events