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

RESOLVED WONTFIX

Status

()

Core
Widget: Gonk
P1
normal
RESOLVED WONTFIX
4 years ago
a year ago

People

(Reporter: wlach, Assigned: wlach)

Tracking

unspecified
B2G C3 (12dec-1jan)
x86_64
Linux
Points:
---

Firefox Tracking Flags

(blocking-basecamp:-, b2g18+)

Details

Attachments

(1 attachment)

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
We should note that the script sets the screen timeout to 0 programmatically, so it isn't the normal screen timeout which is occurring.
Here's the code which is supposed to perma-unlock the screen:

https://github.com/mozilla/mozbase/blob/master/mozb2g/mozb2g/b2gmixin.py#L169
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

4 years ago
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.
blocking-basecamp: --- → +
Priority: -- → P1
Target Milestone: --- → B2G C2 (20nov-10dec)

Comment 5

4 years ago
Faramarz/Andrew - William suggested he's not in the best position to perform this engineering investigation. Who could look at this early this week?
QA Contact: frashed
(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. :)

Updated

4 years ago
Assignee: wlachance → frashed
QA Contact: frashed
(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'm quite busy ATM, sorry.
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.
s/one/on
The patch in https://bugzilla.mozilla.org/show_bug.cgi?id=817730#c47 may be useful here. Investigating.
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)?
(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.
(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

4 years ago
(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.
(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.
Created attachment 691825 [details] [diff] [review]
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?
Attachment #691825 - Flags: feedback?(wlachance)
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.

Updated

4 years ago
Assignee: frashed → tzimmermann
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.
Attachment #691825 - Flags: feedback?(wlachance)
We should be able to call ScreenManager.turnScreenOn(true) from within a Marionette script.
(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.
William, can I give this bug to you? You're in a much better position to fix the issue.
Assignee: tzimmermann → wlachance
(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.

Updated

4 years ago
Target Milestone: B2G C2 (20nov-10dec) → B2G C3 (12dec-1jan)
How are you doing on this one, William?
Flags: needinfo?(wlachance)
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).
Flags: needinfo?(wlachance)
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.
blocking-basecamp: + → -
tracking-b2g18: --- → +
No longer using pandas at mozilla
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.