This commit adds a weston_buffer structure to replace wl_buffer. This way
we can hold onto buffers by just their resource. In order to do this, the
every renderer.attach function has to fill in the weston_buffer.width and
weston_buffer.height fields.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
AC_USE_SYSTEM_EXTENSIONS enables _XOPEN_SOURCE, _GNU_SOURCE and similar
macros to expose the largest extent of functionality supported by the
underlying system. This is required since these macros are often
limiting rather than merely additive, e.g. _XOPEN_SOURCE will actually
on some systems hide declarations which are not part of the X/Open spec.
Since this goes into config.h rather than the command line, ensure all
source is consistently including config.h before anything else,
including system libraries. This doesn't need to be guarded by a
HAVE_CONFIG_H ifdef, which was only ever a hangover from the X.Org
modular transition.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
[pq: rebased and converted more files]
The old code had an off-by-one error on the y coordinate
where it says height - (cur_y - y). And it does the vflipping of
the *destination* buffer, whereas what is really needed is to
vflip the whole source buffer. This only affects when you read
out part of the image, such as when using the screen recoder.
Also, instead of doing the flipping manually we just let pixman
handle it.
We changed the protocol to always list modes in physical pixel
units (not scaled). And we removed the scaled mode flag. This
just updates the DRM and X11 compositors and the gl and pixman renderers
to handle this.
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>
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.
The X11 backend uses a shadow buffer to be able to support transformed
outputs. However, this belongs in the renderer, since otherwise this
code would have to be copied into every backend that uses the pixman
renderer and supports transformed outputs.
This renderer could be used when there's no graphic accelerator available,
for example in (future) KMS and fbdev backends.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Tomeu Vizoso