Description: When the user scrolls down on the New window screen, flickering black stripes appear on the screen. Repro Steps: 1) Update a Flame device to BuildID: 20141001040205 2) Open the New window screen by selecting the Browser icon on homescreen or by opening a webpage via typing URL on Rocket bar> "..." > Select "New window". 3) Scroll down on the screen. Actual: Flickering black stripes appear on the screen. Expected: The overscroll animation is shown properly. Note: - The flickering black stripes disappear when the user scrolls all the way up on the screen. But the issue re-appears after the user restarts the device. - The issue does not reproduce when Overscrolling is unchecked in the Developer menu. Flame 2.2 KitKat Base (319mb)(Full Flash) Environmental Variables: Device: Flame 2.2 Master BuildID: 20141001040205 Gaia: 0e280591881d44b80f456bc27e12d9114c218868 Gecko: 14665b1de5ee Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Repro frequency: 100% See attached: logcat, video http://youtu.be/2ZLlqQgmORs

This issue also occurs on Flame 2.1: Flame 2.1 KitKat Base (319mb)(Full Flash) Environmental Variables: Device: Flame 2.1 BuildID: 20141001000202 Gaia: 86a3626055ed58b39525424126870dc0a503e79f Gecko: c20912812877 Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 The flickering black stripes appear when scrolling down on the New window screen. ========================================= New window screen is a new feature on v.2.1. Unable to reproduce on v.2.0: Flame 2.0 KitKat Base (319mb)(Full Flash) Enviromental Variables: Device: Flame 2.0 BuildID: 20141001000205 Gaia: ddb7567c60b31dbcb27817f8c126bbba8dccb63b Gecko: e3545ca967ae Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf Version: 32.0 (2.0) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Is the video in the URL field showing 2.1 or 2.2? I do see this pretty clearly on 2.2, but it is not so visible for me on 2.1 using the latest nightly build. Also, it seems to happen initially for me and then go away. Adding No-Jun since he covers the graphic area.

(In reply to Marcia Knous [:marcia - use needinfo] from comment #2) > Is the video in the URL field showing 2.1 or 2.2? I do see this pretty > clearly on 2.2, but it is not so visible for me on 2.1 using the latest > nightly build. > > Also, it seems to happen initially for me and then go away. > > Adding No-Jun since he covers the graphic area. The video is taken with 2.2. I can also reproduce this issue on 2.1 every time after restarting the device and opening the Browser app.

[Blocking Requested - why for this release]: This looks pretty bad in the video so nominating this 2.1?

Milan, any idea here?

Nice! Seems to be device specific, and I wonder if it's related to general graphics corruption we're seeing on KitKat (e.g., bug 1070199.) Does anyone have a JB Flame to compare, just to narrow things down? Botond, I'll let you ask for the regression range if we need it. On a side note, on JB Nexus 4 with 2.1, I have the search bar disappear when going into overscroll, but I don't get the same weird effect as in this video.

Sotaro, does this look familiar to you at all? It looks more like a graphics driver problem then an APZ bug as far as I can tell.

I flashed rom 20141001040205 and confirmed the symptom. overscroll effect happened on non-tiled layer. The problem happened when hw composer composition & overscroll effect case. When HwComposer is disabled the problem did not happen. From it, overscroll effect seems to hit HwComposer's limitation. I do not know sure why overscroll effect happened on non-tiled layer.

(In reply to Sotaro Ikeda [:sotaro] from comment #8) > I do not know sure why overscroll effect happened on non-tiled layer. PaintedLayer with SCROLLABLE hint creates ClientTiledPaintedLayer. But there seems a case that PaintedLayer without SCROLLABLE hint could be APZ enabled.

(In reply to Sotaro Ikeda [:sotaro] from comment #8) > I flashed rom 20141001040205 and confirmed the symptom. overscroll effect > happened on non-tiled layer. The problem happened when hw composer > composition & overscroll effect case. When HwComposer is disabled the > problem did not happen. When tiled layer is used for rendering HwComposer is not used for Hwcomposer's composition.

In the following case, current HwComposer is not used for composition. - Transform is not 2d transform. + http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#356 - Container layer uses intermediate surface + http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#363 - Tiled layer exists + layer does not provide gralloc buffer to HwComposer + http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#387

2 problem seems to exist in this bug. - [1] There is a case that APZ enabled layer is not tiled layer. - [2] HwComposer do not composer correctly even when all the precondition checks in Comment 11 are passed.

(In reply to Sotaro Ikeda [:sotaro] from comment #12) > 2 problem seems to exist in this bug. > - [1] There is a case that APZ enabled layer is not tiled layer. This is just a performance concern, right, i.e. in terms of correctness, this combination should still work? > - [2] HwComposer do not composer correctly even when all the precondition > checks in Comment 11 are passed. Perhaps HwComposer does not support transforms which scale one axis differently than the other (which is what the overscroll effect does)?

(In reply to Sotaro Ikeda [:sotaro] from comment #12) > - [1] There is a case that APZ enabled layer is not tiled layer. It's also interesting we're overscrolling that page at all, since according to the video there's not enough content to be able to scroll it. No scroll should mean no overscroll either.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #14) > (In reply to Sotaro Ikeda [:sotaro] from comment #12) > > - [1] There is a case that APZ enabled layer is not tiled layer. > > It's also interesting we're overscrolling that page at all, since according > to the video there's not enough content to be able to scroll it. No scroll > should mean no overscroll either. The ability to overscroll or not here is governed by whether the rocketbar is collapsible or not. If the rocketbar is collapsible, the height of the container that groups the expanded rocketbar and the browser iframe is greater than the screen height, and therefore this container is scrollable (and thus overscrollable), even if the browser iframe itself isn't. Generally, the rocketbar should be collapsible only when the page is scrollable; however, this is a heuristic that cannot be perfect (see bug 1068792).

(In reply to Botond Ballo [:botond] from comment #15) > Generally, the rocketbar should be collapsible only when the page is > scrollable; however, this is a heuristic that cannot be perfect (see bug > 1068792). That said, it seems we're not even trying to make the rocketbar non-collapsible in this case (as it's collapsible even when the history is empty). I filed bug 1078709 for this.

(In reply to Botond Ballo [:botond] from comment #13) > (In reply to Sotaro Ikeda [:sotaro] from comment #12) > > 2 problem seems to exist in this bug. > > - [1] There is a case that APZ enabled layer is not tiled layer. Here's a simplified view of the relevant part of the layer structure here: (1) ContainerLayer scrollid=1 (2) PaintedLayer (3) RefLayer scrollid=1 (4) ContainerLayer scrollid=2 (5) PaintedLayer Layers (1) and (3) scroll together, and it is this scroll frame that's being scrolled/overscrolled. Since neither is a PaintedLayer, neither is tiled. (2) is a PaintedLayer, but we don't propagate the scrollable property down to it to make it tiled. (5) is a PaintedLayer which is tiled only if scrollid=2 is scrollable (which it's not in this case). From a tiling heuristics point of view, I think this outcome is reasonable; we wouldn't want to tile (2) anyways as it's a small layer for the rocketbar.

(In reply to Botond Ballo [:botond] from comment #13) > > - [2] HwComposer do not composer correctly even when all the precondition > > checks in Comment 11 are passed. > > Perhaps HwComposer does not support transforms which scale one axis > differently than the other (which is what the overscroll effect does)? To get a better sense for this, I tried making a couple of modifications to the overscroll transform: - If I stretch both axes by an equal factor, the bug does not reproduce. - If I stretch both axes, but by different factors, the bug does not reproduce. Therefore the bug seems to be specific to the case where a layer is stretched by some factor along one axis, and not stretched at all along the other axis. These symptoms suggest a hardware composer bug, and a fix on the hardware composer side would be ideal. Michael, do you have enough information to investigate this? Barring a fix on the hardware composer side, I suppose we could work around this by adjusting the heuristics for using the hardware composer to not use it when a single-axis stretch transform is in place.

I do not see this issue on H/W Overlay device with v2.1 . Is Flame a H/W Overlay device ? What is special in this particular use case ? By seeing the video, it seems something very basic is broken or a HWC limitation check could be missing in HwcComposer2D to not allow this use case to use HWC.

We do not have Flame with v2.1. Can you share ADB and kernel logs when the issue occurs ? What is special in Over-scrolling use case ? Is it possible for you to identify this use case in HwcComposer2D, then you can add a check in HwcComposer2D to fallback the frame to GPU Compostion, like other cases Sotaro mentioned in Comment 11.

(In reply to Sushil from comment #20) > We do not have Flame with v2.1. Can you share ADB and kernel logs when the > issue occurs ? Please see the attached log. > What is special in Over-scrolling use case ? We scale a layer along one axis but not the other. As described in comment 18, scaling both axes, even by different amounts, does not trigger the bug. > Is it possible > for you to identify this use case in HwcComposer2D, then you can add a check > in HwcComposer2D to fallback the frame to GPU Compostion, like other cases > Sotaro mentioned in Comment 11. I will give that a try.

This patch appears to successfully work around the problem. Jeff, does this look reasonable?

(In reply to Sushil from comment #19) > I do not see this issue on H/W Overlay device with v2.1 . Is Flame a H/W > Overlay device ? What is special in this particular use case ? By seeing the > video, it seems something very basic is broken or a HWC limitation check > could be missing in HwcComposer2D to not allow this use case to use HWC. Flame uses msm8610. Its HwComposer works as copybit hwcomposer.

If it is not just after phone start, the problem seems not happen.

Sotaro, I see most of the frames are not using HWC due to such errors: qdhwcomposer: prepare: wrong params for display screen_w=480 src_crop_width=480 screen_h=0 src_crop_height=0 So, can you try this patch in hwc_utils.cpp in CAF display HAL code? It will help in removing the errors. I do not think it will help in fixing the issue but at-least it will clean up the logs and some frames can start using HWC (if possible). @@ -1127,13 +1127,15 @@ void optimizeLayerRects(hwc_context_t *ctx, hwc_rect_t dest_rect; //if intersection is valid rect, deduct it dest_rect = deductRect(bottomframe, irect); - qhwc::calculate_crop_rects(bottomCrop, bottomframe, - dest_rect, transform); - //Update layer sourceCropf - layer->sourceCropf.left = bottomCrop.left; - layer->sourceCropf.top = bottomCrop.top; - layer->sourceCropf.right = bottomCrop.right; - layer->sourceCropf.bottom = bottomCrop.bottom; + if (isValidRect(dest_rect)) { + qhwc::calculate_crop_rects(bottomCrop, bottomframe, + dest_rect, transform); + //Update layer sourceCropf + layer->sourceCropf.left = bottomCrop.left; + layer->sourceCropf.top = bottomCrop.top; + layer->sourceCropf.right = bottomCrop.right; + layer->sourceCropf.bottom = bottomCrop.bottom; + }

Got logcat log when the problem happened by applying the patch in comment 30.

another logcat log by using same rom to attachment 8502756 [details].

During debugging the flickering problem, when I scroll up the over scroll effect a lot, its effect did not come back to normal.

botond, is there already such bug like comment 33?

botond, I found another over scroll related problem in the following STR. Is there a bug about it? -(1) show home screen. -(2) touch "Browser" icon. new window is opened. -(3) scroll up until dynamic toolbar becomes small. -(4) quickly scroll down(but this window is non scrollable page). Dynamic toolbar becomes large. During the Dynamic tool bar becoming larger, black area appear between dynamic tool bar and content area.

(In reply to Sotaro Ikeda [:sotaro] from comment #32) > Created attachment 8502766 [details] > logcat log [2] - when the problem happened by applying comment 30 > > another logcat log by using same rom to attachment 8502756 [details]. When "flickering black stripes" happens, the stretching area seems to stop stretching. Just black flickering width and number seems to be changed.

Sotaro, Plz make sure, your build has patch from Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1078189. It was recent regression found. I checked the frames sent to HWC. Noticed this: screen_w=480 src_crop_width=480 screen_h=1 src_crop_height=1 Can you try these 2 things step by step: 1. Add a check in HAL code to return false here, when either crop or dst is 1 pixel. I want to make sure we are not hitting any H/W limitation. 2. Comment out optimizeLayerRects() call in hwc_utils.cpp in CAF display HAL code ?

If above 2 steps do not help, can you check if it is hitting line # 464 OR 476 OR 486 in hwc_copybit.cpp, where it complains for params and scaling limitation.

kats, can you answer the questions of Comment 33 and Comment 35?

(In reply to Sotaro Ikeda [:sotaro] from comment #34) > botond, is there already such bug like comment 33? That one looks like bug 1073250 which was just fixed recently. (In reply to Sotaro Ikeda [:sotaro] from comment #35) > During the Dynamic tool bar becoming larger, black area appear between > dynamic tool bar and content area. I'm not aware of any bug on file for this but Chris Lord might know.

(In reply to Sushil from comment #37) > Sotaro, > > Plz make sure, your build has patch from Bugzilla: > https://bugzilla.mozilla.org/show_bug.cgi?id=1078189. It was recent > regression found. > > I checked the frames sent to HWC. Noticed this: > screen_w=480 src_crop_width=480 screen_h=1 src_crop_height=1 height=1 happned in attachment 8502756 [details] in this case, during over scrolling gpu composition and HwComposer's composition happened alternately. But height=1 did not happn in attachment 8502766 [details]. In this case, only HwComposer's composition happned staedily. > Can you try these 2 things step by step: > 1. Add a check in HAL code to return false here, when either crop or dst is > 1 pixel. I want to make sure we are not hitting any H/W limitation. I am going to check it but from the above, the problem happened when height=1 did not exist. > 2. Comment out optimizeLayerRects() call in hwc_utils.cpp in CAF display HAL > code ? I already tested it. When it is done, HwComposer is not used in this use case.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #40) > (In reply to Sotaro Ikeda [:sotaro] from comment #34) > > botond, is there already such bug like comment 33? > > That one looks like bug 1073250 which was just fixed recently. I confirmed it is fixed on latest v2.1. > > (In reply to Sotaro Ikeda [:sotaro] from comment #35) > > During the Dynamic tool bar becoming larger, black area appear between > > dynamic tool bar and content area. > > I'm not aware of any bug on file for this but Chris Lord might know. This problem still exists on latest b2g v2.1

> > (In reply to Sotaro Ikeda [:sotaro] from comment #35) > > > During the Dynamic tool bar becoming larger, black area appear between > > > dynamic tool bar and content area. > > > > I'm not aware of any bug on file for this but Chris Lord might know. > > This problem still exists on latest b2g v2.1 It is fixed on latest master.

Get logcat log when the problem happned by applying attachment 8503324 [details] [diff] [review] and attachment 8502699 [details] [diff] [review].

(In reply to Sushil from comment #37) > Sotaro, > > Plz make sure, your build has patch from Bugzilla: > https://bugzilla.mozilla.org/show_bug.cgi?id=1078189. It was recent > regression found. My source code have the above fix. > > I checked the frames sent to HWC. Noticed this: > screen_w=480 src_crop_width=480 screen_h=1 src_crop_height=1 > > Can you try these 2 things step by step: > 1. Add a check in HAL code to return false here, when either crop or dst is > 1 pixel. I want to make sure we are not hitting any H/W limitation. I added the above check but the problem was not fixed. It seems not related. > 2. Comment out optimizeLayerRects() call in hwc_utils.cpp in CAF display HAL > code ? When optimizeLayerRects() was commented out, CopyBit::canUseCopybitForRGB() returned false, then HwComposer was not used with the following log. > 10-10 14:29:58.560 205 713 E qdhwcomposer: canUseCopybitForRGB:renderArea 765120, fbArea 409920

Get a log when optimizeLayerRects() was commented out and extend CopyBit::canUseCopybitForRGB() as to use Hwcomposer in the bug STR. In this case the problem was still happened.

(In reply to Sushil from comment #38) > If above 2 steps do not help, can you check if it is hitting line # 464 OR > 476 OR 486 in hwc_copybit.cpp, where it complains for params and scaling > limitation. They are not hit when the problem happened.

By borrowing ScalesOnlyOneAxis() from attachment 8502133 [details] [diff] [review], I tried the following code, then the flickering black stripes did not happen. From it, this bug seems to be caused by kernel driver level. ----------------------------------------------- HwcComposer2D::PrepareLayerList() // snip + if (ScalesOnlyOneAxis(transform)) { + transform.Scale(1.01, 1.0); + } + hwc_rect_t sourceCrop, displayFrame; if(!HwcUtils::PrepareLayerRects(visibleRect, transform * aGLWorldTransform, clip, bufferRect, state.YFlipped(), &(sourceCrop), &(displayFrame)))

(In reply to Sotaro Ikeda [:sotaro] from comment #48) > > If above 2 steps do not help, can you check if it is hitting line # 464 OR > > 476 OR 486 in hwc_copybit.cpp, where it complains for params and scaling > > limitation. > > They are not hit when the problem happened. Good, they are not being hit. I was mainly suspecting them. Now, lets try to debug it from sync fence perspective. One potential cause for such Black bars could be, if the release fence wait is not honored in Gecko framework, i.e. someone closes fd or overwrites the layer gralloc buffer even when display driver is displaying it. OR the acquire fence of HWC layers (sent to HWC) are bogus or being overwritten, when the driver is reading it. As mentioned in Comment 0, issue does not reproduce when Overscrolling is unchecked in the Developer options. Does it have effect on the layer painting side OR are there any new buffers (or tiles) for over-scrolled content, which does not honor sync fence or have NULL handle? So, can you please check from sync fence perspective. Also can you dump the "clearRegion" rectangle being passed to clear() call in draw() function in hwc_copybit.cpp . The patch in Comment 24 looks OK to me. Please make sure it does not break Video and Camera/Camcorder use cases, which are critical use cases for HWC.

For Comment 49, by hacking scale factor, you are forcing source crop (and destination rect) to be limited to actual buffer hence over scrolled content is not being displayed. It can still be a sync fence on the new tiles.

I checked on non H/W overlay device (similar to Flame) on v2.1 build environment, I do not see any issue on Browser. It falls back to GPU Composition due to error at [1]. So it means some change has landed around "LayerRenderState" which has added support to have a non NULL "state.mSurface", acquired at [2], on your build. As I suspected, it seems to be a buffer (new tiles) or sync fence related issue. Check for the Gecko change which has added this new support. Overscrolling is enabled in Settings. Please debug in Gecko. [1]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#404 for ThebesLayerComposite [2]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#395

(In reply to Sushil from comment #52) > I checked on non H/W overlay device (similar to Flame) on v2.1 build > environment, I do not see any issue on Browser. It falls back to GPU > Composition due to error at [1]. On flame device, tiled layer is not used. Therefore such thing does not happen. And by using same gecko, flame-jb does not cause a problem. But only flame-kk cause the problem.

And I do not think this is fence related problem. This black stripes is very clear stripe. During over-scrolling gecko does no paint update, only layer's transform is changed. Only related fence is from FramebufferSurface. But NUM_FRAMEBUFFER_SURFACE_BUFFERS changed from 2 to 4 doe not make effect to the problem.

(In reply to Sotaro Ikeda [:sotaro] from comment #54) > > Only related fence is from FramebufferSurface. But > NUM_FRAMEBUFFER_SURFACE_BUFFERS changed from 2 to 4 doe not make effect to > the problem. About the above, reverting the following also have no effect. from it, fence seems not related at all. https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/commit/?h=kk_3.5&id=c67b03798c274884172c1f99222ba31ce33e1b6b

(In reply to Sotaro Ikeda [:sotaro] from comment #53) > > On flame device, tiled layer is not used. Therefore such thing does not > happen. And by using same gecko, flame-jb does not cause a problem. But only > flame-kk cause the problem. Correction: Sorry, the above is not correct, flame-jb do not use Hwcomposer in this use case. layer is not optimized enough to use Hwcomposer.

One strange thing to this bug is the following. - When the symptom is happening, if I continue to do over-scroll up/down relatively largely(including dynamic toolbar move), the black border problem disappears.

(In reply to Sushil from comment #50) > Good, they are not being hit. I was mainly suspecting them. Now, lets try to > debug it from sync fence perspective. One potential cause for such Black > bars could be, if the release fence wait is not honored in Gecko framework, > i.e. someone closes fd or overwrites the layer gralloc buffer even when > display driver is displaying it. OR the acquire fence of HWC layers (sent to > HWC) are bogus or being overwritten, when the driver is reading it. As > mentioned in Comment 0, issue does not reproduce when Overscrolling is > unchecked in the Developer options. Does it have effect on the layer > painting side OR are there any new buffers (or tiles) for over-scrolled > content, which does not honor sync fence or have NULL handle? overscrollling effect is just handled as a transform in compositor side, it have no affect to the painting. It just add a transform to the layer on composition.

(In reply to Sushil from comment #52) > I checked on non H/W overlay device (similar to Flame) on v2.1 build > environment, I do not see any issue on Browser. It falls back to GPU > Composition due to error at [1]. So it means some change has landed around > "LayerRenderState" which has added support to have a non NULL > "state.mSurface", acquired at [2], on your build. As I suspected, it seems > to be a buffer (new tiles) or sync fence related issue. Check for the Gecko > change which has added this new support. Overscrolling is enabled in > Settings. Please debug in Gecko. > > [1]: > http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D. > cpp#404 for ThebesLayerComposite > [2]: > http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D. > cpp#395 If tiled layer is used in the STR, we could disable tiling from developer menu.

(In reply to Sotaro Ikeda [:sotaro] from comment #49) > By borrowing ScalesOnlyOneAxis() from attachment 8502133 [details] [diff] [review] > [review], I tried the following code, then the flickering black stripes did > not happen. From it, this bug seems to be caused by kernel driver level. > > ----------------------------------------------- > HwcComposer2D::PrepareLayerList() > // snip > > + if (ScalesOnlyOneAxis(transform)) { > + transform.Scale(1.01, 1.0); > + } > + > hwc_rect_t sourceCrop, displayFrame; > if(!HwcUtils::PrepareLayerRects(visibleRect, > transform * aGLWorldTransform, > clip, > bufferRect, > state.YFlipped(), > &(sourceCrop), > &(displayFrame))) But the following code did not fix the problem. ----------------------------------------------- HwcComposer2D::PrepareLayerList() // snip + if (ScalesOnlyOneAxis(transform)) { + transform.Scale(0.9, 1.0); + } + hwc_rect_t sourceCrop, displayFrame; if(!HwcUtils::PrepareLayerRects(visibleRect, transform * aGLWorldTransform, clip, bufferRect, state.YFlipped(), &(sourceCrop), &(displayFrame)))

(In reply to Sotaro Ikeda [:sotaro] from comment #56) > (In reply to Sotaro Ikeda [:sotaro] from comment #53) > > > > On flame device, tiled layer is not used. Therefore such thing does not > > happen. And by using same gecko, flame-jb does not cause a problem. But only > > flame-kk cause the problem. > > Correction: > Sorry, the above is not correct, flame-jb do not use Hwcomposer in this use > case. layer is not optimized enough to use Hwcomposer. By modifying CopyBit::canUseCopybitForRGB(), flame-jb also becomes to use HwComposer on the STR. I also saw the black stripes, but it rarely happen compared to flame-kk.

By applying the patch to kernel side driver, the problem was fixed on my flame-kk.

Sushil, can you check attachment 8503634 [details] [diff] [review]?

Comment on attachment 8503634 [details] [diff] [review] patch - Fix ppp scale config Review of attachment 8503634 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me. Please do a display sanity on Flame device and make sure it does not break Video playback and Camera/Camcorder use cases in using HWC Composition.

Thanks for looking at this while I was away, Sotaro! I changed Assignee to you to reflect that the proper fix (the patch posted in comment 62) was written by you.

Issue DOES occur in Flame 2.2, 2.1 (Full Flash, nightly). Actual Results: Opening the Browser app and attempting to scroll up and down causes UI malfunction. Note: Repro rate is about 25% and Restarting/Power Off does not always fix the issue. Device: Flame Master Build ID: 20141016040204 Gaia: 841d0d7d1b879f0ff4b5a8727f5dd23c7b0000a9 Gecko: a280a03c9f3c Version: 36.0a1 (Master) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Device: Flame 2.1 Build ID: 20141016001201 Gaia: 477a9e61c3edf12f32a62a19d329cd277202cc6b Gecko: 67573e422a0f Version: 34.0 (2.1) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

ddixon, did you do confirmation on flame-KK? The kernel fix is committed only for kit kat. JB is going to become obsolete. I did re-confirmation on latest master nightly and latest v2.1 on flame-kk. I did not see the problem. Can you reconfirm again with "Full Flash"? If the problem happens, can you upload a video of it?

This bug's fix updates kernel driver. Therefore "Full Flash" is necessary to update kernel.

Sotaro, V180 is a 2.0 KK base so he was on KK. I will recheck this myself.

Thanks!

This issue no longer reproduces on the latest 2.2 Flame KK build when doing Full Flash. Environmental Variables: Device: Flame 2.2 BuildID: 20141020055012 Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a Gecko: f2d7d694aae5 Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Version: 36.0a1 (2.2) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

No-Jun here is another graphical issue that is still present on 2.1

KTucker: thank you, just curious, it is marked verified, but since it's still present in 2.1, shouldn't we revert it back to the open status? (since it's a 2.1 blocking bug, I thought it was verified in 2.1) milan, should we move the component from Firefox:General to Core:Graphics? Would be easier to identify graphics blocking issues with the existing queries.

This was not a Gecko (graphics or otherwise) bug - I don't know what component we use for the drivers/codeaurora issues.

I guess we just use POVB in the whiteboard.

In reply to comment 76, the status is always changed to "Verified" if the issue is verified as fixed on master. It doesn't matter if the issue still exists on 2.1. I know this is super confusing but that has always been the policy.

This issue re-appeared on Flame 2.2. Result: Flickering black stripes appear on the screen when scrolling "New window" screen. Device: Flame 2.2 (319mb, KK, Shallow Flash) BuildID: 20141119040205 Gaia: e64428c5b2dce5db90b75a5055077a04f4bd4819 Gecko: bc2c36dda0a9 Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

(In reply to Yeojin Chung [:YeojinC] from comment #80) > This issue re-appeared on Flame 2.2. > > Result: Flickering black stripes appear on the screen when scrolling "New > window" screen. > > Device: Flame 2.2 (319mb, KK, Shallow Flash) > BuildID: 20141119040205 > Gaia: e64428c5b2dce5db90b75a5055077a04f4bd4819 > Gecko: bc2c36dda0a9 > Version: 36.0a1 (2.2 Master) > Firmware: V188-1 > User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 YeojinC, do you confirmed your flame has correct kernel? This fix is about kernel. Shallow Flash does not update the kernel.

I always do full flash and I did not see the problem on Flame 2.2.

sushi, diego, is this bug's fix already merged to caf? b2g_kk_3.5 seems not have this fix. https://www.codeaurora.org/cgit/quic/le/kernel/msm/tree/drivers/video/msm/mdss/mdp3_ppp_hwio.c?h=b2g_kk_3.5#n956

I full flashed my device to today's nightly build, and I still see the issue reproducing. Note: The flickering black stripes disappear when the user scrolls all the way up on the screen. But the issue re-appears after the user restarts the device. Environmental Variables: Device: Flame 2.2 Master (319mb, KK, Full Flash) BuildID: 20141120040205 Gaia: 1abe09b4925547699dfdb2d358aed019137c3aa6 Gecko: 6ce1b906c690 Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

(In reply to Yeojin Chung [:YeojinC] from comment #84) > I full flashed my device to today's nightly build, and I still see the issue > reproducing. > > Note: > The flickering black stripes disappear when the user scrolls all the way up > on the screen. But the issue re-appears after the user restarts the device. YeojinC, can you upload the video of the symptom? I can not reproduce the symptom.

(In reply to Sotaro Ikeda [:sotaro] from comment #85) > (In reply to Yeojin Chung [:YeojinC] from comment #84) > > I full flashed my device to today's nightly build, and I still see the issue > > reproducing. > > > > Note: > > The flickering black stripes disappear when the user scrolls all the way up > > on the screen. But the issue re-appears after the user restarts the device. > > YeojinC, can you upload the video of the symptom? I can not reproduce the > symptom. Sure, here it is: http://youtu.be/TCMpwj7DwKQ

(In reply to Yeojin Chung [:YeojinC] from comment #86) > > YeojinC, can you upload the video of the symptom? I can not reproduce the > > symptom. > > Sure, here it is: http://youtu.be/TCMpwj7DwKQ Thanks for the video. Its symptom is this bug's one. It seems that your flame's kernel seems not correctly updated.

Leaving ni? for Sushil as he did the initial review of the patch.

It has landed in branch for v2.0. Diego, can you please help to get it merged in branch on which issue is seen now (v2.2 master).

Looks like this patch hasn't been propagated to the CAF msm8610 kitkat baseline. I'll have to check if that can be done and then update here.

(In reply to Sotaro Ikeda [:sotaro] from comment #83) > sushi, diego, is this bug's fix already merged to caf? b2g_kk_3.5 seems not > have this fix. > > https://www.codeaurora.org/cgit/quic/le/kernel/msm/tree/drivers/video/msm/ > mdss/mdp3_ppp_hwio.c?h=b2g_kk_3.5#n956 This fix landed on the v2.1/msm8226 branch [1]. Sushil has propagated to the v2.0/msm8619 (flame) branch but that hasn't been published yet. I'll let you know once it makes it to caf.org [1] https://www.codeaurora.org/cgit/quic/le/kernel/msm/commit/?id=232d30a4e0abd4ca6e078ddd0db4c3b009947b87

Can we update the target milestone to see when we expect to close this bug? Thank you.

This issue appears to be happening in settings too on Flame 2.2(319mb)(KK)(Full Flash). Environmental Variables: Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash) BuildID: 20141217040204 Gaia: d22dfece04fc00457e8369c660c11f945b088d2f Gecko: cb8ad2251c09 Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442 Version: 37.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 STR: 1. Reboot the phone. 2. Open the settings app after restart. 3. Scroll down on the main settings page. Actual: Flickering black lines can be seen when scrolling settings.

change component to vendcom

Mike, do this issue appear to be happening now?

No, I cannot reproduce this issue with the latest v2.1, mark as fixed Gaia-Rev db751d9c200dce41cd03a61665746d245739a175 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/28ffee0d5b0c Build-ID 20150312001452 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150312.034011 FW-Date Thu Mar 12 03:40:22 EDT 2015 Bootloader L1TC100118D0

This bug has been verified as "pass" on latest build of Flame 2.1,2.2&3.0,Nexus5_2.2&3.0.by the STR in Comment 0 and Comment 93. Actual result:It is shown properly when scrolling down the scren in Browser. See attachment:Verify.3gp Reproducing rate: 0/10 Device:Nexus5_3.0 build(Pass): Build ID 20150614010203 Gaia Revision 1bf2da102560481748ff3f6202fbed5c4daa5832 Gaia Date 2015-06-13 00:22:05 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/c223b8844264 Gecko Version 41.0a1 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150614.044149 Firmware Date Sun Jun 14 04:42:08 EDT 2015 Bootloader HHZ12f Device:Nexus5_2.2 build(Pass): Build ID 20150614002504 Gaia Revision cfceba16e48ede3defee24be93637a0fa291c494 Gaia Date 2015-06-11 22:10:18 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/2cfd86c2ba1b Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150614.042607 Firmware Date Sun Jun 14 04:26:25 EDT 2015 Bootloader HHZ12d Device:Flame2.1 build(Pass): Build ID 20150614001205 Gaia Revision f8b848c82d1ed589f7a1eb5cc099830c867ff1d4 Gaia Date 2015-06-08 09:48:23 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/7d767fc15126 Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150614.033810 Firmware Date Sun Jun 14 03:38:22 EDT 2015 Bootloader L1TC000118D0 Device:Flame2.2 build(Pass): Build ID 20150614002504 Gaia Revision cfceba16e48ede3defee24be93637a0fa291c494 Gaia Date 2015-06-11 22:10:18 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/2cfd86c2ba1b Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150614.040237 Firmware Date Sun Jun 14 04:02:49 EDT 2015 Bootloader L1TC000118D0 Device:Flame3.0 build(Pass): Build ID 20150614010203 Gaia Revision 1bf2da102560481748ff3f6202fbed5c4daa5832 Gaia Date 2015-06-13 00:22:05 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/c223b8844264 Gecko Version 41.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150614.044513 Firmware Date Sun Jun 14 04:45:25 EDT 2015 Bootloader L1TC000118D0