* Fixes touch on some devices like chiron/sagit
* Some other devices (e.g. most MTK) need this because their kernel driver
implementations do not perform as expected (initial unblank is only
happening when altering the panel brightness x -> 0 -> y). In regular
Android, that "unblanking" is done on boot when the lights HAL loads and
sets the initial brightness.
Change-Id: I2fffac508d09d07355a7a7f087805b0dceb5f97e
This reverts commit 159a5473a2.
Reason for revert: This breaks menu scrolling on wear devices
Bug: 309813434
Change-Id: If68683fcef0e9689fa6cfea1af5aab559f99fb3a
Recovery and fastbootd hardening.
With GKI we find in certain situations the timing of the drivers
loading is delayed as compared to a monolithic kernel. This
exasperates an existing race where during second stage init, the
graphics driver might not have completely instantiated by the time
fastboot or recovery menu ui is being set up.
To address this, we call gr_init() every 10ms until either 5 seconds
timeout or success. If we timeout, there will be no TUI (minui), but
this is better than if we just tried once and dropped the TUI and was
effectively running headless. 5 seconds timeout is arbitrary, based
on the default in init for wait for file; but makes sense as any
longer will impact flashstation and fastboot flashall enough to be
a cause for consternation.
It should be noted that both recovery and fastbootd can still service
adb or fastboot gadgets headless. For instance if the device tree is
misconfigured as a permanent issue that would head for the timeout.
Prefering to give up after a timeout so that device can be flashed by
fastbootd, or rebooted by recovery adbd, over the protocol is
advantageous for tool stability.
Architectural Concern:
The graphics driver, if not well written, may panic the kernel if we
try to access it too soon while it is probing. On such devices it
will be necessary to hold off in 'on init' or 'on early-init' phases
until the graphics drivers have completely probed. Or better yet,
fix the driver. This problem would happen in any case occasionally
even without this adjustments, but could conceivably be amplified by
the loop trying to open the graphics device.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 151950334
Test: make sure user space fastbootd comes up reliably for a GKI kernel
Change-Id: I1ce31a01544a58cdf7b9d657c1146bee77894e46
When display screen size is too small, some images in recovery
resource cannot caculate the right display position. So the
image cannot show in the screen.
Limit the calculated position to avoid such issue.
Change-Id: Iebebfe0dfbc568ee3a6b6a31b81d060b3ce5f940
Signed-off-by: zhang sanshan <sanshan.zhang@nxp.com>
Bug: 144974129
Test: Manual - Testing OTA and Factory Reset
1) Tested with matching device name ({devicename}00000.png)
2) Tested with no matching device name (uses loop00000.png default)
3) Tested with empty string device name (uses loop00000.png default)
Change-Id: I4c73af82ab8826d1a43fe193a7616bc219d536e4
Then we can override this function in the device specific recovery ui;
and allow customizing the help message.
Bug: 137965958
Test: Check the menu on sailfish
Change-Id: I09f23166f4205c5edf6c62eb42c8ada0fa710b26
We used to show the image for the last locale or an empty image, if
the localized image is missing for a specific locale. As the default
english one is more meaningful to users, we should just error out and
fall back to use the default locale when the image loading fails.
Bug: 128934634
Test: run graphic test, locale test
Change-Id: Iafd3e8466aec63b4952d1959b2a3d37e358677d4
This helps to expose librecovery_ui for device specific RecoveryUi.
Bug: 76436783
Test: mma, unit tests pass
Change-Id: Ic6c3d301d5833e4a592e6ea9d9d059bc4e4919be
(cherry picked from commit b5108c372c)
