Closed
Bug 1085593
Opened 10 years ago
Closed 10 years ago
[SHB] The "Enter SIM PIN" page flashes when Software Home Button is enabled
Categories
(Core :: Graphics, defect)
Tracking
()
People
(Reporter: smiko, Assigned: BenWa)
References
()
Details
(Whiteboard: [2.2-Daily-Testing][shb-enabled][POVB])
Attachments
(4 files, 1 obsolete file)
Description: The "Enter SIM PIN" page flickers when launched with the software home button enabled. Repro Steps: 1: Update a Flame to 20141020040204 2: Open Settings > SIM Manager > SIM Security and create a SIM PIN 3: Open Settings > Developer Menu and enable Software Home Button 4: Long press the power button and select Restart 5: Unlock the phone. Actual: The "Enter SIM PIN" page flashes black before displaying Expected: The page is displayed without any flashing/flickering Device: Flame 2.2 (319mb/ full flash) BuildID: 20141020040204 Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a Gecko: ca6b46cbca3b Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Version: 36.0a1 (2.2) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Notes: 1: This issue ONLY occurs with the software home button enabled Repro frequency: 100% See attached: logcat Video clip: http://youtu.be/4tBoMTlYVWQ
Reporter | ||
Comment 1•10 years ago
|
||
This issue Does occur on Flame 2.2 (319mb/full flash/v188 base) Actual result: The "Enter SIM PIN" page flashes black before displaying Device: Flame 2.2 BuildID: 20141020040204 Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a Gecko: ca6b46cbca3b Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Version: 36.0a1 (2.2) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 ____________________________________________________________________________________________________________________________________________ This issue does NOT occur on Flame 2.1 (319mb/full flash/v180) or Flame 2.1 (319mb/full flash/v188) Actual result: The page is displayed without any flashing/flickering Device: Flame 2.1 BuildID: 20141020001201 Gaia: 2904ab80816896f569e2d73958427fb82aebaea5 Gecko: 12dc9b782f2a Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Version: 34.0 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.1 BuildID: 20141020001201 Gaia: 2904ab80816896f569e2d73958427fb82aebaea5 Gecko: 12dc9b782f2a Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Version: 34.0 (2.1) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1:
--- → unaffected
status-b2g-v2.2:
--- → affected
Flags: needinfo?(pbylenga)
Whiteboard: [2.2-Daily-Testing]
Comment 2•10 years ago
|
||
[Blocking Requested - why for this release]: Poor user experience with high visibility. Confirmed with Reporter that he reported 2.1 as unaffected because the screen doesn't recover from the overlap. therefore, I believe this is related to bug 1082071.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1:
unaffected → ---
Depends on: 1082071
Flags: needinfo?(pbylenga)
Whiteboard: [2.2-Daily-Testing] → [2.2-Daily-Testing] [shb-enabled]
Comment 3•10 years ago
|
||
Yup, this is definitely caused by bug 1082071, which will soon be uplifted to 2.1. The problem is that when the screen unlocks, we need to trigger a system wide screen resize when SHB is enabled. If we don't trigger this, many screens like the one in bug 1082071 will be the wrong size. App windows are also affected. Alive, is there anything we can do about the flickering here? Perhaps we could wait to dismiss the lockscreen until after the resize has been propagated across all window managers?
Flags: needinfo?(alive)
Whiteboard: [2.2-Daily-Testing] [shb-enabled] → [2.2-Daily-Testing] [shb-enabled][systemsfe]
Comment 4•10 years ago
|
||
(In reply to Michael Henretty [:mhenretty] from comment #3) > Yup, this is definitely caused by bug 1082071, which will soon be uplifted > to 2.1. > > The problem is that when the screen unlocks, we need to trigger a system > wide screen resize when SHB is enabled. If we don't trigger this, many > screens like the one in bug 1082071 will be the wrong size. App windows are > also affected. > > Alive, is there anything we can do about the flickering here? Perhaps we > could wait to dismiss the lockscreen until after the resize has been > propagated across all window managers? Offline discussed =)
Flags: needinfo?(alive)
Updated•10 years ago
|
Assignee: nobody → mhenretty
Comment 6•10 years ago
|
||
WIP patch. We still see the flashing, but it's much less pronounced. I think we still need to do more here.
Comment 7•10 years ago
|
||
Here's a real strange thing I found, this only reproduces if the app behind the SIM PIN dialog is the homescreen, and only if it is scrolled all the way to the top. I wonder if this has something to do with the statusbar being transparent.
Updated•10 years ago
|
Target Milestone: --- → 2.1 S8 (7Nov)
Comment 8•10 years ago
|
||
After much investigation and profiling, I'm pretty sure this is a graphics issue. The flashing only seems to occur when the screen over which the SIM PIN dialog is displayed has a transparent statusbar. Furthermore, if you enable the FPS hud, you see very similar artifacting on the screen as bug 1089040 [1]. There's a good chance these issues are related. After systematically disabling js that runs on 'system-resize' using the profiler as a guide, I fairly certain this is something lower. BenWa, could you help me investigate this issue? The line that causes the flashing/artifacting is when we update the height of the SIM PIN dialog here [2]. But it only happens when closing the lockscreen when the statusbar is transparent. Let me know if I can collect any more information here of use to you. 1.) https://www.youtube.com/watch?v=tmjGR6uyClI 2.) https://github.com/mozilla-b2g/gaia/blob/78be6285b44310cc45fd3c4dd41bb2e71bb7ce69/apps/system/js/system_dialog.js#L177
Flags: needinfo?(bgirard)
Comment 9•10 years ago
|
||
Lets put this on Milans radar since it might become a gfx blocker.
Flags: needinfo?(milan)
Comment 10•10 years ago
|
||
Thanks for the heads up. Quick question - which devices don't have the hardware button and need the software button?
Comment 11•10 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #10) > Thanks for the heads up. Quick question - which devices don't have the > hardware button and need the software button? Tako will have SHB.
Updated•10 years ago
|
Assignee: mhenretty → nobody
Component: Gaia::System::Lockscreen → Graphics
Product: Firefox OS → Core
Updated•10 years ago
|
Whiteboard: [2.2-Daily-Testing] [shb-enabled][systemsfe] → [2.2-Daily-Testing] [shb-enabled]
Comment 12•10 years ago
|
||
This only becomes 2.1+ if we actually uplift bug 1082071 to 2.1 - we should not do that and introduce a regression until we have the regression taken care of. I've commented in bug 1082071 to that effect. In the meantime, we can take a look at this on the trunk. I have serious doubts that this is graphics, but Benoit can help find the problem.
Assignee: nobody → bgirard
Flags: needinfo?(milan)
Assignee | ||
Comment 13•10 years ago
|
||
(In reply to Michael Henretty [:mhenretty] from comment #8) > After much investigation and profiling, I'm pretty sure this is a graphics > issue. Can you list what you tried on the bug and your though process for coming to this conclusion. To me it doesn't feel like a graphics issue but perhaps if you shared your work so far that would help. Specially I'd like to know that the app isn't just asking for the wrong content on that frame like we're seen many thing in these bugs before jumping to thinking it's a graphics issue. Also when a document is loaded we only block rendering for a fraction of a second so if we have something delay the document load we will show whatever we've loaded up to that point which may very well be a black background. This is a pretty common mistake. > The flashing only seems to occur when the screen over which the SIM > PIN dialog is displayed has a transparent statusbar. Can we get a testcase reduction of that? Trying to simplify the app and system down to a minimal set of feature/complexity will help narrow down the bug. Particularly since the bug is very short lived debugging is more difficult. > Furthermore, if you > enable the FPS hud, you see very similar artifacting on the screen as bug > 1089040 [1]. There's a good chance these issues are related. If that's the case then yes this is likely a graphics bug. But the original video doesn't show any artifacts, it looks more like bad/slow content provided for that frame. We could also have 2 or more bugs here. The artifact in that video are certainly a graphics issue. I'll look at that issue first (which wont fix this if this isn't a graphics issue). > After > systematically disabling js that runs on 'system-resize' using the profiler > as a guide, I fairly certain this is something lower. Can you share your profile and what you saw in it that makes you think that so that I can follow your analysis? Can you show me what you disabled? > > BenWa, could you help me investigate this issue? The line that causes the > flashing/artifacting is when we update the height of the SIM PIN dialog here > [2]. But it only happens when closing the lockscreen when the statusbar is > transparent. Let me know if I can collect any more information here of use > to you. > > > 1.) https://www.youtube.com/watch?v=tmjGR6uyClI > 2.) > https://github.com/mozilla-b2g/gaia/blob/ > 78be6285b44310cc45fd3c4dd41bb2e71bb7ce69/apps/system/js/system_dialog.js#L177 Can someone confirm if this is a regression? If so we should run a regression window. I'd be particularly curious to know if the offender was bug 1085223 based on the video in [2] if the regression is recent. Even if this didn't work in 2.1 we can still run a regression along the gecko changes that we're made in 2.2 to see if a change broke it.
Flags: needinfo?(bgirard) → needinfo?(mhenretty)
Updated•10 years ago
|
Comment 14•10 years ago
|
||
I took a video of the problem https://www.youtube.com/watch?v=ZtJqGx6fX8I. You'll notice you only see the artifacts when the homescreen is scrolled all the way up (which makes the statusbar transparent). If you scroll down a little (which makes the statusbar opaque black), the glitching doesn't appear. Perhaps it's unrelated to the statusbar color, but that's my best guess at this point. (In reply to Benoit Girard (:BenWa) from comment #13) > (In reply to Michael Henretty [:mhenretty] from comment #8) > > After much investigation and profiling, I'm pretty sure this is a graphics > > issue. > > Can you list what you tried on the bug and your though process for coming to > this conclusion. To me it doesn't feel like a graphics issue but perhaps if > you shared your work so far that would help. Basically, I narrowed down the code we called when closing lockscreen to this line [1] being the problem, and only when the statusbar is transparent on the homescreen. Furthermore, you only see the artifacting when the FPS counter is on, otherwise it is just a black background flashing like the original video. 1.) https://github.com/mozilla-b2g/gaia/blob/78be6285b44310cc45fd3c4dd41bb2e71bb7ce69/apps/system/js/system_dialog.js#L177 > Can we get a testcase reduction of that? Trying to simplify the app and > system down to a minimal set of feature/complexity will help narrow down the > bug. Particularly since the bug is very short lived debugging is more > difficult. I'm not sure how to narrow it down more than it being line [1] when the lockscreen is closing. It appears to be some interaction between lockscreen, statusbar and this dialog (all of which live in the system app). Note, it seems that if any other apps are open when the dialog displays, we don't have this issue. > > After > > systematically disabling js that runs on 'system-resize' using the profiler > > as a guide, I fairly certain this is something lower. > > Can you share your profile and what you saw in it that makes you think that > so that I can follow your analysis? Can you show me what you disabled? The profiler was only used to help me find the line in gaia which causes the problem when unlocking the screen. Here is a commit that demonstrates the narrowed down case, perhaps that will help: https://github.com/mikehenrty/gaia/commit/698ead8595ba28ddb008ef5eec71fad5700cc753 > > BenWa, could you help me investigate this issue? The line that causes the > > flashing/artifacting is when we update the height of the SIM PIN dialog here > > [2]. But it only happens when closing the lockscreen when the statusbar is > > transparent. Let me know if I can collect any more information here of use > > to you. > > > > > > 1.) https://www.youtube.com/watch?v=tmjGR6uyClI > > 2.) > > https://github.com/mozilla-b2g/gaia/blob/ > > 78be6285b44310cc45fd3c4dd41bb2e71bb7ce69/apps/system/js/system_dialog.js#L177 > > Can someone confirm if this is a regression? If so we should run a > regression window. I'd be particularly curious to know if the offender was > bug 1085223 based on the video in [2] if the regression is recent. Even if > this didn't work in 2.1 we can still run a regression along the gecko > changes that we're made in 2.2 to see if a change broke it. It will be pretty hard to have QA run a regression window on this, since the bug is only uncovered after bug 1082071 landed. Yeah, I am also not convinced this is a regression at all. The only way I see is to bisect gecko with bug 1082071 applied, which I can probably help with, but I won't be able to get to it until later this week.
Flags: needinfo?(mhenretty)
Comment 15•10 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #12) > This only becomes 2.1+ if we actually uplift bug 1082071 to 2.1 - we should > not do that and introduce a regression until we have the regression taken > care of. I've commented in bug 1082071 to that effect. In the meantime, we > can take a look at this on the trunk. I have serious doubts that this is > graphics, but Benoit can help find the problem. We uplifted bug 1082071 to 2.1 last week :/
Assignee | ||
Comment 16•10 years ago
|
||
I just noticed that the log contains "y req scale factor beyond capability" which means this is likely the same underlying issue as bug 1075265.
Assignee | ||
Comment 17•10 years ago
|
||
I'm having trouble reproducing the bug on master. Going to setup a 2.2 build. Meanwhile since you can reproduce can you see if the bug goes away when you disable Hardware composer from the develop menu? Notice how the glitches happens on the frames where the FPS counter doesn't render (those frames we use HWC)? This points to my theory in bug 1075265 Comment 12. Milan might be correct in bug 1075265 Comment 11. It could be that HWC has a scaling limitation that we don't check before running through HWC.
Flags: needinfo?(mhenretty)
Comment 18•10 years ago
|
||
Michael, while Sushil is away, can you find somebody to tell us if there are HWC limitations on the type of scaling it can do? Looking at some code it seems that anything outside of 8x scale (in either direction) may be a problem.
Flags: needinfo?(sushilchauhan)
Flags: needinfo?(mvines)
Assignee | ||
Comment 19•10 years ago
|
||
Alright I was able to reproduce the problem. Disabling HWC does in fact make the problem goes away. It looks like we're missing some checks in |gecko/widget/gonk/HwcComposer2D.cpp|. I've tried few obvious things (force a large scale) but that wasn't it. I'm going to dig deeper but this is something that codeaurora can probably give us a good answer on.
Comment 20•10 years ago
|
||
Sorry about the late response here. Yeah, turning off the HWC did indeed eliminate the issue. Also, this issue does happen on master for me, but it seems far less pronounced for some reason. Let me know if you want me to try anything else.
Flags: needinfo?(mhenretty)
Comment 21•10 years ago
|
||
So, Benoit, extending the check https://github.com/mozilla/gecko-dev/blob/master/widget/gonk/HwcComposer2D.cpp#L374 to see if the scale on the transform is < 1/8 or > 8 does not work?
Flags: needinfo?(bgirard)
Comment 22•10 years ago
|
||
(Diego, can you please check on this with folks here?)
Flags: needinfo?(sushilchauhan)
Flags: needinfo?(mvines)
Flags: needinfo?(dwilson)
Comment 23•10 years ago
|
||
(But yes there are limitations to the amount of scaling up/down the MDP can do. 1/4 to 8x seems about right, but I don't have the actual limits handy ATM)
Assignee | ||
Comment 24•10 years ago
|
||
Ok wow, I think we're hitting a ton of things here. First we need to fix to bug 1075265 but that's not sufficient. This further tweaks the opacity code. I'm not certain why this is needed. It feels like the hardware composer touches the bits between a complex region so if we're not blending then we override the data. It would be nice to get someone who knows HWC more to comfirm that this is needed and a good fix. It fixes the graphical glitches for me. We still get the black rendering which like I said earlier I suspect is a content bug (or layout bug at the worse).
Flags: needinfo?(bgirard)
Assignee | ||
Updated•10 years ago
|
Attachment #8513797 -
Flags: review?(dwilson)
Assignee | ||
Comment 26•10 years ago
|
||
Hey Sotaro, do you feel comfortable reviewing this patch? Note since Sushil is away and we're missing a bit of information we're going to be taking a bit of a risk putting this on 2.1.
Flags: needinfo?(sotaro.ikeda.g)
Comment 27•10 years ago
|
||
HwComposer hal's function optimizeLayerRects() seems a root cause of the problem. https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/tree/libhwcomposer/hwc_utils.cpp?h=b2g_kk_3.5#n1152
Flags: needinfo?(sotaro.ikeda.g)
Comment 28•10 years ago
|
||
optimizeLayerRects() do layer optimization without thinking about visibleRegionScreen. If layer is composed from multiple visible Region, it could expose un-rendered areas.
Comment 29•10 years ago
|
||
The patch fixes the problem at HwComposer level. It seems to fix the problem on local testing.
Comment 30•10 years ago
|
||
Comment on attachment 8516204 [details] [diff] [review] patch - Do not optimize layers when layer has multiple visible regions BenWa, can you give a feedback to the patch?
Attachment #8516204 -
Flags: feedback?(bgirard)
Assignee | ||
Updated•10 years ago
|
Attachment #8513797 -
Attachment is obsolete: true
Attachment #8513797 -
Flags: review?(dwilson)
Assignee | ||
Comment 31•10 years ago
|
||
Comment on attachment 8516204 [details] [diff] [review] patch - Do not optimize layers when layer has multiple visible regions Review of attachment 8516204 [details] [diff] [review]: ----------------------------------------------------------------- Thanks Sotaro, this is a better fix!
Attachment #8516204 -
Flags: feedback?(bgirard) → feedback+
Comment 32•10 years ago
|
||
Comment on attachment 8516204 [details] [diff] [review] patch - Do not optimize layers when layer has multiple visible regions Diego, can you review the patch? Now, it becomes clear the problem is caused by optimizeLayerRects() in /libhwcomposer/hwc_utils.cpp.
Attachment #8516204 -
Flags: review?(dwilson)
Comment 33•10 years ago
|
||
When the HwComposer hal is landed, we could remove similar workaround from HwcComposer2D.
Comment 34•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #32) > Comment on attachment 8516204 [details] [diff] [review] > patch - Do not optimize layers when layer has multiple visible regions > > Diego, can you review the patch? Now, it becomes clear the problem is caused > by optimizeLayerRects() in /libhwcomposer/hwc_utils.cpp. Sorry for the delay, I was on vacation. Have you checked if the video playback and camera preview cases still use HWC after this patch is applied?
Flags: needinfo?(dwilson) → needinfo?(sotaro.ikeda.g)
Comment 35•10 years ago
|
||
No problem. I confirmed that full screen video playback and camera preview are still using HwComposer by applying the patch on v2.1 flame.
Flags: needinfo?(sotaro.ikeda.g)
Comment 36•10 years ago
|
||
Comment on attachment 8516204 [details] [diff] [review] patch - Do not optimize layers when layer has multiple visible regions LGTM. Let me fix this to CAF
Attachment #8516204 -
Flags: review?(dwilson) → feedback+
Comment 37•10 years ago
|
||
Thanks!
Comment 38•10 years ago
|
||
(In reply to Diego Wilson [:diego] from comment #36) > Comment on attachment 8516204 [details] [diff] [review] > patch - Do not optimize layers when layer has multiple visible regions > > LGTM. Let me fix this to CAF diego, is there a progress to CAF about this bug?
Flags: needinfo?(dwilson)
Comment 39•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #38) > (In reply to Diego Wilson [:diego] from comment #36) > > Comment on attachment 8516204 [details] [diff] [review] > > patch - Do not optimize layers when layer has multiple visible regions > > > > LGTM. Let me fix this to CAF > > diego, is there a progress to CAF about this bug? I landed this patch internally but the release process is stuck right now. I'll update you once it's in CAF.
Flags: needinfo?(dwilson)
Comment 40•10 years ago
|
||
Landed on CAF https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/commit/?h=LNX.LF.3.5.1_RB1.2&id=db3737d957e10661b3f8d2fb7e70e7fbda25a699
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 41•10 years ago
|
||
diego, if we want to use the above change, which version(tag) should we use? LNX.LF.3.5.1_RB1.2? current flame build use b2g_kk_3.5. https://github.com/mozilla-b2g/b2g-manifest/blob/master/flame-kk.xml#L24
Flags: needinfo?(dwilson)
Updated•10 years ago
|
Whiteboard: [2.2-Daily-Testing] [shb-enabled] → [2.2-Daily-Testing][shb-enabled][POVB]
Comment 42•10 years ago
|
||
(In reply to Diego Wilson [:diego] from comment #40) > Landed on CAF > > https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/ > commit/?h=LNX.LF.3.5.1_RB1.2&id=db3737d957e10661b3f8d2fb7e70e7fbda25a699 Just replace /hardware/qcom/display/ from revision="b2g_kk_3.5" to revision="LNX.LF.3.5.1_RB1.2" caused the build failure. MDSS_MDP_HW_REV_100 is already defined by out/target/product/flame/obj/KERNEL_OBJ/usr/include/linux/msm_mdp.h in moz build kernel source. ----------------------------------------------------- target thumb C++: libqdutils <= hardware/qcom/display/libqdutils/mdp_version.cpp In file included from hardware/qcom/display/libqdutils/mdp_version.cpp:31:0: hardware/qcom/display/libqdutils/mdp_version.h:67:5: error: expected identifier before '(' token hardware/qcom/display/libqdutils/mdp_version.h:67:5: error: expected '}' before '(' token hardware/qcom/display/libqdutils/mdp_version.h:67:9: error: expected unqualified-id before numeric constant hardware/qcom/display/libqdutils/mdp_version.h:67:9: error: expected ')' before numeric constant hardware/qcom/display/libqdutils/mdp_version.h:67:9: error: expected ')' before numeric constant hardware/qcom/display/libqdutils/mdp_version.h:67:9: error: expected ')' before numeric constant hardware/qcom/display/libqdutils/mdp_version.h:67:9: error: expected ')' before numeric constant In file included from hardware/qcom/display/libqdutils/mdp_version.cpp:31:0: hardware/qcom/display/libqdutils/mdp_version.h: In member function 'bool MDPVersion::is8084()': hardware/qcom/display/libqdutils/mdp_version.h:136:27: error: 'MDSS_MDP_HW_REV_104' was not declared in this scope hardware/qcom/display/libqdutils/mdp_version.h: In member function 'bool MDPVersion::is8092()': hardware/qcom/display/libqdutils/mdp_version.h:140:27: error: 'MDSS_MDP_HW_REV_206' was not declared in this scope hardware/qcom/display/libqdutils/mdp_version.h: At global scope: hardware/qcom/display/libqdutils/mdp_version.h:164:1: error: expected declaration before '}' token make: *** [out/target/product/flame/obj/SHARED_LIBRARIES/libqdutils_intermediates/mdp_version.o] Error 1
Comment 43•10 years ago
|
||
moz build msm_mdp.h is very different compared to recent caf code. It seems to cause the problem.
Updated•10 years ago
|
Flags: needinfo?(dwilson)
Comment 44•10 years ago
|
||
Diego, is it possible to apply the fix to caf b2g_kk_3.5.
Flags: needinfo?(dwilson)
Comment 45•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #44) > Diego, is it possible to apply the fix to caf b2g_kk_3.5. Hey Sotaro, you probably should fork and apply the fix yourself in your tree.
Comment 46•9 years ago
|
||
clear need info. This is moz build specific problem.
Flags: needinfo?(dwilson)
Comment 47•9 years ago
|
||
Is this fixed on Mozilla's end at this point for v2.1+?
Comment 48•9 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #47) > Is this fixed on Mozilla's end at this point for v2.1+? When we do shallow flash, the problem is fixed. But when we do deep flash, the problem exits on flame.
Flags: needinfo?(sotaro.ikeda.g)
Comment 49•9 years ago
|
||
(In reply to Michael Vines [:m1] [:evilmachines] from comment #45) > (In reply to Sotaro Ikeda [:sotaro] from comment #44) > > Diego, is it possible to apply the fix to caf b2g_kk_3.5. > > Hey Sotaro, you probably should fork and apply the fix yourself in your tree. mwu, should we create a fork by ourselves and fix the problem only for deep flash case? As in comment 43, just update related module to latest caf code causes the build failure on moz build.
Flags: needinfo?(mwu)
Comment 50•9 years ago
|
||
I think we should actually be switching to LNX.LF.3.5.1_RB1.2 where appropriate. We should be tracking CAF closely on Flame. I don't know if T2M is switching to these new releases yet though.
Flags: needinfo?(mwu)
Comment 51•9 years ago
|
||
Viral, do you know if we're getting a kernel source update for v10D?
Flags: needinfo?(vwang)
Comment 52•9 years ago
|
||
(In reply to Michael Wu [:mwu] from comment #51) > Viral, do you know if we're getting a kernel source update for v10D? Hi Michael, So far t2m provide the latest release is v18D. they still use caf b2g_kk_3.5 (tag:caf_AU_LINUX_GECKO_B2G_KK_3.6.01.04.00.000.120) for kernel Shall we merge the fix in comment 40 to our own kernel branch (b2g/t2m-flame-3.4-kk)? or we should move to LNX.LF.3.5.1_RB1.2 directly? (i'm not sure t2m would like to change kernel branch in their side)
Flags: needinfo?(vwang)
Comment 53•9 years ago
|
||
Created a branch for flame-kk https://github.com/mozilla-b2g/hardware_qcom_display/tree/flame-kk
Comment 54•9 years ago
|
||
merged the fix to flame-kk https://github.com/mozilla-b2g/hardware_qcom_display/commit/e9fec005c70530d74f3c922800f0fa0947b93364
Comment 55•9 years ago
|
||
Updated•9 years ago
|
Attachment #8643302 -
Flags: review?(mwu)
Updated•9 years ago
|
Attachment #8643302 -
Flags: review?(mwu) → review+
Comment 56•9 years ago
|
||
https://github.com/mozilla-b2g/b2g-manifest/commit/881a4434e83265c00f7390e5b5c9e4cec80d6cc2
You need to log in
before you can comment on or make changes to this bug.
Description
•