We never want to update the transform and then damage below. Damage
below is always used to trigger a repaint where the surface used to be
so we need to record the damage before updating the transform.
The X11 compositor currently posts its key presses as keycode - 8; this
is due to X11 having a historical minimum keycode of 8, whereas evdev is
numbered starting from 1. So while the KEY_* constants begin with
KEY_ESC at 1, the corresponding keycode in both X11 and the XKB keymaps
is 9.
window, on the other hand, was relying on xkb->min_key_code being 8 to
translate its keycodes back to useful values in the XKB 'evdev' keycode
map. min_key_code may not always be 8, for restricted subsets of the
keycode map.
Perhaps not the best solution, but at least consistent.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This change depens on the Wayland core commit:
"protocol: remove absolute coordinates from pointer".
Remove the absolute coordinates from pointer motion and pointer_focus
events.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Needed for implementing drag'n'drop icons. When a drag starts, the
compositor will position the top-left corner of the client supplied
icon surface at the cursor hotspot. On the first attach to that
surface, the client may want to reposition it but shell->map did not
take sx and sy parameters.
This changes shell->map interface to take sx and sy parameters and
change dekstop shell implementation to update the position of a
surface of type none according to those parameters. Since a surface
of type none won't actually be mapped, the effect of this change is
only visible for surfaces that are made visible by the compositor.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Surfaces like drag'n'drop icons shouldn't receive events as a normal
surface but are still created by the client so add a way for the
compositor to enable or disable the picking of a client surface.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
The condition to return from surface_attach with a null buffer involves
es->output being non-null. However if a surface was just created this
field would be null and an attach of a null buffer would cause the
compositor to crash.
The other crash happened if surface_attach was called twice with a
null buffer after a valid buffer was attached to the surface. Since
es->buffer was not being set to NULL, surface_attach() would call
wl_list_remove(&es->buffer_destroy_listener.link) twice for the same
surface.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
I know it's hard to figure out what the shells or backends will be
using as internal API at this point but we can try to minimize the
amount of WL_EXPORT being used anyway.
[pq: redone due to my earlier changes]
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This clean-up seems alright, but someone with better knowledge has to
doublecheck this function. I guess there's a lot of space for clean-up
there.
[pq: looks ok, redone since did not apply after my changes]
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Setting a window type is a non-visual operation, it is not supposed to
affect the rendering immediately. Therefore it does not need to apply
surface damage.
The proper surface damage is applied on an attach request following a
window type change.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
As weston_surface_update_transform() automatically applies before and
after damage on surface geometry change, we don't need to explicitly add
the same damage in motion_notify() for the cursor surface.
We still need the side-effect, that is scheduling a repaint.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Round off fractions from non-transformed surface position coordinates.
Transformed surface moved by a client may have non-integer position
coordinates. That is required to prevent drifting on continuous
resizing.
We can round the position to integers when the surface is not (anymore)
transformed.
This change may fix a rounding inconsistency in the opaque region setup,
where the rectangle is initialised from the coordinates without explicit
rounding operation.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
In the past, weston_surface_configure() was used to change the geometry,
apply damage, and assign an output.
Remove all calls to weston_surface_configure() that do not change the
surface geometry. Add damage calls where needed to keep the wanted
configure side-effects.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Move the call to assign an output from weston_surface_configure() to
weston_surface_update_transform().
As update_transform takes new geometry into use, it should also reassign
the output for the surface, but only if an output was already assigned.
Add explicit assing output calls to where we relied on
weston_surface_configure() unconditionally assigning the output.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Move the surface opaque region setup from weston_surface_configure() to
weston_surface_update_transform(), so we have less reason to call
update_transform from configure. Opaque region depends on geometry,
after all.
Also move the opaque field from weston_surface to
weston_surface::transform to make this obvious.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Remove redundant weston_surface_update_transform() calls from within
output repaint paths, and add a comment that we need to rely on
surface->geometry.dirty == 0 within the repaint sub-functions.
Now that weston_surface_update_transform() does damage as needed, and
weston_output_repaint() explicitly calls update_transform, we can reduce
the updates in rotate_grab_motion() to simply scheduling a repaint. This
will guarantee that the change in rotation ends up on screen ASAP.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
weston_surface_update_transform() is similar to
weston_surface_configure() in that it changes the surface region on
screen. Unlike configure, update_transform forgets to deal damage at
all, yet it is the only place where we can do damage_below() as needed.
Add a damage_below call to deal damage for the old surface region only
when needed. This uses the cached state from surface->transform to get
the old region.
Add a damage call to deal damage for the new surface region, after
updating the cached state.
Add a repaint call, since we have changed the scene and should render it
out.
This change fixes the rotation not updating the screen properly.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The non-transformed case looked a little odd, calling
weston_surface_to_global(), since it already tests for transform.enabled
and simply uses width, height for the box.
Streamline it, by open-coding weston_surface_to_global(), and avoiding
another call into weston_surface_update_transform(). This way it does
not look suspicious to me.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
In surface_compute_bbox(), call surface_to_global_float() instead of
weston_surface_to_global(). This avoids the recursion:
weston_surface_update_transform()
weston_surface_update_transform_enable()
surface_compute_bbox()
weston_surface_to_global()
weston_surface_update_transform()
which might be non-obvious when reading the code.
Computing the min and max coordinates in floats, we can have a tight
rounding margin by using floor() and ceil().
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Split two helper functions out of weston_surface_update_transform() to:
- make the code clearer
- update the bounding box properly even if transformation fails
- unify the return point
Also add a comment on what matrix.d[12] is.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Extract the core into a function that does not call
weston_surface_update_transform() or schedule repaint.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Rotating a surface should not force a full display repaint, so remove
that.
This change exposes a bug: weston_surface_update_transform() does not
apply damage, but it does change surface geometry. While you rotate a
surface, repaints do not work.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
