You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Forwarding keys with virtual-keyboard has a performance penalty (input latency). The key travels in this way:
compositor -> im -> compositor -> end_client
We need to forward keys based on our state sometimes (e.g. Return, Tab, Backspace). We could tell the compositor at connection time the set of keys we would like to receive for each of the "states" and tell the compositor every time the state changes. In this way forwarding has no penalty:
compositor -> end_client
But we would need to extend the input-method protocol for this. Is it doable?
For wlanthy the partial keyboard grab config would look like this:
In state 0, we want to receive: Space...asciitilde
In state 1, we want to receive: Space...asciitilde+F5...F8+Return+BackSpace+Tab+Left_Tab+Alt_L (mod) Important: If any modifier is active, the compositor must not send keys unless we specified that modifier in the list. If the user presses Ctrl+A, we don't want to catch A. But if we are in state 1, we do want to receive Alt+Tab.
The partial grab is configured by issuing multiple times (for different values of state) this request:
But... for this to work, the above must be sent every each key event (even if the state stays the same), and the compositor must wait for it before sending the next.
Another approach might be to statically configure also the keys that change states so the compositor is automatically aware:
Forwarding keys with virtual-keyboard has a performance penalty (input latency). The key travels in this way:
compositor -> im -> compositor -> end_client
We need to forward keys based on our state sometimes (e.g. Return, Tab, Backspace). We could tell the compositor at connection time the set of keys we would like to receive for each of the "states" and tell the compositor every time the state changes. In this way forwarding has no penalty:
compositor -> end_client
But we would need to extend the input-method protocol for this. Is it doable?
For
wlanthy
the partial keyboard grab config would look like this:In state 0, we want to receive:
Space
...asciitilde
In state 1, we want to receive:
Space
...asciitilde
+F5
...F8
+Return
+BackSpace
+Tab
+Left_Tab
+Alt_L
(mod)Important: If any modifier is active, the compositor must not send keys unless we specified that modifier in the list. If the user presses
Ctrl
+A
, we don't want to catchA
. But if we are in state 1, we do want to receiveAlt
+Tab
.The partial grab is configured by issuing multiple times (for different values of state) this request:
And in order to notify the compositor of a state change:
But... for this to work, the above must be sent every each key event (even if the state stays the same), and the compositor must wait for it before sending the next.
Another approach might be to statically configure also the keys that change states so the compositor is automatically aware:
So:
The text was updated successfully, but these errors were encountered: