anduril: immediate on/off options

Bug #1803001 reported by Selene ToyKeeper
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Flashlight Firmware Repository
Fix Released
Medium
Unassigned

Bug Description

Anduril could really use some compile-time options to select between "immediate on" and "delayed on", and between "immediate off" and "delayed off". Several people have expressed a preference for Narsil-like behavior, and it wouldn't be hard to add, but it pretty much has to be done at compile time.

The options are:

- Immediate on: Anduril's current behavior. Lights up at the floor level as soon as the button is pressed, then goes to the memorized level when the button is released. If held, it briefly blinks, and then letting go makes it stay at the floor level.

- Delayed on: Narsil's behavior. Does nothing when the button is pressed, and then goes to the memorized level when the button is released. If held, it lights up at moon, and then letting go makes it stay at moon. The advantage is: Some people find it easier to get the moon timing this way.

- Delayed off: Anduril's current behavior. After a single click, it waits for the release timeout to expire before turning the light off. This makes it possible to do multiple-click actions without turning the light off. For example, going to turbo or ramping down.

- Immediate off: Narsil's behavior. After a single click, the LEDs shut off as soon as the button is released. If another click follows, the emitters turn back on. This makes shutting off faster, but also means there must be a dark period before multiple-click actions are executed.

The most-requested of these is immediate off.

Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

Thanks, looks like you helped Texas_Ace quite a bit. :)

This branch will need some cleanup before merging though, to clear up a few things:

- This makes click-for-off override the memorized level, even if it was accessed from a shortcut.
- Since the new definitions are mutually exclusive, it should probably have two defines instead of four.
- Also includes some unrelated changes:
  - Full turbo from off
  - PWM table compression
  - The beginning of a patch to disable stepped ramping

Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

This was delayed for a long time, but I just published some revisions to the fsm branch which include a solution for this feature request.

There are two #defines:

- B_TIMING_ON
- B_TIMING_OFF

And there are three values they can be set to:

- B_PRESS_T - respond when button is pressed
- B_RELEASE_T - respond when button is released
- B_TIMEOUT_T - respond when event times out (when sure the user isn't going to double click)

Each timing option only has two usable values right now though... for on, it can respond at press or release. Almost nobody seems to want the timeout mode. And for off, it can respond at release or timeout... almost nobody seems to want the press mode.

The default values right now are release-on and timeout-off. A lot of people seem to like release-on more than press-on, so I changed the default even though I kinda prefer press-on.

So this is released. I still need to do something with the PWM table compression though, since that can probably save some significant space and space is becoming a bit of an issue again.

Changed in flashlight-firmware:
status: Confirmed → Fix Released
Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

Oh, um, I didn't change the default to release-off. I tried it, and it works... but yuck. It makes all multi-press actions awkward to use, and can easily confuse people who want to turn the light off and then turn it back on in a different mode... because it can't be turned back on until a moment after it shuts off. If they try to turn it back on too soon, it'll be interpreted as a multi-click event instead.

So that remains an option only for people who are willing to compile the code.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.