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

Bindings to keysyms are layout-dependent #8275

Open
chebykinn opened this issue Aug 4, 2024 · 7 comments
Open

Bindings to keysyms are layout-dependent #8275

chebykinn opened this issue Aug 4, 2024 · 7 comments
Labels
i3-compat Sway doesn't match i3's behavior

Comments

@chebykinn
Copy link
Contributor

Hi, I've been using Sway on and off for a while already, but I wanted to understand the reason for making bindings layout-dependent.

Let's say for example a user sets a key binding to open an application menu the same way they did it in i3:

bindsym $mod+d exec rofi -show run

This will only work with English keyboard layout. If they have a setup with multiple layouts like with an additional Cyrillic layout the menu wouldn't be called unless they switch back to English. To avoid this it is suggested to use bindsym --to-code in the man page, but it's not straightforward for the people who come from i3 and I've found multiple related issues here before posting this.

So roughly I have these questions:

  • What is the use case for binding keys to layouts? (AFAIK, other OSes, and environments don't do this)
  • Can the default be changed?
@chebykinn chebykinn added the i3-compat Sway doesn't match i3's behavior label Aug 4, 2024
@chebykinn
Copy link
Contributor Author

Or maybe this is an incorrect behavior on the i3 side, since they have bindsym and bindcode, the latter is supposed to work independently from the layout, but then I just don't understand the reason for having bindsym.

@emersion
Copy link
Member

emersion commented Aug 4, 2024

A keysym (key symbol) doesn't identify a physical key. It identifies the result of translation a key according to a keyboard layout. A keycode identifies a physical key.

One could write a full config with keycodes rather than keysyms, but that's not what bindsym does. But that isn't very user-friendly, e.g. KEY_A is the position of the A key on a US keyboard (second row first key after Tab), and e.g. on a French keyboard it's the Q key.

@chebykinn
Copy link
Contributor Author

Right, but from my everyday experience on i3 bindsym somehow maps to physical keys, why does it work differently?

I understand now the use case for binding to letters, French layout is a good example, do I understand that you have it as the only layout?

@emersion
Copy link
Member

emersion commented Aug 4, 2024

I don't remember what i3 does but probably it does --to-code by default or something. We chose to not do that in Sway because it went against the principle of keysyms.

Some people have French as the only layout, some people have both French and English (personally I only have English).

@chebykinn
Copy link
Contributor Author

Got it, thanks! But what is the difference between bindsym --to-code vs bindcode?

@emersion
Copy link
Member

emersion commented Aug 4, 2024

bindsym --to-code takes keysyms as input and converts them into keycodes according to the default layout. bindcode takes keycodes as input.

bindsym accepts symbol names e.g. "a", but for bindcode you'd need to look up the KEY_* constant in /usr/include/linux/input-event-codes.h and put the number in the config file.

@chebykinn
Copy link
Contributor Author

I understand now, thanks. I still think that for i3 compatibility it would've been best to keep the same behavior, but I get why you didn't do that. I'll leave this thread open for a while in case someone else would be interested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i3-compat Sway doesn't match i3's behavior
Development

No branches or pull requests

2 participants