This patch adds a feature to the DRM backend that uses libva for
encoding the screen contents in H.264. Screen recording can be
activated by pressing mod-shift-space q. A file named capture.h264
will be created in the current directory, which can be muxed into
an MP4 file with gstreamer using
gst-launch filesrc location=capture.h264 ! h264parse ! mp4mux ! \
filesink location=file.mp4
This is limitted to the DRM compositor in order to avoid a copy when
submitting the front buffer to libva. The code in vaapi-recorder.c
takes a dma_buf fd referencing it, does a colorspace conversion using
the video post processing pipeline and then uses that as input to the
encoder.
I'm sending this now so I get comments, but this is not ready for
prime time yet. I have a somewhat consistent GPU hang when using
i915 with SandyBridge. Sometimes a page flip never completes. If you
want to try this anyway and your system get stuck, you might need to
run the following:
# echo 1 > /sys/kernel/debug/dri/0/i915_wedged
After that, alt-sysrq [rv] should work.
Once that's fixed it would also be good to make the parameters used by
the encoder more flexible. For now the QP parameter is hardcoded to 0
and we have only I and P frames (no B frames), which causes the
resulting files to be very large.
Previously the configure script would silently disable the use of
accelerated cairo in the clients if cairo-gl could not be found (or
cairo-glesv2 if that was requested.) Conversely the use of cairo-gl
would be automatically enabled if it was found with no way to disable
that feature
This change adds --with-cairo which takes one of "image", "gl" or
"glesv2" (defaulting to "image"). If "gl" or "glesv2" is specified
cairo-egl is checked for as well as the specified renderer. If the check
fails then the configure process errors out.
This patch adds a configure option which will enable
user to install demo clients if desired. It is disabled
by default.
v2: Remove AC_DEFINE as it is not necesary
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]
Whether or not a shm pool is used for resizing is now configurable at
build time (--disable-resize-optimization).
[pq: removed an unnecessary hunk from the patch]
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>
This allows users to change the assigned display profile in GNOME (using
gnome-control-center) or KDE (using colord-kde) and also allows the profiling
tools to correctly inhibit the calibration state whilst measuring the native
screen response.
Add a demo program with:
- a main surface (green)
- a Cairo-image sub-surface (red)
- a raw GLESv2 widget (triangle)
Sub-surface input region is set empty to avoid problems in toytoolkit.
If Cairo links to libGL, then we will end up with also libGLESv2 linked
to subsurfaces program, and both libs getting really used, which leads
to disaster.
Do not build subsurfaces demo, if Cairo links to libGL and cairo-egl is
usable.
The GL rendering loop is not tied to the toytoolkit or the widget, but
runs directly from its own frame callback. Therefore it runs
independent of the rest of the application. This also relies on one of
two things:
- eglSwapInterval(0) is implemented, and therefore eglSwapBuffers never
blocks indefinitely, or
- toytoolkit has a workaround, that guarantees that eglSwapBuffers will
return soon, when we force a repaint on resize.
Otherwise the demo will deadlock.
The code is separated into three sections:
1. The library component, using only EGL, GLESv2, and libwayland-client
APIs, and not aware of any toolkit details of the parent application.
This runs independently until the parent application tells otherwise.
2. The glue code: a toytoolkit application widget, who has its own
rendering machinery.
3. The application written in toytoolkit.
This patch also adds new toytoolkit interfaces:
- widget_get_wl_surface()
- widget_get_last_time()
- widget_input_region_add()
Toytoolkit applications have not had a possibility to change the input
region. The frame widget (decorations) set the input region on its own
when used, otherwise the default input region of everything has been
used. If a window does not have a frame widget, it can now use
widget_input_region_add() to set a custom input region.
These are not window methods, because a widget may lie on a different
wl_surface (sub-surface) than the window.
Changes in v3:
- replace set_commit_mode with set_sync and set_desync
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This patch is the 6th version of the FreeRDP based compositor.
Changes from last version:
* use pixman_image_get_stride() when appropriate
* always realloc
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Otherwise, it means the X11 compositor depends on another library to
pull xcb-shm (cairo?), which is not always the case. Here I end up with:
[01:54:38.970] Failed to load module:
$prefix/lib/weston/x11-backend.so: undefined symbol: xcb_shm_id
This patch installs the three header files that define the compositor
plugin interface as well as a pkg-config file. This allows
building weston plugins outside the weston tree. We currently don't make
any guarantees about the plugin API/ABI except that within a stable
branch we won't break it.
libunwind has a dwarf parser and automatically queries the dlinfo
for location of dlopened modules. The resulting backtrace is much
better and includes stack frames in dynamically loaded modules.
krh: Originally submitted for Xorg, adapted for weston:
http://lists.x.org/archives/xorg-devel/2013-February/035493.html
Note this require libunwind at least 1.1 to get the pkg-config files.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
By default enabled but one can disable it by passing --disable-xwayland-test
to the configure script. Also, the weston-tests-env script is trying to load
xwayland.so in either case, but it behaves resilient in the absence of that
meaning all the other tests are still going to be kicked for running.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
When cairo-gl and mesa-glu are present on the system, autoconf successfully
recognizes both. However, I was wondering why weston-screensaver was not
building since autoconf reported all dependencies were met.
Move the mesa-glu PKG_CHECK before the conditional. Additionally, remove
redundant check for enable_egl, as it is implied when GLU is 'yes.'
Signed-off-by: Joe Konno <joe.konno@intel.com>
Add a frame buffer backend using pixman to render to fbdev.
This has been tested against nouveaufb but nothing else. Much of the code
came straight from the rpi backend (and copyright has been attributed
accordingly).
The behaviour of this backend on less modern frame buffers has yet to be
tested.
The refresh rate is calculated from the frame buffer's metadata. Every frame
is finished in synchrony with the refresh rate.
Frame buffer devices are currently specified on the command line (or using
the default of /dev/fb0); udev could be used in future to enumerate them.
pixman is used for compositing, and a suitable pixman format is built from
the frame buffer's metadata. This doesn't support the full range of
frame buffer formats, but does support varying BPPs of RGBA and ARGB. That
should be enough for now.
The following are not currently supported:
• FOURCC
• Non-packed formats (interleaved, planes, etc.)
• Non-true-colour formats (monochrome, greyscale, etc.)
• Big-endian formats (with component MSBs on the right)
• Non-RGBA and non-ARGB formats
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
