| Commit message (Collapse) | Author | Files | Lines |
|
Auto detect and support both the v1 and v2 fstab formats
Support putting TWRP style flags in a separate /etc/twrp.flags file
twrp.flags format is the same as twrp.fstab (v1 with TWRP flags)
Support using a wildcard in a block device and find all partitions:
/usb-otg vfat /dev/block/sda*
Support using sysfs entries (voldmanaged) and read uevents and scan for
wildcard partitions from uevent data. (twvold?)
May not be complete for some of the newer flags found in fstabs in newer
build trees and there is a slim chance of a crash if the user removes a
removable device while TWRP is performing actions. May need to add some
kind of mutex to prevent the 2 threads from causing this crash. We need
to start somewhere though and this change is pretty innocuous when not
using a v2 fstab.
Change-Id: I617d97c7db332cbe671a9d2b8ad98b3d9c4f03cc
|
|
Apparently we are supposed to delay going to the next line until the next
character is printed.
Change-Id: I5cd0cc128cc00dcdd0dd2dd9508281f1249db257
|
|
Change-Id: I93c65973679894bb8587da4b38b410d38036b8bd
|
|
Translating CR to LF was an old hack that breaks Enter in nano.
Change-Id: If259e8b133f2f56f4126a1fb68856bf014a2daae
|
|
This makes the terminal grab focus no matter what on SetPageFocus
which isn't ideal but it's unlikely that any other visible input
elements will be on the page with a terminal anyway.
Credit _that for pointing me in the right direction for this fix.
Change-Id: I2b0e6fc1169521f58e863c58f7ef3578413dfb21
|
|
Note: events.cpp is still old code renamed to cpp to make it
easier to call functions like gr_fb_width().
I had to modify AOSP fbdev code to provide a separate memory
surface for drawing to as drawing directly to the framebuffer
resulted in rendering taking about 5 times longer.
I also modified AOSP adf code to provide a separate memory surface
for drawing for the same performance reasons. The Nexus 9 supports
adf graphics.
Overlay graphics work on at least one device. Overlay provides a
separate memory buffer already so performance is good.
I do not have a drm device yet that I know of. I made some attempt
to update the drm code to determine the correct pixel format based
on the drm graphics format, but what is available in pixel flinger
and what is available in drm do not line up all that well. Reports
are that the Pixel C is using drm graphics, but performance is
slow, likely due to the use of a mmap instead of a memory buffyer.
Change-Id: Ibd45bccca6ac2cb826037aa9b2aa5065cf683eed
|
|
Only the last action got its keys and ate all of them (om nom nom).
This fixes the power button action that activates the lock screen.
Change-Id: Ia724568b159090c2c14a282cf3927915b2dc70e7
|
|
Change-Id: Ia46d8acb8b13075a2519df1deb91dd30a5969a48
|
|
Emulates enough of a VT-100 to run busybox vi.
Change-Id: I99c829c6c9de2246194ecb8b8b3cdf4ac34a0606
|