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 backports some changes to #319 to fix the screenshooter data
format. This also adds wlr_backend_get_renderer which will be
useful to support multiple renderers.
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.
Without this, a client will lose modifiers for one keyboard, when a key
is pressed on the other.
With this the client will always use the modifiers tate of the keyboard
the key was pressed on.
When DRM refreshed, wlr_output_set_mode is called. It would then call
the DRM set_mode callback which sends the updated matrix and mode info.
However once that call completed it would then immediantly send the
information again. This is handled poorly by xwayland, causing it to
scale up the clients twice.