There's nothing really that different here when compared to the
common HAL except for the specific DT2W handling, which can simply
be supported as a power feature lib.
Change-Id: I4c9c2530c8090e05dab38ed829d59ece5e00e1fb
Some variants of dipper have fts instead of fts_ts.
Test: DT2W works again with this touchscreen type on dipper.
Signed-off-by: Henrique Pereira <hlcpereira@pixelexperience.org>
Change-Id: I75ab85e1badbb4bc22fec073c4382e4da1634593
It is no longer a surprise for anyone to see Xiaomi shipping the same
device with different displays and different displays usually mean
different touchscreen drivers.
The current double tap handling in the power HAL only takes into
account one specific node, meant to be set in the device tree.
However, if the touchscreen was registered as a different input device
it would cause the feature to be broken. Address the issue by iterating
through the input devices in order to find one supported touchscreen
input to be used.
Co-authored-by: LuK1337 <priv.luk@gmail.com>
Change-Id: I2f7fb4a8b0c9cd1a16d6c2b93602d285a191f170
Moving from the default implementation to a binderized service with no
wrapping.
Now using 1.2 implementation of the IPower interface.
Change-Id: Ibefd916544f51545e6889684a051b2ecc5867fe2
The current use of the SCROLL_PREFILING hint hurts scroll performance
and results in a lot of dropped frames.
The hint ID corresponding to SCROLL_PREFILING only takes into effect for
a default timeout value of 80 ms (as found in perfboostsconfig.xml),
while the duration value in the process_interaction_hint function runs
for a much longer time, from 1500 ms up to 5000 ms (bounds of
kMinFlingDuration and kMaxInteractiveDuration). During the period
of time, when the timeout value has elapsed and current time is less
than duration, another interaction hint cannot be processed. Therefore,
if the user decides to scroll during this period, high frame drops can be
experienced as the CPU freq isn't raised by processing another hint to
account for this additional scrolling.
By only using SCROLL_VERTICAL, fluidity can be maintained, improving user
experience.
Change-Id: I2fbde8b2db6710d262e9a058e0bc9c02e524648c
Currently, the launch boost perflock is held for a fixed duration, either
specified in perfboostsconfig.xml for perf HAL platforms or hardcoded in the
powerHAL for non-perf HAL platforms.
Using a fixed duration for this perflock has two shortcomings:
* perflock can be held for too long, causing the CPU freq and other resources
to be boosted for too long even if the application has finished launching,
resulting in excessive battery drainage
* perflock can be held not long enough if it takes more than the timeout
time to finish launch
The framework sends out a powerhint for both when launch starts and when
launch ends. The launch finish hint can be used to signal when to release the
perflock.
Reference: Wahoo power-libperfmgr
Change-Id: I405cc453c5f58d9fb2583b9c6017f3964a0ce024
The service must be made part of the input group,
so that the power HAL can access the input nodes present
in the different targets.
Change-Id: I30a7bde8aebac4b76cbf59f5f795ea245aba1014
Signed-off-by: Giuseppe Barillari <joe2k01dev@gmail.com>
Removed unused code and added generic hint handling to power.c file,
does not need to be device specific anymore.
Change-Id: I0d4e2a73de0ce4d3735314d2e49ba58c23eb313c
Using the wall clock will cause boosts to be disabled
when/if the clock is adjusted backward.
Bug: 29191415
Bug: 29208304
Change-Id: I8af5f40b46d996ce7bccb8324fc186e2f3a5b267
* MP-CTL does not handle POWER_HINT_INTERACTION and POWER_HINT_LAUNCH
directly. Requests for processing are sent by Qualcomm BoostFramework
(QPerformance) at the framework service level. Since we do not have
BoostFramework, process POWER_HINT_INTERACTION and POWER_HINT_LAUNCH
in PowerHAL to ensure a sufficient level of performance.
* For proper operation, perfboostsconfig.xml file is required.
Change-Id: I9fedcbaa189147c91d932711c831c2ce038a7ec7
