The commit 'input: Send leave and enter pair when the surface moves
under the cursor' introduced focused surface local pointer coordinates
to keep track of if a surface had been moved or transformed in a way
that the pointer posititon relative to that surface would change.
Update these coordinates also for the popup grab as otherwise every
pointer motion during a popup grab results in leave and then enter
events.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
At the calculation of the first FPS, gears has initialized last
FPS time with gettimeofday().
But the callback_data passed in the callback of wl_surface_frame()
is the current time, in milliseconds, with an undefined base.
Because of this subtracting last FPS time from callback_data makes no sense.
For example, below is the result of running weston-gears on weston with
drm backend:
$ weston-gears
Warning: FPS count is limited by the wayland compositor or monitor refresh rate
1 frames in 1094460.125 seconds = 0.000 FPS
301 frames in 5.016 seconds = 60.008 FPS
301 frames in 5.016 seconds = 60.008 FPS
301 frames in 5.016 seconds = 60.008 FPS
As you can see, the the first FPS value is something odd.
This patch fixes it by initializing last FPS time with the callback_data passed in
the first callback.
Reviewed-by: Nils Chr. Brause <nilschrbrause@gmail.com>
At the moment when surfaces are destroyed they are faded out but let's
make it configurable!
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This option is so we can disable showing any panel at all. The default
is to continue showing the panel and no example is added to weston.ini
because it's an uncommon request.
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Enable by adding the following to your weston.ini:
[libinput]
enable_tap=true
This also makes weston require libinput >= 0.5.0.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
An error makes the client exit, which cleans up the resources anyway.
Note (Jason Ekstrand):
This is safe for two reasons. First, we should be handling object
destruction nicely anyway. Second, in each of these cases, the resources
don't have any implementation or destruction set so it has absolutely no
effect on the rest of weston whether we destroy it now or later.
If we're fading a view with weston_fade_run() and half way through we
want to unfade it we can use weston_fade_update() to set a new alpha
target. When the animation finishes, reset_alpha() is called which
ensures the alpha value of the view is exactly as requested.
Although weston_fade_update() was updating the spring target so the
animation would look fine, it would then reset to the alpha target
given in the first call to weston_fade_run().
It looks like that in the great conversion introducing weston_view, one
conditional was forgotten from the code that builds the global flat list
of views. Sub-surfaces are added to the view list specially, as they are
not governed by their presence in a layer's view list, and therefore
need an explicit check for mappedness.
The bug, missing the explicit check, caused sub-surfaces to enter the
global view_list regardless of their state. This lead to the pointer
focus picking code processing them, and as the input region defaults to
infinite, picking these unmapped surfaces. Clients then get confused
about the wl_pointer.enter events with unexpected wl_surface.
To trigger this issue, it is enough to just create one additional
wl_surface and make it a sub-surface of a main surface that is or gets
mapped. Literally, just a wl_subsomcpositor_get_subsurface() call is
enough. At some point later, the unmapped sub-surface will get pointer
focus, depending on view stacking order.
Fix the issue by adding a is_mapped check when building the view_list.
Note, that 95ec0f95aa accidentally also
prevents this bug from happening, because it adds a test against the
transform.masked_boundingbox in weston_compositor_pick_view().
Reported-by: George Kiagiadakis <george.kiagiadakis@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Init cursor size to 64x64 if drmGetCap() fails.
Use Mesa GBM_BO_USE_CURSOR define (which removes 64x64 restriction)
Signed-off-by: Alvaro Fernando García <alvarofernandogarcia@gmail.com>
If a client does this:
1. create a main window and map it
2. create a wl_surface, and make it a sub-surface of the main window
3. set the sub-surface to desync
4. commit content to the sub-surface to map it
Then step 4 should cause the sub-surface to become mapped. However,
Weston fails to schedule a repaint in that case, so the sub-surface will
not appear until something else causes a repaint on that output, e.g.
the main window.
A quick and dirty fix is to set the output mask for the surface in
Weston, which allows the repaint to be scheduled. This patch implements
that, and might only work right on single-output systems.
A proper fix would involve rewriting the whole "is surface mapped"
mechanism in Weston, to not rely on output assignments but to have a
separate flag for "mapped", and figuring out how to schedule repaints
for the right outputs.
Following is the actual protocol sequence used to trigger the problem:
[3224648.125] -> wl_compositor@4.create_surface(new id wl_surface@3)
[3224648.206] -> xdg_shell@7.get_xdg_surface(new id xdg_surface@8, wl_surface@3)
[3224648.311] -> xdg_surface@8.set_title("simple-shm")
[3224648.378] -> wl_surface@3.damage(0, 0, 250, 250)
[3224649.888] -> wl_shm@6.create_pool(new id wl_shm_pool@9, fd 6, 250000)
[3224650.031] -> wl_shm_pool@9.create_buffer(new id wl_buffer@10, 0, 250, 250, 1000, 1)
[3224650.244] -> wl_shm_pool@9.destroy()
[3224651.975] -> wl_surface@3.attach(wl_buffer@10, 0, 0)
[3224652.100] -> wl_surface@3.damage(20, 20, 210, 210)
[3224652.243] -> wl_surface@3.frame(new id wl_callback@11)
[3224652.317] -> wl_surface@3.commit()
[3228652.535] -> wl_compositor@4.create_surface(new id wl_surface@12)
[3228652.610] -> wl_subcompositor@5.get_subsurface(new id wl_subsurface@13, wl_surface@12, wl_surface@3)
[3228652.644] -> wl_subsurface@13.set_desync()
[3228652.659] -> wl_subsurface@13.set_position(100, 100)
[3228654.090] -> wl_shm@6.create_pool(new id wl_shm_pool@14, fd 6, 250000)
[3228654.140] -> wl_shm_pool@14.create_buffer(new id wl_buffer@15, 0, 250, 250, 1000, 1)
[3228654.180] -> wl_shm_pool@14.destroy()
[3228654.408] -> wl_surface@12.attach(wl_buffer@15, 0, 0)
[3228654.436] -> wl_surface@12.damage(0, 0, 250, 250)
[3228654.462] -> wl_surface@12.commit()
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: George Kiagiadakis <george.kiagiadakis@collabora.com>
Cc: Jason Ekstrand <jason.ekstrand@intel.com>
If X windows are created and destroyed very fast sometimes the WM window
object gets created and destroyed before we get around to handling client
messages. Failing to check that the window is still valid can result in a
segfault.
When Xwayland requests that a wl_surface be created and the X event is
handled before the wayland requests, a surface ID is stored to
window->surface_id and the window is added to the unpaired window list. When
weston_wm_create_surface is called, the window is removed from the list and
window->surface_id is set to zero. If window->surface_id is not zero when
weston_wm_window_destroy is called, the window is assumed to be in the
unpaired window list and wl_list_remove is called. If
weston_wm_window_handle_surface_id is called and the surface has already
been created, the window is not added to the unpaired window list, but
window->surface_id isn't set to zero. When the window is destroyed, removing
the window from the list is attempted anyway and a crash occurs.
This patch stores the surface ID in a temporary variable and only assigns it
to window->surface_id when the window is added to the unpaired window list.
Otherwise window->surface_id is set to zero to maintain its use as a flag
variable.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=80273
Signed-off-by: Tyler Veness <calcmogul@gmail.com>
this adds a mechanism to mask the views belonging to a layer
to an arbitrary rect, in the global space. The parts that don't fit
in that rect will be clipped away.
Supported by the gl and pixman renderer only for now.
This introduces a new struct, weston_layer_entry, which is now used
in place of wl_list to keep the link for the layer list in weston_view
and the head of the list in weston_layer.
weston_layer_entry also has a weston_layer*, which points to the layer
the view is in or, in the case the entry it's the head of the list, to
the layer itself.
With expect_protocol_error, we need a possibility to wait for a frame
without aborting the test when wl_display_dispatch returns -1;
This patch adds function frame_callback_wait_nofail that only
returns 1 or 0 (instead of aborting on error).
Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com>
This function checks if a particular protocol error came in wire.
It's usefull in the cases where we hitherto used FAIL_TEST.
The problem with FAIL_TEST is that *any* assert will pass the test,
but we want only some asserts to pass the test (i. e. we don't
want the test to pass when it, for example, can't connect to display).
FAIL_TESTs are good only for sanity testing.
The expect_protocol_error allows us to turn all FAIL_TESTs to TESTs
as will be introduced in following patches.
v2: fixed white-space error and a mistake in comment
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com>
Currently, there is a fun flicker when toggling maximization or
fullscreen on a window in mutter or more sophisicated compositors
and WMs.
What happens is that the client want so go maximized, so we
calculate the size that we want the window to resize to (640x480),
and then add on its margins to find the buffer size (+10 = 660x500),
and then send out a configure event for that size. The client
renders to that size, realizes that it's maximized, and then
says "oh hey, my margins are actually 0 now!", and so the compositor
has to send out another configure event.
In order to fix this, make the the configure request correspond to
the window geometry we'd like the window to be at. At the same time,
replace set_margin with set_window_geometry, where we specify a rect
rather than a border around the window.
This new structure is used for both weston_surface.pending and
weston_subsurface.cached.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com>
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>
