Derive client from simple-shm and hook up the API defined in
wayland-protocols to allow client screensaver inhibition requests.
v5:
+ Add simple-idle client demo
+ Add command line options to delay creation/destruction of inhibitor
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
When a client has registered idle inhibition on a surface, don't trigger
the fade-out animation on the output(s) the surface is displayed on.
But when the surface is destroyed or the inhibitor itself is destroyed
by client request, re-queue the fade out animation.
Adds a helper routine weston_output_inhibited_outputs() which returns a
mask of outputs that should inhibit screen idling.
Use this routine to check for inhibiting outputs for handling of idle
behaviors in core: In sleep mode, only halt repainting outputs that
don't have valid inhibits. Don't send these monitors DPMS off commands
either, if the system would otherwise be powering them down.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
v5: Drop unused view variable
Instead of creating a single global fade surface across all outputs,
create a separate surface for each output. This will permit
e.g. individual fades for each output (or blocking the fade-outs if
inhibiting idling as will come in a latter patch.)
This also fixes a potential issue if on multihead layout spanning a
desktop wider than 8096 (or higher than 8096), the fade animation may
not completely cover all surfaces.
This assumes the output geometry doesn't change larger during the course
of the fade animation.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
v5:
+ Use the new libweston-desktop API for dropping idle inhibitor to
ensure fade_out gets triggered if the client destroys the inhibitor
early.
+ Fix a crash when running multi-head due to double free of animations
+ Split idle inhibition implementation to a subsequent patch
Its usage is now limited to some dock-related helper, and the plugin
registry is a better fit for that kind of helper.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Now we properly unregister from the panel/background surface destroy
signals if the output is destroyed first.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
It doesn't destroy the view per se (except for internal surfaces) and
require the caller to also destroy the view itself at the appropriate
time.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
We're leaking the fd when sending cut'n'paste. Failure to close can also
makes the other end unhappy because it doesn't know the paste is finished.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Remove the output transform from the view transform list when its
surface is destroyed. The surface destruction also triggers the
freeing of its views, so the next access to the output transform link
could crash.
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Invert the Y_INVERT flag for the EGL import fo dmabufs. This fixes
weston-simple-dmabuf-intel to show the same image on both GL-composited
and with direct scanout on a hardware plane. Before, the image would
y-flip when switching between these two cases. Now the orientation also
matches the color values written in simple-dmabuf-intel.c.
The GL-renderer uses the OpenGL convention of texture coordinates, where
the origin is at the bottom-left of an image. This can be observed in
texture_region() where the texcoords are inverted if y_invert is false,
since the surface coordinates have origin at top-left. Both wl_shm and
dmabuf buffers have origin at the top-left.
When wl_shm buffer is imported with glTexImage2D, it gets inverted
because glTexImage2D is defined to read in the bottom row first. The shm
data is top row first. This incidentally also means, that buffer pixel
0,0 ends up at texture coordinates 0,0. This is now inverted compared to
the GL coordinate convention, and therefore gl_renderer_attach_shm()
sets y_inverted to true. This causes texture_region() to NOT invert the
texcoords. Wayland surface coordinates have origin at top-left, hence
the double-inversion.
Dmabuf buffers also have the origin at top-left. However, they are
imported via EGL to GL, where they should get the GL oriented
coordinates but they do not. It is as if pixel 0,0 ends up at texcoords
0,0 - the same thing as with wl_shm buffers. Therefore we need to invert
the invert flag.
Too bad EGL_EXT_image_dma_buf_import does not seem to specify the image
orientation. The GL spec implied result seems to conflict with the
reality in Mesa 11.2.2.
I asked about this in the Mesa developer mailing list. The question with
no answers:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120249.html
and the thread I hijacked to get some answers:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120733.html
which culminated to the conclusion:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120955.html
that supports this patch.
simple-dmabuf-v4l is equally fixed to not add Y_INVERT. There is no
rational reason to have it, and removing is necessary together with the
GL-renderer change to keep the image the right way up. This has been
tested with VIVID.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Add very short explanation on how to set up Vivid driver, when you don't
have suitable V4L2 device to use.
Using the XR24 (DRM_FORMAT_XRGB8888) format practically guarantees that
you can test direct scanout on a hardware overlay, too. At least on PC
hardware that has overlays. Tested to work on Intel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Since one is (about to be) using libweston, they should check for it as
opposed to libwayland.
Silly copy/paste mistake that would have caused a lot of confusion.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
The "state" variable in x11_backend_deliver_button_event is basically the
same as (event->response_type == XCB_BUTTON_PRESS), thus update the code
to use the last one.
Signed-off-by: Benoit Gschwind <gschwind@gnu-log.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
The x11_backend_deliver_button_event can be called with any
xcb_generic_event. The assert check if the call is done with the
expected events.
Signed-off-by: Benoit Gschwind <gschwind@gnu-log.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Valgrind noticed that we send uninit data to drmModeAddFB2. While
the kernel should never read this (because of the plane format),
it's probably still nicer to zero the data before we send it.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Check that the defined versions for Weston and libweston are consistent
and according to the version bumping rules:
- In pre-release and only pre-release versions the weston and libweston
may differ
- when they differ, libweston version must be exactly (weston.major+1).0.0
- otherwise, the versions must be exactly the same.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This bump is required for the following patch that adds strict version
consistency checking between weston and libweston.
This bumps libweston major from 0 to 1. All libweston users need to
adapt. This major bump would have to be made on the 1.11.91 release
anyway.
Cc: Giulio Camuffo <giuliocamuffo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
We have agreed to use the major as the ABI-version, so talk about major
to avoid confusion.
Remove unncessary or incorrect wording related to breaking ABI on minor
bumps.
Explain a little about the weston vs. libweston version numbers.
v2:
- Add a paragraph about ABI breaks between alpha and .0 releases.
- clarify pre-release definition
- Add two paragraphs about libweston versions differing from weston
version and how to use pkg-config properly.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
libweston has separate version numbering from weston because of
development needs.
During development, weston version is major.minor.90 which will never be
a release version number. While developing, we may break the libweston
backward-compatibility, in which case libweston_major_version will be
bumped. This means that libweston_major_version > weston_major_version
but only during the development period and for the pre-releases. When
the official x.y.0 release is made, weston and libweston versions will
get synchronized as explained in releasing.txt.
The reason we do this is that e.g. during the weston 3.0.90 development
period we must be able to install libweston-4.so because the development
has broken the compatibility and so we cannot install it as libweston-3.so
anymore. However, we cannot bump weston to 4.0.90, because then the
official release would go backwards in numbers to 4.0.0.
This also means that weston pre-releases major.minor.9x may install
libweston-(major+1).so. There is also libweston-(major+1).pc file but it
will give the weston version as the version number. IOW, pkg-config
check for 'libweston-M < M.0.0' matches only the pre-releases of the
libweston major version M. Hence, 'libweston-M >= M.0.0' cannot be
satisfied by pre-releases.
The weston and libweston version numbers MUST be identical in all
releases except the pre-releases major.minor.9x.
When the 1.11.91 pre-release is made, the rules imply that libweston
version will be bumped from 0.0.0 to 1.11.91. The bumping will continue
up to the 1.12.0 release. After the bump to 1.12.90, the libweston
version may be bumped to 2.0.0. Then the rules imply that:
- 1.12.9x pre-releases install libweston 2.0.0
- the next .0 release is 2.0.0 containing libweston 2.0.0
If the 1.12 stable branch will see additional releases, those will be
numbered 1.12.1, 1.12.2, etc. with the libweston version being the same
as the release version number.
If we have release 2.0.91 without libweston major bump, then libweston
version will match the release version, leading up to 2.1.0.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This way, the environment is correctly preserved for weston. Since
commit 636156d5f6, clearenv() is only
called when we open a new PAM session, so it makes sense to only use a
login shell in that case.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
shared/image-loader.c: In function 'load_image':
shared/image-loader.c:434:12: warning: 'image' may be used uninitialized
in this function [-Wmaybe-uninitialized]
} else if (!image) {
^
Warning produced by GCC 5.3 and 6.1, with -Og.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
libweston/gl-renderer.c: In function 'compress_bands':
libweston/gl-renderer.c:481:6: warning: 'merged' may be used
uninitialized in this function [-Wmaybe-uninitialized]
if (!merged) {
^
Warning produced by GCC 5.3 and 6.1, with -Og.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
There is a UTF-8 no-break space (U+A0, U8+C2A0) in the definition of
macro NSC_RESET in the case of 1.2.2 <= FreeRDP < 2.0.
This is causing build issues (\302 is 0xC2, \240 is 0xA0):
http://autobuild.buildroot.net/results/f49/f49a9cbb7bdc5d9e05dcf0a20bd83f059e234e74/build-end.log
Fix that by using a plain, boring space U+20.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Instead we store the buffer move and just use it when the signal is
fired.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This is what we are interested in for real, and new_buffer is wrongly
named.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Bryce Harrington