Add input.xkb_file option

[alexherbo2]

No description provided.

[ammen99]

Can you elaborate why this can be useful?

[ammen99]

Oops. accidentally closed.

[epsilon-0]

Duplicate of #418

[travankor]

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]

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]

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.