1065404 - (LED-API) LED API

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[[:fabrice] Fabrice Desré]

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

Comment 1

[[:fabrice] Fabrice Desré]

Attachment: wip patch

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.

Comment 2

[:gerard-majax]

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

Comment 3

[:gerard-majax]

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) :)

Comment 4

[:gerard-majax]

Attachment: Gecko PoC with flash support

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

Comment 5

[:gerard-majax]

Attachment: Gaia PoC LED flashing notification

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

Comment 6

[:gerard-majax]

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).

Comment 7

[dattaz]

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

Comment 8

[:gerard-majax]

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.

Comment 9

[:gerard-majax]

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?

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 11

[(no longer active)]

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

Comment 12

[an]

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..

Comment 15

[:gerard-majax]

Attachment: Implementing a LED API

Comment 16

[:gerard-majax]

Attachment: Blink LED on unread notifications

Comment 17

[:gerard-majax]

Attachment: Implementing a LED API

Rebased.

Comment 18

[:gerard-majax]

Attachment: Blink LED on unread notifications

Comment 19

[:gerard-majax]

Attachment: Implementing a LED API

Comment 20

[:gerard-majax]

Attachment: Implementing a LED API

Comment 21

[:gerard-majax]

Attachment: Blink LED on unread notifications

Comment 22

[:gerard-majax]

Attachment: Implementing a LED API

Comment 23

[:gerard-majax]

Attachment: Blink LED on unread notifications