Idle trigger - Githubissues

joshuaflanagan commented 9 years ago

I noticed my computer went to sleep, but the LCD on my Infinity ErgoDox continued to glow. I wondered if there was any way to get a message from the OS when the computer sleeps, but it looks like the LED Indicators are the only USB HID messages the computer sends to the keyboard.

My next thought was that it could be added as a Trigger in KLL. There would be an internal counter in the firmware that kept track of the time since last user input. When a certain threshold was met (either specified via a KLL variable, or using the Trigger Timing syntax already defined (section 5.1.8).

So your KLL might look like

Idle(300ms) : <lower LED illumnination>
Idle(5s): <turn off LED illumniation>
Idle(120s): <turn off LCD backlight>

Alternatively, there could be hardcoded trigger names, where the threshold is specified via variable:

Idle1Threshold = 300
Idle2Threshold = 5000
Idle3Threshold = 120000
Idle1 : <lower LED illumnation>
Idle2 : <turn off LED illumniation>
Idle3 : <turn off LCD backlight>

I think the first syntax would be more intuitive, but wasn't sure if it would be more complicated to implement.

I'd be happy to try and implement, but there are a few points I'd like to get feedback on:

1) Do you agree this would be useful, and this is the proper way to approach it? 2) It seems like it would be fairly easy to implement the idle counter - where in the code do you think that would hook in? 3) How hard is it to define a custom trigger? Are triggers meant to be extended, or is everything hardwired to the current set?

haata commented 9 years ago

(First off, apologies if I take a while to respond, I'm riding my bicycle across NZ this month...)

Interesting :D

So, first off, I think this is a really neat idea for a trigger. Quickly thinking about it, I'm not quite sure the best place to put this, but I think it could work.

Your first suggestion of syntax I think would be closer to ideal. Since there's a separate syntax for delays between trigger events in a macro we don't really have to worry about that. There are a couple issues (which I hope are already dealt with using the assignment syntax).

Multiple result events on a single trigger using separate assignments

Idle(100ms) : <1>;
Idle(100ms) :+ <2>;

Unsetting a specific trigger (this behaviour would be a special case that would be handled by the kll compiler and not the firmware)

Idle(100ms) : None;

Removing a specific trigger result from a list of results

Idle(100ms) :- <1>;

Implementation wise, most of the work I'd say is Python related, then second, planning out the C packed data structures (see kll.h in Macros/PartialMap and generatedKeymap.h). There's already an internal ms counter implemented, so it should be as simple as just checking this global variable (systick_millis_count I believe) to see if any events have expired while the keyboard has been idle. Firmware wise, I think the code should be added to the Macros/PartialMap module.

As for the triggers, you'll need to add the grammar to the kll compiler. You'll need to brush up on your compiler/DSL notes if you're CS trained. If you haven't done anything of that sort, it's not too bad (just think tokenize, parse, organize, generate). https://github.com/kiibohd/kll/blob/master/kll.py#L136 <- Tokenize https://github.com/kiibohd/kll/blob/master/kll.py#L652 <- Main parsing rules https://github.com/kiibohd/kll/blob/master/kll_lib/containers.py <- Where the data is organized (this is a Macro technically, so you'll need a new classification, ie USB/SYS/CON) https://github.com/kiibohd/kll/blob/master/backends/kiibohd.py <- Code generation (On a side note, the kll compiler really needs some basic regression tests or unit tests as it's pretty easy to break an obscure expression, so try to include a .kll file with any corner cases you think might be affected by your changes).

Ok, so now that that's out of the way. There is another signal from the OS that is received (that I'm currently not handling yet). USB Suspend. After about 3 ms of idle time, the USB device will notified that the device should go into a lower power mode if possible. http://cache.freescale.com/files/32bit/doc/ref_manual/K20P64M72SF1RM.pdf (41.10.3)

While not as powerful as your suggested method, this signal could be used for things like keyboard low power mode (I'm not utilizing any of the low power states right now, which is a project in itself to do the re-clocking/re-initialization of hardware).

Also, if you hadn't noticed, I've created a github repo for the kll spec: https://github.com/kiibohd/kll-spec Every once in a while I'll resync with the overleaf/official version.

joshuaflanagan commented 9 years ago

Thanks, this is very helpful guidance. I'll give it a try. Enjoy your ride!

micke commented 7 years ago

Has there been any progress on this? I would love to have my ergodox infinity go to sleep when i turn off my computer as i have my computer in the bedroom.

joshuaflanagan commented 7 years ago

I never made any significant progress. It was very useful information, but my priorities changed and I never got back into it. It'd be great to see if someone could move this forward.

haata commented 7 years ago

I've been working on some time duration functions. I need to check, I'm getting closer to be able to add this (working on manufacturing tests atm...).

lailoken commented 6 years ago

Would this also apply to the K-Type I have? I've been thinking to add this as an animation, but the syntax is pretty archaic with zero documentation.

kiibohd / controller

Idle trigger #72