This allows each output back end to optimize drawing using overlay planes
and cursors (yet to be integrated). If a surface is assigned to a
plane, the back end should clear its damage field so that the later
repaint code won't look at it.
Ideally, we would want to use <modifier>+Scroll binding but that will have
to wait for axis events. For now we just use keybindings. Zoom in/out with
Super+Up/Down.
We just set the input region to the bounding box of the window frame
and set the opaque region to be the opaque rectangle inside the window
if the child widget is opaque.
If client send set_fullscreen/set_transient request before the first attach,
compositor has no chance to map the surface due to "if (es->output == NULL)".
You can pull it from git://gitorious.org/wayland-for-krh/weston.git map-bug
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>
Jesse Barnes
Scott Moreau
Kristian Høgsberg
Ander Conselvan de Oliveira
Alex Wu
Daniel Stone
Pekka Paalanen
Ander Conselvan de Oliveira
Juan Zhao
Tiago Vignatti