wayfire icon indicating copy to clipboard operation
wayfire copied to clipboard

Add input.xkb_file option

Open alexherbo2 opened this issue 5 years ago • 6 comments

alexherbo2 avatar Feb 08 '20 23:02 alexherbo2

Can you elaborate why this can be useful?

ammen99 avatar Feb 09 '20 07:02 ammen99

Oops. accidentally closed.

ammen99 avatar Feb 09 '20 07:02 ammen99

Duplicate of #418

epsilon-0 avatar Feb 24 '20 18:02 epsilon-0

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?

travankor avatar Dec 02 '20 02:12 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?

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 :)

ammen99 avatar Dec 02 '20 06:12 ammen99

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.

travankor avatar Dec 02 '20 21:12 travankor