Trying to fix the backlight bug...

Discussion in 'Pandora OS (SuperZaxxon GNU/Linux)' started by Zink, Jun 16, 2016.

  1. Zink

    Zink Member

    Joined:
    Mar 8, 2012
    Messages:
    169
    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?
     

    Attached Files:

    directive0 likes this.
  2. _jr_

    _jr_ Advanced Member

    Joined:
    May 5, 2013
    Messages:
    1,170
    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.
     
  3. sulu

    sulu Guest

    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
     
  4. Zink

    Zink Member

    Joined:
    Mar 8, 2012
    Messages:
    169
    _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.
     
  5. edgex004

    edgex004 Advanced Member

    Joined:
    Jan 5, 2008
    Messages:
    1,159
    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.
     
    directive0 likes this.
  6. _jr_

    _jr_ Advanced Member

    Joined:
    May 5, 2013
    Messages:
    1,170
    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).
     
  7. notaz

    notaz Certified Guru

    Joined:
    Aug 23, 2005
    Messages:
    4,908
    Location:
    Lithuania
    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.

    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.

    acpi is x86-only thing.

    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.
     
    _jr_ likes this.
  8. Zink

    Zink Member

    Joined:
    Mar 8, 2012
    Messages:
    169
    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).

    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.
     

    Attached Files:

    _jr_ likes this.
  9. sulu

    sulu Guest

  10. _jr_

    _jr_ Advanced Member

    Joined:
    May 5, 2013
    Messages:
    1,170
    Nice! Have to remember that.


    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.
     
  11. notaz

    notaz Certified Guru

    Joined:
    Aug 23, 2005
    Messages:
    4,908
    Location:
    Lithuania
    I have not attempted to fix it, I just don't have that problem.

    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?
     
  12. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    9,841
    Location:
    Somewhere off the coast of the EU
    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.
     
  13. Zink

    Zink Member

    Joined:
    Mar 8, 2012
    Messages:
    169

    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 :)

    Done, the script attached. Seems to be working fine.

    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.
     

    Attached Files:

  14. notaz

    notaz Certified Guru

    Joined:
    Aug 23, 2005
    Messages:
    4,908
    Location:
    Lithuania
    Looks good from a quick look, thanks, I'll all it when I can find some time to test it.

    IIRC it's not, so should be fine I guess, yes.

    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.
     
    _jr_ likes this.
  15. notaz

    notaz Certified Guru

    Joined:
    Aug 23, 2005
    Messages:
    4,908
    Location:
    Lithuania
    OK testing went well, so update published.
     
    Zink likes this.
  16. Zink

    Zink Member

    Joined:
    Mar 8, 2012
    Messages:
    169
    Did you make the option to switch between new and old behaviour?
     
  17. notaz

    notaz Certified Guru

    Joined:
    Aug 23, 2005
    Messages:
    4,908
    Location:
    Lithuania
    Sort of, if someone has problems he can create /etc/pandora/my_lid_is_broken to get the old behavior.
     
    _jr_ likes this.
  18. Zink

    Zink Member

    Joined:
    Mar 8, 2012
    Messages:
    169
    Should be enough. It's not a user preference, but rather an emergency aid in the end.
     
  19. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    9,841
    Location:
    Somewhere off the coast of the EU
    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.
     
  20. notaz

    notaz Certified Guru

    Joined:
    Aug 23, 2005
    Messages:
    4,908
    Location:
    Lithuania
    Neelix and _jr_ like this.

Share This Page

Loading...