SuperZaxxon v1.52 released!

[porg]

I want to enable L and R as song changers, starting xbindkeys when the lid is closed.

Yes yes yes! I already filed that suggestion in 2011-08-21.


And in 2012 I also read others asking for it, i.e. ian_j for asked it for Audacious.


I too would love this to work with Audacious, my favorite Pandora audio player.


Glad that someone with Pandora coding skills now considers realizing facilitating that buttons in closed lid mode!


Please update/link-to that issue in the tracker accordingly for transparency/synergies. Thanks.

 

[porg]

I have taken the charging + battery runtime issues very seriously!


[...]


Complete data (CSV and other plots as well)


[...]

Dear hardware experts!


@WizardStan @MWeston @DJWillis @squid ...


Could someone please reply to my issues:

• Charging patterns with unexpected pauses
  
• Charging near stalled already at 3000 mAh (~70-80%)
  

which I documented with charts and .CSV logs. Thanks!


UPDATE 2012-11-20: Given link was wrong (lead to sysinfo repo page instead of my report)

 

[Kosmos]

I ran op_standby from the cli and when it came back the CPU was set to 125mhz and the screen was at brightness=0.


This worked fine from 1.5 and running a script for this worked just like holding the power-button. Now the button works but the script has the above bug.


This lets me run long scripts and then I put the pandora in standby when complete. But this bug makes life difficult when it goes to 125Mhz and stays there. It is no longer returning to default when coming out of Standby.

Again, Any ideas?

 

[notaz]

Tries running with sudo?


Why do you need that in the 1st place?

 

[Kosmos]

Tries running with sudo?


Why do you need that in the 1st place?

I did...


I already said why... MORE INFO: I am doing some Arduino robotics work I am in need of Software Powerdown.


Now, I notice that this only happens when external power is used. Is there an easy way to check if power is external/charging or not? I am guessiing that charging is somehow preventing a proper standby mode... I can understand that and so need a simple test to not go into standby if charging...


Thanks

 

[lomaxx]

Something like "cat /sys/class/power_supply/bq27500-0/status", but I am not sure if it's right.


Because there are 2 more directories in the "power_supply" directory that both have a "status"-file that can be viewed. One is called "twl4030_ac" and one "twl4030_usb". I guess one is for the PSU-charge-input and one for the USB-charge-input. Maybe the "bq27500-0" is some battery-internal controller. I'm no expert on this topic.

 

[Kosmos]

thats enough to get me in the right direction. Thank You!

 

[lomaxx]

Since I have been doing some personal research about the charging-software-mechanism, I was trying to understand the way the charging-LED is being controlled. So far I do not completely understand it, but there are some things going on that I find a bit strange. Maybe they are bugs, so I want to report my discoveries and thoughts here.


LEDs are being controlled in "/sys/class/leds/". Each LED has it's own subdirectory. For example you can turn on the charging-LED by typing (as root):

echo "250" > /sys/class/leds/pandora\:\:charger/brightness

Turn it off with the value "0".



Additionally I found a init-script (/etc/init.d/led-config) that is run on system-start. This script echoes a "trigger"-value depending on the configuration stored in "/etc/default/leds" into the file "trigger" of each LED-subdirectory in "/sys/class/leds/". If you "cat" that file, you get for the charge-LED the following output:

cat /sys/class/leds/pandora\:\:charger/trigger

[none] nand-disk bq27500-0-charging-or-full bq27500-0-charging bq27500-0-full bq27500-0-charging-blink-full-solid twl4030_ac-online twl4030_usb-online mmc0 mmc1 mmc2 timer heartbeat backlight gpio default-on

As far as I understand you can set some trigger this way. The one currently shown is the the one printed in [], which is "none" by default. If you "echo" one of the listed triggers you can activate that trigger. The strange thing is that "/etc/default/leds" sets the trigger "twl4030_bci_battery-charging", which obviously does not exist. So IMHO this is a mistake in "/etc/default/leds".


Unfortunately I do not understand the benefit of setting that trigger. For now. So I can't judge the importance of this. Any info on this would be welcome.


Next, while searching for an answer to the question "What turns the LED on/off?", I found an info that pndevmapperd somehow is involved. So i browsed it's sourcecode and found indeed a part where it turns the LED on/off by sending integer-values to the "brightness"-file. Now here comes the next strange part:


When I kill pndevmapperd, then the LED still nicely turns on/off when I plug in/out the AC- or USB-cable. So something else is controlling the LED too.


Is this maybe a reason for the LED-confusion that is going on? IMHO only one of them should control the LED.


Last but not least I again paid attention to the behavior of the charge-LED when you take the turned-off Pandora, plug in the AC-cable and make it boot this way. The LED is turned off after boot, but the Pandora IS charging. So this is a flaw in the startup-scripts. Would it be wise to put a small code in one of the startup-scripts (e.g. either in /etc/init.d/led-config or /etc/init.d/pndevmapperd-init) that checks the status of the battery-charging and lights the LED if it is charging?


I'm still unsure about the whole method being used, which is also the reason why I write this. If you know more about it, then please let me know.

 

[Linux-SWAT]

Some leds are going on even before the kernel is loaded, so i presume it's a hardware thing.

 

[lomaxx]

Addition to my last post:


The last line of "/etc/pandora/conf/eventmap" looks like this:

devices		    twl4030_bci_battery twl4030_ac twl4030_usb

Does the "twl4030_bci_battery" maybe need to be replaced by "bq27500-0" as "/sys/class/power_supply/" lists those three directories?


The "heartbeat" trigger for the charge-LED works, but all those related to the batteries/power-plugs seem not to take any effect. But my Pandora is currently at 100% charge so i can't test it very well.

 

[lomaxx]

woot! LED turns on after reboot. Need to make more tests.


Edit: My excitement rose too early. I don't know why it lit - I'm not even sure if it did or if I hallucinated/got confused - but the LED still does not light when booting by plugging in the charger.

 

[notaz]

As far as I understand you can set some trigger this way. The one currently shown is the the one printed in [], which is "none" by default.

Not true, default one for power is bq27500-0-charging (determined by kernel).

The strange thing is that "/etc/default/leds" sets the trigger "twl4030_bci_battery-charging", which obviously does not exist. So IMHO this is a mistake in "/etc/default/leds".

You're right here, that value is only valid for 2.6 kernel. On 3.2 it tries to set invalid trigger, and that write is simply ignored, so default stays and it still works. I think that /etc/default/leds entry should simply be removed so that default stays and works both on 2.6 and 3.2. Would be cool if you did a git patch against http://git.openpando...ee10c89;hb=HEAD , if not maybe I'll do it, someday..

Next, while searching for an answer to the question "What turns the LED on/off?", I found an info that pndevmapperd somehow is involved. So i browsed it's sourcecode and found indeed a part where it turns the LED on/off by sending integer-values to the "brightness"-file. Now here comes the next strange part:


When I kill pndevmapperd, then the LED still nicely turns on/off when I plug in/out the AC- or USB-cable. So something else is controlling the LED too.


Is this maybe a reason for the LED-confusion that is going on? IMHO only one of them should control the LED.

You've probably found the root cause here. pndevmapperd's job is to blink the LED when battery is low as the kernel doesn't offer such functionality, and that works. But what it doesn't do is handing LED control back to kernel by setting the trigger when it's done blinking. It might be that 2.6 kernel did not drop kernel trigger when you write to /sys/class/leds/.../brightness, but 3.2 kernel does, so things break. Obvious fix would be to patch pndevmapperd to set trigger back when it's finished blinking, as it's better to avoid hacking the kernel as it's likely to be updated in future.


Again a git patch would be cool, but if nobody does do anything I'll have to get to it when there is time and if I don't forget. Or somebody could try nagging skeezix..

Last but not least I again paid attention to the behavior of the charge-LED when you take the turned-off Pandora, plug in the AC-cable and make it boot this way. The LED is turned off after boot, but the Pandora IS charging. So this is a flaw in the startup-scripts. Would it be wise to put a small code in one of the startup-scripts (e.g. either in /etc/init.d/led-config or /etc/init.d/pndevmapperd-init) that checks the status of the battery-charging and lights the LED if it is charging?

That's kernel's job, it's probably pndevmapperd disabling the trigger..

Addition to my last post:


The last line of "/etc/pandora/conf/eventmap" looks like this:

devices		 twl4030_bci_battery twl4030_ac twl4030_usb

These are here for overcharge protection, nothing to do with LEDs.

 

[porg]

Glad, that some-one (@lomaxx) is investigating this unsatisfying issue!


The whole charging process and its monitoring (LEDs and software gauge) is yet very unsatisfying on the Pandora.


OpenPandora is a community project, yes, but this essential part is the responsibility of the core team, IMHO — I expected at least this to work out of the box.


Glad that high profile dev @notaz responds to this, probably involves @skeezix as well. Sounds promising.


I am also still awaiting an answer to my observed charging troubles.

 

[lomaxx]

These are here for overcharge protection, nothing to do with LEDs

Ok, but anyway: "twl4030_bci_battery" is correct for both kernel-versions?


I deleted the line for the charging-led from "/etc/default/leds" and rebooted the system, but "/sys/class/leds/pandora\:\:charger/trigger is still set to "none" when i cat it right after booting. Not to "bq27500-0-charging" like I expected from your explanation.

 

[lomaxx]

Something else. For quite a while I am booting from SD-card with disabled splashscreen since i prefer to see the messages. Though I am surprised that I didn't take notice of it before, I now stumbled across an insmod-error-message as the last line of the boot/init-process:

insmod: can't read ´/lib/modules/3.2.30/kernel/drivers/gpu/pvr/bufferclass_ti.ko´: No such file or directory

What's that about? Worth mentioning it?

 

[lomaxx]

I found a page (for the raspberry pi though) that mentions:

Setting the brightness to 0 automatically sets the trigger to "none".

Tried it and it's the same for the Pandora. So this is almost what Notaz suspected and should be kept in mind.


But if pndevmapperd would be the only source of the problem, then the LED should light while booting the kernel and (if at all while starting) first be turned of when devmapperd started. Shouldn't it? It doesn't light up at all (for me), unless I plug it out after booting, wait a few seconds and plug it in again.

 

[notaz]

Ok, but anyway: "twl4030_bci_battery" is correct for both kernel-versions?

no, but pndevmapperd is smart enough to pick the right one.

I deleted the line for the charging-led from "/etc/default/leds" and rebooted the system, but "/sys/class/leds/pandora\:\:charger/trigger is still set to "none" when i cat it right after booting. Not to "bq27500-0-charging" like I expected from your explanation.

I said it has no effect, you should disable pndevmapperd instead.

insmod: can't read ´/lib/modules/3.2.30/kernel/drivers/gpu/pvr/bufferclass_ti.ko´: No such file or directory

What's that about? Worth mentioning it?

I don't know, TI ships it with their drivers, Nokia doesn't, this came after switching to Nokia ones, no negative effects noticed.

But if pndevmapperd would be the only source of the problem, then the LED should light while booting the kernel and (if at all while starting) first be turned of when devmapperd started. Shouldn't it? It doesn't light up at all (for me), unless I plug it out after booting, wait a few seconds and plug it in again.

It does for me, no idea why it doesn't for you, maybe it's SD boot related?

 

[Wrath Of Khan]

Hmm im having some odd issues with my 1ghz pandora. Not sure if its the touchscreen itself or software related. Most of the time the touchscreen does not work. However sometimes upon booting up the touchscreen again works. The calibration cannot be set as this then renders the touchscreen inert again. If i touch the screen with the stylus when the screen is working the mouse arrow appears about 7 millimetres away ie its improperly calibrated. Today my pandora has also started to not wake up after sleep mode. If I push the power switch to the right and it eneters sleep mode I cannot wake it up. Removed battery for several minutes, Re-flashed pandora but no luck. i find that it is as if the nubs or touchscreen is locked or depressed as the mouse arrow often becomes stuck in drag mode,odd. I will try another full re-flash tomorrow. If no luck i will send it to edd for repairs. i may wait awhile before sending it in.

 

[EvilDragon]

Sounds like the top lid is not snapped on properly or there is some bigger dust particle between the screen and the bezel.


That can trigger the touchscreen and therefore the mouse cannot be moved, neither with the touch nor the nub.


Use your fingernail or a piece of paper and go all the way around the screen below the bezel to make sure it's clean and also make sure it's fully snapped it.


After that, calibrate the touch.

 

[Wrath Of Khan]

^^^^^cheers ed Ill give that a try.