Nothing Special   »   [go: up one dir, main page]

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

after unlocking from swaylock: phantom keypress events #1114

Closed
m1027 opened this issue Sep 28, 2023 · 5 comments
Closed

after unlocking from swaylock: phantom keypress events #1114

m1027 opened this issue Sep 28, 2023 · 5 comments
Labels
bug Something isn't working PR pending PR to fix the issue is already pending

Comments

@m1027
Copy link
m1027 commented Sep 28, 2023

Hi,

this is probably closely related to #1091. I am using labwc from git where the according PR has been integrated.

I am using <keybind key="W-l"> <action name="Execute"><command>swaylock</command></action> </keybind>.

I receive phantom l (small "L") keypress events in the following situation. This is always reproducable:

  • Lock screen: W-l
  • Unlock screen: PW + Enter to return into bash
  • Press l once

Result: Then I receive lllllllllllllllllll.... until I do ctrl-c.

Note: This does not happen when I press another key after unlocking. Only l tiggers that. Which may be related to my W-l mapping.

@stefonarch
Copy link
Contributor

I can't reproduce this here, but I could hardly reproduce this phantom keys anyway.

@Consolatis Consolatis added bug Something isn't working help wanted Extra attention is needed investigation required Needs further investigation labels Sep 28, 2023
@Consolatis
Copy link
Member
Consolatis commented Sep 28, 2023

@johanmalm I guess we don't reset the pressed state of the keybind here (via key_state_bound_key_remove()) because we return before that when seat->server->session_lock != NULL.

Maybe its enough to just move the two Ignore labwc keybindings if input is inhibited blocks down before uint32_t modifiers = wlr_keyboard_get_modifiers(wlr_keyboard);?

That way we should allow the release event of a bound key to be reset even though the input is already inhibited / locked.

johanmalm added a commit to johanmalm/labwc that referenced this issue Sep 28, 2023
Do not withhold the release event associated with a keybind which executes
a keyboard-input-inhibiting client like swaylock.

In other words, make release-events of absorbed keys (those used up by a
keybind) de-register as such even though session-lock or input-inhibit is
in-force.

Fixes: issue labwc#1114

Helped-by: @Consolatis
@johanmalm
Copy link
Collaborator

I can reproduce the bug and confirm that #1115 fixes it.

Thanks @Consolatis for analysis + tell me how to do it.
I'm sure I would have got there, but having the solution spelt out is pretty handy 😄

Maybe its enough to just move the two Ignore labwc keybindings if input is inhibited blocks down before uint32_t modifiers = wlr_keyboard_get_modifiers(wlr_keyboard);?

Consolatis pushed a commit that referenced this issue Sep 28, 2023
Do not withhold the release event associated with a keybind which executes
a keyboard-input-inhibiting client like swaylock.

In other words, make release-events of absorbed keys (those used up by a
keybind) de-register as such even though session-lock or input-inhibit is
in-force.

Fixes: issue #1114

Helped-by: @Consolatis
@Consolatis
Copy link
Member
Consolatis commented Sep 28, 2023

Should be fixed by latest master thanks to @johanmalm :)
Feel free to comment / reopen if that is not the case.

@Consolatis Consolatis added PR pending PR to fix the issue is already pending and removed help wanted Extra attention is needed investigation required Needs further investigation labels Sep 28, 2023
@m1027
Copy link
Author
m1027 commented Sep 29, 2023

The above test succeeds now. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working PR pending PR to fix the issue is already pending
Projects
None yet
Development

No branches or pull requests

4 participants