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>
The Wayland protocol permits a client to request the pointer, keyboard
and touch multiple times from the seat global. This is very useful in a
component like Clutter-GTK where we are combining two libraries that use
Wayland together.
This change migrates the weston input handling code to emit the
events for all the resources for the client by using the newly added
wl_resource_for_each macro to iterate over the resources that are
associated with the focused surface's client.
We maintain a list of focused resources on the pointer and keyboard
which is updated when the focus changes. However since we can have
resources created after the focus has already been set we must add the
resources to the right list and also update any state.
Additionally when setting the pointer focus it will now send the
keyboard modifiers regardless of whether the focused client has a
pointer resource. This is important because otherwise if the client
gets the pointer later than you getting the keyboard then the
modifiers might not be up-to-date.
Co-author: Neil Roberts <neil@linux.intel.com>
This makes the drag-and-drop code available to in-weston data sources,
similar to how we can set a selection data source internally. The
wl_data_device.start_drag entry point now calls this function after
validating protocol arguments.
config.h includes were missing in a few files, including input.c, the
lack of which caused the X11 backend to segfault instantly due to not
having an xkbcommon context.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This removes the use of wl_client_get_display() where the client is
derived from the focussed resource. This starts the removal of the
assumption of a single resource on a client that would be notified about
events on the focussed surface.
This commit sets the version numbers for all added/created objects. The
wl_compositor.create_surface implementation was altered to create a surface
with the same version as the underlying wl_compositor. Since no other
"child interfaces" have version greater than 1, they were all hard-coded to
version 1.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
We were assigning drag from the resource user data, which was wrong
(resource data is the weston_seat) and confusing since drag is later
assigned newly malloc()ed memory.
We used to refcount the data source, but switched to using a destroy signal
instead. When we switched we forgot to free the source insted of
unreffing it.
Because of its links to selection.c and xwayland, a destroy_signal field
was also added to wl_data_source. Before selection.c and xwayland were
manually initializing the resource.destroy_signal field so that it could be
used without a valid resource.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This is the first in what will be a series of weston patches to convert
instances of wl_resource to pointers so we can make wl_resource opaque.
This patch handles weston_surface and should be the most invasive of the
entire series. I am sending this one out ahead of the rest for review.
Specifically, my machine is not set up to build XWayland so I have no
ability to test it fully. Could someone please test with XWayland and let
me know if this causes problems?
Because a surface may be created from XWayland, the resource may not always
exist. Therefore, a destroy signal was added to weston_surface and
everything used to listen to surface->resource.destroy_signal now listens
to surface->destroy_signal.
Currently the core input code does surface picking before calling into
the focus callback of the current grab. Not all grabs need to pick a
surface however, so we're doing work we don't have to in those cases.
For example, the shell move and resize grabs don't need to pick and the
default grab in implicit grab mode doesn't either.
With this change, the pointer grab mechanism is now very simple:
the focus callback is called whenever the pointer may have a new focus,
the motion callback is called whenever the pointer moves and
the button callback whenever a button is pressed or released.
This was another complication that we had to have to support the
split between libwayland-server and weston. Different grabs want to send
events relative to different surfaces at different times. The default
grab switches between sending coordinates relative to the 'current' surface,
that is the surface the pointer is currently above, or the 'clicked'
surface, in case of an implicit grab.
The grab focus was set by the grab implementation and the core input code
would transform the pointer position to surface relative coordinates for the
grab focus and store in grab->x/y.
Now we can just let the grab implementation transform the pointer
coordinates itself, leaving the implementation free to transform
according to whichever surface it wants. Or not transform at all if
it doesn't need surface relative coordinates (like the shell move and resize
grabs).
device_setup_new_drag_surface() and device_release_drag_surface() are both
now fairly small and only called from data_device_start_drag() and
data_device_end_grab() respectively. Folding the two functions in where
they're called from simplifies the code flow a bit.
struct weston_surface is now the only surface type we have (in core, shell.c
has shell_surface, of course). A lot of code gets simpler and we never
have to try to guess whether an API takes a wl_surface or a weston_surface.
We can now update the drag icon position directly from the configure
handler or the grab motion handler, and no longer need
weston_seat_update_drag_surface().
Previously we just got the drag_icon signal and had to figure out what
changed. Now we can directly setup or release the drag icon when the
drag starts and stops.
We have to deal with the data source going away. Even if we have a
reference to the server side data source, we can't do anything if the
client that provided the source went away. So just NULL the offers
source pointer in the destroy callback for the source.
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
This is the other direction. The selection bridge will grab the X11
CLIPBOARD selection on behalf of the Wayland client when it sets the
Wayland selection. Right now only UTF-8 text is supported, but the
data types offered will be taken from the Wayland data source.
Jason Ekstrand
Neil Roberts
Kristian Høgsberg
Daniel Stone
Rob Bradford
Peter Hutterer