819431 - Seems impossible to prevent pandaboard (or at least its HDMI output) from going back to sleep

Status: RESOLVED WONTFIX

(Core Graveyard :: Widget: Gonk, defect, P1)

Description

[William Lachance (:wlach)]

You can reproduce this problem by running an eideticker test, which attempts to run this script. The screen should stay on after the test completes, but instead it dies just a few minutes later.

To set up / run eideticker see the instructions in: 

http://github.com/mozilla/eideticker

To run the actual test that reproduces the problem:

./bin/runtest.py --no-capture --device-type b2g src/tests/b2g/appswitching/appswitching.py

Comment 1

[Jonathan Griffin (:jgriffin)]

We should note that the script sets the screen timeout to 0 programmatically, so it isn't the normal screen timeout which is occurring.

Comment 2

[William Lachance (:wlach)]

Here's the code which is supposed to perma-unlock the screen:

https://github.com/mozilla/mozbase/blob/master/mozb2g/mozb2g/b2gmixin.py#L169

Comment 3

[Jonathan Griffin (:jgriffin)]

I've seen this as well.  It seems quite random, and does not resolve by turning the screen on programatically ala https://github.com/mozilla/gaia-ui-tests/blob/master/gaiatest/atoms/gaia_lock_screen.js#L13.  Once it happens, the only resolution is to restart B2G.

Comment 4

[Alex Keybl [:akeybl]]

William - please make this a top priority today, and ping me in IRC if you need any dev help. I'll find the right people.

Comment 5

[Alex Keybl [:akeybl]]

Faramarz/Andrew - William suggested he's not in the best position to perform this engineering investigation. Who could look at this early this week?

Comment 6

[William Lachance (:wlach)]

(In reply to Alex Keybl [:akeybl] from comment #5)
> Faramarz/Andrew - William suggested he's not in the best position to perform
> this engineering investigation. Who could look at this early this week?

I guess I'd add that although I don't feel I have the background to do this in a timely manner (or at least guarantee anything), I'd be quite happy to assist with this bug in any way I can -- hopefully learning more about how the Panda/Android/B2G video out subsystem works in the process so I can start looking at stuff like this in the future. :)

Comment 7

[Andrew Overholt [:overholt]]

(In reply to Alex Keybl [:akeybl] from comment #5)
> Faramarz/Andrew - William suggested he's not in the best position to perform
> this engineering investigation. Who could look at this early this week?

mwu or tzimmerman?

Comment 8

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I'm quite busy ATM, sorry.

Comment 9

[Thomas Zimmermann [:tzimmermann] [:tdz]]

If you just want something one the screen, you can apply the workaround in bug 818506 and push the board's GPIO button whenever the display turns black.

Comment 10

[Thomas Zimmermann [:tzimmermann] [:tdz]]

s/one/on

Comment 11

[William Lachance (:wlach)]

The patch in https://bugzilla.mozilla.org/show_bug.cgi?id=817730#c47 may be useful here. Investigating.

Comment 12

[Thomas Zimmermann [:tzimmermann] [:tdz]]

dhylands told me that the screen timeout (in seconds) can be configured by setting screen.timeout in gaia/build/settings.py. What happens if you set it to a high value (e.g., hours)?

Comment 13

[Jonathan Griffin (:jgriffin)]

(In reply to Thomas Zimmermann from comment #12)
> dhylands told me that the screen timeout (in seconds) can be configured by
> setting screen.timeout in gaia/build/settings.py. What happens if you set it
> to a high value (e.g., hours)?

FWIW, I've seen this HDMI problem during gaia smoke tests too, on the panda.  We have code already that sets screen.timeout to 0 (which disables the screen timeout), and I still see this HDMI issue.  I do not see it on an unagi, just the panda.

Comment 14

[William Lachance (:wlach)]

(In reply to Thomas Zimmermann from comment #12)
> dhylands told me that the screen timeout (in seconds) can be configured by
> setting screen.timeout in gaia/build/settings.py. What happens if you set it
> to a high value (e.g., hours)?

Yeah, as :jgriffin hinted, changing this setting seems to have no effect.

Comment 15

[Michael Wu [:mwu]]

(In reply to Andrew Overholt [:overholt] from comment #7)
> (In reply to Alex Keybl [:akeybl] from comment #5)
> > Faramarz/Andrew - William suggested he's not in the best position to perform
> > this engineering investigation. Who could look at this early this week?
> 
> mwu or tzimmerman?

I am traveling Thursday and Friday. There might be a little bit of time for me to look at this on Thursday but it may not be enough. I'll post an update here if I find anything interesting.

Comment 16

[Thomas Zimmermann [:tzimmermann] [:tdz]]

(In reply to Andrew Overholt [:overholt] from comment #7)
> (In reply to Alex Keybl [:akeybl] from comment #5)
> > Faramarz/Andrew - William suggested he's not in the best position to perform
> > this engineering investigation. Who could look at this early this week?
> 
> mwu or tzimmerman?

Bug 817730 isn't reproducible any longer; I'll look at this problem today.

Comment 17

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: Turn on screen if timeout gets disabled

This patch explicitly turns on the screen when the screen timeout gets cleared. William, could you test it?

Comment 18

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I further looked into the problem. I think what happens is that the screen was turned off by the screen timeout before the test sets the timeout to zero. Setting the timeout to zero will only remove the timeout itself, it will not turn on the blanked screen.

IMHO, the correct solution here is to not modify the timeout at all, but to acquire and hold a screen wake lock while the test is running. This will keep the screen turned on during the test. See gaia/shared/js/media/video_player.js for an example on how to use wake locks.

Some feedback from a Gaia dev is appreciated.

Comment 19

[William Lachance (:wlach)]

Comment on attachment 691825 [details] [diff] [review]
Turn on screen if timeout gets disabled

As discussed on irc, this fixes the problem for me. Of course it's not something we actually want to apply.

Comment 20

[Jonathan Griffin (:jgriffin)]

We should be able to call ScreenManager.turnScreenOn(true) from within a Marionette script.

Comment 21

[Thomas Zimmermann [:tzimmermann] [:tdz]]

(In reply to Jonathan Griffin (:jgriffin) from comment #20)
> We should be able to call ScreenManager.turnScreenOn(true) from within a
> Marionette script.

Sure. I just thought that the wake lock would be the safest option. Don't know what happens if you turn on the screen and some other program modifies the screen state as well.

Comment 22

[Thomas Zimmermann [:tzimmermann] [:tdz]]

William, can I give this bug to you? You're in a much better position to fix the issue.

Comment 23

[William Lachance (:wlach)]

(In reply to Thomas Zimmermann [:tzimmermann] from comment #22)
> William, can I give this bug to you? You're in a much better position to fix
> the issue.

Yup, no problem. I'll try and figure things out on this end, and get in touch with people in the know about this stuff if I can't.

Comment 24

[Andrew Overholt [:overholt]]

How are you doing on this one, William?

Comment 25

[William Lachance (:wlach)]

I haven't really had time to look into this yet, but yes, I don't mind doing a bit more digging into this when I get the chance (next week or the week after).

Comment 26

[Lawrence Mandel [:lmandel] (use needinfo)]

Changing this bug to basecamp-, b2g18+. The sentiment in triage today is that we really do want to have this test infrastructure in place but we will ship without it. The guidance is that we should work to get Eideticker tests running as soon as we can.

Comment 27

[Justin Wood (:Callek)]

No longer using pandas at mozilla