We don't want to send enter/leave events to the compositor when the pointer
enters the surface, only when the pointer enters the content area. This
avoids hiding the cursor when entering the frame and sending out-of-bounds
coordinates to notify_pointer_focus().
This way we map the surface if it currently isn't mapped and avoid
duplicating some of the code already in pointer_cursor_surface_configure().
Without this, the cursor code relied on a wl_surface.attach() to show the
new pointer surface. If we're not changing the cursor buffer, we don't
get that, but we still need to map the cursor.
Replace all occurrences of workspace_damage_all_surfaces() with
weston_compositor_schedule_repaint(). This fixes a bug exposed by
982387011f where trying to switch workspaces while there are no
surfaces on the current workspace fails to start the animation.
This patch, along with the wayland patch, adds the ability to specify
a cursor theme in the weston.ini file:
[cursors]
theme=THEME_NAME
If specified, than Weston can use a specific X cursor theme for the
pointer. This relies on the 0001-Add-support-for-X-cursor-themes.patch
for wayland.
[krh: edited to use shell section and key name cursor-theme]
Place the window in a random position on the output where the first seat with
a pointer is. When calculating the random position limit the range to the
area that would ensure that the whole surface is visible. If the surface is
larger than the output then the surface is placed at the origin of the
output.
This change is based on the good work of Scott Moreau <oreaus@gmail.com>
If a client sends a pong message out of the blue, we deref ping_timer
which is NULL and then crash. Unsolicited pong requests indicate that
something is wrong on the client, but the compositor should survide that.
Add a wl_seat argument to the activate and deactivate requests of
text_method.
On activation a text_model gets assigned to the input_method of the
wl_seat specified in the activate request.
This makes the separation between panels and input panels clearer and
prevents the (desktop) panel from removing existing input panels on
redraw.
The input panel layer is below the panel layer.
Not all hw supports hw cursors. Similar to the case with sprites, if
the driver does not support it, don't keep trying and spamming the log
with error messages.
Signed-off-by: Rob Clark <rob@ti.com>
They can't be imported by gbm, so no point in trying, and segfaulting
in gbm when we try to import (because it tries to deref the buffer as
a wl_drm_buffer).
Signed-off-by: Rob Clark <rob@ti.com>
A call to strcmp() is already made in output_section_done() and
output->config is set appropriately if mode is "off". There is
no need to duplicate that in create_output_for_connector().
Since weston_surface_update_transform() was changed so it called
surface_damage_below() instead of surface_damage(), the trick of
clearing the surface damage did not work anymore.
Fix this by moving the repaint surface to a special plane before
calling update_transform. The move is made manually (as opposed to
calling weston_surface_move_to_plane()) to avoid the call to
weston_surface_damage_below(). The transform update causes the
damage to be added to this special plane, which is simply ignored.
After the geometry.dirty bit is clear, the surface is moved back to
the primary plane.
When accumulating damage in the repaint loop, the opaque region of
surfaces in other planes is added to the overall opaque region. This
causes surface->clip to contain the areas obscured by surfaces in
other planes. Change it to contain only the opaque region of surfaces
in the primary plane
This fixes a bug where moving a window that was just moved from the
primary plane to another would leave artifacts on the screen. The
problem was that the damage generated by weston_surface_move_to_plane()
would be clipped on weston_surface_redraw(), leaving the contets below
it unchanged. Moving the overlaid surface would no longer generate
damage on the primary plane, so the contents would remain unchanged
(i.e. wrong) indefinitely.
To handle the case where wall clock time jumps forwards by a large amount or
backwards limit the execution of the spring calculation loop.
We do this by forcing the spring update timestamp to being no older that 1s of
the most current time we've been given. We also present a log message if the
timestamp jumps more than expected.