[:fabrice] Fabrice Desré Reporter
	Description • 10 years ago

See discussion at https://groups.google.com/forum/#!topic/mozilla.dev.b2g/Lrt-eE9WsQs

	[:fabrice] Fabrice Desré Reporter
	Comment 1 • 10 years ago

The api seems to work correctly, but my flame doesn't change its light color at all. Not sure if it's a hardware limitation or if I'm doing something wrong.

	:gerard-majax
	Comment 2 • 10 years ago

Let's try this on my Desire Z, this one has LEDs that can change their color :)

	:gerard-majax
	Comment 3 • 10 years ago

So, applied on Desire Z, ran from your webpage that does random stuff on the BATTERY indicator: I have my Desire Z with the battery charging mode LED (orange) :)

	:gerard-majax
	Comment 4 • 10 years ago

Enhancing the first WIP with the ability to make use of the flashing feature.

	:gerard-majax
	Comment 5 • 10 years ago

Making the notifications LED flashing when there are pending notifications to be read.

	:gerard-majax
	Comment 6 • 10 years ago

Several devices have a LED that allows to make the device buttons visible. We can drive them with this API. I just checked, Geeksphone Keon and Peak exposes both this buttons LED. Also, the Peak allows to drive red/green/blue colors (i.e., they are exposed at SysFS level).

	dattaz
	Comment 7 • 10 years ago

On a ZTE Open C we can change the brightness of button-backlight with : adb shell "echo n > /sys/class/leds/button-backlight/brightness" where 0<= n < 40

	:gerard-majax
	Comment 8 • 10 years ago

Status update: this is working good enough for a hack, but we need to take some time and think about an API that is not just exposing how Android's light interface works.

	:gerard-majax
	Comment 9 • 10 years ago

Any input/suggestions for spinning up a new API on this topic ?

Some more finding that I just came accross:
 - Flame has a "torch-light" driver exposing in SysFS ; I cannot find something similar on other devices
 - there's no access to flash light from the Android liblights' implementation on the Flame
 - there is no proper consistency regarding the available physical lights exposed
 - there is more or less consistency regarding the notifications means exposed in liblights:
   - this is dependant on each OEM
   - that's in <hardware/lights.h>
   - a set of #define LIGHT_ID_*, covering: backlight, keyboard, buttons, battery, notifications, attention, bluetooth and wifi
   - those last two are said not to be supported yet

For the torch-light not exposed for the Flame, we can probably quite easily expose it ourselves. For the rest of the issues, we can maybe have a higher level API that makes use of liblight but not only.

One question we will have to address is probably what do we expose: lights directly, or their use and let low-level code drive the proper lighting according to what we need to do?

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 10 • 10 years ago

It seems like it's hard to get access to the color capabilities of the LED. If so, maybe we can simply make this a compile time thing. I.e. create setting which contain the patterns for the various "modes", and then give this setting a default value at compile time. We already have code which allows distributions to set distribution-specific settings. Then have the system app code read this setting and pass the values from the settings to the API.

As for an API for driving the tourch-light. Having an API which takes the same type of array as the vibration API seems like it'd get us pretty far. I.e. something like [timeon, timeoff, timeon, timeoff, ...]. But for the LED we'd automatically repeat it. You could then pass [Infinity] to turn on, and [0, Infinity] to turn off. That's a bit hacky though, so maybe having separate functions for turn-on and turn-off would be good.

Not sure if I'm answering the asked question?

	(no longer active)
	Comment 11 • 10 years ago

If we don't want to support colors, Jonas' suggestion makes sense to me.

	an
	Comment 12 • 9 years ago

Just tried the above patches on my Open C (v2.1) and it works! Thank you people. The led doesn't blink or change color but at least I can tell when I missed a call or sms. Hard to understand why this feature was/is not available by default.

Another feature missing from v2.1 (but existing in 1.3) is the home button led lighting up when opening the phone. I can set it manually as mentioned above but it's permanent..

	:gerard-majax
	Comment 17 • 9 years ago

Rebased.