A grab can potentially allocate memory and would normally end the grab
itself, freeing the allocated memory in the process. However at in some
situations the compositor may want to abort a grab. The grab owner still
needs to free some memory and abort the grab properly. To do this a new
function 'cancel' is introduced in all the grab interfaces instructing
the grabs owner to abort the grab.
This patch also hooks up grab cancelling to seat device releasing and
when the compositor looses focus, which would potentially leak memory
before.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
We used to leak the input fds, as weston would reopen all fds on vt
enter. We could just close them after sending the open fd through the
socket, but this patch also adds support for the new EVIOCREVOKE evdev
ioctl, that revokes the fd in question (including the copy that we
sent to the compositor).
https://bugs.freedesktop.org/show_bug.cgi?id=70849
Previously the renderers destroy function assumed they are only called
when the compositor is shutting down and that the compositor had
already destroyed all the surfaces. However, if a runtime renderer
switch would be done, the surface state would be leaked.
This patch adds a destroy_signal to the pixman and gl renderers. The
surface state objects will listen for that signal and destroy
themselves if needed.
This is a step towards runtime switchable renderers.
Remove create_surface() and destroy_surface() from the renderer
interface and change the renderers to create surface state on demand
and destroy it using the weston_surface's destroy signal.
Also make sure the surfaces' renderer state is reset to NULL on
destruction.
This is a step towards runtime switchable renderers.
(rpi-renderer changes are only compile-tested)
Also make sure backends destroy the renderers before shutting down the
compositor to avoid a double call to weston_binding_destroy().
This is a step towards making renderers switchable during runtime.
The compositor will check if the client destroyed the wl_buffer
while it was in use in a display update, and delete the resource
itself once the update has finished.
It was possible to start a move or resize with a pointer and then
start another move for the same surface with touch or a pointer from
another seat, which would make the window flicker around. With this
commit, we now reject any attempts to move or resize a surface that is
currently grabbed.
Most of the shell.c bindings take effect on the current pointer or
touch focus. That's now a view, but we need a surface in these cases.
Just get the surface from view->surface instead of trying to cast a
view to a surface.
setup_output_destroy_handler() deal with output created at
drm backend initialize time.
handle_output_create() deal with output created by hot plug handler
output_destroy_handler is removed when output was unplugged or
shell is destroyed.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
when output is removed, weston-desktop-shell should destroy panel
and background surface on destroyed output.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
In drm backend, the cursor_surface->plane point to
drm_output->cursor_plane.when this output is removed,
drm_output->cursor_plane is destroyed, butcursor_surface->plane
still point to destroyed plane. So once mouse move to this
cursor_surface and system will repaint this cursor_surface,
segment fault will generate in weston_surface_damage_below() function.
V2:
-set surface->plane to NULL whose plane point to unplugged output,
then change weston_surface_damage_below() to do nothing if
surface->plane is NULL (Kristian)
-set surface->plane to NULL in weston_surface_unmap(),
so that all surfaces that have a non-NULL plane pointer wil be
on compositor->surface_list (Kristian).
bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69777
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
We don't have a reliable way to know when to clear this indicator.
Typically the pointer will still be over the window when the resize is
done and we'll get an enter event, but if the window sets a max size
the pointer may be over another window when the resize is done.
We'll need a new wl_shell (or more likely xdg_shell) event for this.
How and when to update the keymap is left to each backend.
The new keymap only becomes effective when no keys are pressed and we
keep latched and locked modifiers from the previous state.
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
If we are about to finish a frame, but a redraw is pending and we let the
compositor redraw, we need to check for errors. If the redraw fails and
the backend cannot schedule a page-flip, we need to finish the frame,
anyway.
All backends except DRM use a timer to schedule frames. Hence, they cannot
fail. But for DRM, we need to be able to handle drmModePageFlip() failures
in case access got revoked.
This fixes a bug where logind+drm caused keyboard input to be missed as we
didn't reenable it after a failed page-flip during deactivation.
If the initial page-flip fails, immediately finish the frame to avoid
being stuck in the given frame. We already do this if we have no fbo
available. Now we do the same if the page-flip fails.
Jonas Ådahl