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.
If we don't have a background image from the desktop-shell client or the
pointer for some other reason doesn't have a focus we trigger a
segfault as we try to deref the seat->pointer->focus NULL pointer.
https://bugs.freedesktop.org/show_bug.cgi?id=73066
This is still fairly unstable, causes lockups with fullscreen and exposay,
leaves small preview surfaces on-screen if used on the same modifier as
mod-tab. We also only need on mod-tab implementation so lets see if we
can consolidate the current and this alt-tab implementation in 1.5.
https://bugs.freedesktop.org/show_bug.cgi?id=72610
All the libexec programs are only built when BUILD_CLIENTS is true,
so we can just assign libexec_PROGRAMS under the condition. This lets us
drop most of the variable assignments and simplify it a bit.
https://bugs.freedesktop.org/show_bug.cgi?id=72812
Previously the option was --enable-demo-clients and the conditional was
ENABLE_DEMO_CLIENTS. They control whether or not we install the demo clients
(ie all other clients than weston-terminal and weston-info). Rename the
option and the conditional to better reflect this.
Popup windows are relative to a plain wl_surface, so that custom surfaces
can have popups. This used for the desktop-shell panel for example. Also,
popups should be immediately on top of their parent surface, as they
typically represent an extension of an UI element in the parent surface
such as a combo box or menu.
This reverts commit da704d97fa.
Conflicts:
desktop-shell/shell.c
https://bugs.freedesktop.org/show_bug.cgi?id=72547
If we don't mark the state as changed, we don't copy over next_state to
state and we fail to treat the surface as a transient. In particular,
we give it a random intial position instead of mapping it at the given
parent relative position.
https://bugs.freedesktop.org/show_bug.cgi?id=72532
Set the internal pointer for the client to NULL. This fixes a
segmentation fault at shutdown, where the shell would hang up before
and cause libwayland to call wl_client_destroy(). When the shell was
destroyed later, another call to wl_client_destroy() would cause the
crash.
https://bugs.freedesktop.org/show_bug.cgi?id=72550
Currently we destroy the renderer before the outputs are destroyed, but
that sometimes leads to an error since a reference to the renderer is
necessary in order to destroy a gl_renderer_output.
Since destroying the renderer is common among all backends, just move
that call into weston_compositor_shutdown() immediately after the
outputs being destroyed.
While the pixman image might be attached, the underlying buffer might be
already gone under certain circumstances. This is easily reproduced by
attempting to resize gnome-terminal on a fbdev backend.
$ WAYLAND_DEBUG=1 strace -emunmap weston --backend=fbdev-backend.so
...
[1524826.942] wl_shm@7.create_pool(new id wl_shm_pool@23, fd 40, 1563540)
[1524827.315] wl_shm_pool@23.create_buffer(new id wl_buffer@24, 0, 759, 515, 3036, 0)
...
[1524829.488] wl_surface@14.attach(wl_buffer@24, 0, 0)
[1524829.766] wl_surface@14.set_buffer_scale(1)
[1524829.904] wl_surface@14.damage(0, 0, 759, 515)
[1524830.248] wl_surface@14.frame(new id wl_callback@25)
[1524830.450] wl_surface@14.commit()
...
[1524846.706] wl_shm@7.create_pool(new id wl_shm_pool@26, fd 40, 1545000)
[1524847.215] wl_shm_pool@26.create_buffer(new id wl_buffer@27, 0, 750, 515, 3000, 0)
[1524847.735] wl_buffer@24.destroy()
[1524847.953] -> wl_display@1.delete_id(24)
[1524848.144] wl_shm_pool@23.destroy()
munmap(0xb5b2e000, 1563540) = 0
[1524849.021] -> wl_display@1.delete_id(23)
[1524849.425] wl_surface@14.attach(wl_buffer@27, 0, 0)
[1524849.730] wl_surface@14.set_buffer_scale(1)
[1524849.821] wl_surface@14.damage(0, 0, 750, 515)
<No commit yet, so drawing is attempted from older buffer that used to be
attached to the surface, which happens to come from a destroyed pool,
resulting it an invalid read from address 0xb5b2e000>
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Remove those listeners when the output is destroyed, otherwise they'll
point to invalid data that may lead to corruption when assigning a new
output for the view.
--
This is possibly related to bug 72845. I didn't have enough equipment
to try and reproduce it.
https://bugs.freedesktop.org/show_bug.cgi?id=72845
Record from the output of the surface that has keyboard focus for the
seat used to activate the recorder key binding. If there is no focused
surface, record from the first one.
Also, use the weston_transformed_region() to transform the damage
region of the output into the coordinates expected by read_pixels().
https://bugs.freedesktop.org/show_bug.cgi?id=71401
If the compositor hasn't been rendering for a while when the recording
stops, the time difference between the last rendered frame and that
moment won't be in the encoded video. Fix that by forcing one extra
frame to be recorded when the user presses the recorder key binding.
https://bugs.freedesktop.org/show_bug.cgi?id=71142
This client tests the wl_scaler and wl_surface_scaler protocol
extensions by cropping and then scaling a surface to ensure it is
rendered correctly. More details in comments in the code.
The pixman renderer doesn't use the weston_surface_to_buffer*
functions to alter coordinates depending on buffer transformation,
buffer scaling, and surface scaler (wl_surface_scaler).
pixman_transform_scale() is used instead to perform said
transformations without having to modify each coordinate.
Implements wl_surface_scaler.set by setting desired
src_{x,y,width,height} and dst_{width,height} values in the
weston_buffer_viewport struct, then altering coordinates in
weston_surface_to_buffer* functions if there is a scaler set for said
surface.
This registers the wl_scaler global object and lets clients create
wl_surface_scaler objects for surfaces. wl_surface_scaler.set is not
implemented so this doesn't really do anything useful yet.
Add cropping and scaling to wl_surface.
Add a global factory interface wl_scaler, which creates
wl_scaler_surface objects tied to a given wl_surface. The
wl_scaler_surface object can be used to set a cropping and scaling
transformation to change how a wl_buffer maps to wl_surface contents.
Changes in v2:
Take into account buffer_transform and buffer_scale, and try to explain
more clearly how the coordinate transformations work and what their
order is. Add, that crop and scale state is double-buffered. Explain
missing dst_x, dst_y. Clarify that undefined content still is some
content, but NULL buffer implies no content nor size.
Changes in v3:
Disallow zero values for dst_width and dst_height.
Open issues:
Should this be a separate interface like here, or just a wl_surface
request?
If we keep this as a separate interface, rename wl_surface_scaler to
wl_viewport.
Surfaces that are created by clients get their size automatically updated
by the attach/commit. Surfaces created directly by shells (such as black
surfaces) sometimes need to be manually resized. This function allows you
to do that while being somewhat less messy than messing with the internals
of weston_surface manually.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
If the saved position for a fullscreen or maximized output view is in an
output that has been unplugged, the coordinates don't make sense
anymore. In that case, invalidate them and use the initial position
algorithm when changing them back to the basic state.
Signed-off-by: Zhang, Xiong Y <xiong.y.zhang@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Previously, if a pointer was inside an output that was unplugged, it
could potentialy end up outside any valid output forever. With this
patch, the pointer is moved to the "closest" output to the pointer.
Set a flag when an output is being destroyed and use that to avoid
repainting. This allows functions that schedule an output repaint to
be called when the output is being destroyed without causing the
compositor to crash.
Use the output destroy signal to move the views in the event the output
was unplugged.
Signed-off-by: Zhang, Xiong Y <xiong.y.zhang@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Previously, when an output was moved due to another output being
unplugged, the views on the first output would remain in the same
position.
This patch adds an output_move signal that the views listen too in
order to repostion themselves in the event of an unplug.
Signed-off-by: Zhang, Xiong Y <xiong.y.zhang@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Instead of having the backends move the remaining outputs when one is
destroyed, let the core compositor deal with that.
Signed-off-by: Zhang, Xiong Y <xiong.y.zhang@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
When destroying ouputs, they would sometimes be removed before the call
to weston_output_destory() and sometimes after, depending on the
backend. Now the output is remove withing that function so the behavior
is standard across all backends.
We now no longer add joysticks at all. They show up as absolute motion
devices without has_button, so we don't add them as a pointer. We may add
a keyboard for the keyboard-style keys, but that's fine. With the previous
commit, we no longer generate spurious absolute pointer motion for the abs
axes.
https://bugs.freedesktop.org/show_bug.cgi?id=71687
Some joysticks have certain buttons that acts keyboard keys. As such,
we'll reconize them as keyboards but not pointers. In that case, don't
send pointer motion events when we get absolute joystick events.
This rule triggers for devices with an ABS_X/Y evaluators and no
keyboard or multitouch events. There is no way we would ever add such
a device as a pointer, keyboard or touch device anyway. A pointer
device requires has_button (in which case the !has_key condtion would
fail); a keyboard device would also mean !has_key is false and a touch
screen device implies that !device->is_mt is false.
Ricardo Vieira
Chris Michael
Kristian Høgsberg
Jason Ekstrand
Hardening
Ander Conselvan de Oliveira
Lubomir Rintel
Jonny Lamb
Pekka Paalanen
Zhang, Xiong Y