search

WayfireWM / wayfire

A modular and extensible wayland compositor
https://wayfire.org/
MIT License
2.41k stars 177 forks source link

Add input.xkb_file option #403

Open alexherbo2 opened 4 years ago

ammen99 commented 4 years ago

Can you elaborate why this can be useful?

ammen99 commented 4 years ago

Oops. accidentally closed.

epsilon-0 commented 4 years ago

Duplicate of #418

travankor commented 3 years ago

Not sure if this is a separate issue, but why does Wayfire's input section read libinput events instead of using the xkb keycodes like sway (and others?) do? This makes it easier to use different keyboard models without having to change configuration files.

For example, the chromebook xkb_model can use XF86AudioMute, which is portable across configs, as opposed to using KEY_F8, which isn't what you would use on a different machine.

Wayfire already uses libxkbcommon, so I wonder if there's any reason for the current behavior?

ammen99 commented 3 years ago

Not sure if this is a separate issue, but why does Wayfire's input section read libinput events instead of using the xkb keycodes like sway (and others?) do? This makes it easier to use different keyboard models without having to change configuration files.

For example, the chromebook xkb_model can use XF86AudioMute, which is portable across configs, as opposed to using KEY_F8, which isn't what you would use on a different machine.

Wayfire already uses libxkbcommon, so I wonder if there's any reason for the current behavior?

There is a reason, by using the keycodes we can have bindings which work independently from the current layout (a problem when you have multiple languages). We could in theory have a separate xkb context with a separate set of options for bindings, however so far you are the first one to request that :)

travankor commented 3 years ago

There is a reason, by using the keycodes we can have bindings which work independently from the current layout (a problem when you have multiple languages). We could in theory have a separate xkb context with a separate set of options for bindings, however so far you are the first one to request that :)

Sway has a --to-code flag that seems to be a good compromise for this. I haven't actually tried it, but it's only drawback afaict is that it expects to be started with the same layout every time. So sway can support both methods: layout independent and dependent.

Bindings to keysyms are layout-dependent. This can be changed with the --to-code flag. In this case, the keysyms will be translated into the corresponding keycodes in the first configured layout.