summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-08-05Merge tag 'LA.QSSI.12.0.r1-08300-qssi.0' into sugisawa-mr1HEADsugisawa-mr1alk3pInjection
"LA.QSSI.12.0.r1-08300-qssi.0" Change-Id: Ib5fe7bc85b384f41d021ab589bcbe766e1530d02
2022-07-14Merge 5772d30adadc6e28c222b1181d018d42e2fc09f9 on remote branchLinux Build Service Account
Change-Id: I43a4b62bd5348447c9896b4f2ae043c25e0b45b2
2022-06-30Merge 9f70df8d9689aa25feff1401d79b0f33e49694a8 on remote branchLinux Build Service Account
Change-Id: Ieb3e1679d44498ece6ed183c031718aa4a43d6c8
2022-06-29Merge tag 'LA.QSSI.12.0.r1-07900.02-qssi.0' into sugisawa-mr1alk3pInjection
"LA.QSSI.12.0.r1-07900.02-qssi.0" Change-Id: I9aa382ae8a20c05271a6ffbe1c57285b63261fc4
2022-06-22Snap for 8753707 from b2c623dae56c6b8ad98baeab49798023374c05e8 to ↵Android Build Coastguard Worker
s-keystone-qcom-release Change-Id: I3bf633dcdf9d1ea1870d04aafdd479438707250f
2022-06-21Merge "sf: do not check virtual display hint on main thread" into ↵Treehugger Robot
s-keystone-qcom-dev
2022-06-21sf: do not check virtual display hint on main threadVikas batchu
CRs-Fixed: 3224354 Change-Id: I0e20ddb96301c746a56a04703eb17d592d08896d
2022-06-15Snap for 8720886 from 7d844c38698fe873829983c91122b07bc92be350 to ↵Android Build Coastguard Worker
s-keystone-qcom-release Change-Id: If7763a35b0fb755602f2431bd8b4bf6843d8ba79
2022-06-14Merge "sf: update phase offsets with extension values properly" into ↵Treehugger Robot
s-keystone-qcom-dev
2022-06-14sf: update phase offsets with extension values properlyPadmanabhan Komanduru
Add change to update VsyncConfiguration with Phase Offset values everytime the vsync configuration is reset during active display change. Change-Id: I5e80875f13a2d0c1229804f328170f6a1778f99d CRs-Fixed: 3197703
2022-06-10Snap for 8705312 from 8973353855b9b73e4e84123b6ae282ccfe4d800a to ↵Android Build Coastguard Worker
s-keystone-qcom-release Change-Id: Ie355faa1690b583f15b70eac4b457a9d4786dd2e
2022-06-09sf: check max display count for async virtual display creationVikas batchu
CRs-Fixed: 3205758 Change-Id: Ib2f0f7529b19422d8d7f025174973d6a9d1cccb3
2022-06-02Merge tag 'LA.QSSI.12.0.r1-07600-qssi.0' into sugisawa-mr1alk3pInjection
"LA.QSSI.12.0.r1-07600-qssi.0" Change-Id: Id9fc85810c1fae395e39c4d53c7633928b2d2bc8
2022-05-30Merge 263a8b3910df5774baafba76077d99693bbc814a on remote branchLinux Build Service Account
Change-Id: I33ee65644b3c71c683646169f09167547c41742e
2022-05-16Merge 473c0482e798a3a4cce580a311ac15e6e2069c6c on remote branchLinux Build Service Account
Change-Id: I7e193eaa9cb592cc465d7aa16526cd2814c543b9
2022-05-06Snap for 8548593 from 0cd2304dfad25401cf47174689d446aa0ecbbe33 to ↵Android Build Coastguard Worker
s-keystone-qcom-release Change-Id: I24ed51c2fef9e72d784b8fd43de292734ee8365a
2022-05-02surfaceflinger: Modify dumpAll to dump on the main threadRajat Yadav
Modify dumpAll to dump on the main thread to address the race condition issue pertaining to dual display use case. surfaceflinger: Modify dumpProtoFromMainThread to lock mStateLock Modify dumpProtoFromMainThread to lock mStateLock in case there are threads outside of main thread accessing local objects. CRs-Fixed: 3163560 Change-Id: I13cad753f07c53585e377a4199d5cec538368914
2022-05-02MotionEvent: Add backwards compatible initialize() functionLuK1337
After 0957669 changed MotionEvent::initialize() function signature, libwfdnative.so compiled for Android 12 fails to load. Change-Id: I8ad721adc0f00610836df62826d74d7da6764a39
2022-05-02Merge tag 'LA.QSSI.12.0.r1-07100.01-qssi.0' into sugisawa-mr1alk3pInjection
"LA.QSSI.12.0.r1-07100.01-qssi.0" Change-Id: I0ee831bc1ae8e0218b43a230c7672b3a4deefb48
2022-04-29Merge 1f5125be037d697985b407487b7be83949c7140f on remote branchLinux Build Service Account
Change-Id: Ic94a7892a8a9421b7d9738de30a4c37a1d78c07a
2022-04-22Snap for 8487650 from 8aa2ae5a0c5255de801c25529b77574bd8661fac to ↵Android Build Coastguard Worker
s-keystone-qcom-release Change-Id: Ic02ab3e92dedda692e521680e0d15e17dc9a24e9
2022-04-22Merge "sf: acquire mStateLock to access mCurrentState" into s-keystone-qcom-devRamesh Garimella
2022-04-21sf: acquire mStateLock to access mCurrentStateVikas batchu
CRs-Fixed: 3166524 Change-Id: I08e687c016ea21d9fab5aa160413ba64f35bac77
2022-04-20sf: Passing Supported Refresh Rate to smomo.Rajat Yadav
CRs-Fixed: 3163067 Change-Id: I58930faf732caa89e281fc183229b38f560ada3e
2022-04-16Merge commit 'c2d8c62c743da5ba1bb6b8a40cf066ff0b607eb6' into ↵Murtuza Raja
ks-aosp.lnx.12.0.r1-rel Change-Id: I37d9d228b86752974fab86facb0fbcbbd16ab9f3
2022-04-15Snap for 8459452 from 8f2727dfc631eda85e153478b8d5d6a5b15aa4f7 to ↵Android Build Coastguard Worker
s-keystone-qcom-release Change-Id: If4e236589b8430a2c91e3f7298c02a45b5abe1f8
2022-04-14sf: add smomoLayerStackId for LayersVikas batchu
avoid using getLayerStack in setTransactionState as it results in sf crashes. CRs-Fixed: 3174977 Change-Id: I029c6488a5165e702ca6b514ba54f47384a7449a
2022-04-13Snap for 8444091 from a3996862bab999901d3682d36ca970e447980427 to ↵Android Build Coastguard Worker
s-keystone-qcom-release Change-Id: I9c06f0d69dcab5cad148d3bbb8bb282b367b0836
2022-04-12Merge "sf: Reconfigure display for mode change only if resolution changes" ↵Treehugger Robot
into s-keystone-qcom-dev
2022-04-12Merge "sf: Reconfigure display for mode change only if resolution changes"Linux Build Service Account
2022-04-12Merge "sf: Reconfigure Display without waiting for mode change"Linux Build Service Account
2022-04-12sf: Reconfigure display for mode change only if resolution changesDevanshi Bansal
CRs-Fixed: 3170218 Change-Id: I9b2db0b5a047c159440ef532211c0cfaa03808da
2022-04-12sf: Reconfigure Display without waiting for mode changeRajat Yadav
CRs-Fixed:3120039 Change-Id: I3743ab8ff1c78aa4ee6521d44976609089c0d661
2022-04-12Snap for 8437239 from ab9fd81c5e8fe736318fdf67a06d58ada737764d to ↵Android Build Coastguard Worker
s-keystone-qcom-release Change-Id: Ib42ddcb39d7d3d416c7a3b1fa93ef832b5db9b90
2022-04-12sf: Reconfigure display for mode change only if resolution changesDevanshi Bansal
CRs-Fixed: 3170218 Change-Id: I9b2db0b5a047c159440ef532211c0cfaa03808da
2022-04-12sf: compare current FB and layer stack params for FB resolution changePadmanabhan Komanduru
Change-Id: I75a452004f5632f49900648fbe1d851bcc358328 CRs-Fixed: 3171148
2022-04-12sf: do not set frame buffer size when display is powered offVikas batchu
CRs-Fixed: 3159480 Change-Id: I7b678d1e9c8c8b3522b7f7ac1e4563dce2b1b790
2022-04-11sf: compare current FB and layer stack params for FB resolution changePadmanabhan Komanduru
Change-Id: I75a452004f5632f49900648fbe1d851bcc358328 CRs-Fixed: 3171148
2022-04-07Merge "SurfaceFlinger/LayerRenderArea: Hold lock while modifying hierarchy" ↵Linux Build Service Account
into ks-aosp.lnx.12.0.r1-rel
2022-04-07Merge "CaptureLayers: Avoid promoting parent on binder thread" into ↵Linux Build Service Account
ks-aosp.lnx.12.0.r1-rel
2022-04-07sf: check layer stack id only for multi display smomo.Vikas batchu
CRs-Fixed: 3159089 Change-Id: Id751d5ab8b7f4c1a02ff9bfdb4cecbf648905994
2022-04-07CaptureLayers: Avoid promoting parent on binder threadRobert Carr
We promote the parent of the root layer when we call getLayerStack. Since we don't hold an IBinder to the root layers parent, just to the layer itself, this could create a situation where we are the last reference to the layer. Layers have to be destroyed on the main thread and so that would be invalid. Hopefully this is the last case and now we can start getting rid of refbase for layer. Bug: 220176775 Bug: 223069308 Bug: 223081111 Test: Existing tests pass Change-Id: I37a0834ddac6d8e84170674aba0c49268d65fa11 (cherry picked from commit 12a3b9bba87d831f78faabb42523598a8d891ecc) CRs-Fixed: 3159089
2022-04-07SurfaceFlinger/LayerRenderArea: Hold lock while modifying hierarchyRobert Carr
Multiple issues are seen in RenderArea when destroying the screenshotParentLayer container layer used by LayerRenderArea. This code executes on the main thread without a lock. Our rules for locking in SurfaceFlinger are like this: 1. The main thread will hold the lock when writing to the state, and be the only writer 2. Anyone can read the state if they hold the lock 3. Main thread can read from the state without the lock since it is the only writer. LayerRenderArea's reparentForDrawing operation violates these rules by updating mDrawingParent without holding the lock. If there were some other binder thread which was accessing the hierarchy (say calling getAlpha on a layer in the hierarchy descending from our screenshot layer), we could have a sequence like this: 1. Other thread calls mDrawingParent.promote(), on the wp we provided constructing ReparentForDrawing 2. At the same time we destroy ReparentForDrawing and overwrite the wp 3. This causes wp::~wp and wp::promote to interleave 4. While the wp counters themselves are atomic, remember the object itself is not locked, and so after ~wp the counters that we think are stored in our ~wp could be anything and so we could promote without properly incremeting the reference ccount 5. When the sp returned from promote is destroyed, it could then destroy the layer, and when our original sp from LayerRenderArea is destroyed, we then get the issue (which is what we see in the traces). It's hard to say what this other thread is. Over time we have tried to move usage of the Layer hierarchy off the Binder threads to achieve a totally lock-free model. At the moment, I can't find spots in tip-of-tree which would race with mDrawingParent in this fashion. Until we are ready to get rid of mStateLock, apply it's usage consistently with our three rules of locking. Bug: 220176775 Bug: 223069308 Bug: 223081111 Change-Id: I89c5add585f96b7de1f1b21f76b6ea0c6b0de127 (cherry picked from commit 22ceeaaff9be3e71c5473aeabccdb02705565190) CRs-Fixed: 3159089
2022-04-05Snap for 8406016 from 843be86c432287f499845d6032e5568ff0313924 to ↵Android Build Coastguard Worker
s-keystone-qcom-release Change-Id: I3c6f1004a320cf08e039ecda0cd448890cd2a3f1
2022-04-04Merge "SurfaceFlinger/LayerRenderArea: Hold lock while modifying hierarchy" ↵Treehugger Robot
into s-keystone-qcom-dev
2022-04-04Merge "CaptureLayers: Avoid promoting parent on binder thread" into ↵Treehugger Robot
s-keystone-qcom-dev
2022-04-04Merge changes I2b778cc0,Id751d5ab into s-keystone-qcom-devTreehugger Robot
* changes: sf: Avoid present hidl call when DP is disconnected. sf: check layer stack id only for multi display smomo.
2022-04-04Merge c3e6bd2fb2223973f26325d11c28b32b8685cfbd on remote branchLinux Build Service Account
Change-Id: Ic5966863c7610787847f8f7fc4f939af5f87f13e
2022-04-04SurfaceFlinger/LayerRenderArea: Hold lock while modifying hierarchyRobert Carr
Multiple issues are seen in RenderArea when destroying the screenshotParentLayer container layer used by LayerRenderArea. This code executes on the main thread without a lock. Our rules for locking in SurfaceFlinger are like this: 1. The main thread will hold the lock when writing to the state, and be the only writer 2. Anyone can read the state if they hold the lock 3. Main thread can read from the state without the lock since it is the only writer. LayerRenderArea's reparentForDrawing operation violates these rules by updating mDrawingParent without holding the lock. If there were some other binder thread which was accessing the hierarchy (say calling getAlpha on a layer in the hierarchy descending from our screenshot layer), we could have a sequence like this: 1. Other thread calls mDrawingParent.promote(), on the wp we provided constructing ReparentForDrawing 2. At the same time we destroy ReparentForDrawing and overwrite the wp 3. This causes wp::~wp and wp::promote to interleave 4. While the wp counters themselves are atomic, remember the object itself is not locked, and so after ~wp the counters that we think are stored in our ~wp could be anything and so we could promote without properly incremeting the reference ccount 5. When the sp returned from promote is destroyed, it could then destroy the layer, and when our original sp from LayerRenderArea is destroyed, we then get the issue (which is what we see in the traces). It's hard to say what this other thread is. Over time we have tried to move usage of the Layer hierarchy off the Binder threads to achieve a totally lock-free model. At the moment, I can't find spots in tip-of-tree which would race with mDrawingParent in this fashion. Until we are ready to get rid of mStateLock, apply it's usage consistently with our three rules of locking. Bug: 220176775 Bug: 223069308 Bug: 223081111 Change-Id: I89c5add585f96b7de1f1b21f76b6ea0c6b0de127 (cherry picked from commit 22ceeaaff9be3e71c5473aeabccdb02705565190) CRs-Fixed: 3159089
2022-04-04CaptureLayers: Avoid promoting parent on binder threadRobert Carr
We promote the parent of the root layer when we call getLayerStack. Since we don't hold an IBinder to the root layers parent, just to the layer itself, this could create a situation where we are the last reference to the layer. Layers have to be destroyed on the main thread and so that would be invalid. Hopefully this is the last case and now we can start getting rid of refbase for layer. Bug: 220176775 Bug: 223069308 Bug: 223081111 Test: Existing tests pass Change-Id: I37a0834ddac6d8e84170674aba0c49268d65fa11 (cherry picked from commit 12a3b9bba87d831f78faabb42523598a8d891ecc) CRs-Fixed: 3159089
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-03 02:42:09 +0000