Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can virtual-keyboard be avoided? (partial keyboard grab) #4

Open
st3r4g opened this issue Nov 21, 2020 · 0 comments
Open

Can virtual-keyboard be avoided? (partial keyboard grab) #4

st3r4g opened this issue Nov 21, 2020 · 0 comments
Labels
enhancement New feature or request protocol question Further information is requested

Comments

@st3r4g
Copy link
Owner

st3r4g commented Nov 21, 2020

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:

<request name="configure_grab">
  <arg name="state" type="uint"/>
  <arg name="ranges" type="array"/>
  <arg name="singles" type="array"/>
</request>

And in order to notify the compositor of a state change:

<request name="state_change">
  <arg name="state" type="uint"/>
</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:

<request name="configure_transitions">
  <arg name="state_i" type="uint"/>
  <arg name="state_f" type="uint"/>
  <arg name="singles" type="array"/>
</request>

So:

<interface name="zwp_input_method_keyboard_grab_v2" version="2">
...
  <request name="configure_grab">
    <arg name="state" type="uint"/>
    <arg name="ranges" type="array"/>
    <arg name="singles" type="array"/>
  </request>

  <request name="configure_transitions">
    <arg name="state_i" type="uint"/>
    <arg name="state_f" type="uint"/>
    <arg name="singles" type="array"/>
  </request>
...
</interface>
@st3r4g st3r4g added enhancement New feature or request question Further information is requested protocol labels Nov 21, 2020
@st3r4g st3r4g changed the title Can virtual-keyboard be avoided? Can virtual-keyboard be avoided? (partial keyboard grab) Nov 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request protocol question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant