The wlr_drm_surface_init function is called (upon others) when the drm
mode is changed.
When the surface was used previously this replaced the gbm_surface, but
did not replace the gbm buffers (front/back).
With this, wlr_drm_surface_get_from never set up the new buffers with
the new glViewport because surf->front existed.
This frees the buffers to get new buffers on the new surface with the
new viewport.
Right now, we are adding systemd and elogind backends to the build
system as soon as their libraries are found on the build system.
Instead, we should only add them if the libraries have been found _and_
the user has actually requested them to be included.
Recently, the support for building rootston without XWayland was broken.
While the breakage was easily fixable, the more important problem is
that actually nobody seems to ever compile wlroots without XWayland,
causing silent breakage. This problem can easily be handled by the CI
system: in addition to the existing job which enables XWayland, add a
second job which compiles wlroots without XWayland. This will catch
breakage at a much earlier stage.
Catching broken builds without XWayland support obviously only covers
one part of a greater issue, as all the other options may cause our
builds to break, too. While we cannot test each combination, we can at
least make sure to have one build with all options enabled and one with
all options disabled.
The XWayland code for creating the cursor as well as creating the
surface itself are currently split up into two ifdef'ed sections in
`desktop_create()`. Move together these two sections in order to avoid
having multiple ifdefs as well as making it clearer that they do in fact
serve the same purpose of setting up the XWayland environment.
In case wlroots is not being compiled with XWayland support, we will not
have an xwayland surface in our roots view. While we make sure to pay
attention to that in some places, we are not being consistent and try to
access the xwayland surface in other places. Obviously, this leads to a
compiler error due to the field not being present.
Fix the issue by sprinkling in a few additional ifdefs where required.
since we're looking at pointer differences.
Otherwise the build fails on arm like
In file included from ../backend/drm/drm.c:19:0:
../include/wlr/util/log.h:34:17: error: format '%jd' expects argument of type 'intmax_t', but argument 7 has type 'int' [-Werror=format=]
_wlr_log(verb, "[%s:%d] " fmt, _strip_path(__FILE__), __LINE__, ##__VA_ARGS__)
^
../backend/drm/drm.c:462:2: note: in expansion of macro 'wlr_log'
wlr_log(L_DEBUG, "%s: crtc=%ju ovr=%jd pri=%jd cur=%jd", conn->output.name,
^~~~~~~
../backend/drm/drm.c:462:39: note: format string is defined here
wlr_log(L_DEBUG, "%s: crtc=%ju ovr=%jd pri=%jd cur=%jd", conn->output.name,
~~^
%d
keymap_size is a size_t. Otherwise the build fails on arm like
../types/wlr_keyboard.c: In function 'wlr_keyboard_set_keymap':
../include/wlr/util/log.h:34:17: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Werror=format=]
_wlr_log(verb, "[%s:%d] " fmt, _strip_path(__FILE__), __LINE__, ##__VA_ARGS__)
^
../types/wlr_keyboard.c:218:3: note: in expansion of macro 'wlr_log'
wlr_log(L_ERROR, "creating a keymap file for %lu bytes failed", kb->keymap_size);
^~~~~~~
../types/wlr_keyboard.c:218:50: note: format string is defined here
wlr_log(L_ERROR, "creating a keymap file for %lu bytes failed", kb->keymap_size);
~~^
%u
This decouples wlr_output_enable and the wl_global.
The previously internal functions wlr_output_(destroy/create)_global are
exposed and used automatically in the wlr_output_layout to create/tear
down the global.
The compositor can handle them itself if it wants to, but I think this
is the right moment to create/destroy the wl_output when the
wlr_output_layout is used.
Markus Ongyerth
Drew DeVault
emersion
Patrick Steinhardt
Guido Günther
Vincent Vanlaer
Tony Crisci
Timidger
Johannes Schramm