wtype not working in xwayland on labwc 0.7.2 about labwc HOT 13 CLOSED

Hi Consolatis. This bug is a show-stopper for me because it breaks numerous of my keyboard shortcuts, so I rolled up my sleeves and did a git bisect.

The bad commit is cafdcd8. If I go back to 097ac44, wtype works just fine in xwayland windows.

I hope this helps fix the bug.

from labwc.

I guess moving wlr_seat_set_keyboard(seat->seat, &seat->keyboard_group->keyboard); from input_device_destroy() to seat_focus() will fix this issue. The crash of chromium and slurp was caused by wl_keyboard.modifiers on focus update without preceding wl_keyboard.keymap, so this will still prevent the crash.

diff --git a/src/seat.c b/src/seat.c
index c16cdcda..34158f2f 100644
--- a/src/seat.c
+++ b/src/seat.c
@@ -31,19 +31,6 @@ input_device_destroy(struct wl_listener *listener, void *data)
 		wl_list_remove(&keyboard->key.link);
 		wl_list_remove(&keyboard->modifier.link);
 		keyboard_cancel_keybind_repeat(keyboard);
-		/*
-		 * If the active keyboard on the seat is destroyed, fall back
-		 * to the keyboard from keyboard group so we can respond to
-		 * wl_seat.get_keyboard requests with wl_keyboard.keymap event.
-		 * This prevents Chromium from crashing when started just after
-		 * the active keyboard is destroyed.
-		 */
-		struct wlr_keyboard *active_keyboard =
-			wlr_seat_get_keyboard(input->seat->seat);
-		if (!active_keyboard || active_keyboard == keyboard->wlr_keyboard) {
-			wlr_seat_set_keyboard(input->seat->seat,
-				&input->seat->keyboard_group->keyboard);
-		}
 	}
 	free(input);
 }
@@ -648,6 +635,15 @@ seat_focus(struct seat *seat, struct wlr_surface *surface, bool is_lock_surface)
 		return;
 	}
 
+	if (!wlr_seat_get_keyboard(seat->seat)) {
+		/*
+		 * wlr_seat_keyboard_notify_enter() sends wl_keyboard.modifiers,
+		 * but it may crash some apps (e.g. Chromium) if
+		 * wl_keyboard.keymap is not sent beforehand.
+		 */
+		wlr_seat_set_keyboard(seat->seat, &seat->keyboard_group->keyboard);
+	}
+
 	/*
 	 * Key events associated with keybindings (both pressed and released)
 	 * are not sent to clients. When changing surface-focus it is therefore

I confirmed chromium crashes when I run sleep 2; wtype hello; chromium on sway, so I don't think copying the logic from sway is a good idea.

Hyprland doesn't seem to have this issue, so I will investigate how it handles this.

from labwc.

Hyprland doesn't seem to have this issue, so I will investigate how it handles this.

Hyprland (v0.39.1) doesn't set the keyboard when the active keyboard is destroyed, and doesn't move the keyboard focus to the surface if there's no active keyboard. So when I run sleep 2; wtype hello; chromium, chromium doesn't crash, but the keyboard focus is not moved to chromium on mapping.

So I think my solution in the PR is the most optimal.

@bdantas Could you test #1816?

Maybe I'll make an issue in xserver later.

from labwc.

Created an issue in xserver: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1681

from labwc.

Just tested
sleep 5; wtype -M ctrl -M shift -k c and then marking something in foot. It was copied fine (note the -k argument to wtype).

Is there a difference between xwayland and wayland native applications?

from labwc.

Hi Consolatis. I tried sleep 5; wtype -M ctrl -k c -m ctrl. It works with wayland native applications but not in xwayland applications. Can you try it in an xwayland application and see if you can reproduce the problem?

from labwc.

Does anyone know how Xwayland translates wl_keyboard.keymap, wl_keyboard.key and wl_keyboard.modifiers?
When I opened xev and ran sleep 2; wtype a, xev shows Escape was pressed/released.

MappingNotify event, serial 235, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 235, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 235, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 235, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 235, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 235, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

KeyPress event, serial 235, synthetic NO, window 0x600001,
    root 0x3d3, subw 0x0, time 13173001, (83,55), root:(1051,589),
    state 0x10, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
    XLookupString gives 1 bytes: (1b) "
mbLookupString gives 1 bytes: (1b) "
FilterEvent returns: False

KeyRelease event, serial 235, synthetic NO, window 0x600001,
    root 0x3d3, subw 0x0, time 13173001, (83,55), root:(1051,589),
    state 0x10, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
    XLookupString gives 1 bytes: (1b) "
FilterEvent returns: False

from labwc.

With cafdcd8, wtype's keymap is updated to physical keyboard's one and it's notified to clients as soon as wtype finishes.
This works fine for wayland native clients, because clients translate key events from the compositor immediately using the current wtype's keymap.
However, I suspect xwayland doesn't translate key events immediately, but buffers the keycodes then translate and send them to the clients later:
https://gitlab.freedesktop.org/xorg/xserver/-/blob/xwayland-24.1/hw/xwayland/xwayland-input.c#L1144
So keycodes wtype generates are not translated using the wtype's unique keymap.

At the moment, I don't know how we should fix this. Should we revert cafdcd8?

from labwc.

Suggest we experiment a bit first (before considering revert).

sway does this slightly differently

https://github.com/swaywm/sway/blob/dcdb72757a5ec591c692df5e96c57c51758dbd8f/sway/input/keyboard.c#L821

Would a wl-event-loop-add-idle help here?

Also, looks like they just keyboard to null

https://github.com/swaywm/sway/blob/dcdb72757a5ec591c692df5e96c57c51758dbd8f/sway/input/keyboard.c#L1089

from labwc.

With cafdcd8, wtype's keymap is updated to physical keyboard's one and it's notified to clients as soon as wtype finishes. This works fine for wayland native clients, because clients translate key events from the compositor immediately using the current wtype's keymap. However, I suspect xwayland doesn't translate key events immediately, but buffers the keycodes then translate and send them to the clients later: https://gitlab.freedesktop.org/xorg/xserver/-/blob/xwayland-24.1/hw/xwayland/xwayland-input.c#L1144 So keycodes wtype generates are not translated using the wtype's unique keymap.

I didn't look into xwayland internal keyhandling at all but if xwayland really just stores the keycode and then later translates it to a sym based on the then set keymap that sounds like a xwayland bug to me. It should either translate to the syms directly or do so for the queued ones using the existing keymap when receiving a new one.

from labwc.

It's been a while since I worked on keyboard stuff, but IIRC we shouldn't set a layout on virtual keyboards (might be wrong on that though - just how I remember it).

from labwc.

The issue you are likely referring to was adding virtual keyboards to the keyboard group because that would set the group keymap to the virtual keyboard (or the other way around, can't remember right now) and thus messing up the keymap created by wtype which only includes the keys actually used.

from labwc.

Hi @tokyo4j. Yes, #1816 works for me. Thank you!

from labwc.