When accumulating damage in the repaint loop, the opaque region of
surfaces in other planes is added to the overall opaque region. This
causes surface->clip to contain the areas obscured by surfaces in
other planes. Change it to contain only the opaque region of surfaces
in the primary plane
This fixes a bug where moving a window that was just moved from the
primary plane to another would leave artifacts on the screen. The
problem was that the damage generated by weston_surface_move_to_plane()
would be clipped on weston_surface_redraw(), leaving the contets below
it unchanged. Moving the overlaid surface would no longer generate
damage on the primary plane, so the contents would remain unchanged
(i.e. wrong) indefinitely.
To handle the case where wall clock time jumps forwards by a large amount or
backwards limit the execution of the spring calculation loop.
We do this by forcing the spring update timestamp to being no older that 1s of
the most current time we've been given. We also present a log message if the
timestamp jumps more than expected.
Input panel surfaces were kept in a list by using layer_link of
weston_surface. This was pretty hacky and resulted in the bug that
an input panel surface was not removed from the list if it was unmapped
at the time of destruction.
This patch wraps the surface in a new input_panel_surface struct and
properly handles destruction with a signal listener.
As said by krh: "Maybe we should also just call it an evdev_device
instead, shorter [and] not really ambiguous."
[krh: if my typo filled irc is going in a commit message, I'm at least going
to insert the missing words.]
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
evdev_led_update() does not really need the whole list of device at
once, it can be called one device at a time.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
compositor.c: In function ‘log_extensions’:
compositor.c:3085:7: warning: field precision should have type ‘int’,
but argument 2 has type ‘long int’
compositor.c:3087:4: warning: field precision should have type ‘int’,
but argument 2 has type ‘long int’
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
compositor-drm.c: In function 'drm_output_set_cursor':
compositor-drm.c:754:4: warning: too few arguments for format
compositor-drm.c:759:4: warning: too few arguments for format
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This patch provides a way to define outputs for the x11 backend. It
parses [output] sections and checks for 'name' and 'mode' keys. The
'name' must start with an 'X' to distinguish from drm output names.
Command line options --width and --height supersede what is in the
config file. When --output-count is passed, the number of outputs
are limited or additional outputs added with default values.
Commit 982387011 causes a bug where starting weston results in a black screen
(if no clients are immediately started). The problem is that the offending
commit causes the compositor to not damage if a surface has an empty output
mask, which is the case for the fade surface, which is created by the
compositor. This patch updates the surface output_mask unconditionally,
and only skips sending out the events if there no client.
In cases where we know the surface bounding box doesn't change in the
next frame, we can limit redraws to only the outputs the surface is
currently on. We could do even better by forcing the transform
update so we know where the surface will be in the next frame, but
this is a much simpler first step.
When the entire output is transformed or we're capturing the output
for screenshot or video, disable all output specific overlays
(drm planes, hw cursors etc) and move all surfaces into the primary
plane.
Modify the pkg-config check for setbacklight so that failure only
disables building setbacklight, instead of failing the whole configure.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The variable '__environ' seems to be libc implementation specific, and
not avaible on Android.
Use the POSIX standard variable 'environ', which also luckily happens to
be available on Android, which is not POSIX.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
evdev.c: In function 'evdev_led_update':
evdev.c:57:9: warning: ignoring return value of 'write', declared with
attribute warn_unused_result
Useless in this case.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Weston's notify_keyboard_focus_*() assume that a keyboard is present, if
they are called. With evdev, there might not always be a keyboard.
Also clean up the variable definition in evdev_notify_keyborad_focus().
I read that function through many times and finally had to grep where
does 'all_keys' come from.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
All input devices are re-added during enter VT, so these messages in the
log will clarify what happened with input.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
If the sysname of the udev device did not start with "event", the
function returned without unreferencing udev_device.
The function is refactored to have a common exit path that unrefs
udev_device. The return value semantics are not changed.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Move all udev-related and now drm backend specific code into
compositor-drm.c.
This makes evdev.c free of udev and launcher-util, and allows it to be
used on Android.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This makes the generic evdev code (i.e. the functions not relying on
udev) independent of launcher-util too. The aim is to allow re-using the
generic evdev code in the Android backend, where neither udev nor
launcher-util are available.
evdev_input_device_create() signature is changed:
- add the opened device file descriptor
- remove wl_display as unused
Also add a bit of failure logging.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
evdev_input_device_destroy() will completement the API of
evdev_input_device_create(), both being independent from udev.
Since the udev-specific device_removed() would only call
evdev_input_device_destroy() and do nothing else, device_remove() calls
are simply replaced with evdev_input_device_destroy().
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Since the time values are unsigned integers we can check whether the msec is
smaller than spring->timestamp by checking if the subtraction overflows into a
value greater than half the maximum unsigned integer range (ie. top bit set)
Like how we handle overlays, we split drm_output_set_cursor() into
drm_output_prepare_cursor_surface() that will assign the hw cursor to
a suitable surface and drm_output_set_cursor() that will do the actual
work of updating cursor contents and moving it. This is more in line
with how we handle everything else, and lets us update cursor contents
based on changes to the cursor plane damage.
This works when the cursor content changes but also accumulates
damage when the cursor changes output. In that case we move the
cursor surface to the cursor plane in the new output and
weston_surface_move_to_plane() will generate the damage that triggers
download of sprite contents there.
When we analyze and accumulate damage prior to repainting, we need to
accumulate damage per plane, so that whatever damage a surface
contributes is accumulated in the plane that it's assigned to. Before,
we would always accumulate damge in the primary plane, which caused
repaints in the primary plane whenever a surface in a sprite or
framebuffer was damaged. Eliminating this repaint is a big win for
cases where we pageflip to a client surface or use a sprite overlay.
This also prepares for fixing the missing cursor updates, since we
now track damage to the cursor surface in a dedicated sprite plane.
This backend has not seen even build testing for months, presumably does
not even compile, and is starting to hinder development a little.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Benjamin Franzke <benjaminfranzke@googlemail.com>
Ander Conselvan de Oliveira
Rob Bradford
Rob Clark
Juan Zhao
Philipp Brüschweiler
Pekka Paalanen
Scott Moreau
Kristian Høgsberg
Andre Heider