Animations are run off the repaint cycle so if there's nothing to
repaint, an animation will stop running. This is usually not a problem
as each frame function of an animation causes something to change and
therefore a repaint to happen. This patch helps detect when the
animation isn't in said case and triggers a repaint to keep the
animation running.
This problem was found by using weston_move_scale_run() to move a view
onscreen from completely off. The very first time the animation frame
function was called the progress wasn't enough to move it into
view. The compositor saw there was nothing to repaint and stopped
doing anything else. When something else (like a pointer move) forced
a redraw, the view's position was very much onscreen and jumped into
view in an ugly way.
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>
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>
The weston_spring is a very flexible and powerful mecanhism for driving
animations. However, it can be a little difficult to tame, but this
little helper can plot the response of the spring to a set of initial
parameters and makes it easy to tune and tweak the spring behavior.
By labelling devices with ENV{WL_SEAT} in udev rules the devices will be
pulled into multiple weston seats.
As a result you can get multiple independent seats under the DRM and
fbdev backends.
And as a result of this stop iterating through the compositor seat list
(of one item) and instead access the udev_input structure directly.
This enables a refactoring to pull out the weston_seat into a separate
structure permitting multiple seats.
We always call enable_udev_monitor and add_devices together and always
disable_udev_monitor and remove_devices together. Let's just have one
entry point for enable and one for disable.
weston-launch starts weston and provides mechanism
for weston to set/drop drm master, open a tty,
and read input devices without being root.
Execution is allowed for local-active sessions
or users in the group weston-launch.
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.
Besides the new header file, there's also a change in the main evdev creation
procedure for a more suggestive name (evdev_input_add_devices ->
evdev_input_create). There's no real functional changes in this commit.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Bryce Harrington
Jonny Lamb
Jason Ekstrand
Daniel Stone
Kristian Høgsberg
Rob Bradford
Benjamin Franzke
Tiago Vignatti