feature request: Passing the very first key presses to host while the keyboard is in deep sleep

[bam80]

Hi,
I'm new to ZMK, but a long time BT keyboards user.

One behavior driving me nuts is the loosing of the first key-presses if the keyboard is in deep sleep (and thus disconnected itself from BT host).
As it's turned out, one half of the problem is a regression in Linux BT stack (Bluez), when the key events gotten by host are just discarded until the keyboard fully re-connects (from host POV). The optional fix (workaround?) for Bluez was recently introduced:
bluez/bluez#737

That still wasn't the end of the story, unfortunately:
apparently, some BT keyboards (even modern ones, with BT 5.0) do not pass the key events to host at all, if they were in deep sleep!:
bluez/bluez#737 (comment)
That was quite unexpected to me, because even ancient BT 3.0 "Microsoft" keyboard didn't have the issue, as well as the other cheap one.

I really upset about this situation. The proper behavior in this case is essential to me.
My only hope is ZMK (and others free keyboard firmwares) do that properly.

Any insight how things are really going?
Could we implement the feature in ZMK, if it doesn't do that yet?
Thanks.

[bam80]

Anybody?

[Nick-Munnich]

I can't tell you off the top of my head how this interacts. I am fairly sure that it could be bypassed with adjustments to firmware if it interacts poorly. ZMK does have some fairly nice control over keyboards sleeping, perhaps you could describe your use case a bit better?

[bam80]

Thanks you for your reply Nicolas,
if you are referring to adjustment the timeout before entering deep sleep, that alone is not enough -
making it longer just eases the problem a little, but doesn't solve it.

The idea is to buffer all the key presses happened while the keyboard was asleep, and push them to host as soon as the connection is awaken. BTW, that's the way all the proprietary RF-dongle keyboards work - not a single press is lost with them. As I mentioned earlier, two cheap BT keyboards I have do that, too, so the behavior must be quite common.

About the use case, it's quite often 10 min or so of idle timeout are expired within normal workflow (e.g. when you just browsing with mouse, etc.), so loosing the keypresses when you start typing just after that is very annoying. Even with 30 min timeout, the problem still exists.
Another example - if the screen is blank and locked on timeout (5 min on my system, but then can last indefinitely), I would like to be able just come in and blindly type the password to unlock it, even when the screen is still off, without tinkering with the keyboard while it awake first.

So if ZMK allow us to implement the feature, I would really love to see it happen, as compromise between battery saving and good user experience.

PS:
here is feedback from one of Keychron users for the auto-sleep feature, most of them seem unsatisfied with it's implementation there (QMK-based?):

10 minutes is a very normal amount of time for me to be using just my trackpad, scrolling, reading, clicking to other articles, reading code, typing nothing. Then I need to type, and boing, keyboard is asleep. Half the time it re-connects in 2 seconds, but the other half it stalls and I have to wait closer to 10 seconds before I can type. No bueno. I finally turned off auto sleep and will try to charge it overnight every night as well as turning it off.

https://www.reddit.com/r/Keychron/comments/i8rdpb/do_you_guys_have_sleep_mode_on/

Thank you.

[Nick-Munnich]

Can this be a feature?

Almost certainly.

Is it currently a feature?

I have no idea, you'd need to test that on your own most likely unless someone else happens to have stumbled into the same rabbit hole. If it isn't yet a feature, you'd most likely need to adjust the firmware accordingly yourself (or commission someone to do it) as there are other priorities ATM.

What method would you suggest to avoid this?

Even without deep sleep ZMK keyboards are very energy efficient. You could easily disable the deep sleep feature and still have multiple months worth of battery life, depending on your keyboard and battery size. That's what I was referring to. See the power profiler.

Keychron bit

I am fairly certain that Keychron keyboards from that time used QMK. Some more modern ones use ZMK. You may want to look for details from the past year or more recent than that, as other points are most likely outdated.

[bam80]

Unfortunately, I don't have any QMK/ZMK keyboards to test yet, and the feature is important factor to purchase for me.

Do you have idea maybe where in code this could be implemented? Just curious.

You could easily disable the deep sleep feature and still have multiple months worth of battery life, depending on your keyboard and battery size.

That's interesting, thanks for informing me.

Some more modern ones use ZMK.

Yes I'm considering Keychron b1 pro for purchase. Didn't found if any others relatively cheap pre-made ZMK keyboards exist.

[bam80]

Some more modern ones use ZMK.

Keychron didn't release their ZMK code (yet?).
So no way I could change the deep sleep timeout then?

[Nick-Munnich]

In theory someone could reverse engineer the firmware if they haven't released it. That would be an undertaking though. Try bakeneko60 go I'd say.

[bam80]

Keychron didn't release their ZMK code (yet?).

@lokher Could you express your position here?
I see https://github.com/Keychron/zmk exists, so maybe it was intended to release the sources eventually?

[bam80]

In theory someone could reverse engineer the firmware if they haven't released it. That would be an undertaking though.

The keyboard in question has MCU: NRF52840-QIAA-R_AQFN73:
https://www.keychron.com/products/keychron-b1-pro-ultra-slim-wireless-keyboard

What would be next steps to reverse engineer it?

[bam80]

To eliminate the need to rebuild the firmware every time we need to change the deep sleep timeout parameter, could we expose it to ZMK Studio?