Even if the surface size is already correct, we need to store the
configured size in case some other state change triggers a configure
event.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Arnaud Vrac <avrac@freebox.fr>
These requests need a mapped surface, which can only happen after the
initial configure event.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This way we are sure the compositor is aware of a surface when we
forward a request for said surface.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This only stores the current state, as libweston-desktop is still in
charge of double-buffering it.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This prevents a segfault when unplugging an output when using pixman.
Signed-off-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
With this weston_view_destroy() call, Xwayland popups make Weston freeze
in a busy-loop (probably corrupted wl_list).
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
weston-terminal intermittently crashes on startup. This occurs because
some parameters in the weston_terminal structure such as data_pitch,
don't get set to non-zero until the resize_handler() callback gets
triggered. That callback makes a call to terminal_resize_cells(), to
calculate the proper values for these parameters.
On occasion, the resize handler call is slow to resolve, and the program
proceeds to start processing characters for the terminal window. With
the parameters defaulting to zero, certain calculations come out wrong,
leading the program to attempt to scroll the buffer when it shouldn't,
and thus follows the crash.
Instead, force the call to terminal_resize_cells() during the init, with
some dummy defaults, to ensure the parameters are always non-zero.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=97539
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
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>
Bryce Harrington
Quentin Glidic
Emmanuel Gil Peyrot
Yong Bakos
Derek Foreman
Arnaud Vrac
Pekka Paalanen
Emil Velikov
Benoit Gschwind