support binding actions to switches

[cmeissl]

Not sure this is the right approach, but it seems to work fine so far. Though the switch bindings should probably be also run during startup.

[YaLTeR]

Hmm, how does it work in other compositors? Also what happens if you e.g. suspend, then switch to tablet mode, then unsuspend?

[cmeissl]

afaik sway has something similar with

# Show the virtual keyboard when tablet mode is entered.
bindswitch tablet:on busctl call --user sm.puri.OSK0 /sm/puri/OSK0 sm.puri.OSK0 SetVisible b true

though there is also the option to react on toggle. If needed I can change the PR to split the actual switch and optional state (toggle), not sure this is really needed.

Will test the suspend behavior.

[cmeissl]

Okay, so it seems I can not directly un-suspend in tablet mode, even the power button is disabled. But I can with an external keyboard. Also I can suspend in Tablet Mode and unsuspend in non Tablet Mode. In both cases the switch does not seem to trigger. But tbh I am not sure handling these cases is important. This would probably require keeping some state somewhere and query the current state after resume.

[YaLTeR]

I just had a shower thought, what if instead of putting this into the binds section with its intercept and repeat and all, this just was in its own section? Maybe even only allow a spawn action? With a comment mentioning that the command may be spawned extra times like on compositor start or w/e.

[cmeissl]

I just had a shower thought, what if instead of putting this into the binds section with its intercept and repeat and all, this just was in its own section? Maybe even only allow a spawn action?

Sure, you had something more static in mind or still keep it dynamic as with the binds?
For now I also expect the spawn action to be enough, though Lid maybe could use some other action in the future?

I tested lid with something like

binds {
    Switch+LidOn { spawn "bash" "-c" "niri msg output \"eDP-1\" on"; }
    Switch+LidOff { spawn "bash" "-c" "niri msg output \"eDP-1\" off"; }
}

which also works nicely (ignoring suspend and so on for now).

With a comment mentioning that the command may be spawned extra times like on compositor start or w/e.

Sure, as long as the command can be considered idempotent I don't see a reason against just re-run it on something like un-suspend or config reloads.

[cmeissl]

(just a side-note, I am still not really happy with the virtual keyboard in tablet mode. LibreOffice Calc just seems to always request input method and I don't see a way to hide the keyboard....)

[YaLTeR]

I think something more static would make sense here. E.g.

switch-events {
    lid-open { spawn ... }
    tablet-mode-on { spawn ... }
}

(names and structure up for discussion)

(just a side-note, I am still not really happy with the virtual keyboard in tablet mode. LibreOffice Calc just seems to always request input method and I don't see a way to hide the keyboard....)

I think they're proposing a Wayland request to enable/disable the osk, wonder if that'll help here..

[cmeissl]

I think something more static would make sense here. E.g.

switch-events {
    lid-open { spawn ... }
    tablet-mode-on { spawn ... }
}

k, sounds good, will do that change tomorrow. maybe we want to keep some options like allow-when-locked=true?

(just a side-note, I am still not really happy with the virtual keyboard in tablet mode. LibreOffice Calc just seems to always request input method and I don't see a way to hide the keyboard....)

I think they're proposing a Wayland request to enable/disable the osk, wonder if that'll help here..

Hm, let's see how this turns out. Current state seems quite annoying :/

[YaLTeR]

maybe we want to keep some options like allow-when-locked=true?

Hm, I thought it would make sense to allow those when locked by default (and document it I guess).

[cmeissl]

Okay, added the new section and implemented the logic to just always run the configured actions.

Seems we can not query the state of the switches, at least not directly through libinput, so we can not easily run the actions other then in response to receiving a libinput toggle event. But so far I have not seen issues with this, even turning
the monitor back on after resume seems to work fine. If needed turning off could be limited to multi-monitor setup with something like [ $(niri msg --json outputs | jq length) -gt 1 ] && niri msg output "eDP-1" off.

We could store the current state in a map per switch and re-run on config changes, but I am not sure this is really worth implementing?

[YaLTeR]

Looks good.

Seems we can not query the state of the switches, at least not directly through libinput, so we can not easily run the actions other then in response to receiving a libinput toggle event. But so far I have not seen issues with this, even turning
the monitor back on after resume seems to work fine.

Interesting, I see.

If needed turning off could be limited to multi-monitor setup with something like [ $(niri msg --json outputs | jq length) -gt 1 ] && niri msg output "eDP-1" off.

Ideally that should happen automatically but it's out of scope for this PR. It's nice that you can do it manually at least.

We could store the current state in a map per switch and re-run on config changes, but I am not sure this is really worth implementing?

Nah, I think it's fine as is.

[YaLTeR]

Thanks!