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

slurp ignores keyboard layout #36

Closed
buffet opened this issue May 3, 2019 · 9 comments · Fixed by #52
Closed

slurp ignores keyboard layout #36

buffet opened this issue May 3, 2019 · 9 comments · Fixed by #52
Labels
bug Something isn't working

Comments

@buffet
Copy link

buffet commented May 3, 2019

I got XKB_DEFAULT_OPTIONS='compose:ralt,caps:swapescape' in my environment (using sway).

When I invoke slurp and try to cancel it with the Caps key nothing happens.
When I press the actual Esc key it gets cancelled, but caps lock gets triggered as well.

@emersion
Copy link
Owner

emersion commented May 3, 2019

This happens because we use keycodes directly, not keysyms.

I'm not sure using libxkbcommon is worth it.

@buffet
Copy link
Author

buffet commented May 3, 2019

Yeah, for a single key it's definitely not worth it.
I feel like leaving it like this isn't a solution either though.

Maybe check XKB_DEFAULT_OPTIONS for caps:swapescape and caps:escape (is it only those two?) "manually" and just listen for a different keycode then?

Edit: is there a situation where there is a different key to use and XKB_DEFAULT_OPTIONS isn't set?

@foxcpp
Copy link

foxcpp commented May 3, 2019

xkb_options can be specified in sway (or other compositors) configuration file so using envvar is not reliable.

@emersion
Copy link
Owner

emersion commented May 4, 2019

xkb_options can be specified in sway (or other compositors) configuration file so using envvar is not reliable.

That's right, don't set XKB_DEFAULT_OPTIONS.

Maybe check XKB_DEFAULT_OPTIONS for caps:swapescape and caps:escape (is it only those two?) "manually" and just listen for a different keycode then?

This sounds like a hack and won't scale, but I don't see a better alternative.

@jvanbruegge
Copy link

I also set caps:escape with xkb_options in sway, and it would be really nice to be able to abort slurp with capslock

@emersion emersion added the bug Something isn't working label Feb 11, 2020
@emersion
Copy link
Owner

According to https://gitlab.freedesktop.org/wayland/wayland/merge_requests/58 there's no way around loading the keymap. Interpreting the raw keycodes directly as we do now is wrong.

@NilsIrl
Copy link
Contributor

NilsIrl commented Mar 24, 2020

I'm currently working on this.

@emersion emersion changed the title slurp ignores XKB_DEFAULT_OPTIONS slurp ignores keyboard layout Mar 24, 2020
@Zocker1999NET
Copy link

Zocker1999NET commented Sep 15, 2020

This is not working in my case, using sway 1.5.3 and slurp 1.2.0 (both from Debian Unstable). It may the case, that the solution #52 does not work if caps:escape is only configured for a single keyboard? This is the keyboard input relevant part of my sway config:

input 6127:24757:Chicony_ThinkPad_X1_Tablet_Thin_Keyboard_Gen_3 {
    xkb_layout de,us
    xkb_options grp:ctrls_toggle,grp_led:caps,caps:escape,altwin:menu,nbsp:level3,terminate:ctrl_alt_bksp
    repeat_delay 500
    repeat_rate 30
}

Other applications do recognize caps as escape without any further configuration.

@emersion
Copy link
Owner

The commit fixing this issue hasn't been released yet.

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

Successfully merging a pull request may close this issue.

6 participants