Instead of connecting to weston-launch from launcher-util, we now try to
connect to logind first. If logind provides session-devices, we use them.
If not, we fall back to the old weston-launch facility.
This adds optional libdbus integration for weston. If libdbus is available
and not disabled via --disable-dbus during weston build, we now provide
basic DBusConnection main-loop integration for weston.
The dbus.c file provides a new helper to integrate any DBusConnection
object into a wl_event_loop object. This avoids any glib/qt/..
dependencies but instead only uses the low-level libdbus library.
Note that we do not provide dummy fallbacks for dbus helpers in case
dbus-support is disabled. The reason for that is that you need dbus/dbus.h
for nearly any operation you want to do via dbus. Therefore, only the most
basic helpers which can be used independently provide a "static inline"
dummy fallback to avoid #ifdef all over the code.
The time spent loading EGL and GLES libraries from disk can be a
considerable hit in some embedded use cases. If Weston is compiled
with EGL support, the binary will depend on those libraries, even if
a software renderer is in use.
This patch splits the GL renderer into a separate loadable module,
and moves the dependency on EGL and GLES to it. The backends still
need the EGL headers for the native types and EGLint. The function
load_module() is renamed to weston_load_module() and exported, so
that it can be used by the backends.
The gl renderer interface is changed so that there is only one symbol
that needs to be dlsym()'d. This symbol contains pointers to all the
functions and data necessary to interact with the renderer. As a side
effect, this change simplifies gl-renderer.h a great deal.
The compositor uses libdrm in launcher-util.c if the drm backend is
built, but there was no explicit requirement in the build. egl brings
libdrm implicity so the build doesn't fail.
This patch adds an explicit dependency between the compositor and
libdrm if the drm backend is built, so that changes to the compositor
modules don't cause build failures.
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>