feat: Add soft lock/off support.

[petejohanson]

Initial work on a soft lock/off support for ZMK. Triggering soft off puts the device into deep sleep with only a specific GPIO pin configured to wake the device, avoiding waking from other key presses in the matrix like the normal deep sleep.

[joelspadin]

Would it be possible to split this up into general soft off functions and then the driver that controls them based on a GPIO? I can think of a couple use cases which would want to trigger the same soft off behavior, but which couldn't use this GPIO code:

1. Connect a toggle switch and use code like the direct GPIO kscan driver to control on/off. This would let you add a power switch to a board with a built-in charger but without the switch being in line with the battery, so it can still be charged even when the keyboard is "off". (
2. Trigger soft off with a behavior and then use the reset switch to wake the keyboard by way of rebooting it. This would let you add soft off behavior to any keyboard that has an accessible reset switch without adding any special hardware.

[petejohanson]

@joelspadin Great ideas, trying to figure out the best way to make this happen in a reasonable way:

Right now, the one driver does the following:

1. Listens for interrupts/presses on the configured GPIO pin, with some (configurable?) delays in triggering the soft-off sequence.
2. On soft-off, does the following:
   1. Prepare system for soft-off: puts existing wakeup-source devices into suspended/off state. ("turn off everyone else")
   2. Do own "be ready to wake up the system" hardware configuration. ("turn on the wake up trigger")
   3. Actually force the state to soft off. ("force PM state")

To do this reasonably, I needed an easy way for #2 to be completely independent from #1. I came up with this theoretical DTS:

/ {
    chosen {
        zmk,soft-off-wakeup-source = &wake_trigger;
    };

    buttons { 
        compatible = "gpio-keys";

        button_wake_sleep: bws {
            gpios = <&gpio0 0 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;
        };
    }


    wake_sleep {
        wake_button_behavior {
            compatible = "zmk,button-behavior";

            button = <&button_wake_sleep>;
            bindings = <&soft_off>;
        }

        wake_trigger: wake_trigger {
            wakeup-source;
            trigger = <&button_wake_sleep>;
            extra-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
        }
    }
}

The reason being, I want the &soft_off behavior to be able to turn on the wake_trigger after all the other wakeup-sources are put to sleep, but have the "listen for the press while we're awake" to be a separate thing that actually can be turned off by the PM subsystem as well.

Thoughts? Too convoluted?

[petejohanson]

Closing in favor of #1942 which supersedes this.