Led Suggestions

[atomicthumbs]

I have some suggestions to improve intuitability of the LEDs and add to the amount of data they provide. I'm glad that they're all under software control.

LEDs numbered from left to right, 1234 5678.

1/2. Current function: SD activity (read, write, or both? not sure). Suggestion: Turn on LED when SD card is inserted and mounted; blink for activity

3: Wifi. Current function: lit when radio is active. Suggestion: Blink occasionally when radio is on but not connected; illuminate when connected to an AP; blink for activity

4: Bluetooth. Current function: lit when radio is active. Suggestion: Blink when bluetooth is set to discoverable; illuminate when paired; blink for activity

5/6: I have no idea what these do. Never seen them illuminated. Are there even LEDs there?

7: Charging light. Current function: light when charging; flash when battery low (this can make things confusing when battery is low while charging). Suggestion: Blink rapidly when battery low when not charging; illuminate when charging; blink slowly when connected to power and full.

8: Power light. Current function: Lit when on, half brightness (?) when in powersave mode. Suggestion: Lit when on; blink in powersave mode (half brightness can be difficult to tell apart, especially in daylight).

Input appreciated.

 

[Prometheus]

It's not too helpful of me, I know, but on my unit (which has Hotfix 3 installed), I'm pretty sure that the red charging light also comes on and blinks once in a while when the battery is low.

 

[WizardStan]

Instead of blinking, I'd have it fade in and out in powersave mode. Too bad only the right LEDs are connected to the PWM; the left ones are all straight GPIO so either on or off.
5 and 6 do not contain any LEDs, although there are pads there for soldering on your own. Not sure whether they exist in the kernel or not though. If not, they should. KP_BL is in the kernel.

 

[peca]

I have some suggestions to improve intuitability of the LEDs and add to the amount of data they provide. I'm glad that they're all under software control.

LEDs numbered from left to right, 1234 5678.

1/2. Current function: SD activity (read, write, or both? not sure). Suggestion: Turn on LED when SD card is inserted and mounted; blink for activity

This is not necessary. I know when SD card is inserted and in which slot. But maybe occasional blinking that inform about proper mounting will be useful.

3: Wifi. Current function: lit when radio is active. Suggestion: Blink occasionally when radio is on but not connected; illuminate when connected to an AP; blink for activity
4: Bluetooth. Current function: lit when radio is active. Suggestion: Blink when bluetooth is set to discoverable; illuminate when paired; blink for activity

Yes, good Idea. For BT I sugest blink occasionally when on, the same but longer lit for discoverable...

5/6: I have no idea what these do. Never seen them illuminated. Are there even LEDs there?

They are not soldered.

7: Charging light. Current function: light when charging; flash when battery low (this can make things confusing when battery is low while charging). Suggestion: Blink rapidly when battery low when not charging; illuminate when charging; blink slowly when connected to power and full.
8: Power light. Current function: Lit when on, half brightness (?) when in powersave mode. Suggestion: Lit when on; blink in powersave mode (half brightness can be difficult to tell apart, especially in daylight).

I like this too.

 

[-Tj-]

@atomicthumbs:

I don't have my Pandora yet, but I do have some suggestions. Mainly, I know LEDs probably use a very negligible amount of power, but I would prefer them to stay off as much as possible for two reasons: same that minimal amount of power, and to be as unobtrusive as possible, except when necessary.

I'm half in agreement with you on the WiFi and Bluetooth, but again, kind of annoying if both Bluetooth and WiFi are on, flashing, and I'm trying to play a game at the same time (on the Pandora's screen).

Is powersave like standby? If it's like standby a slow blink would be nice.

 

[Bosbeetle]

please no blinking in low mode. Its on that mode when I sleep and I dont mind a few leds but blinking would be annoying!

 

[Loon]

What I'd like to see is an application that shows the current LED configuration and allows users to change the behaviour of the LEDs as required.

Not sure how difficult it would be to do this but it would be a nice addition to the Pandora OS.

 

[vadsamoht]

What I'd like to see is an application that shows the current LED configuration and allows users to change the behaviour of the LEDs as required.

This.

Start messing with the defaults and people will complain/get confused/etc. it would be nice to be able to set up a profile of your own, although I realise it's probably not the most urgent piece of software for the system.

 

[Fishbong]

It may look cool to have lots of blinking LEDs there, but won't it be annoying after a while? Especially when using the Pandora in the dark, with the display set to a low brightness level, i could imagine the bright blinking LEDs would be quite irritating.

 

[dflemstr]

Knowing the OP team, they'll probably implement blinking lights with "while $shouldBlink; do echo 1 > /dev/foo; sleep 1; echo 0 > /dev/foo; sleep 1; done".
And I dislike hacks as solutions to problems.
That dislike has largely evolved after seeing prior solutions to problems in the Pandora's software, that introduced other problems, etc...
(Yes, they lack the time to do stuff properly, but better not doing something at all than doing it sloppily)

Soooo...
To prevent someone from hardwiring this setup,
(while maintaining the illusion that this process is democratic)
I won't vote for any suggestion like "While BT is on, blink the light with a 0.2-0.3-0.2-0.4 interval".
I'll rather vote for something like "expose an API so that applications can listen to events such as 'BT paired' or 'BT in discoverable state', and expose an API for controlling LED blink patterns, and create a daemon that runs by default that uses sensible blinking defaults and is configurable".
It can be made to be extremely easy to configure, via e.g. udev events and a LED controller daemon.
Leverage existing technology!

 

[WizardStan]

I think I misunderstood something. You talk about using a script that blinks the LED on and off as a bad hack, and then about "exposing an API" which (to me) is basically the exact same thing.
Yeah, a little bit more needs to be exposed (no way that I can find to detect BT is paired, for example, just on/off) but once you've got that, the trigger... calls a script. Or any other executable really. Blink that LED however you want then.

 

[dflemstr]

I think I misunderstood something. You talk about using a script that blinks the LED on and off as a bad hack, and then about "exposing an API" which (to me) is basically the exact same thing.
Yeah, a little bit more needs to be exposed (no way that I can find to detect BT is paired, for example, just on/off) but once you've got that, the trigger... calls a script. Or any other executable really. Blink that LED however you want then.

When I say "hackish solution", I mean something like a CRON job that checks the BT status every second and then forks a child process that runs the script I posted. Which will have problems, outlined below.

My point is that there needs to be a "maintainable solution", so that, for example:

1. We avoid common problems so that:
   • The LEDs don't go psychedelic once two BT transfers run simultaneously
   • A race condition doesn't make the "BT transfer stopped" event disappear, leaving the LED blinking forever
   • The lights don't go black after resuming from suspend (or a low-power mode) just because there's no mechanism for resuming any LED check processes
   • The lights don't "stick" at their last state when suspending the device because the method of controlling the LEDs isn't aware of the machine's power status.
2. You can wire the system to other systems, like lm-sensors, or Solid, or ConsoleKit, or PowerDevil (I don't know which systems are used for this stuff in the Pandora...) so that the LED indication intervals (etc) can be influenced by other parts of the system automatically via common protocols without causing racing conditions.

tl;dr: Yes, eventually there'll just be a process that makes periodic syscalls (but no need to spawn a process or run a script because of that - far too expensive!) to control the LEDs, but there needs to be some level of abstraction involved.

 

[WizardStan]

When I say "hackish solution", I mean something like a CRON job that checks the BT status every second and then forks a child process that runs the script I posted.

So something like "Bluetooth turned on: run X; Bluetooth paired: run Y; Bluetooth pair lost: run Z;" type triggers should work, right? That what you mean? Kind of like the low battery warnings?
And then the clever author ties their X, Y, and Z programs together to handle the right thing, yes?

 

[MonkeyChops]

as long as I can configure it to do the knight rider effect when it's closed, I'll be happy.

 

[SomeGuy99]

as long as I can configure it to do the knight rider effect when it's closed, I'll be happy.

 

[dflemstr]

When I say "hackish solution", I mean something like a CRON job that checks the BT status every second and then forks a child process that runs the script I posted.

So something like "Bluetooth turned on: run X; Bluetooth paired: run Y; Bluetooth pair lost: run Z;" type triggers should work, right? That what you mean? Kind of like the low battery warnings?
And then the clever author ties their X, Y, and Z programs together to handle the right thing, yes?

More like: Create a D-Bus service that monitors the devices (via hardware-level polling or interrupts if possible... CRON jobs and scripts being ran every seconds take huge amounts of power so that's a no-no. Let the BT device tell when its status has changed, instead of doing constant checks), and make it possible for other D-Bus services to subscribe to events from this service.
Then also make a D-Bus service for controlling the LEDs (in one central location: *that* service has the "EnumLEDState blue = LEDStateOff/Blink/Whatever;" variable; the "current LED state" isn't stored in any other location).

Finally make one or more client processes that communicate with these services. The process that controls the "Radio enabled LED" for example should run as a system-wide process and listen to the sensor service, while the (potential) "Incoming IM message LED" controller process should be started with the specific IM application as a plug-in.

So the system would rely on a classical message-passing communications protocol (which is what most Linux services use nowadays anyways) and be completely scalable.

The grudge I have with - as you suggested - defining actual programs to be invoked when certain events occur, is that 1. you actually have to spawn a whole process for every event emission (even if the process doesn't actually need to do anything it gets started anyways) and 2. the system isn't "pluggable"; you can't add event listeners on the fly, or use different protocols than process-spawning for the event handling.

 

[jdbye]

It may look cool to have lots of blinking LEDs there, but won't it be annoying after a while? Especially when using the Pandora in the dark, with the display set to a low brightness level, i could imagine the bright blinking LEDs would be quite irritating.

I agree.
Though I'd prefer if the charging LED lit up properly when you plugged in the charger with a low battery level. Otherwise I don't know if it's actually charging or not.
Fading the power LED in powersave mode would be an improvement over half brightness as well, which is hard to differentiate in some cases. Fading would be less annoying than flashing in my opinion