Trying to fix the backlight bug...


Zink

Member
Joined
Mar 8, 2012
Messages
170
There is a bug, reported long time ago, but never fixed: if the lid close action is set to "Turn off the screen", then when the lid is closed on a powered on Pandora, the screen gets turned off as intended. But after the automatic screen blanking period (around 15 minutes, I think) if a shoulder button is pressed, the screen turns on and will never go off again (until the lid is opened and closed again).

This is somewhat annoying for people listening to audio on Pandora, as when Pandora is in a pocket, the shoulder buttons can get easily pressed by accident, significantly lowering the battery life (not mentioning the backlight life).

And it just got unbearably annoying, as I have found a way to bind the right shoulder button to DeaDBeeF's pause function (after 3 years!), so I can pause playing without taking Pandora out of the pocket. But when I press the shoulder button, the screen goes on, and won't turn off by itself!

So my approach was this:
1. The /usr/pandora/scripts/op_power.sh file defines what happens to the backlight in various situations. There is a function display_on(), which does what its name says, so it should be enough to add a simple check whether the lid is up, and do nothing if it isn't.
2. But there is a problem: no easy way to check the current state of the lid.
3. So I have written this simple program, lidstate, that will echo 0 or 1 depending on the current lid state (source and binary attached).
4. Then I have added the following code to the dislpay_on() function:

if [ $(lidstate) = "1" ]; then
return 0
fi

And this works, but has a bad side effect: if the lid is down for more than 15 minutes, opening it won't turn on the screen. Nor will pressing any buttons, or moving the nubs. I have to close the lid again, and open it for the second time to make the screen lit. I don't understand why that is. If you have any ideas, please tell.

I would like to debug it, but I don't know how. the op_power.sh file contains some debug echos, and I tried adding my own echos, but I don't know where the output from the echo goes. I can't see it on the terminal. How can I display anything from the scripts when they are called by the system?
 

Attachments

  • lidstate.zip
    4.1 KB · Views: 551
You'll see it on vt1. You could either bind a key to switch VTs (for some reason such a binding only works on the gamepad part of the keyboard for me) or use the chvt command (I forgot the actual name, something like this). Or you could change the script to append the debug output to a file.
 
If I interpret [1] correctly, then the event code you're checking doesn't report the state of lid open/closed, but rather the action of opening/closing the lid.
So what happens is when you close the lid, the action is reported, which turns the display off. The action of pressing a shoulder button turns the display on again. But since there will be no further lid-closing action, the display will stay on.

What you need to do is to either remember the last lid action (e.g. in an environment variable or in a file), or actually look at the state, instead of the action.

If your kernel has an acpi interface (which I don't know), have a look at: /proc/acpi/button/lid/LID/state
If that file contains reasonable data (i.e. reports "open" on an open lid and "closed" on a closed lid), you can use that info, to trigger your screen.


[1] https://www.kernel.org/doc/Documentation/input/event-codes.txt
 
_jr_, thanks. It's vt2 actually. By the way: is that normal that Ctrl+Alt+(Fn)+Fx don't work on Pandora? I had to "sudo chvt -t 2".

sulu, I understand that the op_power.sh is called on various events, one of which is changing the lid state. My program, "lidstate", on the other hand, calls the input driver through ioctl and checks the SW_LID switch state, so it should read the lid state in real-time, and it seems to be working (I have checked). So in theory, when a button is pressed, the op_power.sh -> display_on() is called, it checks the current lid state (closed), and does not do anything. But when the lid is opened, the display_on() is called, checks the lid state (open) and turns on the screen. If the latter doesn't work, it could be because of some race condition, or I don't know what.
 
I would greatly appreciate if you can get this working. The screen turning on while the lid is closed has always been very annoying. I sometimes thought it was happening because a notification came up (such as WiFi connection lost) that turned the screen on again.

I never did anything about it, because even with the screen on my Pandora's battery life is very good.
 
By the way: is that normal that Ctrl+Alt+(Fn)+Fx don't work on Pandora? I had to "sudo chvt -t 2".
Yes. The default xkbd layout has these bindings, but they get removed by the xmodmap call in the session startup script. But vt switch bindings don't seem to work on the alphanumeric part of the pandora keyboard anyway (which is probably the reason why they are removed). I've mapped switch to vt to the Pandora key, which works fine (and switching on the non X vt's works as expected).
 
But after the automatic screen blanking period (around 15 minutes, I think) if a shoulder button is pressed, the screen turns on and will never go off again (until the lid is opened and closed again).
And that is really strange, I've tried to reproduce and it is not the case for me (the screen happily blanks after 10 minutes without touching the lid). Are you on some old firmware? There were some changes to that script recently.

How can I display anything from the scripts when they are called by the system?
I know this has been answered, but you can also do "/etc/init.d/pndevmapperd-init restart" in some terminal and the messages will then go to it.

If your kernel has an acpi interface
acpi is x86-only thing.

But vt switch bindings don't seem to work on the alphanumeric part of the pandora keyboard anyway
Yeah, I wonder why. Haven't really dug into it, but it's one of those annoying things similar to shift-backspace being impossible to bind as del.
 
And that is really strange, I've tried to reproduce and it is not the case for me (the screen happily blanks after 10 minutes without touching the lid). Are you on some old firmware? There were some changes to that script recently.
Ah, you're right. I have upgraded to the newest firmware, but haven't tested again if the screen would stay on forever. I only saw that the shoulder buttons turn the screen on regardless of the lid position, and assumed the backlight persistence has not been fixed too (and haven't found any mention about that in the change logs).

I know this has been answered, but you can also do "/etc/init.d/pndevmapperd-init restart" in some terminal and the messages will then go to it.
Thanks, this looks like the most convenient option.

Alright, I have finally did it. The problem was that when pressing a shoulder button after the 15-minute period after closing the lid the powerstate was changed from "liddisplayoff" to "on" without the screen turning on. Then when the lid was opened the script thought the screen was on (because the powerstate was "on"), and did not try to turn the screen on again.

I have replaced all powerstate="on" with my function that checks the lid state and sets powerstate to "on" when the lid is up, and to "liddisplayoff" when the lid is down. This has a positive side effect that the screen won't turn on also when connecting a charger with the lid closed.
I have also replaced the simple $(lidstate) = "0" check with a function that checks if the lidstate program actually exists, and always report lid open if not. Just to be on the safe side.

I have attached the modified op_power.sh. Notaz, maybe you could add the modifications to the next firmware update? I know the screen won't stay on forever on the current version, but I think not turning it on at all when the lid is closed is much better way.
The lidstate program is in the first post. I have not modified it since. It should be copied to /usr/bin.
 

Attachments

  • op_power.zip
    3.3 KB · Views: 557
I know this has been answered, but you can also do "/etc/init.d/pndevmapperd-init restart" in some terminal and the messages will then go to it.

Nice! Have to remember that.


Yeah, I wonder why. Haven't really dug into it, but it's one of those annoying things similar to shift-backspace being impossible to bind as del.

The Delete binding actually does work, but the modifier is not SHIFT, because the keycode is associated with a different key class by the xkbd mapping (CTRL+ALT; see https://www.pyra-handheld.com/boards/threads/xmodmap-help-needed.77160/#post-1371239 for an equivalent xkb keymap file).

The vt switch action is different. Mapping the combination to any keysym works fine, but an action is ignored when it is attached to a keycode from the alphanumeric part. I played around with only setting the keymap for the individual input device (and not for the combined one), but that didn't seem to make a difference. I was too lazy to look at the source.
 
Ah, you're right. I have upgraded to the newest firmware, but haven't tested again if the screen would stay on forever. I only saw that the shoulder buttons turn the screen on regardless of the lid position, and assumed the backlight persistence has not been fixed too (and haven't found any mention about that in the change logs).
I have not attempted to fix it, I just don't have that problem.

The lidstate program is in the first post. I have not modified it since. It should be copied to /usr/bin.
I did not like the "based on Chromium OS" statement so added something that's different but hopefully equivalent:
https://git.openpandora.org/cgi-bin...d58ce844355534603430c6971baa326303407;hb=HEAD
It's also named op_lidstate to be consistent with other op_* tools already in firmware, it should get installed if you run a OS update. Could you update the script to use that and retest?

Also, what do you think about people with tv-out editions or broken lid switch, can your changes cause any problems for them?
 
It shouldn't be a problem for tv-out only units, since it doesn't matter to them whether the LCD is on or off - the LCD connector's not connected to anything, so even if the PCB is supplying a voltage to the backlight it can't draw any current therefore it uses no battery power.

If you implemented the ext port TV out blanking thing we discussed in the idle thread it might make a difference, although my unit does have a lid and a speaker in the appropriate place so I wouldn't be able to test that.
 
I did not like the "based on Chromium OS" statement so added something that's different but hopefully equivalent:
https://git.openpandora.org/cgi-bin...d58ce844355534603430c6971baa326303407;hb=HEAD
https://git.openpandora.org/cgi-bin...d58ce844355534603430c6971baa326303407;hb=HEAD
I did not like it too, but I couldn't find any reference specs for EVIOCGxxx ioctls, and that was the only example I found that I was able to comprehend :)

It's also named op_lidstate to be consistent with other op_* tools already in firmware, it should get installed if you run a OS update. Could you update the script to use that and retest?
Done, the script attached. Seems to be working fine.

Also, what do you think about people with tv-out editions or broken lid switch, can your changes cause any problems for them?
I don't know about tv-out. I don't have the cable to test. Is it affected by "echo 0 > /sys/class/graphics/fb0/blank" ? If not, then it should not be affected by my changes too. If yes, the tv-out will be blanked as the screen would (which means it won't turn on on button press while the lid is closed). But the first of the modifications proposed below will solve that.

For a broken lid switch: it depends on the reported lid state. If the reported value is always up - it won't change anything from the current behaviour. If the value is always down - it will prevent the screen from turning on at all. I think this may be solved by two modifications:
1. Additional screen setting to enable/disable my changes: needs just adding another condition in the op_power script::is_lid_open function - if the setting is on, the function should behave normally - the screen won't turn on while the lid is closed. If the setting is off, the function should ignore the reported lid state and always return the lid open.
2. A modification to the op_power script that I have already made: now the screen will be always turned on when waking Pandora from power-down or suspend, even if the lid is closed. This way if someone's lid sensor is broken so the reported value is always closed, he will be able to turn on the screen by suspending and waking the Pandora (and won't have that problem again after changing the setting from point 1).

If you are going to introduce the script with my modifications to the firmware, please review it before, because I don't fully understand it, and I may have made a mistake. In particular I could not make the script to enter the "resume" function, thus I could not test how it will behave there.
After enabling debug I could see the "resume" output on the console after flipping the power switch for the second time, but without debug it didn't seem to be called while resuming. I have added an echo at the beginning, but it was never displayed.
 

Attachments

  • op_power.zip
    3.3 KB · Views: 525
Done, the script attached. Seems to be working fine.
Looks good from a quick look, thanks, I'll all it when I can find some time to test it.

I don't know about tv-out. I don't have the cable to test. Is it affected by "echo 0 > /sys/class/graphics/fb0/blank" ?
IIRC it's not, so should be fine I guess, yes.

If you are going to introduce the script with my modifications to the firmware, please review it before, because I don't fully understand it, and I may have made a mistake. In particular I could not make the script to enter the "resume" function, thus I could not test how it will behave there.
It's for the old 2.6 kernel that did not have working suspend to RAM, and while charging I think (because battery monitoring process needs to keep running while charging, suspend to RAM is not entered while charging). On 3.2 everything is frozen in the middle of suspend_real so after that returns, the actual resume has already happened and there is no need to call that resume function.
I also don't know everything about that script, multiple people worked on it and it's a bit of a mess, to be honest.
 
Did you make the option to switch between new and old behaviour?
 
Should be enough. It's not a user preference, but rather an emergency aid in the end.
 
Sort of, if someone has problems he can create /etc/pandora/my_lid_is_broken to get the old behavior.
Out of interest, are you documenting these hidden behaviours on the Pandora somewhere, or somewhere on the internet that I can bookmark? Cos I can see myself in the future having a vague recollection of this stuff but not being able to find the thread it's documented in.
 
Back
Top