Database Info

[PATCH][KERNEL] EB13 camera video lag & sports mode FC fix

Attached is a kernel source patch that fixes the EB13 camera video lag and "Sports" scene mode force-close. It's actually the same kernel bug that's responsible for both.
Also attached is an Odin/redbend-flashable, otherwise stock EB13 kernel with this patch applied. It's intended for anyone who wishes to further test the fix and who is familiar with Odin and/or redbend_ua. For others, I'd recommend waiting until one of the custom kernels integrates the patch or until Sprint releases an official update.
I'll update this post in the morning with a workup of the bug (done, see below), since it's a bit interesting/illustrative. And yes, it's very simple and very silly. One of those things that really never should've happened. Thanks to everyone in the solutions thread for providing clues that were instrumental in locating it.
Bug details:
Shortly after the release of EB13 folks reported lag when recording videos, particularly in low light. Although not obviously related at the time, folks also reported that switching to "Sports" scene mode results in a force-closed (and in my experience, renders the screen inoperable as well, sigh). Folks in the solutions thread also reported that (i) these problems are new to EB13, they weren't present in DK28; and (ii) replacing the user-space camera components (app, libraries, etc.) with DK28 versions did not resolve the problems, implying they were likely due to one or more kernel bugs.
Unfortunately we do not have the DK28 source code to compare EB13 against, but at least knowing that these problems weren't present in DK28 helps narrow down the possible bug locations quite dramatically. Furthermore, it's quite likely that this bug was introduced rather recently, as I imagine it would've been caught by internal testing had it been present in say, December.
So with that in mind, I sorted the kernel source files by modification time and started looking for the most recently-changed files that might be relevant to the camera driver. "include/linux/videodev2_samsung.h" was the first hit with a modification date of 2/8, and indeed it's used by the camera driver ("drivers/media/video/victory/ce147.c", itself last modified on 12/1). Again, we don't have DK28 sources for comparison, but fortunately header files typically don't change too significantly and a comparison (diff) against the DI18 version was rather easy to follow.
And yes, a snippet of code stood out right away as rather strange, especially given the cirumstances of the problem:
Code:
enum v4l2_iso_mode {
ISO_AUTO = 0,
ISO_50,
ISO_100,
ISO_200,
ISO_400,
ISO_800,
ISO_1600,
ISO_FIREWORKS, // Added since DI18.
ISO_SPORTS,
ISO_NIGHT,
ISO_MOVIE,
ISO_MAX,
};
For folks less-familiar with C, this code defines an enumerated type, basically a mapping of "descriptive labels" to numeric values; in this case: ISO_AUTO=0 ISO_50=1, ISO_100=2, etc. This enables kernel code to contain descriptive statements like "iso_mode = ISO_200;" instead of the more arbitrary "iso_mode = 3;".
Now, as the above comment (which I added, but the diff points it out) suggests, ISO_FIREWORKS is a new speed that was added to the middle of the enum since DI18. Seasoned C programmers will recognize that, this is often something that leads to trouble. To understand why, compare the "before" and "after" enum mappings:
Code:
Before: After:
ISO_AUTO: 0 ISO_AUTO: 0
ISO_50: 1 ISO_50: 1
ISO_100: 2 ISO_100: 2
ISO_200: 3 ISO_200: 3
ISO_400: 4 ISO_400: 4
ISO_800: 5 ISO_800: 5
ISO_1600: 6 ISO_1600: 6
ISO_SPORTS: 7 ISO_FIREWORKS: 7
ISO_NIGHT: 8 ISO_SPORTS: 8
ISO_MOVIE: 9 ISO_NIGHT: 9
ISO_MOVIE: 10
The addition of ISO_FIREWORDS to the middle of the enum shifts the mapping of any labels below it, in this case ISO_SPORTS, ISO_NIGHT, and ISO_MOVIE. This isn't fatal, but it does mean that all code that uses the enum needs to be recompiled to reflect the new mapping. Often, kernel header files contain data types that are exclusive to the kernel, so any relevant code gets recompiled as part of the process of compiling a kernel.
But as it turns out, the entries in this enum are used in exactly one location (on the Epic anyways) in the kernel: as a case in a switch statement in the camera driver that sets the ISO mode in a camera hardware register. This means, assuming these values are used at all, they must be provided by a user-space library. In other words, the enum mapping is an integral part of the driver API, and not something that can be altered willy-nilly.
So basically, on EB13 when the Camera app goes to record a movie, it sets mode ISO_MOVIE (9), which the kernel interprets as ISO_NIGHT and sends to the camera hardware. Presumably ISO_NIGHT biases picture quality over shutter speed, hence the blurry laggy video when recording. Similarly, ISO_NIGHT => 8 => ISO_SPORTS (which no one noticed), and ISO_SPORTS => 7 => ISO_FIREWORKS. Except ISO_FIREWORKS isn't implemented, so the driver call fails which results in the force close. Oops!
The fix is fairly simple, just remove ISO_FIREWORKS from the enum. This allows the kernel and the user-space libraries to agree on the mapping. And since ISO_FIREWORKS isn't even implemented in the kernel, no harm can possibly come from it.
Finally, as I stated earlier, this is a bug that never should've happened, for two reasons. First, it was introduced into the Epic kernel source tree after DK28. Now, keep in mind that DK28 was effectively a Froyo "release candidate", especially given that it was packaged up as an OTA update and accidentally pushed to some handsets. Any changes made to the kernel post-DK28 should be limited to strict bug fixes only. The addition of ISO_FIREWORKS to the enum is not part of any bug fix (indeed it introduces one), rather one would consider it a "new feature". But "new features" shouldn't creep into stable code trees. This suggests poor code management.
Second, this alteration would've been a non-issue had ISO_FIREWORKS been appended to the end of the enum, just before ISO_MAX (which, presumably just reports the numer of entries in the enum as opposed to describing a particular mode). This would've assiged ISO_FIREWORKS to an unused value, instead of remapping existing values. Adding ISO_FIREWORKS to the middle of the enum is a particularly short-sighted choice, as it immediately renders any code that uses it unnecessarilly incompatible with new kernels. Adding ISO_FIREWORKS to the end preserves backwards compatibility, for free, with absolutely no downsides--why not do that instead?
So, in short, the failure to properly consider both of these issues, as well as the neglect to notice the change, bespeaks of an incompetent moment on the part of Samsung. If the change really was made on 2/8, one can't really blame Sprint for failing to pick it up during last-minute testing. I'm not sure how much this particular bug was a factor in Sprint pulling the EB13 update, but it's pretty embarassing that it made it out there in the first place.
Mirror links (does not require forum login):
epic_camera_fix-EB13.diff
epic_camera_fix-EB13.tar
epic_stock-EB13.tar (for flashing back to the stock EB13 kernel)

Thank you! This will be in the ACS kernel team's kernel.

Excellent, patching up as we speak.
Sent from my SPH-D700 using XDA App

Just wanted to be 3rd
Sent from my SPH-D700 using Tapatalk

Cool, looks good.
Sent from my SPH-D700 using Tapatalk

patching myself too thx will be in Genocide Kernel 0.3a

THANKS! leave it up to xda to do a better job then Samsung lol
Sent from my SPH-D700 using XDA App

Sweet,
tested working perfect. the LSD trails in video are gone and no FC in sports mode. TY so much.

fix worked great! i just released genocide 0.3a with this patch included! thanks again!

Gotta love 1 line fixes

Would like to try this but only have mac os so odin...

Awesome, thanks man!
Sent from my SPH-D700 using XDA App

Noob question.
Do you put this in PDA? Also no need for PIT or modem file right?
Via TapaTalk on Nook Tablet
-Edit-
Okay, used Odin, put patch in PDA with nothing else set. Worked perfectly! Thanks to all!

You sir a genius....thx for this fix!!!

What is sports mode? I can't find it.

Silent25r said:
What is sports mode? I can't find it.
Click to expand...
Click to collapse
Still camera, settings (gear button)>Scene Mode> Sports Before the fix it's an automatic FC

Can't wait to hear the details behind the bug.
Sent from my SPH-D700 using XDA App

This patched worked perfectly on the genocide kernal!! Thanks For Your Hard Work!!
Now Just Waiting For Bonsai!!

The geniuses at XDA strike again! Brilliant! Thanks!

MoCoTerp said:
Noob question.
Do you put this in PDA? Also no need for PIT or modem file right?
Via TapaTalk on Nook Tablet
Click to expand...
Click to collapse
Help please? I've flashed lots of roms but never a kernal like this. i'd like to stay with the stock ROM. Can't find anything on a search. Can someone either post a link or instructions.

[Q] ICS & SGX - suggestions from developers seeked

Hi,
During implementation of Ice Cream Sandwich for the Renesas Emma EV (dual A9 SoC) based tablets, Renesas support met big problems on the 3D driver (based on a SGX 530 GPU). They have spend more than 2 weeks and still can't find a solution...
I'm forwarding this request on this forum hoping some developer has some bright and smart idea...
Because SGX driver source code is strictly confidential, they can't share the soure code, but they have tries to discribe the problem as clearly as possible.
SGX driver include two parts, kernel mode driver (pvrsrvkm.ko, emxxlfb.ko) and user mode driver(*.so). When they installed the SGX driver, Android halted on finish of boot animation (seems starting to load "home launcher").
When the system halted, it does not response to adb connection and even the serial console (ttyS0) also halted. Seems to be kernel halted.
They got the same problem on official 4.0.1 and 4.0.3. They tested the default openGL test program with the driver (sgx_flip_test, sgx_render_flip_test, texture_benchmark), they all passed.
Possible reason:
1. Status Bar using a different method to draw on screen (not by gralloc.emxx.so? They remember that it doesn't use framebuffer flip operation on Eclair),
it use a unsupported operation cause system halt.
2. Something cause memory overlap, maybe halted in GC_CONCURRENT operation.
3. Other reason...
They need suggestions, any thread is welcome!
I personally found this discussion in a Blog about the official Renesas EMEV development board (requires translation from Japanese):
http://blog.kmckk.com/archives/4030770.html
It mentions something similar and also suggests a solution, but I'm not sure...
thanks!

Would it be possible to "take" some files or learn from another devices(witch also use SGX530) ROM, e.g. the Motorola Defy. If so check: CM9 for Defy

new binder driver helps your phone run smoother

Hi guys,
I've written a completely new Android binder driver (for IPC), which is targeted to solve some fundamental issues in the existing driver. One main improvement is to make concurrent IPC calls possible. Some background info can be found in my earlier post on Android kernel group:
http: slash slash groups.google.com/group/android-kernel/browse_thread/thread/c57874670e4decb1
(oops external urls are not allowed for new users
There weren't many people interested due to low volume of the group. Now that I have completed the first version, which is back compatible with the existing driver, and fixed a few bugs. I've tested on the ICS emulator and my phone U8150 Froyo. It seems to be running quite well, but I want to see how it runs on other Android devices while I'm getting my new phone. Test results, bug/issue reports, and of course community comments will be very welcomed, which are important for me to determine how the code should further move on.
Although not proven, I'm expecting not only those dual core phones, but single core ones will get an overall smoother response in various parts of the system.
Okay if this still somehow interests you, you can find my project on github
https: slash slash github.com/rong1129/android-binder-ipc
and just dive into the release directory, use the latest version (0.4 so far) to patch your kernel source tree, then upload the new kernel image to your device and see whether it works for you.
Note this is still an early release and has very limited tests so far. Please make sure you understand the risk before you hack your phone and always back up everything before you started. As other disclaims go, I'm not responsible for any damage may be caused by or related to using or in the process of using the driver
Lastly, happy hacking!
Cheers,
Rong

*subscribing to this thread*
Hi Rong,
thank you so much
our phones, tablets, etc.
can't have too much smoothness
I hope that I'll find some time within the next weeks to also give this a test on the Xoom and see whether it works (with ICS; Team Eos kernel)
there at least seem to be issues with ICS on the SGS (galaxys s1)
http://forum.xda-developers.com/showpost.php?p=23937103&postcount=2502

I found this thread . Is this driver the same on all android devices and roms? Or do you have to mod it for every single device/rom?

[Project] Porting 3.X kernel to Defy(+)

Even though JB is more or less feature-complete on Defy(+) there are still a few nits which will be hard to squash without having access to features which are only available in later kernels (eg. the ION memory allocator). Given that this board is frequented by people who (theoretically at least) should be able to give a hand in porting the required drivers/features to get a 3.X kernel up and running on Defy(+) I started making an overview of those missing bits. It should only take a relatively small group of willing volunteers, each responsible for a driver or feature, to get those bits ported.
From a quick glance at the configuration options used with the currently used 2nd-boot kernel I come to the following list of drivers/features which will need to be ported to 3.X. Some of these might already be available under different names in the kernel. Others might have been ported but are simply not part of the kernel tree I used to make this comparison (Quarx2k/jordan-kernel; branch 3.0.8-defy_display). Yet others might not be needed in the newer kernel because their functions are taken over by other drivers/features.
This is not a complete list of features needed to get a kernel running on the Defy(+) (see mapphone_defconfig in branch 2.6.32 for what is needed).
In the following list I marked potential replacements in bold type, usually followed by a question mark (?) to indicate I'm not sure they are fully compatible replacements for the 2.6.X drivers/features. The drivers/features are listed in 2.6.X menuconfig order using Kconfig names and symbols.
Drivers needed for Jordan w/kernel 3.x
Top level
Support for open firmware device tree (ARM port)
ARM_OF -> USE_OF ?
Support for device tree in /proc
PROC_DEVICETREE
DSP Bridge driver
MPU_BRIDGE
System Type
Motorola Android Platform Phone
MACH_MAPPHONE -> MACH_OMAP_MAPPHONE ? complete?
Motorola Android Platform phone 2nd-boot kernel modifications
MAPPHONE_2NDBOOT
Export DIE ID code under /proc/socinfo
OMAP3_EXPORT_DIE_ID
Device Drivers/Misc devices
AKM8973 Magnetometer
SENSORS_AKM8973_AKMD
KXTF9 Accelerometer
SENSORS_KXTF9
Bluetooth power control driver for TI wl127x
WL127X_RFKILL
Motorola OMAP Device Type Driver
OMAP_DEV_TYPE_DRV
Motorola Modem PM Driver
MODEM_PM_DRIVER
Motorola netmux driver
NETMUX_DRIVER
Motorola netmux link driver
NETMUX_LINKDRIVER
Motorola Camera Driver
CAMERA_MISC
Device Drivers/Multimedia support/Video capture adapters
HP OMAP3 Imaging/3A driver
VIDEO_OMAP3_HP3A
Video out driver
VIDEO_OMAP_VIDEOOUT -> VIDEO_OMAP2_VOUT ?
Device Drivers/Sound card support/Open Sound System (DEPRECATED)
Audio driver for OMAP3430 with CPCAP
SOUND_CPCAP_OMAP -> SND_OMAP_SOC ( = ALSA)
Device Drivers/USB support
CPCAP USB Transceiver Driver
CPCAP_USB
Device Drivers/USB support/USB Gadget Support
USB Gadget Drivers (MOTO Android Gadget)
USB_MOT_ANDROID
Device Drivers/Real Time Clock
CPCAP RTC
RTC_DRV_CPCAP
So... anyone here who is willing and able to take on one of these drivers/features? Within a reasonable time frame (weeks, not months)? Anyone who knows of existing ports for these missing bits?
Why wait for Quarx or any of the other already overworked developers to do all the work? Just join hands, sing Kumbayah and get porting - but post here which driver/feature you want to work on to avoid needless duplication of effort.
I'll wait a few days for others to take the fun projects, then I'll start on those which are left.

it's a great idea，but it seems so difficult for us to complete such a huge program.

one-piggy said:
it's a great idea，but it seems so difficult for us to complete such a huge program.
Click to expand...
Click to collapse
It is not as big as you make it out to be. The drivers already exist, they just need to be ported. The differences between 2.6.32 and 3.0.X (the first target) are not that big, so the changes needed should be limited. The number of drivers which need to be ported is also rather limited, especially given the potential number of volunteers. The difficulty level for porting these drivers is generally not that high, there are plenty of examples to be found for similar hardware which has already been ported.
The list contains 17 items. Several of them need to be checked for compatibility only (USE_OF, MACH_OMAP_MAPPHONE, VIDEO_OMAP2_VOUT, SND_OMAP_SOC, USB_MOT_ANDROID). This leaves 12 items. The CPCAP-related drivers might already be available (need to check later Motorola code). The procfs-related stuff should be easy to implement (PROC_DEVICETREE, OMAP3_EXPORT_DIE_ID) and might already be available under different names.
For OMAP-specific stuff (CONFIG_MPU_BRIDGE etc) there is linux-omap, more specifically several mailing lists frequented by people who have experience with porting to the linux-omap tree.
Porting the sensor drivers (SENSORS_AKM8973_AKMD, SENSORS_KXTF9) should be straightforward. The camera/video-related drivers might be more complicated as they'll need to be adapted to use ION. Then again, maybe they have already been ported? If not, there should be plenty of examples for similar hardware to base a port on.
I'm not saying porting these drivers/features will be effortless. Nor does it have to be. Porting ICS and later JB to Defy(+) wasn't effortless either yet still someone did it. By dividing the tasks needed to port these drivers/features the amount of effort needed will be limited. As said, I assume that there are several people frequenting this (part of this) site who should be capable of partaking in this effort.

YetAnotherForumUser said:
The differences between 2.6.32 and 3.0.X (the first target) are not that big
Click to expand...
Click to collapse
I second that. There's a huge misconception that 3.0.x a major change. But it wasn't. They just bumped up the version number.
Sent from my MB526 using xda premium

simmilar drivers in this repository
https://github.com/redyk/omap3630-3.0.8
Lg Optimus Black(sniper) 3.0.8 sources..
I found smmilar drivers but i don't know these drivers same them

quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.

junesoung said:
https://github.com/redyk/omap3630-3.0.8
Lg Optimus Black(sniper) 3.0.8 sources..
I found smmilar drivers but i don't know these drivers same them
Click to expand...
Click to collapse
LG Optimus Black 'sniper' kernel, 3.0.57:
https://github.com/TheMeier/lge-kernel-sniper-linux-stable
Has source for the following drivers, probably more - I just cloned the repository.
AKM8973 Magnetometer
KXTF9 Accelerometer
WL127X_RFKILL

m11kkaa said:
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
Click to expand...
Click to collapse
don't see a problem if someone wants to make a separate attempt. i think community effort has better chance in getting latest kernel up and running.

YetAnotherForumUser said:
LG Optimus Black 'sniper' kernel, 3.0.57:
https://github.com/TheMeier/lge-kernel-sniper-linux-stable
Has source for the following drivers, probably more - I just cloned the repository.
AKM8973 Magnetometer
KXTF9 Accelerometer
WL127X_RFKILL
Click to expand...
Click to collapse
Sounds good
GalaxySL use same cpu(omap3630)
It has 3.0 kernel too
You can find more drivers
Sent from my MB525 using xda app-developers app

Which is the base you intend to use as a starting point, test / compile against?
https://github.com/Quarx2k/jordan-kernel/tree/3.0.8-defy_display
This one?

May be this would help http://forum.xda-developers.com/showthread.php?p=33801839
http://forum.xda-developers.com/showthread.php?p=33710566
Sent from my MB526 using xda app-developers app

Comparison between Defy and LG Optimus Black kernel configuration
m11kkaa said:
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
Click to expand...
Click to collapse
The display subsystem in the LG Optimus Black seems to resemble that in the Defy(+), so for that purpose those sources can be useful.
For comparison purposes I attached a side-by-side diff of the default Defy(+) kernel .config and that for the LG Optimus Black.

domokos said:
Which is the base you intend to use as a starting point, test / compile against?
https://github.com/Quarx2k/jordan-kernel/tree/3.0.8-defy_display
This one?
Click to expand...
Click to collapse
That is the base I used to find missing drivers/features. For porting purposes it does not matter that much which base is used, as long as it is as close to baseline as possible. The linux-omap tree would be a good starting point as that is a) synchronized with baseline and b) where work on OMAP-related stuff takes place. As the purpose of the port is to get Android to run, the most recent Android-specific branch would be a good target. Of course there is much to say for taking the path of least resistance so if one of those other trees around here (Quarx 3.0.8-defy_display, LG, Samsung, a mashup of all three, etc) can get us where we want to be in less time that would be an option as well.

http://forum.xda-developers.com/showthread.php?t=1546102
maybe this will be helpfull?!

YetAnotherForumUser said:
Even though JB is more or less feature-complete on Defy(+) there are still a few nits which will be hard to squash without having access to features which are only available in later kernels (eg. the ION memory allocator). Given that this board is frequented by people who (theoretically at least) should be able to give a hand in porting the required drivers/features to get a 3.X kernel up and running on Defy(+) I started making an overview of those missing bits. It should only take a relatively small group of willing volunteers, each responsible for a driver or feature, to get those bits ported.
From a quick glance at the configuration options used with the currently used 2nd-boot kernel I come to the following list of drivers/features which will need to be ported to 3.X. Some of these might already be available under different names in the kernel. Others might have been ported but are simply not part of the kernel tree I used to make this comparison (Quarx2k/jordan-kernel; branch 3.0.8-defy_display). Yet others might not be needed in the newer kernel because their functions are taken over by other drivers/features.
This is not a complete list of features needed to get a kernel running on the Defy(+) (see mapphone_defconfig in branch 2.6.32 for what is needed).
In the following list I marked potential replacements in bold type, usually followed by a question mark (?) to indicate I'm not sure they are fully compatible replacements for the 2.6.X drivers/features. The drivers/features are listed in 2.6.X menuconfig order using Kconfig names and symbols.
Drivers needed for Jordan w/kernel 3.x
Top level
Support for open firmware device tree (ARM port)
ARM_OF -> USE_OF ?
Support for device tree in /proc
PROC_DEVICETREE
DSP Bridge driver
MPU_BRIDGE
System Type
Motorola Android Platform Phone
MACH_MAPPHONE -> MACH_OMAP_MAPPHONE ? complete?
Motorola Android Platform phone 2nd-boot kernel modifications
MAPPHONE_2NDBOOT
Export DIE ID code under /proc/socinfo
OMAP3_EXPORT_DIE_ID
Device Drivers/Misc devices
AKM8973 Magnetometer
SENSORS_AKM8973_AKMD
KXTF9 Accelerometer
SENSORS_KXTF9
Bluetooth power control driver for TI wl127x
WL127X_RFKILL
Motorola OMAP Device Type Driver
OMAP_DEV_TYPE_DRV
Motorola Modem PM Driver
MODEM_PM_DRIVER
Motorola netmux driver
NETMUX_DRIVER
Motorola netmux link driver
NETMUX_LINKDRIVER
Motorola Camera Driver
CAMERA_MISC
Device Drivers/Multimedia support/Video capture adapters
HP OMAP3 Imaging/3A driver
VIDEO_OMAP3_HP3A
Video out driver
VIDEO_OMAP_VIDEOOUT -> VIDEO_OMAP2_VOUT ?
Device Drivers/Sound card support/Open Sound System (DEPRECATED)
Audio driver for OMAP3430 with CPCAP
SOUND_CPCAP_OMAP -> SND_OMAP_SOC ( = ALSA)
Device Drivers/USB support
CPCAP USB Transceiver Driver
CPCAP_USB
Device Drivers/USB support/USB Gadget Support
USB Gadget Drivers (MOTO Android Gadget)
USB_MOT_ANDROID
Device Drivers/Real Time Clock
CPCAP RTC
RTC_DRV_CPCAP
So... anyone here who is willing and able to take on one of these drivers/features? Within a reasonable time frame (weeks, not months)? Anyone who knows of existing ports for these missing bits?
Why wait for Quarx or any of the other already overworked developers to do all the work? Just join hands, sing Kumbayah and get porting - but post here which driver/feature you want to work on to avoid needless duplication of effort.
I'll wait a few days for others to take the fun projects, then I'll start on those which are left.
Click to expand...
Click to collapse
Maybe this link can be useful: http://blackscratches.blogspot.ro/2012/04/how-to-build-android-kernel-308-for-ti.html it seems very explicit about porting kernel 3.0.8 on omap 3630 including drivers

Fight4Music said:
http://forum.xda-developers.com/showthread.php?t=1546102
maybe this will be helpfull?!
Click to expand...
Click to collapse
It might. For more stuff like that have a look at the Linux OMAP Kernel Project where you'll find more about the various OMAP-related development efforts. The above link points to one of the many branches of this tree:
http://git.omapzoom.org/?p=kernel/omap.git;a=summary
In the p-android-omap-3.4 branch there is a camera driver for the "Aptina MT9P031 Camera". The Defy+ (and Defy/Bayer) contain a camera based on the MT9P012. It stands to reason that there is a family relationship between all these mt9xyyy sensor drivers.

Working 3.0 kernel for Samsung Galaxy SL
The Samsung Galaxy SL shares quite a bit of hardware with the Defy(+). There now is a working (if not feature-complete) 3.0 kernel for this device.
https://github.com/dhiru1602/android_kernel_samsung_latona
Attached to this message is a side-by-side diff between the Defy default config and that for the latona (S G SL) as well as a side-by-side diff between the Optimus Black default config and that for the latona.

http://forum.xda-developers.com/showthread.php?t=1546102
Sent from my MB525 using xda app-developers app

junesoung said:
http://forum.xda-developers.com/showthread.php?t=1546102
Sent from my MB525 using xda app-developers app
Click to expand...
Click to collapse
See #14...

YetAnotherForumUser said:
See #14...
Click to expand...
Click to collapse
Oh, sorry;
Sent from my MB525 using xda app-developers app

[ROM][UNOFFICIAL][7.1.2] LineageOS 14.1 for Elephone Trunk

This is a genuine 64bit LineageOS 14.1 ROM for the Elephone Trunk. It's the follow up to my previous CM13.1 ROM as discussed here:
https://forum.xda-developers.com/android/development/rom-cyanogenmod-13-0-elephone-trunk-t3394060
It can be used as a daily driver, all important features seem to be working, including:
Voice
Mobile Data
Audio
Bluetooth
Camera
WiFi
GPS
Please feel free to post any bug reports here.
XDA:DevDB Information
LineageOS 14.1 for Elephone Trunk, ROM for all devices (see above for details)
Contributors
ottmi
Source Code: https://github.com/ottmi/android_device_elephone_trunk
ROM OS Version: 7.x Nougat
ROM Kernel: Linux 3.10.x
Based On: LineageOS
Version Information
Status: Snapshot
Current Stable Version: 20180114
Stable Release Date: 2018-01-14
Created 2017-02-10
Last Updated 2018-01-14

Changelog
20180114
Upstream LineageOS changes, including December 2017 security patches
Fix camera recordings
20170811
Upstream LineageOS changes, including August 2017 security patches
Remove libwvm and use Crackling Widevine blobs instead
20170430
Upstream LineageOS changes
20170419
Update to latest LineageOS Upstream, including Android 7.1.2 merge & April Security Patches
Enable F2FS
Get rid of annoying selinux denials for setsched
Enable Pinner Service to pin key files in memory
20170409
Return to Crackling camera blobs to fix issues re-enable higher camera resolution
Disable backlight dimming in thermal-engine
Fix random reboots due to qcom subsystem crashes
20170314
Replace netmgrd by proper binary from ASUS Z00T
Pull camera blobs (mostly) from Google Seed
20170224
Fix crashes of the WCNSS subsystem
20170221
Fix GPS
20170220
Fix torchlight tile
Fix netmgrd crashes that caused mobile data to stop working
Remove ZRAM, LZ4, and Swap
Remove F2FS support
Replace Camera with Snap
Replace Browser with Gello
20170210
First beta

ottmi said:
20170210
First beta
Click to expand...
Click to collapse
@ottmi
Thanks for your work we were expecting. Installed the new rom L_OS 14.1 without difficulty using "TWRP-3.0.2-20161108-trunk.img" + open_gapps-arm64-7.1-pico-20170210.zip + SuperSU-v2.79-201612051815.zip. so far also works updating of installed apps after a thorough tour will let you know any bugs.
Thanks again and good work.

This afternoon I installed the new ROM.
@ottmi first thank you, a job well done. the first impression is really good, I believe that from this foundation will do a wonderful job.
bug:
- The flashlight does not work.
- Some animations are jerky.
Considerations:
The general flow is good, Wi-Fi reception OK
GPS OK
Camera improvements, noisy photos. The 8 megapixel resolution is not selectable.
Battery: I do not know, it takes time to understand.

Awesome first release! Was this a lot of work to get to this stage, @ottmi?
Looking forward to the next build with currently reported bugs addressed, which is when I'll jump into the testing.
Martin

@ottmi
after using for a couple of days the first version of the Rom L_OS 14.1 I consider still to be improved especially the battery life, the management of the status bar and especially the lack of advanced configurations. All this by referring to the Rom "RR-N-v5.8.0-20170115-peach" I have used for nearly a month without any problems and with several customization options although 32Bit. It would be interesting on your part to verify the basis of http://www.resurrectionremix.com/ development for our Trunk 64Bit. Thanks anyway for the wonderful work you are doing.
I'm sorry for my english.

Guys, you have to be more specific than that if you want me to fix problems: @Sampierdarena:
Which animations are jerky? Is this still the case after the 2nd reboot?
Was the 8MP selection available with CM13.1? I think this is a feature of the camera apk..
@josoft86:
What's wrong with the status bar?
Which advanced configuration options are you missing?
I know about the flashlight, this has been a problem already in CM13.1 and I never found a way to fix it properly.
Also there seem to be some issues with the 2nd SIM slot. I sometimes don't get a data connection with the 2nd SIM - the status shows LTE or HSDPA and connected but I don't get an IP address. This doesn't seem to be a problem with the 1st SIM card. Did anybody else witness this problem?

@ottmi
I try to be more precise:
The animations are jerky affect the output from applications. I partially solved with the trim.
The camera: using CameraFV5 you can choose 8 megapixels, I think you're right, the problem is the camera application stock.
The battery with this release has a shorter duration than 10%, I think it is normal with Android 7.1
Thanks again for your work.

@ottmi
perhaps you interpreted my little appropriate proposals, but I did not remotely affect your work but address it on what I thought was perhaps valid for your own product development. I enclose the examples on the configuration and status bar that I used with the Rom RR. Thanks for your work always appreciated and I hope that more and more continuous.

Guys, I'm about to donate my dead elephone trunk if anyone needs it.
it was in great condition but one day it just won't turn on anymore.
it showing charging process once connected to charger, but doesn't react on power button.
case and some other accessories such as spare new back cover can also be donated .
And thanks Ottmi and all other guys for this great rom that extending life of this device!

@ottmi
I do not know if you might be interested in helping you develop your wonderful work for our Trunk:
Reference: https://plus.google.com/communities/109352646351468373340
"Resurrection Remix (official)
ROM Release │ DEVS ONLY-DO NOT POST HERE
İmportant announcement & some good news
So a few days back we came to an important decision , and we went ahead and decided to merge Full OMS Support.
Yes many users will be happy , some will be upset but honestly it has been too long waiting for Lineage Theme Engine .
Anyhow the manifests will be updated soon and maintainers can push oms builds as official .
Thank you for being patient with us.
Now You can enjoy full OMS supported themes and themers can now officially support our ROM .
PS: users please wait for your maintainers to upload your builds
NO ETA.
If coming from a 5.8.0 build , please clean flash .You will run into issues with dirty flashes and help will not be provided in that scenario
Read before posting
https://plus.google.com/101154841950858558748/posts/RAuHneppoKa
Thank you for understanding
Happy flashing..
Sincerely
RR Team"

Sampierdarena said:
@ottmi
I try to be more precise:
The animations are jerky affect the output from applications. I partially solved with the trim.
The camera: using CameraFV5 you can choose 8 megapixels, I think you're right, the problem is the camera application stock.
The battery with this release has a shorter duration than 10%, I think it is normal with Android 7.1
Click to expand...
Click to collapse
Can you name an application that shows the video problems?
Regarding the camera: the next ROM will ship with the new Snap app as stock camera that allows for setting the resolution to 7.7MP. I'm not sure thought whether that is native or will be interpolated from 13MP..
I can't really comment on battery life as I'm currently using the phone more intensive than usual and connect it to the computer very often, so the battery will recharge quite often..
@ josoft86:
Since the Ark RR ROM seems to be working fine for you, why don't you just this? I personally have no interest in porting another ROM. I don't even use half the features LineageOS offers on top of stock Android. My focus is on creating a stable ROM and being able to regularly pull upstream security fixes. That being said, all my work is published on my Github account, so anybody who's interested can pick it up and use it as a stepping stone for any other ROM.

New ROM 20170220
There's a new ROM available in the download section. Main improvements are fixing of the disappearing torchlight tile (thanks to the good people working on the Redmi2) and fixing of non-operational mobile data after disconnecting from WiFi. Also, I removed support for ZRAM, LZ4, swap, and F2FS. I don't think we need this (other msm8916 devices are living without it) and removing this brings the kernel closer to the stock kernel and hence improve long-term maintainability. I'm using this now as a daily driver and from my point of view it's quite stable.
EDIT: I messed up the GPS blobs in yesterday's release. There's a new ROM now in the download section that should have workiong GPS. Sorry for the inconvenience..
For those who are interested in details and for documentation purposes: on some msm8916 devices on Android 7, mobile data stops working after disconnecting from WiFi. There a few bug reports on LineageOS's jira on this:
https://jira.lineageos.org/projects/BUGBASH/issues/BUGBASH-72
https://jira.lineageos.org/browse/BUGBASH-129
It seems that netmgrd occasionally crashes and leaves the RIL in an undefined state that doesn't allow for new mobile data connections to be established. The crashes are due to netmgrd freeing non-allocated memory (which jemalloc intercepts and causes the process to abort). As netmgrd is a proprietary Qualcom binary, there is no way to fix this in source. I've tried to use the netmgrd binary from other devices but that didn't help. So I ended up patching the binary and replacing the respective calls to the free function by NOPs. Obviously, this introduced a memory leak and we will have to watch this carefully over time. But at least for now this seems to fix the problem and the memory leak seems to be small.

ottmi said:
It seems that netmgrd occasionally crashes and leaves the RIL in an undefined state that doesn't allow for new mobile data connections to be established. The crashes are due to netmgrd freeing non-allocated memory (which jemalloc intercepts and causes the process to abort). As netmgrd is a proprietary Qualcom binary, there is no way to fix this in source. I've tried to use the netmgrd binary from other devices but that didn't help. So I ended up patching the binary and replacing the respective calls to the free function by NOPs. Obviously, this introduced a memory leak and we will have to watch this carefully over time. But at least for now this seems to fix the problem and the memory leak seems to be small.
Click to expand...
Click to collapse
Maybe it's a silly question, but where is that netmgrd binary from? Would it be possible to use the netmgrd binary from the 32 bits version of Nougat for the google seed?
Meanwhile, my attempts with [email protected] are failing: wifi and ril cannot even start. I will try some change looking at your tree
Sorry for not having tried your rom yet, but I am spoiled with your great CM13

siljaer said:
Maybe it's a silly question, but where is that netmgrd binary from? Would it be possible to use the netmgrd binary from the 32 bits version of Nougat for the google seed?
Click to expand...
Click to collapse
It's the 64bit binary from Crackling. I thought about trying the 32bit netmgrd from Seed, but it has quite a few dependencies in terms of libraries. I would probably have to replace the libraries as well which would mean that the version numbers of the 32bit and 64bit libraries would be different. I'm not sure whether that would contribute towards a more stable ROM
Anyway, the patched version seems to work fine for now. I didn't notice any growth in memory consumption of the netmgrd process, so the leakage is probably small..

New ROM 20170224
There was a problem in the previous ROM with occassional WCNSS subsystem (WiFi) crashes which also caused the BlueTooth stack to crash. Should be fixed now in the new build.

Hi ottmi,
gorgeous work! I just got this device, therefore i did not do excessive testing yet. In comparison to cm-13.0-20160902, the 14.1-20170221 seems to work better (e.g. camera is not crashing). I do have only one question: At least on my device, root can be only set to 'ADB' or 'disabled'. Is this a restriction of LineageOS?
Best Regards,
Jan

jan_100 said:
Hi ottmi,
gorgeous work! I just got this device, therefore i did not do excessive testing yet. In comparison to cm-13.0-20160902, the 14.1-20170221 seems to work better (e.g. camera is not crashing). I do have only one question: At least on my device, root can be only set to 'ADB' or 'disabled'. Is this a restriction of LineageOS?
Best Regards,
Jan
Click to expand...
Click to collapse
LineageOS requires rooting. It can be done in several ways, I chose to use the addon provided by them in the "extras" download section on the LineageOS website.
---------- Post added at 10:56 ---------- Previous post was at 10:50 ----------
ottmi said:
It's the 64bit binary from Crackling. I thought about trying the 32bit netmgrd from Seed, but it has quite a few dependencies in terms of libraries. I would probably have to replace the libraries as well which would mean that the version numbers of the 32bit and 64bit libraries would be different. I'm not sure whether that would contribute towards a more stable ROM
Anyway, the patched version seems to work fine for now. I didn't notice any growth in memory consumption of the netmgrd process, so the leakage is probably small..
Click to expand...
Click to collapse
I've read that Lenovo is planning to officially release Nougat for msm8916 G4... I hope they can provide updated BSP too...
Meanwhile, I switched to your new ROM. It's been a short time, but it looks even better than CM13
Thanks for your great work!

@siljaer
Thank you very much! I was not aware of that.

karabassssss said:
Guys, I'm about to donate my dead elephone trunk if anyone needs it.
it was in great condition but one day it just won't turn on anymore.
it showing charging process once connected to charger, but doesn't react on power button.
case and some other accessories such as spare new back cover can also be donated .
And thanks Ottmi and all other guys for this great rom that extending life of this device!
Click to expand...
Click to collapse
Hi karabassssss, I will appreciate so much if you could donate me your Trunk.
I need a new case and, more, I've broken it and the camera glass too but I don't reach to contact any assistance to do this work.
I live in Italy, close to Florence and logically I will pay for the shipping of the package. Please let me know, thanks
PS Many many thanks to @ottmi for your previous CM13 rom, in a couple days I will flash your new one too