Use PORT events for kscan matrix interrupts, add option for deep sleep.

[petejohanson]

• Lower power usage compared to regular interrupts on nrf52.

I've taken the first approach suggested in zephyrproject-rtos/zephyr#28499 and updated the matrix KSCAN driver to using GPIO_INT_LEVEL_ACTIVE, and disabling the interrupt(s) as soon as we get our first one.

This is fine, since we continuously poll and read while keys are pressed to properly detect releases, especially for multiple keys sharing the same input pin.

@Nicell Before I spend more time pursuing this, would you mind testing this, and power profiling it to compare the idle usage with this change?

Assuming this is working properly (I believe it is), we should be able to leverage this for enabling deep sleep, and allow waking each half with key presses, since the PORT events should still trigger when in that low power mode.

[petejohanson]

Ok, I've pushed ever more to this branch, this now includes the initial sleep/power management support I've been working on. This include support for:

1. Going to deep sleep after a configured number of milliseconds without any key position event activity.
2. Waking on keypress afterwards.
3. Skipping deep sleep if we detect an active USB connection, since saving power in that scenario isn't as important, keeping the keyboard up is.

To test, you should be able to add:

CONFIG_ZMK_SLEEP=y
# CONFIG_ZMK_IDLE_SLEEP_TIMEOUT=30000

And uncomment the timeout to change the default idle from 15 minutes to 30 seconds for easier testing.

@Nicell I haven't had a chance to fix the adveristing stuff yet to reduce power further, but can you try profiling this, in particularr once this actually enters deep sleep?

Caveats

On Linux (only so far), sometimes when resuming from sleep, my laptop will reconnect to the keyboard, but fail to setup the correct HOG input device, so even though the keyboard is sending GATT notifications on HID events, no one on the other end is listening.

I've got some hcidumps for working/non-working times, so I will be trying to analyze a bit more and try to see if it's something we are doing wrong on our end.

[petejohanson]

Ok, so digging a bit more on the Linux reconnect issue, I find this discrepancy between working and non-working hcidump.

Working:

< ACL data: handle 8 flags 0x00 dlen 11
    ATT: Read By Type req (0x08)
      start 0x0001, end 0xffff
      type-uuid 0x2b3a
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 8 packets 1
> ACL data: handle 8 flags 0x02 dlen 9
    ATT: Error (0x01)
      Error: Attribute not found (10)
      Read By Type req (0x08) on handle 0x0001
< ACL data: handle 8 flags 0x00 dlen 11
    ATT: Read By Type req (0x08)
      start 0x0001, end 0xffff
      type-uuid 0x2b2a
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 8 packets 1
> ACL data: handle 8 flags 0x02 dlen 24
    ATT: Read By Type resp (0x09)
      length: 18
        handle 0x0008, value 0x00 0xe7 0x76 0x4c 0xbf 0x18 0x56 0x90 0xc6 0x1e 0x47 0xe5 0x8e 0x5c 0xf0 0x3b•

There is a "read by type" request that the keyboard responds to with an error.

When not working, I see this:

< ACL data: handle 22 flags 0x00 dlen 11
    ATT: Read By Type req (0x08)
      start 0x0001, end 0xffff
      type-uuid 0x2b3a
> ACL data: handle 22 flags 0x02 dlen 21
    ATT: Handle notify (0x1b)
      handle 0x0021    
      value 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00•

The "read by type" never is responded to by ZMK, which I think leaves the Linux HOG code "waiting" for a response, so it never finishes subscribing, creating the necessary HOG input device, etc.

Will dig more.

[petejohanson]

The 0x2b3a attribute is defined in Zephyr as BT_UUID_GATT_SERVER_FEATURES, which for whatever reason Zephyr does not seem to respond to sometimes.

[petejohanson]

Oh! For testing, make sure you do a west update before trying to build this. It requires a one line patch to our Zephyr fork.

[tominabox1]

It appears that with ZMK_USB (usb hid) disabled, the build fails

As an end user, I would not expect USB HID output configuration to be related to power stuff, so I'm not sure if this is intended or not but its not what I would personally expect.

[petejohanson]

Here goes nothing!