Scale-crop mode scales the wallpaper to tightly fill the whole output,
but preserving wallpaper aspect ratio. If aspect ratio differs from the
output's, the wallpaper is centered cutting it from top/bottom or
left/right.

Add this to the weston.ini man page, and explain all three modes.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

On Raspberry Pi, weston-desktop-shell is so slow to start, that the
compositor has time to run the fade-in before the wallpaper is up. The
user launching Weston sees the screen flipping to black, the fbcon
fading in, and then the desktop popping up.

To fix this, wait for the weston-desktop-shell to draw
everything before starting the initial fade-in. A new request is
added to the private desktop-shell protocol to signal it. If a
desktop-shell client does not support the new request, the fade-in
happens already at bind time.

If weston-desktop-shell crashes, or does not send the 'desktop_ready'
request in 15 seconds, the compositor will fade in anyway. This should
avoid a blocked screen in case weston-desktop-shell malfunction.

shell_fade_startup() does not directly start the fade-in but schedules
an idle callback, so that the compositor can process all pending events
before starting the fade clock. Otherwise (on RPi) we risk skipping part
of the animation. Yes, it is a hack, that should have been done in
window.c and weston-desktop-shell instead.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

There is no need to support weston_plane anymore.
The max-planes option is removed as unused.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

Replace the GL renderer with the new rpi-renderer on the Raspberry Pi
backend. This makes Weston on rpi not use EGL or GL anymore, at all.

The weston_plane feature is disabled, since the rpi-renderer does the
same, but better.

Add a command line option to select the output transform. It is not a
weston.ini option for now, since the rpi backend does not read the
configuration file yet. Hopefully that will be done later with some
shared code.

Add the rpi options to 'weston --help' output.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

Dispmanx is the prorietary display API on the Raspberry Pi, which
provides hardware compositing. Every visible surface is assigned a
Dispmanx element, and the hardware or firmware will do all compositing
onto screen. The API supports translation, scaling, flips, discrete
rotations in 90-degree steps, alpha channel on the surfaces, and
full-surface alpha on top.

Previously, Dispmanx capabilities were used via the weston_plane
mechanism, where surfaces were assigned to planes when possible, and
otherwise transparently falling back to GLESv2 compositing. Because we
have no way to use the same memory buffer as a GL texture and a Dispmanx
resource, we had to prepare for both. In the worst case, that means one GL
texture, and two (double-buffered case) Dispmanx resources, all the size
of a whole surface, for all surfaces. This was eating memory fast. To
make things worse (and less slow), the wl_shm buffer was kept around,
since it was copied to either a texture or a resource as needed. This
caused all clients to need two buffers. In a Dispmanx-only renderer, we
can drop the GL texture, and we can release wl_shm buffer immediately
after the first copy, so clients become effectively single-buffered. So
from the worst case of 5 buffers per surface, we go down to 3 or just
2 (single-buffered Dispmanx element, one wl_shm buffer in the client)
buffers per surface.

As this will replace the GL renderer on rpi, we cannot fall back to the
GLESv2 compositing anymore. We lose arbitrary surface rotation, but we
lose also the GL fallback, which caused glitches.

This patch depends on new RaspberryPi firmware. Older firmware may not
render ARGB surfaces correctly, solid color surfaces maybe cause a
performance hit, and the output may completely fail in case the firmware
does not fall back internal off-line compositing properly as needed.

This new rpi-renderer support surface translation and scaling, but not
rotation or transpose (not even in 90-deg steps). In theory, 90-deg step
surface rotation is possible to support. Output transformations are
supported, but flipped variants do not seem to work right.

As a detail, menus and other surfaces that are simply translated with
respect to another surface caused falling back to the GL renderer. The
rpi-renderer handles them directly.

This patch only adds the new renderer, but does not hook it up into use.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

Both GL and pixman renderer (pixman probably only because GL did?)
return the screen capture image as y-flipped, therefore Weston y-flips
it again. However, the future rpi-renderer can produce only right-way-up
(non-flipped) screen captures, and does not need an y-flip.

Add a capability flag for y-flip, which the rpi-renderer will not set,
to get screen captures the right way up.

The wcap recording code needs yet another temporary buffer for the
non-flipped case, since the WCAP format is flipped, and the code
normally overwrites the input image as it compresses it. This becomes
difficult, if the compressor is supposed to flip while processing.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

The upcoming rpi-renderer cannot handle arbitrary rotations. Introduce
Weston capability bits, and add a bit for arbitrary rotation. GL and
Pixman renderers support it.

Shell or any other module must not produce surface transformations with
rotation, if the capability bit is not set. Do not register the surface
rotation binding in desktop shell, if arbitary rotation is not
supported.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

The array of arguments supplied to execv must be NULL terminated. If
unitialized values are used as pointers the exec call may fail with a
EFAULT error ("Bad address").

https://bugs.freedesktop.org/show_bug.cgi?id=64874

If you specify e.g. scale=2 in an output section in weston.ini
we scale all modes by that factor.

We also correctly scale cursor positioning, but ATM there is no
scaling of the cursor sprite itself.

Set a clip on the GC when painting the damaged region so that
we don't copy the entire shadow buffer each time.

If you specify e.g. scale=2 in weston.ini an output section for the
X11 backend we automatically upscale all normal surfaces by this
amount. Additionally we respect a buffer_scale set on the buffer to
mean that the buffer is already in a scaled form.

This works with both the gl and the pixman renderer. The non-X
backends compile and work, but don't support changing the output
scale (they do downscale as needed due to buffer_scale though).

This also sends the new "scale" and "done" events on wl_output,
making clients aware of the scale.

Rather than storing the shadow_image in the untransformed space
and rotating on copy to hw_buffer we store both on the transformed
space. This means a copy between them is a straight copy, and that
apps supplying correctly transformed surface buffers need not
change them.

We also correctly handle all output transform including the previously
unhandled flipped ones, as well as client supplied buffer_transforms (which
were previously ignored).

We also simplify the actual rendering by just converting any damage
region to output coordinates and set it on a clip and composite
the whole buffer, letting pixman do the rectangle handling. This
means we always do all the transforms, including the surface positioning
as a pixman_image transform. This simplifies the code and sets us up
for handling scaling at a later stage.

The transform looks complicated, but in practice it ends up being
an integer translation almost always, so it will hit the pixman
fastpaths.

This makes it easy to test buffer_transform and buffer_scale handling.
left-right: rotate
space: toggle inverse
z: toggle scale between 1 and 2

We pick the highest scale of any output the terminal is on, and the
transform from the last one it entered.

This lets you find the maximal scale for all the outputs a window
is on, which is useful for picking a buffer_scale.

We pick the window scale/tranform based on what the output uses, which means
we can avoid rotations in the compositor, and get sharper rendering
in scaled outputs.

We used to just store the buffer size here which is not right if the
surface has a buffer_transform or a buffer_scale. To fix this we pass
the transform and scale into the toysurface prepare and swap calls and
move both the surface to buffer and the buffer to surface size
conversion there.

Without this interactive resize on the top or left sides of a transformed
or scaled surface will not work correctly.

Rather than doing our own transformation handling when drawing we
just rely on the generic code in widget_cairo_create

If a buffer_transform it specified in the window we automatically
compensate for it in the cairo_t

Apparently some compilers complain about set but not used variables
'available' and 'bufs', but I don't get the warning. Still, separate the
debugging code from shm_surface_buffer_release(), so that we only
compute 'bufs' when it is printed. This should fix the warnings.

The debugging code now prints the shm_surface buffer state before and
after, instead of just after.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

The shell_grab_start function sets up a destroy notification on the
shell surface such that when the shell surface is destroyed the pointer
on the grab to the shell surface is set to NULL.

We must therefore check whether the shell surface is NULL and end the
grab if it is.

https://bugs.freedesktop.org/show_bug.cgi?id=64689

Mention, that sub-surfaces are not clipped to the parent.
Be more accurate on surface commit vs. apply state.
Mention the initial stacking order.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

This patch fixes a crash with the surface_pong when one of the
seats doesn't have a pointer. This was the case with the RDP compositor
that use a fake seat with no mouse or keyboard.

This patch brings back the user environment from the shell.
In the future, weston-launch could create the Wayland socket earlier, in
which case the user's shell could be used to run Wayland-specific tools
in the new Weston session.

Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>

This was left over from allowing nesting.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

The only way to create a sub-surface loop by recursive nesting is to
make the main surface (which does not have a role) a sub-surface of any
of its sub-surfaces. All other cases should already be cought.

This change checks for that exact case, and sends a protocol error.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

It should not be possible to create a loop by nesting sub-surfaces.
Currently Weston fails this test.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

wl_subsurface.set_desync should apply the cached wl_surface state.
Otherwise, the sub-surface may be stuck: a commit on the parent surface,
if desynchronized, will not commit the sub-surface because it is
desynchronized, too. A commit on the sub-surface may not happen, if it
is waiting for the frame callback from the previous commit.

Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>

Add a test for varying the object destruction order in a complex
sub-surface tree.

This test attemps to fuzz the destruction of a sub-surface tree to make
sure the server does not crash on any wl_surface or wl_subsurface
destruction sequence.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

surface-global-test and surface-test did not get updated to
the new module_init(...) signature when it changed in
a50e6e4c.  Thus, they
failed to compile.  Simply running 'make check' shows the
problem. This patch fixes it.

fixes https://bugs.freedesktop.org/show_bug.cgi?id=64691



Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>

Saves some start up time by not compiling specific shaders until they
are needed.

Looks like that theme uses different names. Also, add the correspoding
horizontal and vertical resize cursors, just for consistency.

This also fixes a compile warning when building the tarball.