Title can decide the geometry of a frame because it may affect the
existence of titlebar, so setting geometry_dirty in frame_set_title for
potential change.
Signed-off-by: Boyan Ding <stu_dby@126.com>
There exist frames which have buttons without title such as a simple
X application piped through xwayland which doesn't specify a title.
We draw the title bar with buttons, but hide it under the window
because geometry thinks a window needs titlebar only if it has title.
This patch change the condition, making it titlebar is needed if a
frame has title or has button(s), which makes more sense.
Signed-off-by: Boyan Ding <stu_dby@126.com>
Commit 9aa8ce69 forgot to set shsurf->fullscreen_output in
fullscreen_binding(), causing segfault when fullscreening using key
bindings. This patch fixes that.
https://bugs.freedesktop.org/show_bug.cgi?id=79828
Signed-off-by: Boyan Ding <stu_dby@126.com>
I've updated this based on comments, simplifying the command handling.
Currently the screen-share module uses a hard-coded command to start the
fullscreen shell server. This patch causes the module to read the command from
the weston config file (from the "command" key in the "screen-share" section).
The default value remains the same (i.e. to run weston with the RDP backend and
fullscreen shell), but is now located in the weston config file.
As well as allowing the arguments to the fullscreen shell server to be changed,
this also permits an alternative fullscreen shell server to be used if required,
without needing to recompile. Since the command is run as the user running
weston, this should not pose any additional security risk.
Signed-off-by: Andrew Wedgbury <andrew.wedgbury@realvnc.com>
Previoiusly, we had a mess of logic that was repeated with one of the
repeats negated. Not only was this unnecisaraly confusing, but it
segfaulted and one of the negations was wrong. This cleans the whole mess
up and should fix bug #79725.
No functional changes, just adjusting for API changes in libinput:
- libinput_destroy() replaced by libinput_unref()
- log functions now take a libinput context, userdata is gone
- udev seat creation is now libinput_udev_create_context() and
libinput_udev_assign_seat()
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It turns out that flipped-270 is the second-simplest transformation besides
normal because it is a direct swapping of the x and y axes. Having that as
the default encourages people to use flipped-270 as the default test for "I
want to try this with a transform". Unfortunately, because flipped-270 is
so simple, it is really easy to have something that works for normal,
flipped-270, and nothing else. This encourages people to test with a
transform thats actually "hard".
In many clients of weston, Display was not being destroyed so added it.
Also destroy windows, widgets which were not being destroyed.
Signed-off-by: vivek <vivek.ellur@samsung.com>
Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Fixes a crash on touch devices without a pointer, when touching
the window frame of a client.
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
sizeof returns size_t, for which the correct printf specifier is %zu.
Fixes the following warning when building for ARMv7.
src/compositor-wayland.c: In function 'wayland_output_get_shm_buffer':
src/compositor-wayland.c:260:3: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'unsigned int' [-Wformat=]
weston_log("could not zalloc %ld memory for sb: %m\n", sizeof *sb);
^
Signed-off-by: Thierry Reding <treding@nvidia.com>
When running the autogen.sh script, libtoolize complains thusly:
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Silence the warnings by following libtoolize's advice.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Animations are run off the repaint cycle so if there's nothing to
repaint, an animation will stop running. This is usually not a problem
as each frame function of an animation causes something to change and
therefore a repaint to happen. This patch helps detect when the
animation isn't in said case and triggers a repaint to keep the
animation running.
This problem was found by using weston_move_scale_run() to move a view
onscreen from completely off. The very first time the animation frame
function was called the progress wasn't enough to move it into
view. The compositor saw there was nothing to repaint and stopped
doing anything else. When something else (like a pointer move) forced
a redraw, the view's position was very much onscreen and jumped into
view in an ugly way.
Commit a7592019 introduced an optimization that caused some
exposay struct members to not be properly initialized, particularly
cur_output, leading to crashes in some circumstances (e.g. pressing
the down arrow key after going to exposay).
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
Both weston_move_scale_run() and weston_slide_run() were broken in
commit 3a869019. Commit a4a6f161 fixed and explained the problem for
weston_slide_run() but weston_move_scale_run() remained broken.
To fix weston_move_scale_run(), weston_view_animation_run() is also
required. It was removed when _run() was split into two functions
_create() and _run() in commit f5cc2b56, but _run() was not added in
this commit.
This is to avoid recursing into weston_compositor_build_view_list()
and therefore fix crashing when destroying a stack of visible subsurfaces
due to weston_compositor_build_view_list() being called recursively
and corrupting the lists it works on.
https://bugs.freedesktop.org/show_bug.cgi?id=79684
This allows for easily testing a compositor's damage tracking in all
currently available configurations including wl_surface.buffer_transform,
wl_surface.buffer_scale, and wl_viewport. It also includes a
--rotating-damage that flag instructs the client to change the
wl_surface.buffer_transform on every commit. This tests the compositor for
proper handling of texture uploads even when the transform has changed but
the buffer size hasn't.
Also update configure.ac to require libinput 0.3 when enabled, as it is
the version where double replaced li_fixed_t.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Post release bump. The master branch version is always x.y.90,
where x.y is the most recent stable branch. This lets other packages
rely on git master as opposed to 1.5.0.
wl_list_for_each dereference's output to increment the
next iteration of the loop. However, output is free'd
inside the loop resulting in a dereference to free'd
memory.
Use wl_list_for_each_safe instead, which is designed to
handle this kind of pattern.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Once we've updated the window state and scheduled a resize, we know that
the next frame we send to the compositor will match the configured state.
This means we can just ack the configure immediately and not jump
through hoops to try to do it from the redraw stage.
As the protocol says, the states determine how the width and height
arguments should be interpreted, so it makes logical sense to do the
interpretation after.
With most of the code in send_configure_for_surface, the helper
methods don't give us that much benefit, so stop using them. We
can't kill them off, as they're part of the shell interface and
used by the WM.
Currently, there's a giant bug in how xdg-shell state management
is done. If a client calls set_fullscreen and then set_maximized,
it will get two configure events:
=> set_fullscreen
<= configure(800, 600, [STATE_FULLSCREEN])
=> set_maximized
<= configure(800, 560, [STATE_FULLSCREEN, STATE_MAXIMIZED])
Since fullscreen takes precedence over maximized, the client will
render full-screen at 800x600 first, and then 800x560 next. As
a result, the surface gets the wrong size.
This is because the code that sends out configure requests is
"immediate" -- when an app calls set_maximized, we immediately
send out the configure event that would have happened if we
transitioned immediately into maximized mode.
In wl_shell, this is correct behavior. However, in xdg-shell,
this is wrong. State needs to be more carefully managed in
xdg-shell, as states aren't exclusive.
Pull all the code that sends out configure events out and send
them centrally, based on Weston's on surface state management.
This should work with both wl_shell and xdg_shell's strategies.
Add a new state_changed_handler callback to the window to know when the
window has changed state; the terminal will use this to know when the
window started and ended its resize operation, and modify the terminal's
titlebar accordingly.
Currently, there's a race condition. When resizing from the left, and
a client attaches a buffer after the resize ends, you suddenly see the
buffer jump to the right, because the resize ended while multiple
attaches were in-flight. Making resize a state can fix this, as the
server can now know exactly when the resize ended, and whether a commit
was before or after that place.
We don't implement the correct tracking in this commit; that's left as
an exercise to the reader.
Additionally, clients like terminals might want to display resize popups
to display the number of cells when in a resize. They can use the hint
here to figure out whether they are resizing.
The states system, so far, has been a complicated mix of weird APIs
that solved a real race condition, but have been particularly ugly
for both compositors and clients to implement.
It's a confusing name that comes from the ICCCM. The ICCCM is best
forgotten about.
With the addition of the potential new "transient" role meaning a
parent-relative toplevel like a long-lived popup, used for e.g.
tooltips, the set_transient_for name will become even more confusing.
xdg-shell mandates that the FULLSCREEN state means that we must match
the size that we were configured to, at least by default. Other states
or protocol extensions might relax this requirement, but at least for
now implement the behavior specified in the protocol documentation.
Toytoolkit was not designed to handle input from subsurfaces and
instead it expects subsurfaces to have an empty input region. That way
input events for subsurfaces are generated on the main surface and
there is no need to convert coordinates before reporting the event to
the user.
However it is possible that a subsurface has a non-empty input region,
but in that case those events aren't properly processed. The function
window_find_widget() assumes the coordinates are in the main surface
coordinate space, and ends up chosing the wrong widget.
This patch changes the input code to completely ignore input events from
subsurfaces. This option was chosen instead of ensuring that the input
region on those surfaces is always empty since there's no enforcement
that a subsurface should completely overlap with the main surface. If
an event happens in the area of the surface that doesn't overlap, the
event could cause a completely unrelated surface to be picked.
https://bugs.freedesktop.org/show_bug.cgi?id=78207