bi4k8

Possibly relatedly: other times, changing back to labwc's TTY causes all input devices to be lost. New ones do get picked up, and by plugging in a new keyboard, I...

Re: "key repeat sometimes broken for unknown reasons", I've also observed this, and have noticed that changing TTY to a console and back seems to resolve it. Still not sure...

I wasn't able to reproduce this behavior, using Wayland-native Chromium (`--enable-features=UseOzonePlatform --ozone-platform=wayland`) on a nested `labwc -c /dev/null` also from commit 35e24a6. Can you clarify: - the browser you used...

This is at least in part an imv bug; the below patch for imv treats a zero repeat interval as 1, which is wrong but prevents the crash: ```patch diff...

Apparently we set the key repeat rate to 0 whenever a keybind is activated: ```C static bool handle_keybinding(struct server *server, uint32_t modifiers, xkb_keysym_t sym) { struct keybind *keybind; struct wlr_keyboard...

I can give some guidance on implementing this if desired--sorry to have introduced merge conflicts with this!

I discovered today that this is also reproducible with regular Chromium, if you play about clicking and dragging bits of text in web pages. Backtrace: ``` Thread 1 "labwc" received...

Debugging this now. It looks like the `struct wlr_drag`'s `seat_client` field is freed out from under it in `seat_client_handle_resource_destroy`. That function unsets a number of pointers in the seat that...

Filed wlroots bug [#3353](https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3533) and PR [!3858](https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3858).

Upstream PR merged. I guess we can leave this open until a wlroots release with the fix comes out.