Modifier key events have their modifier bits set differently on Linux vs OSX

@kovidgoyal

Edited by @kovidgoyal to add the poll:

We are discussing the best approach to take for fixing this issue, the two options are below with updated votes.

The modifier bits should reflect the modifier state taking into account the current key event. This is the platform behavior of macOS , Windows and Qt ( @neurocyte @j4james @dankamongmen @kovidgoyal @rockorager )
The modifier bits should reflect the modifier state as it was before the current key event. This is the platform behavior of Linux and GTK on Linux (havent been able to test GTK on other platforms). (@kchibisov @mitchellh)

(1) requires no changes to the existing kitty keyboard protocol beyond specifying the behavior. (2) requires adding a new "fake key code" and sending these events to update the modifier state.

Original issue is below:

On linux the modifier bit is clear on press events and set on release events. OSX is the other way around.

For example:

Linux:
LEFT_CONTROL PRESS
CSI 57442 u

ctrl+LEFT_CONTROL RELEASE
CSI 57442 ; 5 : 3 u

macOS:
ctrl+LEFT_CONTROL PRESS
CSI 57442 ; 5 u

LEFT_CONTROL RELEASE
CSI 57442 ; 1 : 3 u

This comes from a discussion with ghostty dev on which behaviour should be considered correct.

See: ghostty-org/ghostty#1082

On Sat, Dec 16, 2023 at 12:18:26PM -0800, Gabriel Nützi wrote: @kovidgoyal Does that mean you need to call xkb (after ctrl key has been pressed, or before starting up kitty) and gather the activated **real modifier** and use that one, once the user presses `CTRL_L`? If yes that basically means you do the same thing or something similar as the keyboard probing loop on wayland when kitty starts up, correct?. So the task is: which modifier from `ctrl, shift, lock, mod1...mod5` is mapping to `CTRL_L`, such that you can kitty-encode this modifier when `CTRL_L` is pressed?

No, I'm not going to bother. I will just assume that whatever xkb identifies as the l_ctrl and r_ctrl keys is what changes the state of the ctrl bit in modifiers in the standard way. If there is some more complex scenario needed, it will be an edge case and I can look into it in the future. For example, to be more sophisticated one could actually dynamically change this assumption after the first time the user presses a key that causes modifiers to change in the next modifiers update event. But frankly, I doubt this will be needed.

Voting was 5 to 2 in favor of (1). I have implemented (1) in master.

Apply modifiers before presses in kitty protocol

Keyboard protocol: Clarify the behavior of the modifier bits during m…

kitty keyboard protocol: Specify the behavior of the modifier bits du…

refactor: remove workaround for kovidgoyal/kitty#6913

Merge upstream: v0.12.3 → v0.13.2 (#4)

Merge upstream: v0.13.2 → v0.14.0 (#6)

Keyboard protocol: Clarify the behavior of the modifier bits during m…

kitty keyboard protocol: Specify the behavior of the modifier bits du…

Navigation Menu

Repository navigation

Modifier key events have their modifier bits set differently on Linux vs OSX #6913

111 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Modifier key events have their modifier bits set differently on Linux vs OSX #6913

Description

Activity

mitchellh commented on Dec 13, 2023

mitchellh commented on Dec 14, 2023

kovidgoyal commented on Dec 14, 2023

mitchellh commented on Dec 14, 2023

neurocyte commented on Dec 14, 2023

kovidgoyal commented on Dec 14, 2023

mitchellh commented on Dec 14, 2023

kchibisov commented on Dec 14, 2023

kchibisov commented on Dec 14, 2023

kovidgoyal commented on Dec 14, 2023

mitchellh commented on Dec 14, 2023

kchibisov commented on Dec 14, 2023

mitchellh commented on Dec 14, 2023

111 remaining items

kovidgoyal commented on Dec 17, 2023

kovidgoyal commented on Dec 24, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions