On 09/27/2014 07:41 PM, Jonas Sicking wrote:
readonly attribute string[] colors; // array of colors the hardware supports
Can you elaborate on what the convention would be here? It seems like
LEDs are characterized by the color channels they have and the number of
quantized light levels. Would an RGB led have "rgb" or "redgreenblue"
here, or would we enumerate all of the hex color values possible given
the quantization levels of the RGB display (which could be a *lot* if
it's a fancy LED/hardware driver or whoever write the hardware
definition wants to just seem fancy.)
As a thought exercise, here's a structure that I think could make sense
but still could be a bit of a hassle to use:
- Boolean white LED: [{ color: 'white', levels: 2 }]
- White LED that can pulse/fade: [{ color: 'white', levels: 64 }]
- Tri-color LED that can pulse/fade: [{ color: 'red', levels: 64 }, {
color: 'green', levels: 64 }, { color: 'blue', levels: 64 }]
- MIDI sampler controllers tend to just have red-green with limited
levels: [{ color: 'red', levels: 4 }, { color: 'green', levels: 4 }]
- Firefox-special orange-only LED: [{ color: 'orange', levels: 8 }]
I enumerate the levels here because even if we assume that the low-level
LED driver appropriately scales from the standard 0-255 range, it would
be wasteful to generate a fade that has a bunch of wasted transition states.
Probably the ideal API to hide more complicated cases would be to let
the patterns be more CSS transition-like where we set the startpoint and
the endpoint, let it be repeat-able, and just broadly inform via the API
the color channels that are available and whether it's "boolean" or
"smooth" fade-capable. This would also open the door to a very fancy
device performing color-space normalization (which could result in
non-linear use of the quantization levels).
Andrew
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
