wlroots seems to 'eat' the first key stroke with clients like foot, (unless you move the mouse first)
This is really evident when pairing cage/foot. I thought it was a cage issue, but it seems that it is more common to wlroots in general as I can replicate similar behavior in labwc and wayfire if the first client is a terminal prompt.
What happens is that if you start cage/foot with the DRM backend (not x11/wayland nested), foot's cursor appears to be an empty rectangle (implying there is no keyboard focus). Hit a key, and the cursor appears, and it gains focus, but foot doesn't get this keystroke.
Attempt to start a new instance of cage/foot again, and bump the mouse first, and it also then appears to gain focus, and the first key you get, foot gets the keystroke
It's hard to explain because I am not familiar with wlroots, but I think I loosely know what is happening
Cage's handle_new_input
which gets set up here to run on &backend->events.new_input
https://github.com/cage-kiosk/cage/blob/e7d8780f46277af87881e0be91cb2092541bb1d5/seat.c#L871
eventually calls its update_capabilities
https://github.com/cage-kiosk/cage/blob/e7d8780f46277af87881e0be91cb2092541bb1d5/seat.c#L114
to call wlr_seat_set_capabilities
I tried to patch the create_seat
function to call update_capabilities
, but that didn't work, it only works after the first input event... Not sure what the fix is for that though