Closed
Bug 1065404
(LED-API)
Opened 10 years ago
Closed 8 years ago
LED API
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: fabrice, Unassigned)
References
Details
(Keywords: feature, foxfood)
Attachments
(2 files, 10 obsolete files)
9.61 KB,
patch
|
Details | Diff | Splinter Review | |
1.05 KB,
patch
|
Details | Diff | Splinter Review |
See discussion at https://groups.google.com/forum/#!topic/mozilla.dev.b2g/Lrt-eE9WsQs
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.
Comment 2•10 years ago
|
||
Let's try this on my Desire Z, this one has LEDs that can change their color :)
Flags: needinfo?(lissyx+mozillians)
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) :)
Flags: needinfo?(lissyx+mozillians)
Comment 4•10 years ago
|
||
Enhancing the first WIP with the ability to make use of the flashing feature.
Comment 5•10 years ago
|
||
Making the notifications LED flashing when there are pending notifications to be read.
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).
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
Updated•10 years ago
|
Alias: LED-API
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.
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?
Flags: needinfo?(jonas)
Flags: needinfo?(ehsan.akhgari)
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?
Flags: needinfo?(jonas)
Comment 11•10 years ago
|
||
If we don't want to support colors, Jonas' suggestion makes sense to me.
Flags: needinfo?(ehsan.akhgari)
Comment 12•10 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..
Updated•9 years ago
|
Keywords: dev-doc-needed
Updated•9 years ago
|
Comment 15•9 years ago
|
||
Attachment #8487209 -
Attachment is obsolete: true
Attachment #8487811 -
Attachment is obsolete: true
Attachment #8487812 -
Attachment is obsolete: true
Comment 16•9 years ago
|
||
Comment 18•9 years ago
|
||
Attachment #8652544 -
Attachment is obsolete: true
Comment 19•9 years ago
|
||
Attachment #8654316 -
Attachment is obsolete: true
Comment 20•9 years ago
|
||
Attachment #8661932 -
Attachment is obsolete: true
Comment 21•9 years ago
|
||
Attachment #8661931 -
Attachment is obsolete: true
Comment 22•9 years ago
|
||
Attachment #8700978 -
Attachment is obsolete: true
Comment 23•9 years ago
|
||
Attachment #8700980 -
Attachment is obsolete: true
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Updated•8 years ago
|
Keywords: dev-doc-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•