The grab stays alive as long as at least one touch point is down. If touch
point 0 is lifted while other touch points are down, the surface will jump
around when touch point 0 is put down again.
This change marks the grab as inactive once touch point 0 is lifted
and then ignores touch events until all touch points eventually are
lifted and the grab terminates.
https://bugs.freedesktop.org/show_bug.cgi?id=73750
The opaque region is in surface coordinates, which we compare to the
output region, which is in compositor coordinates. For non-primary
outputs, that means that the output region is not located at 0,0 but
something like 1920,0 instead. That means that the output region isn't
contained in the surface opaque region and then we decide we can't scan
out from it.
Instead, compare the surface opaque region to the output region
translated to 0,0.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=7348i5
Handles potential out of memory situation by skipping the title update.
This fixes the following warning:
terminal.c: In function ‘resize_handler’:
terminal.c:851:11: warning: ignoring return value of ‘asprintf’,
declared with attribute warn_unused_result [-Wunused-result]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Add a config file option to enable it, but leave it off by default. Exposay
still triggers too many lock-ups or stuck grabs and triggers under X even
when the Wayland window doesn't have keyboard focus.
This fixes a regression caused by either 918f2dd4 or da75ee1d. In
particular, if a client called commit without attaching a buffer and if the
compositor had already released its reference to the buffer, then a size of
0x0 would be set on the surface. In particular, this affects the wayland
backend because it frequently sends only a frame request in order to cause
a refresh.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
There's a small window between the input method (eg the on-sreen keyboard)
receiving the deactivate and destroying the context, where the keyboard may
send requests, which we forward to the destroyed input method. Fix this
by setting the contexts model to NULL right away and then avoid sending
events if context->model is NULL.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69490
If we destroy a window with an active tooltip, we leave the tooltip
hanging around. Call tooltip destructor when destroying a window.
This fixes the stuck tooltip observed when unplugging a monitor with
an active tooltip on the panel.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=72931
We now track the child surfaces of a shell surface and the child surfaces
have a pointer back to their parent. We need to clean all this up and
NULL out the childrens parent pointers when a shell surface is destroyed.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=72931
The keyboard is too chatty, make it use a dbg() function for logging
which defaults to disabled.
Also drop a noisy fprintf() in input_panel_configure().
strncat() into a newly allocated buffer isn't well-defined. I don't know
how this didn't crash all the time, getting blocks from malloc() with
a NUL in the first byte must be fairly common.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=71750
It's possible to touch a surface to move it and let go before we get
to common_surface_move(), in which case we don't have a touch focus
when we get there. For pointers, we could click a surface, but have the
surface go away before we get to common_surface_move(), in which
case the button count is non-zero, but we don't have a surface.
In either case we crash, so let's add a check to make sure we still
have a focus surface before we try to move it.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=73448
The subsurfaces example creates a subsurface widget and uses EGL to
render to it directly rather than using the cairo context from the
widget. In theory this shouldn't cause any problems because the westoy
window code lazily creates the cairo surface when an application
creates a cairo context. However commit fdca95c7 changed the behaviour
to force the lazy creation at the beginning of each surface redraw.
This ends up making the triangle surface get two attaches – one from
Cairo and one from the direct EGL.
It looks like it would be difficult to reinstate the lazy surface
creation behaviour whilst still maintaining the error handling for
surface creation because none of the redraw handlers in the example
clients are designed to cope with that. Instead, this patch adds an
explicit option on a widget to disable creating the Cairo surface and
the subsurface example now uses that.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=72854
This fixes the crash when move, rotate or resize binding is activated
while exposay effect is active.
Steps to reproduce:
- activate exposay
- try to rotate the surface with mod + right mouse button
- crash
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=72885
This patch fixes an issue where Weston using the DRM backend, cannot start
the display. This happens in the following context:
- no video mode is set before weston starts (eg no "/dev/fb" set up)
- weston is not configured with any default video mode (nothing from
weston.ini nor command line)
- the DRM driver provides with a list of supported modes, but none of them
is marked as PREFERRED (which is not a usual case, but it happens)
In that case, according to the current implementation, the DRM compositor
fails to set a video mode.
This fix lets the DRM compositor selects a video mode (the best one of the
list, which is the first) from the ones provided by the driver.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
weston_xkb_info_create() takes ownership of the xkb_keymap instance so
we should drop our reference or we would leak it later if the keymap
was changed.
This seems like a better name, and will not conflict if someone later
extends wl_surface with a request scaler_set (yeah, unlikely).
This code was written by Jonny Lamb, I just diffed his branches and made
a patch for Weston.
Cc: Jonny Lamb <jonny.lamb@collabora.co.uk>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This patch fixes the compiler errors:
CC weston_test_la-weston-test.lo
weston-test.c:34:21: fatal error: EGL/egl.h: No such file or directory
CC buffer-count-test.o
buffer-count-test.c:30:21: fatal error: EGL/egl.h: No such file or directory
On rpi, the EGL headers are not in the standard path.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
screenshooter.c: In function ‘recorder_binding’:
screenshooter.c:509:5: warning: ‘listener’ may be used uninitialized in
this function [-Wuninitialized]
This was not really a problem so far, because the variable was
uninitialized only in the case where Weston had no outputs.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Comment #2 in the bug report says Mesa 10.0 branch does not have the
fix, and indeed buffer-count test fails on Mesa 10.0.1. Fix the test to
require Mesa 10.1 or later.
Now I correctly get:
mesa version too old (OpenGL ES 3.0 Mesa 10.0.1 (git-12484d2))
https://bugs.freedesktop.org/show_bug.cgi?id=72835
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
With multiple touch screens on one seat, the touch points IDs from the
different evdev devices may overlap. We have to remap the IDs we forward
to core weston so that the touch points all have unique IDs within the seat.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=73003
We were calling exposay_highlight_surface() inside a wl_list_for_each
loop for a layer, but exposay_highlight_surface() calls activate()
which calls shell_surface_update_layer(), which removes the surface
from its layer and reinserts it, causing an infinite loop.
Call exposay_highlight_surface() outside the for_each to avoid this.
https://bugs.freedesktop.org/show_bug.cgi?id=72404
Similar to 7c4f6cc145, if we don't have
a background image from the desktop-shell client or the touch point
for some other reason doesn't hit a surface we trigger a
segfault as we try to deref the seat->touch->focus NULL pointer.
For touch, another problem could be fudgey calibration that ends up
giving touch coordinates outside the output space.
https://bugs.freedesktop.org/show_bug.cgi?id=72839
Set up X windows that are transient for another window as transient
surfaces in shell.c. This keeps the transient windows on top of their
parent as windows are raised, lowered for fullscreened.
https://bugs.freedesktop.org/show_bug.cgi?id=69443
If we fail to allocate space for a new drm_sprite, then we should
properly call drmModeFreePlane (not free) to release the drm plane.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If a surface is not on any output, scheduling a repaint for it is a no-op.
weston_view_schedule_repaint() schedules repaints for all outputs that
overlap with the surface extents, but if the surface is completely
outside all outputs nothing will be scheduled. Fix this for now by starting
the slide slightly into the output.
The input-panel codes tries to see determine if a buffer has not yet
been attached (or a NULL buffer has been attached), and doesn't map
the input panel surface yet in that case. However, it test for
buffer_ref being NULL, which can happen for other reasons. The right
test is to see if surface->width is 0, which means that either a
buffer hasn't yet been attached or a NULL buffer has been attached.
https://bugs.freedesktop.org/show_bug.cgi?id=72519
If we're not currently showing the input panels, we still need to set the
panel position so that it's set when we later need to show them. This fixes
the initial flicker of the input panel in the wrong position when we first
show it.
Kristian Høgsberg
Axel Davy
Bryce W. Harrington
Wieland Hoffmann
Jason Ekstrand
Neil Roberts
Rafal Mielniczuk
Fabien DESSENNE
Rui Matos
Pekka Paalanen
Emilio Pozuelo Monfort
Armin K
Ricardo Vieira
Chris Michael