We used to rely on an ugly hack where the xwayland server would always
report RGB X windows as having ARGB pixels, so that texturing from these
would also sample the undefined alpha. We also relied on Xrender rendering
to RGB X windows to write the alpha channel correctly, so that when we
texture from the RGB X window as an ARGB surface we end up getting the
alpha written by Xrender.
That was obviously all broken. We can instead reparent client windows into
ARGB frame windows. That way we can render the decorations using a
ARGB render pictformat and sample back those alpha values in a well-defined
way. We can also unbreak xwayland and let it report RGB pixel format for
RGB windows. We still need the opaque region or the RGB-only client window
but that's OK.
in drm_fb_create_dumb, the return value of the drmIoctl function call
to map the dumb buffer was never checked, thus the following "if
(ret)" check was invalid as it was checking the previous return value
from the above drmModeAddFB call.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
Fixes a segfault. Steps to reproduce:
* start weston with the x11 backend
* open a terminal
* click on the icon in the top left corner, choose close
* close the x11 window containing weston
The keycodes received by the FreeRDP server aren't evdev keycodes.
This patch adds the correct convertion to evdev keycodes. After the
patch all keys that are marked as extended in RDP packets become
functionnal (that's the case for the windows key).
Please note that this patch rely on some corrections that have been
pushed on the FreeRDP github tonight.
Most backends relies on gettimeofday(2) for output repaint timestamps
but this is not a requirement. Before this patch repaints coming from
idle_repaint() always used gettimeofday(2) for timestamps. For backends
not using that time source this could cause large jumps between
timestamps.
To fix this, timestamps needs to always come from the backend. This
means that the backend needs to always be responsible of starting the
repaint loop in case that the repaint cannot start immediately.
The drm backend implementation is from the patch by Ander Conselvan de
Oliveira found here:
http://lists.freedesktop.org/archives/wayland-devel/2013-February/007393.html
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This API call handles setting the current surface on the wl_pointer and also
maintaining a destroy notification to monitor that surface for destruction.
This is part of the fix for: https://bugzilla.gnome.org/show_bug.cgi?id=696946
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>
This state is used when the user switches the vt. It turns of rendering
and frame events, but doesn't set the DPMS state to off.
As a part of this change, also turn off the idle timer when entering
the SLEEPING or OFFSCREEN states, which fixes
https://bugs.freedesktop.org/show_bug.cgi?id=61910 (rpi backend
untested).
This ensures the popup_grab.initial_up field isn't reset to 0
if the popup was not opened because of a mouse press but because
of moving the mouse with a popup already open. Not doing so will
make the first click outside the client area go ignored.
This patch implements a popup stack. When the first popup is opened
the grab is started, and it is added to a list. Further popups will
be added to this list but the grab won't change. When a popup is
closed it is removed from the list and, if it is now empty, the grab
is ended.
A click outside the client area will send the popup_done event to
all the popups in the list, and the grab will end.
Before this commit, weston-launch returned 0 if weston was killed by a
signal. This makes it hard to automatically test weston by using
weston-launch, as there is no way to know why weston was terminated.
This commit makes weston-launch return 10+N instead, where N is the code
of the signal that terminated weston. 10 was chosen because it allows a
script to distinguish it from the case that weston-launch itself was
killed by a signal (128+N), and does not overlap the standard exit codes
defined in sysexits.h.
Partial fix for https://bugs.freedesktop.org/show_bug.cgi?id=60935. I
can't reproduce the SIGHUP using the fbdev backend.
v3: better commit message.
Surface will preserve its rotation transformation when maximizing, which
will cause inconsistencies (eg. no window shadows drawn)
This patch removes rotation from maximized surface and restore it when
unmaximizing (just like in fullscreen mode)
To remain consisten with client side window, which blocks moving and
resizing of window in maximized state, we should do so on the compositor
side as well.
(until there is some unmaximize notification from server, which will
allow window to start drawing shadows and revert itself to toplevel
state)
Implements surface transform inheritance. A 'parent' pointer is added to
weston_surface::geometry, and is automatically used by
weston_surface_update_transform(). When updating the transform, the
parent transform is updated as needed, too.
shell_map_popup() is converted to use the new
weston_surface_set_transform_parent() function. Now, if we moved the
popup's parent surface while the popup is open, the popup surface will
stick to the parent properly.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Instead of directly setting the dirty flag on weston_surface geometry,
use a function for that.
This allows us to hook into geometry dirtying in a following patch.
Also add comments to weston_surface fields, whose modification causes
transform state to become outdated.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Remove redundant geometry dirtying from surface_commit() to simplify
further changes.
This code was added in commit 5df8ecac5d
"compositor: Fix partial repaints"
as the fix to:
https://bugs.freedesktop.org/show_bug.cgi?id=56538
The issue fixed by that commit was making the geometry dirty on every
attach, which caused full-surface repaints every time. The bug was
probably introduced by the opaque region changes during implementing
wl_surface.commit. The mentioned commit fixes the opaque handling by
comparing the new and old regions.
However, the commit also introduces additional checks that set
geometry.dirty. In the current code base, this should be unnecessary.
If the pending.sx or pending.sy are not zero, or if the surface size
changes, the configure() hook is responsible for applying the new
values, and so also marking the geometry dirty.
The configure() hook is only called, if there has been a new
wl_surface.attach. Nothing else can change these variables, so this
should be enough.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
When an axis (scroll) event results in a key binding function
being executed, eat the scroll event so the underlying window
doesn't receive it.
Thanks to Scott Moreau for helping me solve this.
Now that we have EXT_buffer_age in mesa, we should stop assuming double
buffering and use the buffer age instead.
Note: this will cause system without the extension to repaint the whole
screen every frame.
Before this change, surface->clip would contain the region of this the
surface that is obscured by opaque containing of other surfaces in any
plane. If a surface was obscured only by a surface in another plane and
the renderer was told to draw that region, the rendering would be
clipped because of that.
This patch changes the clip to be plane specific, so that it contains
only the region of the surface obscured by other surfaces in the same
plane. We also calculate a per plane clip, so that we don't tell the
renderer to draw regions of the primary plane that are obscured by
other planes. This damage remains on the primary plane until the its
clip changes so that they are not obscured anymore.
The core uses this region to clear from the primary plane damage the
area that was repainted. If we add the old buffer damage to that, it
may end up clearing more damage from the primary plane than it was
intended.
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.
Jan Arne Petersen
Kristian Høgsberg
Richard Hughes
Chris Michael
Philipp Brüschweiler
Hardening
Jonas Ådahl
Rob Bradford
Giulio Camuffo
Peter Maatman
Rafal Mielniczuk
Siddharth Heroor
Pekka Paalanen
Rune K. Svendsen
Scott Moreau
Ander Conselvan de Oliveira
John Kåre Alsaker
Andre Heider