Closed mochaaP closed 2 weeks ago
This is a change in fcitx that breaks existing programs. They need to fix it there. At the very least they should not be making breaking changes in minor updates.
As for kitty, you can simply add
wayland_enable_ime no
to workaround it. IME is a god awful hack, that causes endless bugs, increased latency and even application crashes. That's why it was disabled by default under kitty in X11, maybe I should be doing that in Wayland too. Unless you actually need to type East Asian languages using it, I strongly recommend turning it off, or downgrade fcitx5 to whatever version before they introduced this bug.
As for the actual bug, I have no idea why @wengxt thinks it's a kitty issue. wl_keyboard.leave is an event sent by the compositor not the application. So kitty isnt "doing" it. And text input is not triggered by keyboard enter/leave, see the keyboardHandleEnter and keyboardHandleLeave functions. Text input is enabled/disabled by the tex tinput enter and leave functions, see text_input_enter and text_input_leave in wl_text_input.c. And regardless of the number of keyboards in a system, in Wayland I know of no way other than keyboard enter and leave events to track keyboard focus. If you do, please enlighten me.
Maybe @wengxt can explain some more.
I am closing since I dont see how this is a bug in kitty, but feel free to continue posting, I am open to being convinced.
On compositor using zwp input method v2, there may be multiple wl_keyboard objects, one represent the real phyiscal keyboard, one represent the “virtual keyboard object” created by input method.
Input method may choose to create, or delete the virtual keyboard object at literally any time. At least it seems on sway, sway will send a wl_keyboard.leave at that time. I think what sway doing makes totally sense.
What kitty doing wrong here, is that kitty assume that wl_keyboard.leave means the window lost focus. and send text-input-v3.enable/disable.
Briefly reading the existing code,
on wayland text-input-v3.enter/leave should be only source of GLFW_IME_UPDATE_FOCUS. You don't really need to match it with keyboard focus, especially it text-input-v3.enter already carries the surface object.
On Sat, Apr 27, 2024 at 09:46:24PM -0700, Weng Xuetian wrote:
On compositor using zwp input method v2, there may be multiple wl_keyboard objects, one represent the real phyiscal keyboard, one represent the “virtual keyboard object” created by input method.
kitty uses text-input-unstable-v3. I assume that's what you mean.
Input method may choose to create, or delete the virtual keyboard object at literally any time. At least it seems on sway, sway will send a wl_keyboard.leave at that time. I think what sway doing makes totally sense.
Then how is any application supposed to track focus? If there are multiple keyboards and they can all focus different things at different times, there is simply no way to know which window actually has keyboard focus.
What kitty doing wrong here, is that kitty assume that wl_keyboard.leave means the window lost focus. and send text-input-v3.enable/disable.
- wl_keyboard.leave does means window lost focus in some cases, but obviously, not all cases. Especially when there are multiple wl_keyboard objects.
- there is text-input-v3.enter/leave that kitty should be using to trigger focus change for text-input-v3, not wl_keyboard.leave
I dont see how that is supposed to work. What if the user hasnt enabled IME? kitty cannot rely on IME for focus events. Indeed, where in the Wayland spec does it say focus is meant to be tracked by IME enter/leave events? text input is an optional protocol. Window focus is a core feature, it cannot depend on an optional protocol.
On Sat, Apr 27, 2024 at 09:54:00PM -0700, Weng Xuetian wrote:
Briefly reading the existing code,
on wayland text-input-v3.enter/leave should be only source of GLFW_IME_UPDATE_FOCUS. You don't really need to match it with keyboard focus, especially it text-input-v3.enter already carries the surface name.
So you are saying that basically, only in Wayland, we now have two kinds of focus actual keyboard focus and text input method focus? That makes no sense.
Window focus cannot depend on an unstable, optional text input protocol. And updating IME state on window focus change is a perfectly reasonable thing to do that causes no issues on anything other than Wayland+fcitx5 with your recent commit to fcitx5. I strongly suggest you consider reverting it and find another way to accomplish whatever you were trying to accomplish with it.
If you expect wayland applications to rely on text input state to manage focus, then you need to get some core wayland specs updated to say so.
Sorry I was confused by some app that bind two seat.
Yeah, there's only one wl_keyboard, but maybe then it's sway to be blamed, when there's no focus change but just virtual keyboard got destroyed and it send a wl_keyboard.enter/leave.
Though I can see why sway's doing this, because it want to clear the key pressed state that was once associated with previous keyboard.
But still, the my statement about text-input-v3.enter still holds. IME focus, and keyboard focus are two separate things. If the event you are calling is IME_FOCUS change, then you should stick to ime focus. Or, if you want to assume the keyboard focus is a prerequisite of ime focus, actually that's also fine and is what compositor do. The easiest fix for the issue would be
_glfwPlatformUpdateIMEState, remove the enable/disable in case GLFW_IME_UPDATE_FOCUS, only keep them as a reply to text-input-v3.enter/leave.
hande_text_input_enter() {
text_input_focus = true
// keep existing code here
// send_enter & commit
}
hande_text_input_leave() {
text_input_focus = false
// keep existing code here
}
_glfwPlatformUpdateIMEState
case GLFW_IME_UPDATE_FOCUS:
if text_input_focus:
// Remove the enable/disable() here
set_content_type .... etc
I am OK with changing GLFW_IME_UPDATE_FOCUS to rely on the text input focus rather than the window focus. That seems harmless, since it only affects IME handling, and wnt break anything for people not using the IME.
Describe the bug When Fcitx 5 is enabled on Sway, on_focus_change is repeatedly called due to multiple
wl_keyboard
's existence. (e.g. on Sway, virtual keyboard and physical keyboard are two different objects.)To Reproduce Steps to reproduce the behavior:
kitty --config NONE --debug-keyboard
libxkbcommon
Environment details
Additional context Notes from fcitx5 developer @/wengxt:
wl-debug.log