Commit [1] ("Introduce a dependency monitor for fences") has added new
members to the GraphicBuffer struct, increasing the size from 0x100 to
0xd30. camera.xiaomi.so creates GraphicBuffer in its constructors using
"new GraphicBuffer(..)" which encodes the size to allocate at compile
time. Then, on destruction of the object, the implicit destructor will
try to destruct the new members, but, since this memory was not
allocated for the object, this leads to memory access of unallocated
storage.
F DEBUG : backtrace:
F DEBUG : #00 pc 000000000003ba00 /vendor/lib64/libui.so (__aarch64_ldadd8_acq_rel+16) (BuildId: b577faa139eb3404c7d3a674b147634c)
F DEBUG : #01 pc 0000000000051364 /vendor/lib64/libui.so (android::GraphicBuffer::~GraphicBuffer()+248) (BuildId: b577faa139eb3404c7d3a674b147634c)
F DEBUG : #02 pc 0000000000051698 /vendor/lib64/libui.so (android::GraphicBuffer::~GraphicBuffer()+20) (BuildId: b577faa139eb3404c7d3a674b147634c)
F DEBUG : #03 pc 0000000000011064 /vendor/lib64/libutils.so (android::RefBase::decStrong(void const*) const+164) (BuildId: 99d1ab745e7b73420d8d2b397483ef54)
F DEBUG : #04 pc 00000000000cd538 /vendor/lib64/hw/camera.xiaomi.so (mihal::GraBuffer::~GraBuffer()+236) (BuildId: a4c59705588bd26d407f0ab181902baf)
[1]: df868baf2a
Change-Id: I239c31b6ea5a7813abc3e9cfbefb6d2bdcc1a9e0
Signed-off-by: therealmharc <therealmharc@gmail.com>
libswvdec.so is no longer needed with the Codec2 media stack + this is a
OMX library which we already drop long ago.
Change-Id: I01a801148e4db65ff8e4357668c08abac8c9c7b2
Signed-off-by: therealmharc <therealmharc@gmail.com>
* breaks google voice match with pixelpropsutils as
we don't have hotword enrollment support
Change-Id: I213626f9729e5ff47ce7e6c990d605ed669b97e3
Signed-off-by: Adithya R <gh0strider.2k18.reborn@gmail.com>
Signed-off-by: therealmharc <therealmharc@gmail.com>
* Having this enabled makes vili fast switch randomly on loops from 120-60Hz, being so fast that our display doesn't have enough time to react, making garbage content to be shown, like a CRT on static...
So, for avoiding the "CRT bug", we disabled it for good:
Test: After disabling that, see if 120Hz seems stable and no glitches on display appeared
Results: 120Hz locked refresh rate when smooth display enabled, no CRT bug at all
To-do: Adjust idle timing, display in inactive likes to switch back and forth, not so fastly, but noticeable
Change-Id: I24641e8e3b6e9b80328cdf1c0fa65d9a16085acd
Signed-off-by: AdarshGrewal <adarshgrewal@gmail.com>
Signed-off-by: therealmharc <therealmharc@gmail.com>
Stune prefer_idle minimizes wakeup latency and helps spreading all tasks
evenly across cores, however, it may increase energy consumption. To
minimize effect on battery disable it when screen goes off, this will
optimize task placement for energy.
Signed-off-by: Andrzej Perczak <linux@andrzejperczak.com>
Change-Id: I57c9820a8a3d8bff8efe6815bb9c053d1c3ff7d5
Signed-off-by: therealmharc <therealmharc@gmail.com>
* The powerhint configuration is really weird here. As it turns out,
in commit [1], Google was probably testing the sm7150-aa and sm7150-ab
for sunfish and for them, they couldn't find any common frequenices.
Hence, they decided to use the pwr_levels of respective SoCs for boosting
the GPU which in this case was very conviniently set to 0 which basically
does no boosting. (Although that shouldn't actually be the case.) (Source:
watch -n 0.5 the node in question)
* To get the frequencies available to userspace we cat the node:
sweetin:/ # cat /sys/class/kgsl/kgsl-3d0/devfreq/available_frequencies
180000000 267000000 355000000 430000000 565000000 650000000 800000000
* Snapdragon 732G at minimum frequencies can't handle blur very well. This
should help a lot.
[1]: d564c5b2c3
Change-Id: I015c609b63d1eabe30e9774e23ea1796e6000fc4
Signed-off-by: therealmharc <therealmharc@gmail.com>
The difference in wakeup latencies isn't so significant, let CPU cores enter
deeper idle states to save some power.
Change-Id: I9b24adc356bf35bbdc0bda6e0eee982b4daf1350
Signed-off-by: therealmharc <therealmharc@gmail.com>
