Closed
Bug 1176301
Opened 9 years ago
Closed 9 years ago
Display breaks when unlocking to Camera
Categories
(Core :: Graphics, defect)
Tracking
()
VERIFIED
FIXED
blocking-b2g | 2.5? |
People
(Reporter: janx, Assigned: sotaro)
References
Details
(Whiteboard: [spark])
Attachments
(2 files)
This bug repoduces easily but not consistently.
Steps:
1. Open Camera app
2. Press home
3. Lock the screen
4. Unlock to Camera
Expected: Camera is displayed.
Actual: The screen splits into 3 parts, does weird UI things, and ends up with the software home button somewhere at 1/3 of the screen (display is shifted vertically).
Reporter | ||
Comment 1•9 years ago
|
||
Justin, please have a look. This happens on the latest Spark build.
Flags: needinfo?(jdarcangelo)
Comment 2•9 years ago
|
||
Updated STR:
1. Open Camera app
2. Take a picture (or two)
3. Press home
4. Lock the screen
5. Unlock to Camera
Comment 3•9 years ago
|
||
[Blocking Requested - why for this release]: This is a fairly common workflow that users may encounter and the result looks really bad.
blocking-b2g: --- → spark?
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(sotaro.ikeda.g)
Comment 4•9 years ago
|
||
Cannot reproduce with HWC disabled.
Turning off hardware composer manually :
settings -> developer -> turn off hardware composer
Comment 6•9 years ago
|
||
Last working build:
https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-central.revision.linux.0093691d37157330d439e2b0d5999a95ab22ff96.aries-dogfood/gecko.v1.mozilla-central.revision.linux.0093691d37157330d439e2b0d5999a95ab22ff96.aries-dogfood.debug
First broken build:
https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-central.revision.linux.0c3bca1b4935c7aa8e77b07a349fa73401b7a744.aries-dogfood/gecko.v1.mozilla-central.revision.linux.0c3bca1b4935c7aa8e77b07a349fa73401b7a744.aries-dogfood.debug
Flags: needinfo?(jdarcangelo)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Updated•9 years ago
|
Component: Gaia → Graphics
Product: Firefox OS → Core
blocking-b2g: spark? → 2.5?
Updated•9 years ago
|
Whiteboard: [spark]
Assignee | ||
Comment 11•9 years ago
|
||
The problem seems to happen because of hardware limitation or driver's problem. When the problem happen, hwc driver hold a lock very long time. By it, hwc prepare failed at the following. It means, someone hold ov_lock very long time.
> ret = mutex_lock_interruptible(&mdp5_data->ov_lock);
https://github.com/mozilla-b2g/codeaurora_kernel_msm/blob/shinano/drivers/video/msm/mdss/mdss_mdp_overlay.c#L2298
Assignee | ||
Comment 12•9 years ago
|
||
When the problem happened, mdss_mdp_cmd_wait4pingpong() was failed by timeout. mdss_mdp_cmd_wait4pingpong() waits mdss_mdp_cmd_pingpong_done(). But when the timout happened, mdss_mdp_cmd_pingpong_done() was not called. It is a callback from hw, therefore, hw status seemed to be abnormal.
mdss_mdp_overlay_kickoff()
->mdss_mdp_display_commit()
->mdss_mdp_cmd_wait4pingpong()
->wait_for_completion_timeout()
Assignee | ||
Comment 13•9 years ago
|
||
When the problem happened, 4 hwc layers were set and one layer was color layer.
Assignee | ||
Comment 14•9 years ago
|
||
I am going to think driver's color layer handling might cause the problem. bug 1160799 also caused by color layer handling.
See Also: → 1160799
Assignee | ||
Comment 15•9 years ago
|
||
The patch fixed the problem for me on aries.
Assignee | ||
Comment 16•9 years ago
|
||
The STR causes application's layer's scale change. But color layer rendering code path did not update the scale setting. It might hit hardware's limitation.
Assignee | ||
Comment 17•9 years ago
|
||
Comment on attachment 8631201 [details] [diff] [review]
patch - Update scale setting for color layer rendering
Sushil, can you give a feedback to the patch?
Attachment #8631201 -
Flags: feedback?(sushilchauhan)
Assignee | ||
Comment 18•9 years ago
|
||
This bug causes very annoying user experience. It seems better to checkin attachment 8631201 [details] [diff] [review] soon.
Assignee | ||
Comment 19•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Attachment #8631639 -
Flags: review?(mwu)
Comment 20•9 years ago
|
||
Sotaro, I see you have a patch, but I'm very surprised: I have been dogfooding this device since march, and this issue only started to be triggered a few weeks ago. Are we sure the bug is on kernel side, and not on Gecko side?
Comment 21•9 years ago
|
||
Comment on attachment 8631639 [details] [review]
https://github.com/mozilla-b2g/codeaurora_kernel_msm/pull/37
r=me with the commits squashed. Just a rubberstamp - I think we'll want sushil's opinion if possible.
Attachment #8631639 -
Flags: review?(mwu) → review+
Assignee | ||
Comment 22•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #20)
> Sotaro, I see you have a patch, but I'm very surprised: I have been
> dogfooding this device since march, and this issue only started to be
> triggered a few weeks ago. Are we sure the bug is on kernel side, and not on
> Gecko side?
As in comment 12, it is a kernel side problem. Change to layout(like Bug 1152461) might trigger the bug though.
Assignee | ||
Comment 23•9 years ago
|
||
(In reply to Michael Wu [:mwu] from comment #21)
> Comment on attachment 8631639 [details] [review]
> https://github.com/mozilla-b2g/codeaurora_kernel_msm/pull/37
>
> r=me with the commits squashed. Just a rubberstamp - I think we'll want
> sushil's opinion if possible.
Thanks. I squashed the commits.
Comment 24•9 years ago
|
||
Sotaro, I see you fixed several bugs related to HWc either in kernel or other parts. Can we make sure those gets applied upstream too? Specifically the kernel changes should be fixed in our kernel and in Sony's one: https://github.com/sonyxperiadev/kernel
Just opening a PR against it and pining Alin Jerpelea should be enough
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(alin.jerpelea)
Assignee | ||
Comment 25•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #24)
> Sotaro, I see you fixed several bugs related to HWc either in kernel or
> other parts. Can we make sure those gets applied upstream too? Specifically
> the kernel changes should be fixed in our kernel and in Sony's one:
> https://github.com/sonyxperiadev/kernel
>
> Just opening a PR against it and pining Alin Jerpelea should be enough
gerard-majax, the bug affect only to Firefox OS not to android. Even in this situation, do we need to upstream to Sony's one? For example, android does not support color layer. Therefore android does not hit color layer related bugs.
Flags: needinfo?(sotaro.ikeda.g) → needinfo?(lissyx+mozillians)
Comment 26•9 years ago
|
||
Well, I think we should ask Alin in this case, but it's possible they will be interested that we push the fix upstream rather than keeping it in our own fork.
Flags: needinfo?(lissyx+mozillians)
Comment 27•9 years ago
|
||
Alin is busy on getting is Camera for Lollipop :). But he confirms he's highly interested in a PR since B2G and Android are not the only users so it's still valuable. Thanks Sotaro for this!
Flags: needinfo?(alin.jerpelea) → needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 28•9 years ago
|
||
merged. When we get feedback from codeaurora, we might update the fix.
https://github.com/mozilla-b2g/codeaurora_kernel_msm/commit/310ef1b341ae278c65d39e3b3f9206125f30e5fe
Assignee | ||
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 29•9 years ago
|
||
Sotaro, can you check (i.e., do you have time and does just reading the code can answer this) if we need to fix this on Lollipop kernel too? Branch is at https://github.com/mozilla-b2g/codeaurora_kernel_msm/tree/sony-aosp-l
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 30•9 years ago
|
||
From the following, mdss_mdp_pipe_solidfill_setup() set MDSS_MDP_REG_SCALE_CONFIG. The problem seems to be fixed on sony-aosp-l.
https://github.com/mozilla-b2g/codeaurora_kernel_msm/blob/sony-aosp-l/drivers/video/msm/mdss/mdss_mdp_pipe.c#L1677
Assignee | ||
Comment 31•9 years ago
|
||
gerard-majax, do we need aries-L base image to build aries-L? I built only aries(KK) until now.
Flags: needinfo?(lissyx+mozillians)
Comment 32•9 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #31)
> gerard-majax, do we need aries-L base image to build aries-L? I built only
> aries(KK) until now.
Yes, ./config.sh aries-l does work. You just need to have uptodate bootloader otherwise flashing Lollipop will not boot :)
Flags: needinfo?(lissyx+mozillians)
Assignee | ||
Comment 33•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #32)
>
> Yes, ./config.sh aries-l does work. You just need to have uptodate
> bootloader otherwise flashing Lollipop will not boot :)
gerard-majax, how can I get uptodate bootloader? Is there a document about aries-l?
Flags: needinfo?(lissyx+mozillians)
Comment 34•9 years ago
|
||
It's easy but there is no document about it. You need to flash lollipop bootloader from FTF file with FlashTool for example.
Rebooting the device in fastboot can help you check if your bootloader is already good:
> adb reboot bootloader && fastboot getvar version-bootloader
Flags: needinfo?(lissyx+mozillians) → needinfo?(sotaro.ikeda.g)
Comment 36•9 years ago
|
||
This issue is verified fixed on the latest Spark 2.5 build.
Device screen maintains proper display after app transitions.
Environmental Variables:
Device: Aries 2.5
Build ID: 20150716033647
Gaia: 981c61cdeb527fac8f8383c110df0e749eff67ea
Gecko: 72835344333f
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: verifyme
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Assignee | ||
Updated•9 years ago
|
Attachment #8631201 -
Flags: feedback?(sushilchauhan)
You need to log in
before you can comment on or make changes to this bug.
Description
•