The current semantics would implicitly attach the most recently attached
buffer at commit time and send a release event when the buffer enventually
was released. The implicit attach is a little too subtle though and this
patch changes the semantics to always only send release events in response
to an attach event. As a consequence, once a compositor releases a buffer,
it no longer has a reference to it and wl_surfcea.damage is undefined.
Thus, the client side visible change is that damage request must always
be preceeded by a wl_surface.attach request, to ensure there's a valid buffer,
even if that means attaching the same buffer again.
Nothing else calls weston_buffer_post_release and the ref-counting and
sending the release event is essentially what weston_buffer_reference is
all about.
We subtract the screen space opaque region from the transformed surface
region. That's going to fail for when we're scaling up a surface, since
the surface bounding box for the scaled up surface is going to be bigger
than the opaque region. Instead, subtract the surface-space opaque region
from a 0,0 - width,height region and see if that's empty.
move_client() needs to attach the buffer, even if it was attached already,
because since 184df50 configure() will be called only on newly attached
surfaces, but the one that sets the test surface position is the configure
function.
We never init this, so we need to copy over the position matrix and then
overwrite the translation entries to make sure we have a valid matrix.
Thanks to Pekka for spotting this (twice).
This way the shell can know when a surface has been unmapped by
checking the value returned by weston_surface_is_mapped(surface).
The configure handlers have now width and height parameters, so
they do not need anymore to check manually the buffer size.
If a surface's buffer is NULL the width and height passed to the
configure are both 0.
Configure is now only called after an attach. The variable
weston_surface.pending.newly_attached is set to 1 on attach, and
after the configure call is reset to 0.
The issue was that touch::down event from the compositor to client apps
would send the previous motion events coordinates and this obviously made
the client do the wrong thing. This happened because we were not waiting
for a SYN event to come from evdev before sending down, motion or up events.
https://bugs.freedesktop.org/show_bug.cgi?id=51909
If there was a fullscreen surface using driver mode when a vt switch is
triggered, but something caused it to be gone when switching back (such
as the client being killed), a call to drm_output_switch_mode() is made
to restore the old mode, and that sets the output's current drm_fb to
NULL, so that the new mode is set drm_output_repaint(). This led to a
crash in vt_func(), because it tried to access output->current for
restoring the old mode.
Fix this by not setting the mode if there's no current fb. Instead,
schedule a repaint so that the mode is set in drm_output_repaint().
https://bugs.freedesktop.org/show_bug.cgi?id=60675
DIST_SUBDIRS should be used for corner cases only, not for conditional
SUBDIRS:
If `SUBDIRS' is defined conditionally using Automake conditionals,
Automake will define `DIST_SUBDIRS' automatically from the possible
values of `SUBDIRS' in all conditions.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Previously, when coming back from idle the compositor would try to
track if the unlock signal needed to be sent, and the shell would
change the compositor state in order to track when to display or
hide the screensaver.
This patch finishes moving this out of the compositor. With this, the
compositor state should be changed only using the exported functions
weston_compositor_wake() and weston_compositor_sleep(). The unlock
signal will be sent if the compositor wasn't in the ACTIVE state
previously. The lock signal is sent when the compositor becomes idle.
The calls to weston_compositor_wake() in the shell where there to allow
it to trigger the fade in only after the lock surface was configured.
Now the shell has full control of the fade and does not needed to
change the compositor state to do that, so those calls were replaced
with shell_fade() calls.
Previously, the shell would change the idle_time of the compositor to
the screensaver timeout and wake the compositor again, so that after
the timeout the compositor would fade to black and then the shell would
receive the lock signal again and would set the dpms state of the
outputs to off.
Instead, use a screensaver-specific timer for that, and call lock
without the back and forth between the shell and core Weston.
Previously, it was impossible to override the fade in/out behavior of
Weston using a different shell, since this was implemented in core
Weston. This also led to complicated interaction between the shell and
the core when displaying lock surfaces and screensavers.
This patch starts to solve this issue by moving the fade animation out
of the core. On compositor.c, besides deleting the fade code, the idle
handler had to be changed to emit the lock signal, since it was called
from the fade_frame() function before. This causes a slight change of
behavior, since before the fade would happen with the compositor being
active, while now it is already in the idle state. That leads to the
dpms state being set when cancelling the fade with mouse movement, and
in turn, to a slight freeze with drm compositor. This problem will be
fixed in a follow up patch.
On the shell side, the fade was re-implemented in a slightly different
manner. Instead of using a custom frame function, the fade animation
from animation.c is used. The interface for starting the fade was also
changed to take the value of an enum instead of a float alpha value,
in order to improve readability.
The function weston_surface_animation_frame() would schedule a repaint
on all outputs, as weston_surface_schedule_repaint() didn't exist when
it was implemented.
The spring code stops when the current value is withing 0.0002 of the
target. In that case, round the value to 0.0 or 1.0 to enable the use
of fast paths, such as disabling blending in the GL renderer when an
opaque region is set.
Add parameters to weston_fade_run() for setting the initial and target
values for the fade, as well as a parameter to set the spring constant
used for the animation.
Also add the weston_fade_update() function, that allows the animation
to be changed while it is still running.
This will be used to move the fade animation from core Weston into the
shell. These changes are needed to be able to fade out as well as in,
and to be able to reverse the fade in case of user input.
If we get a fullscreen client message before we map the window, we don't
have a shell surface yet. Just dont call set_fullscreen yet, and rely on
xserver_map_shell_surface() to fullscreen it when we map it.
Make sure that display_acquire_window_surface() creates the Cairo
surface as necessary. Otherwise surface->toysurface can be NULL.
This fixes weston-screensaver fullscreen mode. Demo mode was not
affected as it uses window decorations, and so the Cairo surface is
created. This regression was introduced by:
commit 0c4445ba57
Author: Pekka Paalanen <ppaalanen@gmail.com>
Date: Wed Feb 13 16:17:23 2013 +0200
window: create Cairo surfaces on demand for redraw
Reported-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
If the window manager doesn't support _NET_WM_STATE_FULLSCREEN, the
fullscreen protocol won't work and we end up waiting indefintely for a
confiure event that doesn't come.
Only try to fullscreen if we have _NET_WM_STATE_FULLSCREEN, and only
wait for map if we're fullscreen.
https://bugs.freedesktop.org/show_bug.cgi?id=61133
When calling shell_map_popup() more than one time on the same shell_surface
the parent transform was getting added more than one time to the transform
list, resulting in an infinite loop when going through the list with
wl_list_for_each in weston_surface_update_transform_enable().
This commit removes the old transform before adding it again.
Because seat_get_keyboard is called after initial
weston_surface_activate, wl_data_device_set_keyboard_focus
fails to send data offer for newly connected client due to
wl_seat.focus_resource being NULL.
This patch calls wl_data_device_set_keyboard_focus
in seat_get_keyboard, so it can send data offer for
newly created client (when wl_keyboard.resource_list
and wl_seat.focus_resource are properly set up).
https://bugs.freedesktop.org/show_bug.cgi?id=60617
We always call enable_udev_monitor and add_devices together and always
disable_udev_monitor and remove_devices together. Let's just have one
entry point for enable and one for disable.
We used to have a bit of naming trouble when the protocol object was called
wl_input_device and the individual evdev devices were call evdev_device.
And we didn't have a drm_seat. Now that we've fixed all that, it's clear
that the drm_seat is all about udev discovery and hotplug of evdev devices,
so let's call it udev_seat instead.
Otherwise we'll kill whatever other display sever we're switching back to.
The tricky thing here is that we never explicitly set drm master in the
startup path, we get that implicitly from being the first to open the
drm device. Even so, we need to drop it before switching VTs.
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.
John Kåre Alsaker
Andre Heider
Kristian Høgsberg
Giulio Camuffo
Satyeshwar Singh
Pekka Paalanen
Ander Conselvan de Oliveira
Scott Moreau
Quentin Glidic
Jan Arne Petersen
Rafal Mielniczuk