Lcd Turning On When Lid Is Closed

[aliking]

Has anyone else seen this? Occasionally, when I pull the Pandora out of my pocket, it feels a little warmer and I can see (through the slightly lifted left side ) that the screen backlight is on. It's not a huge deal, but it depletes the battery faster than I'd like.

Presumably there is just a script that turns the screen off as it detects that the lid is closed, and one that turns it on when it stops detecting that. I don't know if we could need a periodic script that checks if the lid is closed and makes sure the screen is off - depends on whether this is just me or everybody

a

 

[MonkeyChops]

mine does that too.
could be this known bug I suppose:
http://bugs.openpandora.org/index.php?do=details&task_id=94&project=1&pagenum=3

 

[skeezix]

yeah, maybe you jiggled the battery lose for a split second causing a reboot?

jeff

 

[aliking]

Oh no, it's not rebooted. I'd be much more worried if it did that in my pocket. It's just that the light turns on.

I've done some experimenting with it and I can also reproduce this by very quickly opening the lid a fraction and closing it. I'd be very surprised if it was opening in my pocket, but for some reason it seems to think it is.

 

[WizardStan]

This was reported before. It only seems to happen when in someone's pocket however, which makes me think something is bumping the switch.
If you put it to sleep and then wake it up while the lid is still closed, the backlight will come on. This should get fixed.
Have you been putting it to sleep before putting it in your pocket? You can check changes to the status by typing "dmesg" in a terminal (watch out, there may be a lot of data): you're looking for the lines "set_opp: OPP 1 set" (into low power mode) and "set_opp: OPP 3 set" (back to normal)
If you aren't putting it to sleep, you shouldn't see those. If you are putting it to sleep and there is a bug, you should only see the OPP 1 one, not the OPP 3. If it's getting bumped in your pocket, you'll see both.

 

[aliking]

I'm not putting it to sleep. I came to the conclusion that it saved me almost no battery and meant that I had to wait longer to use it when I wanted to.

It seems to be getting worse for me, has happened 5 times this morning already. And I always keep it in my pocket. There's really no room in there for it to bump open, this is my front pants pocket that we're talking about. So either something is bumping and moving the sensor around, or maybe the heat in my pocket has something to do with it?

Is this behavior controlled by a script (and if so, anyone know which one?), or is it lower-level than that? I'd be interested to see if there was some way to track the reading from the Hall effect sensor over a period.

a

[edit] alright, it is somewhat controlled by a script, /usr/bin/scripts/op_lid.sh and it's called with 0 for lid open or 1 for lid closed. So a better question is - how is that called and can the current sensor value be queried?

For now I've added some debug code to the script to see when it's getting called.

 

[WizardStan]

Wait? What wait? Coming back from sleep takes one second. Putting it into low power mode should also save 20% battery beyond just closing the lid, and it should only get better going forward.
At any rate, I wish you'd check dmesg just to completely rule out low power mode being accidentally activated with a bump.
The lid is detected by a hall sensor which is activated by the magnet in the speaker on the right side of the lid. You can simulate it by putting a magnet around the enter key. To the best of my knowledge there's no simple way of detecting it's actual state. As far as I know it's on a GPIO, so it's entirely possible to write a program to query it in memory, I just don't know what location I would have to look in.
If you can, edit the op_lid.sh file ("sudo vi op_lid.sh", or "gksudo mousepad op_lid.sh", whichever you're most comfortable with) and add the lines

echo `date` >> /tmp/lidstatus
echo $1 >> /tmp/lidstatus

near the top (under the # lines). That'll write a timestamp to the file /tmp/lidstatus every time the lid is opened or closed. Note the time, close it, put it in your pocket and walk around. Later you open it, see if it registered the lid being opened while it was in your pocket.

Now that I've thought on it, it's entirely possible the speaker is not sitting perfectly in the case and may be shifting just enough that it stops registering when being jostled around in your pocket.

edit: Ninja'd by your edit

 

[aliking]

All good thoughts. I did check dmesg and it's definitely not low power mode. And as for that; I don't know about you, but my Pandora when closed and in low power mode takes 4-5 secs to open and come out of sleep. Which annoyed me more than a 20% saving was worth. With or without an extra 20%, I get 1 day of use, so I'm not using it until such time as there is a better powersave mode.

Anyway here is some of the log I've collected. 0 is op_lid.sh called with an open lid event, 1 is it called with a close lid event. I've added a star by the ones that I didn't intentionally do myself.

Thu Feb 10 13:21:40 GMT-5 2011 ---- 0
Thu Feb 10 13:22:02 GMT-5 2011 ---- 1
Thu Feb 10 13:34:37 GMT-5 2011 ---- 1 *
Thu Feb 10 13:37:31 GMT-5 2011 ---- 0 *
Thu Feb 10 13:41:41 GMT-5 2011 ---- 0
Thu Feb 10 13:42:53 GMT-5 2011 ---- 1

This is just one instance of several, what I'm missing is tracking my movements at the time, but I'm pretty sure I was just sitting here, which makes me think more towards heat or possibly I'm generating my own magnetic field with my midichlorians.

now added a beep to the script so I can see what I'm doing when it happens...

 

[skeezix]

IT could be open/closing _very quick_; theres a 'spam suppression' tiny bit in pndevmapperd (mostly for keyboard .. don't want too many events to come too quick in some cases.) But if the lid opens/closes _Really close together_ it coudl well trip that up. I knew about that case in the abck of my head but didn't think it'd be an issue when I wrote it .. evidently forgot the 'pocket edge case'

Try open/close really quick, can you get it out of sync or confused, or does it work ok? (ie: Can you get it to stay off while open by going up/down really quick?) IF so, thats our man, and I can patch pndevmapperd to not have that condition for lid-events (or non-key events.)

jeff

 

[WizardStan]

I also added some basic debugging to mine, and funny thing, I see a lot of similar superfluous open and close messages. It's always open, then closed one second later, but the fact that there's any makes me wonder. The last time seems to be from when I put it in my bag on the floor, which was 5 hours ago. No matter how I bump it or whatever, I can't seem to get it to misbehave again. So yeah, curious. Probably just the hall sensor losing the magnet for a second for some reason, which is fine for me, such devices are far from perfect, but why doesn't yours seem to pick it up again?

Anywho, it takes less than a second between flipping the power switch and it coming back to life. 5 seconds is quite a long time.

 

[MWeston]

Maybe the odd speaker magnet isn't strong enough to keep the sensor tripped in the base. Perhaps another test would be to tape a small chunk of fridge magnet in there for a day and see if it keeps doing this. It might be good to rule out hardware here.

 

[aliking]

IT could be open/closing _very quick_; theres a 'spam suppression' tiny bit in pndevmapperd (mostly for keyboard .. don't want too many events to come too quick in some cases.) But if the lid opens/closes _Really close together_ it coudl well trip that up. I knew about that case in the abck of my head but didn't think it'd be an issue when I wrote it .. evidently forgot the 'pocket edge case'

Try open/close really quick, can you get it out of sync or confused, or does it work ok? (ie: Can you get it to stay off while open by going up/down really quick?) IF so, thats our man, and I can patch pndevmapperd to not have that condition for lid-events (or non-key events.)

jeff

I can indeed. I'd already reproduced having the light on when closed by waggling the lid a bit, and I've just managed to have it stay off when open. I'd assumed it was something like this, but do you think it would work to just have all the events fire triggers? Since the lid script takes some time to run and write values out, there might be unforeseen results if there are two versions of the script running in very quick succession.

What I was thinking of roughly was an extra check in the script to just be sure that the lid is still in the state that the script was called with. Is is easy to check the current state of the sensor?

Maybe the odd speaker magnet isn't strong enough to keep the sensor tripped in the base. Perhaps another test would be to tape a small chunk of fridge magnet in there for a day and see if it keeps doing this. It might be good to rule out hardware here.

I can certainly give this a try when I can get my hands on a fridge magnet, but I'm not suspecting the magnet itself here. When I open my Pandora, the lid sensor isn't triggered until it reaches about 7mm open on the front edge, so fully closed, the magnet isn't even close to the threshold of tripping the switch.

Hey thanks for all the help on this. I'm still geeking out that it's *possible* to just add debug code to part of the system to see what's going on here. Gotta love the Pandora..

a

 

[skeezix]

I'll make a note to look into the pndevmapperd code and see if the spam limiter is causing us heartache this round; could just reduce the spam limiter timeframe, or have a different timeframe per event type or something.

jeff