Up until now, wlr_backend_autocreate() created the wlr_session and
then stuffed it into struct wlr_multi_backend so that compositors
can grab it later.
This is an abuse of wlr_multi_backend and the wlr_backend API:
wlr_backend_get_session() and wlr_multi_backend.session only exist
to accomodate the needs of wlr_backend_autocreate(). What's more,
the DRM and libinput backends don't implement
wlr_backend_impl.get_session.
Instead, return the struct wlr_session to the compositor in the
wlr_backend_autocreate() call. wlr_backend_get_session() will be
removed in the next commit.
With protocol additions such as [1], compositors currently have no
way to opt out of the version upgrade. The protocol upgrade will
always be backwards-compatible but may require new compositor
features.
The status quo doesn't make it possible to ship a protocol addition
without breaking the wlroots API. This will be an issue for API
stabilization [2].
To address this, let compositors provide a maximum version in the
function creating the global. We need to support all previous versions
of the interface anyways because of older clients.
This mechanism works the same way as Wayland clients passing a version
in wl_global.bind.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3514
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1008
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3397
Running with WLR_BACKENDS=headless, there is no keyboard device.
Avoid crashes like so:
../tinywl/tinywl.c:136:2: runtime error: member access within null pointer of type 'struct wlr_keyboard'
../tinywl/tinywl.c:136:2: runtime error: member access within null pointer of type 'struct wlr_keyboard'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==331107==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000120 (pc 0x556ed03e4e99 bp 0x7ffce834bc10 sp 0x7ffce834bbb0 T0)
==331107==The signal is caused by a READ memory access.
==331107==Hint: address points to the zero page.
#0 0x556ed03e4e99 in focus_view ../tinywl/tinywl.c:136
#1 0x556ed03eb3be in xdg_toplevel_map ../tinywl/tinywl.c:603
#2 0x7f75d6f768db in wlr_signal_emit_safe ../util/signal.c:29
#3 0x7f75d6e9cac7 in xdg_surface_role_commit ../types/xdg_shell/wlr_xdg_surface.c:315
#4 0x7f75d6eb6944 in surface_commit_state ../types/wlr_compositor.c:466
#5 0x7f75d6eb7b02 in surface_handle_commit ../types/wlr_compositor.c:523
#6 0x7f75d5714d49 (/usr/lib/libffi.so.8+0x6d49)
#7 0x7f75d5714266 (/usr/lib/libffi.so.8+0x6266)
#8 0x7f75d68cb322 (/usr/lib/libwayland-server.so.0+0xd322)
#9 0x7f75d68c65cb (/usr/lib/libwayland-server.so.0+0x85cb)
#10 0x7f75d68c91c9 in wl_event_loop_dispatch (/usr/lib/libwayland-server.so.0+0xb1c9)
#11 0x7f75d68c6d36 in wl_display_run (/usr/lib/libwayland-server.so.0+0x8d36)
#12 0x556ed03eef55 in main ../tinywl/tinywl.c:905
#13 0x7f75d5d2330f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)
#14 0x7f75d5d233c0 in __libc_start_main@GLIBC_2.2.5 (/usr/lib/libc.so.6+0x2d3c0)
#15 0x556ed03e46e4 in _start (/home/simon/src/wlroots/build/tinywl/tinywl+0x136e4)
This doesn't work if scene outputs are not used as the primary output of
scene surfaces will always be NULL.
Therefore, take a wlr_scene_output instead of separate wlr_scene and
wlr_output arguments and rename the function to
wlr_scene_output_send_frame_done().
The actual behavior of the function is unchanged.
When using `meson --buildtype=release`, `-Wextra -Werror` is passed.
This includes `-Werror=maybe-uninitialized`, which complains about
the instances fixed in this commit.
If a NULL xkb_rule_names pointer is passed to
xkb_keymap_new_from_names, libxkbcommon will default to reading
the XKB_* env variables. So there's no need to do it ourselves.
Also s/xkb_map_new_from_names/xkb_keymap_new_from_names/ since the
latter is more consistent with the returned struct name.
[1]: https://xkbcommon.org/doc/current/structxkb__rule__names.html
Previously, when dragging the left border of a window with the mouse in tinywl,
there was a bug where it snap the top level surface's geometry X coordinate
directly to the position of the mouse, as if you started the resize right on the
border. This also affected the other (right, top and bottom) borders.
I think that the previous resize code was hard to understand. Honestly I
have not spent a lot of time trying to understand why it didn't work and
I wrote another resize algorithm instead: now, instead of working directly
with widths and heights which are complicated, we work with the borders (left,
right, top, bottom). This is easier to understand IMO.
Note: I originally fixed this [in the waybox compositor](https://github.com/wizbright/waybox/pull/23) but
then I realized that the code was taken from tinywl and that it had the same
issues so I copied my fix for tinywl.
While trying out the tinywl code, I found that the resize mode was behaving
weirdly ... so I looked into code. Turns out the `begin_interactive` method
stores the cursor position plus the geo_box position; however,
`process_cursor_resize` wasn't taking this into account, causing windows to
jump down in size unexpectedly when resized and lose alignment with the cursor.
To fix this, I simply added a member to the `tinywl_server` struct that stores
the geo_box when the mouse enters grab mode, and I referenced that data in the
resize method. I considered polling for this data every time instead of storing
it in the server struct, but 1) since changes in this value are not relevant
and 2) it could potentially decrease performance (I don't know enough about
wlroots to know how much) I decided to just store it. I can change this if
desired.
Kirill Primak
Alexander Orzechowski
Simon Ser
Simon Zeni
Isaac Freund
Alexander Orzechowski
xiaoyaobing
Leonardo Hernández Hernández
Quantum
Elyes HAOUAS
Isaac Freund
Greg Depoire--Ferrer
Kalyan Sriram