I thought we could use an organized thread for focusing on getting the camera to work on 4.2-based ROMs for the Galaxy Player 5. Right now, there are three iterations of CM10.1 threads, and discussion is also going on in other ROM threads. I'm basically putting this here so we can all talk about it in one place and not have to dig every time we need to find a piece of information that was previously mentioned.
I'll update the OP as more information surfaces.
Things that we already know
http://forum.xda-developers.com/attachment.php?attachmentid=1988153&d=1369421491 this fixes camcorder for the rear camera. Source
Speculation
The image sizes could be off because our CM10.1 was ported from the other Galaxy S devices. Source
The Galaxy Stellar also uses a 3.2MP camera and has native 4.0.4. This could possibly be of use.
Other things that could be potentially useful
https://sites.google.com/site/jaiprakashgogi/professional this is the website for the person who develops the driver for the s5K5CCGX sensor. We could try contacting him to see if he could help us out.
The developer profile says that he developed for Qualcomm Snapdragon powered devices so the drivers are likely to be incompatible with our Exynos SoC. However, if our front facing camera is 1.3 MP, I think we might be able to use the drivers from the Galaxy Tab
Supermaster34 said:
The developer profile says that he developed for Qualcomm Snapdragon powered devices so the drivers are likely to be incompatible with our Exynos SoC. However, if our front facing camera is 1.3 MP, I think we might be able to use the drivers from the Galaxy Tab
Click to expand...
Click to collapse
Nope, our Front-Facing is a measly 0.3MP VGA cam like the other Galaxy S phones.
halomademeapc said:
Nope, our Front-Facing is a measly 0.3MP VGA cam like the other Galaxy S phones.
Click to expand...
Click to collapse
Well that put a spanner in my plan. I guess the next step from here is to work out why the FFC saves pictures but the RFC doesn't. There must be a difference in the method they use to store the image, but we need to locate where the code specifies the method of saving the image
Supermaster34 said:
Well that put a spanner in my plan. I guess the next step from here is to work out why the FFC saves pictures but the RFC doesn't. There must be a difference in the method they use to store the image, but we need to locate where the code specifies the method of saving the image
Click to expand...
Click to collapse
In cm10 the saving of grey images was fixed by changing the postview sizes in the header[1]. There are also other random places values are hardcoded into the HAL[2]. One interesting thing is that we are using the HAL's from two different sources in jellybean, so they have different problems: crespo on cm10 and p5 on cm10.1 (EDIT: I see JackpotClavin switched to crespo... This is all very confusing), so possibly compare/combine the two to find what is causing each problem.
For video recording (media_profiles.xml) we need to figure out what the actual numbers are for our device, and not just take them from somewhere else. Plus, they have to align with the HAL. The same applies to OpenMAX codec libraries. Last, don't forget that at some point we will need to get the torch working, too.
EDIT: I saw the discussion on the other thread and decided to move it here
Supermaster34 said:
I don't think changing the resolution will fix it. I just tried taking a photo with the resolution set to 1.3 MP, but it didn't work. I think the issue is when the image is being saved as the width and height both come up as 0 and even when the flash is forced on, the image details say no flash. If we look at how the front facing camera saves the image, we could compare it with how the rear facing camera is set to save the image and modify it to match. I'm not entirely sure that this would work, but it might be worth a try
Click to expand...
Click to collapse
Does any EXIF data save? I don't think it does, so that's another item on our todo list (and saving GPS information in the pictures). Our FFC is the 3DFX, which is the exact same as crespo, so it should work perfectly with no modifications. Therefore, any issues are caused by something else, like media_profiles.xml. This is what happens when I talk without checking... I tried the FFC, and everything works perfectly AFAIK: EXIF and location data save (although it was using network location, it should work exactly the same with GPS). So no worries or breakage there.
android1234567 said:
Yeah I just looked at the resolutions and some of them are the same as before. I also noticed that some ISOs that aren't supported by our sensor were added in, so I put my hand in front of the camera to lower the ISO and lo and behold it actually took a picture and made the capture sound instead of hang on taking the picture like it usually does. But after that it just hung and didn't save the picture, so you're right that the camera isn't saving the image correctly.
Click to expand...
Click to collapse
Do we have a definitive list of which ISO's our camera does support? I would assume the only way to know is from a different camera HAL, but the only other device with the S5K5CCGX uses blobs. I guess we could look in the stock app, or use trial and error if there was no other list.
Supermaster34 said:
At least we're making some progress. I think we have the same camera hardware as the Galaxy Tab and I believe it has CM10.1 so it might be worth having a look at their source or just trying to use their drivers as I think they also have the Exynos 3 single SoC
Click to expand...
Click to collapse
zaclimon said:
Depends which gtab you're talking about. The Gtab P1 (original) uses the sony isx005 which we have. I think the galaxy tab 10.1 do have your sensor, it would need to be checked further.
Your back cam is s5k5ccgx
Your front cam is s5ka3dfx
Hope it helps.
EDIT: the galaxy tab 10.1 do use the same sensor as you, you can check there: https://github.com/CyanogenMod/android_kernel_samsung_p4/blob/cm-10.1/arch/arm/configs/pershoot_samsung_p4-jb_defconfig#L1939
EDIT2: Hmm the galaxy tab 10.1 do use tegra chipset so maybe it's not a good choice, but you can look into the p1 drivers and take a look of their s5k5ccgx drivers here: https://github.com/CyanogenMod/android_kernel_samsung_p1/blob/cm-10.1/drivers/media/video/s5k5ccgx.c
Click to expand...
Click to collapse
Yes, they use Tegra blobs. They look self-contained, so I was thinking they might be possibly portable; say, take their blobs and their kernel driver and see if those together work on our camera. What's interesting in looking at all of the different kernel drivers is the different firmwares for different devices, and how some say different megapixel ratings than others, almost as if there were different cameras with the same model, or someone at Samsung was doing a lot of copypasting.
android1234567 said:
Think I found a solution: https://github.com/humberos/android...mmit/5bab5c8c8797f96855b777e6c2328d341187014e
Click to expand...
Click to collapse
Supermaster34 said:
This is the code across a few devices:
Nexus S + 5.0 atm - 4.2
Code:
int SecCamera::interleaveDataSize = 5242880;
GTab - 4.2
Code:
int SecCamera::interleaveDataSize = 0x33F000;
Galaxy S - GB I think
Code:
int SecCamera::interleaveDataSize = 4261248;
I have no idea what these numbers mean, but could 0x33F000 be some sort of memory address location?
Also why is there an 8 thanks per day limit?!
Click to expand...
Click to collapse
Well, 0x33F000 is 3403776 in decimal (for comparison). It is the size of a memory buffer, and its value has to do with a few things: Image resolution, image format (i.e. extra space for metadata or less space because of hardware JPEG compression), and pixel format (i.e. bits per pixel, like YUV, RGB888, RGB565, etc.). So at 2048 by 1536 pixels, that 3MP is exactly 3145728 pixels; I don't see where that number comes from.
android1234567 said:
It'll work! On the Galaxy Tab the number was previously 4261248 then it was changed to 0x33F000! The number is universal across devices as long as they have the same camera Nexus S has a different camera so the number is different.
Click to expand...
Click to collapse
It should be linear relative to image size, but it doesn't seem to be, which is confusing.
android1234567 said:
I'll do that now . I have all the CM10.1 source and device tree on my laptop because I need it to build kernels. I'll also clean up some ISOs and resolutions while I'm at it. If it works then we can merge the video changes that got the camcorder working and have fully functional CM10.1
Click to expand...
Click to collapse
A tip to save lots of disk space and time by building only what you need:
Code:
mmm -B device/samsung/venturi_usa/libcamera
android1234567 said:
I'm going to combine the Galaxy Tab HAL with the current HAL we're using, retaining the FFC code we have right now.
Sent from my HTC Sensation 4G using xda app-developers app
Click to expand...
Click to collapse
Sounds like a good idea. I will see where I can get starting on Tuesday or so.
android1234567 said:
I'm trying to build with my camera changes but I get this error after a little while:
Code:
No rule to make target `/home/sultan/cm10.1/out/target/product/venturi_usa/obj/SHARED_LIBRARIES/libs3cjpeg_intermediates/export_includes'
Anyone know how to fix it?
Click to expand...
Click to collapse
You need the hardware/samsung repo:
Code:
<project name="CyanogenMod/android_hardware_samsung" path="hardware/samsung" remote="github" />
If you already have it, try running
Code:
mmm hardware/samsung/exynos3/s5pc110/libs3cjpeg
P.S. We can't keep the discussion in one place if we aren't keeping it in one place...
[1] https://github.com/Mevordel/android...mmit/1cad68704bcd856638357e0b18118b46c8f198ba
[2] https://github.com/Mevordel/android...mmit/e6f4507fac8768d9a62c54ee375cdfd584aad889
Mevordel said:
In cm10 the saving of grey images was fixed by changing the postview sizes in the header. One interesting thing is that we are using the HAL's from two different sources in jellybean, so they have different problems: crespo on cm10 and p5 on cm10.1, so possibly compare/combine the two to find what is causing each problem.
For video recording (media_profiles.xml) we need to figure out what the actual numbers are for our device, and not just take them from somewhere else. The same applies to OpenMAX codec libraries.
Click to expand...
Click to collapse
A fix has already been found for video recording in CM10.1 and it changes the media profiles file, so we don't have to worry about that
We already have our fix for the camera without even touching the libcamera (for the 3.0 kernel). Here's the commit if ever you want to check it:
https://github.com/bbelos/android_kernel_samsung_aries/commit/ab11000777e4363460ccaebe3221a721252c4f56
@Mevordel
Not going to quote your entire post because that would be ridiculous, but thanks x1000 especially for those 2 commits
it's very reassuring knowing that we have another person helping who has done this before
zaclimon said:
We already have our fix for the camera without even touching the libcamera (for the 3.0 kernel). Here's the commit if ever you want to check it:
https://github.com/bbelos/android_kernel_samsung_aries/commit/ab11000777e4363460ccaebe3221a721252c4f56
Click to expand...
Click to collapse
This pretty much completely confuses me... Is CONFIG_SAMSUNG_GALAXYS defined for your device? A lot of what was added looks to be support for the P1. Is that because you took some of the code from the P1?
android1234567 said:
@Mevordel
Not going to quote your entire post because that would be ridiculous, but thanks x1000 especially for those 2 commits
it's very reassuring knowing that we have another person helping who has done this before
Click to expand...
Click to collapse
Thank you. I still have no idea what much of this does, but I will spend some time this month looking into it.
Final post for the day:
I decided to look into the kernel-side driver for some explanation for a few of these magic numbers, and here's what I found staring us in the face this whole time (drivers/media/video/s5k5ccgx.c):
Code:
/* Default resolution & pixelformat. plz ref s5k5ccgx_platform.h */
#define FORMAT_FLAGS_COMPRESSED 0x3
#define SENSOR_JPEG_SNAPSHOT_MEMSIZE 0x33F000 //3403776 //2216 * 1536 384000 33F000
#define POLL_TIME_MS 10
#define DEFAULT_RES WVGA /* Index of resoultion */
#define DEFAUT_FPS_INDEX S5K5CCGX_15FPS
#define DEFUALT_MCLK 24000000 /* 24MHz default */
#define DEFAULT_FMT V4L2_PIX_FMT_UYVY /* YUV422 */
#define INNER_WINDOW_WIDTH 143
#define INNER_WINDOW_HEIGHT 143
#define OUTER_WINDOW_WIDTH 320
#define OUTER_WINDOW_HEIGHT 266
/*
* Specification
* Parallel : ITU-R. 656/601 YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Serial : MIPI CSI2 (single lane) YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Resolution : 1280 (H) x 1024 (V)
* Image control : Brightness, Contrast, Saturation, Sharpness, Glamour
* Effect : Mono, Negative, Sepia, Aqua, Sketch
* FPS : 15fps [user=366900]@full[/user] resolution, 30fps [user=355664]@vga[/user], 24fps [user=3621271]@720p[/user]
* Max. pixel clock frequency : 48MHz(upto)
* Internal PLL (6MHz to 27MHz input frequency)
*/
So the 0x33F000 is the correct value, and the postview defines in SecCamera.h (not to mention the rest of the values) need to be updated with those here.
The only problem is that some of the information is wrong. The resolution stated in the comment is 1.3MP, the beginning of the file says 2.0MP, but we know (and the resolution list later in the file confirms) that it is a 3.0MP sensor. Meh.
Mevordel said:
Final post for the day:
I decided to look into the kernel-side driver for some explanation for a few of these magic numbers, and here's what I found staring us in the face this whole time (drivers/media/video/s5k5ccgx.c):
Code:
/* Default resolution & pixelformat. plz ref s5k5ccgx_platform.h */
#define FORMAT_FLAGS_COMPRESSED 0x3
#define SENSOR_JPEG_SNAPSHOT_MEMSIZE 0x33F000 //3403776 //2216 * 1536 384000 33F000
#define POLL_TIME_MS 10
#define DEFAULT_RES WVGA /* Index of resoultion */
#define DEFAUT_FPS_INDEX S5K5CCGX_15FPS
#define DEFUALT_MCLK 24000000 /* 24MHz default */
#define DEFAULT_FMT V4L2_PIX_FMT_UYVY /* YUV422 */
#define INNER_WINDOW_WIDTH 143
#define INNER_WINDOW_HEIGHT 143
#define OUTER_WINDOW_WIDTH 320
#define OUTER_WINDOW_HEIGHT 266
/*
* Specification
* Parallel : ITU-R. 656/601 YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Serial : MIPI CSI2 (single lane) YUV422, RGB565, RGB888 (Up to VGA), RAW10
* Resolution : 1280 (H) x 1024 (V)
* Image control : Brightness, Contrast, Saturation, Sharpness, Glamour
* Effect : Mono, Negative, Sepia, Aqua, Sketch
* FPS : 15fps [user=366900]@full[/user] resolution, 30fps [user=355664]@vga[/user], 24fps [user=3621271]@720p[/user]
* Max. pixel clock frequency : 48MHz(upto)
* Internal PLL (6MHz to 27MHz input frequency)
*/
So the 0x33F000 is the correct value, and the postview defines in SecCamera.h (not to mention the rest of the values) need to be updated with those here.
The only problem is that some of the information is wrong. The resolution stated in the comment is 1.3MP, the beginning of the file says 2.0MP, but we know (and the resolution list later in the file confirms) that it is a 3.0MP sensor. Meh.
Click to expand...
Click to collapse
I'm going to do that now
No progress @Mevordel the camera just force closes with the header changes. I think we might need to mess around with the camera driver in the kernel
Or maybe I need to allocate more memory to the camera
I am hell sure that it is not connected to the memory, as aries an crespo with 5mpx use same memory amount as we have set
Wysyłane z mojego Nexus S za pomocą Tapatalk 2
Mevordel said:
This pretty much completely confuses me... Is CONFIG_SAMSUNG_GALAXYS defined for your device? A lot of what was added looks to be support for the P1. Is that because you took some of the code from the P1?
Click to expand...
Click to collapse
What I did was to take the 3.0 p1 drivers, then modify the ifdef to comply with our devices. (config_samsung_galaxys to replace mach_aries and config_samsung_ypg1 to replace config_mach_p1) with the 2.6 drivers , bbelos had completely copied the p1 which is why we have the camera working on it. We're only doing the same thing but with some ugly manners of implementing it. (it's implementation will be different with the cm10.1 kernel.). This is how we got it working.
Also wouldn't be more easier to take your camera drivers from p1?
Envoyé depuis mon Nexus 7 avec Tapatalk
I had always thought that the issue was with the camera.aries library and not the kernel. I flashed back to my old CM9 build from a year or so ago (with the 2.6.35.7 kernel, that worked with Gingerbread and its camera) and used our camera library for 4.2.2 and I got the exact same errors with the rear camera, but the front worked fine as it did with 4.2.2
Sent from my Galaxy Nexus using xda app-developers app
JackpotClavin said:
I had always thought that the issue was with the camera.aries library and not the kernel. I flashed back to my old CM9 build from a year or so ago (with the 2.6.35.7 kernel, that worked with Gingerbread and its camera) and used our camera library for 4.2.2 and I got the exact same errors with the rear camera, but the front worked fine as it did with 4.2.2
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
Hmm to get mostly your camera working, you need the camera HAL drivers to fit with the FIMC kernel drivers. So if you want to use the P1 camera HAL, you will need to update your fimc drivers in order to get it working. In your case you would only need to add ifdef CONFIG_MACH_VENTURI.
We can take pictures with Fast Burst Camera (but the quality is poor)...
flouflou said:
We can take pictures with Fast Burst Camera (but the quality is poor)...
Click to expand...
Click to collapse
Fastburst just takes a screenshot; it doesn't take actual photos
android1234567 said:
Fastburst just takes a screenshot; it doesn't take actual photos
Click to expand...
Click to collapse
I know but it's still practice...
It seems that it might be worthwhile to take a look at the code that produces the preview images... I mean that technically is our device producing images from the BFC right?
Sent from my SAMSUNG-SGH-I577 using xda app-developers app
TEST Firmware: A510FXXU3.....
Only tested on models A510F
Description:
Improved jpeg quality from 96 to 100
Reduced the flash-off threshold when the battery is low, up to 3%
Removed unnecessary localizations ( remained russian and eng )
Unlocked experimental items in the camera settings
* Correction of the form.
* Snapshot of motion.
* Focus mode.
* Methods of shooting
* Timer
* Stabilization of video.
* Full screen mode (16: 9).
* Shutter sound.
* Select a grid (3 * 3 / square)
* Identify QR codes.
* The function of the volume keys (change the point of the scale to the system volume)
For my english sorry......
Thanks Dev! Nice work
---------- Post added at 12:37 AM ---------- Previous post was at 12:18 AM ----------
It would be great to record video in 60fps...?
hello
wowanbelousov said:
TEST Firmware: A510FXXU3.....
Only tested on models A510F
Description:
Improved jpeg quality from 96 to 100
Reduced the flash-off threshold when the battery is low, up to 3%
Removed unnecessary localizations ( remained russian and eng )
Unlocked experimental items in the camera settings
* Correction of the form.
* Snapshot of motion.
* Focus mode.
* Methods of shooting
* Timer
* Stabilization of video.
* Full screen mode (16: 9).
* Shutter sound.
* Select a grid (3 * 3 / square)
* Identify QR codes.
* The function of the volume keys (change the point of the scale to the system volume)
For my english sorry......
Click to expand...
Click to collapse
Can the A710 be used?
IT force closed ! I restore Stock camera
Sent from my SM-A510F using Tapatalk
explorer1234 said:
IT force closed ! I restore Stock camera
Sent from my SM-A510F using Tapatalk
Click to expand...
Click to collapse
Because you do not have DEODEX firware
This is one of the most important requirements for installing similar and generally mod
Does pro mode have manual autofocus? Or it is the same?
Do a new update?dev?
works with n900 and darkwolf_fw rom ? thanks
Introduction:
Hello everyone!
This Module is created with the goal of improving both the battery life and performance of our Mi 8 devices.
Disclaimer:
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
Features:
*Reduced battery consumption
*Device-specific enhancements for the best possible balance between battery life & performance
*CPUSet improvements & optimizations
*I/O tuning for battery and performance
*Configured dynamic stune boost
*Decrease memory latency
*Better partition performance
*Network tweaks for slightly reduced battery consumption when being "actively" connected to a network connection
*Enable bus-dcvs
*Enable Power Efficient Work Queues
Prerequisites:
*Must have Magisk installed.
*Must have either Sphinx or extreme kernel installed.
*Must have Busybox installed.
Download:
https://www.androidfilehost.com/?fid=11410963190603858584
I have dedicated countless hours developing this module so if you like my work consider buying me a coffee to help me stay awake an keep improving it Click for coffee
Will it be compatible with Poco's stock Pie kernel?
If not, could you implement it?
why this mod is here if it's for mi 8 devices? or poco and mi 8 are basically the same? just asking...
Working like a charm on my Poco. Good work man.
Sent from my Poco F1 using Tapatalk
afarnedi said:
why this mod is here if it's for mi 8 devices? or poco and mi 8 are basically the same? just asking...
Click to expand...
Click to collapse
It works for both because they're very similar.
Tested on caf with sphinx 1.9 and while i was listening music on Spotify or YouTube with the screen off from nothing the music or YouTube stop, so I disable from magisk the module and issue solved, so I don't know in what part of the tweaks generate this issue
eLaDiio said:
Tested on caf with sphinx 1.9 and while i was listening music on Spotify or YouTube with the screen off from nothing the music or YouTube stop, so I disable from magisk the module and issue solved, so I don't know in what part of the tweaks generate this issue
Click to expand...
Click to collapse
I listen to music all the time on that rom no issue :/
well i enabled again and nothing, no issues, i don't know what could be, anyway i will testing this days to see if again the issue appears
Code:
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
The Lynnrin AOSP Project for Mi 10T Lite / Mi 10i / Redmi Note 9 Pro 5G [gauguin]What is this?
The Lynnrin AOSP Project is a Pixel Experience based ROM, with some customization add that I liked.What's working?Wifi
RIL
Mobile data (5G NSA/SA, LTE+/LTE, 3G, 2G)
GPS
Camera
Flashlight
Bluetooth
Fingerprint
Lights
Sound/vibration
NFC
SafetyNet Passed
DRM L1
SELinux EnforcingKnown IssuesYou tell meHow to Install?https://telegra.ph/Flashing-Instructions-for-ROMs-with-Android-11-Vendor-04-06-2Download LinkOneDriveBig ThanksLineageOS Team
Pixel Experience Team
Havoc-OS Team
Evolution-X Team
exTHmUI Team
Guaiyihu
TH779
And Of Course To All The Supporters, Testers And UsersRedmi Note 9 Pro 5G | Mi 10i | Mi 10T Lite Telegram CommunityUpdates Channelhttps://t.me/Gauguin_Updateshttps://t.me/Mi10i5GOfficialUpdateshttps://t.me/Lynnrin_channelDonatePayPal: https://paypal.me/LynnrinChan
爱发电(For Chinese): https://afdian.net/@Lynnrin
Android OS version: 12.0.0
Security patch level: 2022/01/05
Build author/Device Maintainer: Lynnrin
Kernel Source code: None, prebuilt kernel
Amazing, thanks! I'm running it for 3 days now and it's stable. Battery life is pretty good compared to Pixel Experience.
Really the best . Especially battery. On stand by , over night, phone lose only 2% of battery. And that's amazing!
OMG THIS IS HANDSDOWN THE BEST ROM I'VE TRIED! Is it just me or "OK Google" voice command is not working? Hopefully that gets fixed in the next update but other than that this is perfect!
Also, ideas for future features: I'd like to have the option to customize number of columns and rows in the status bar, be able to adjust brightness with the status bar it self and have a way of turing on flashlight with the screen off as in other roms. But it doesn't matter, I'm staying with this rom! LOVED IT!
wufabul0us said:
OMG THIS IS HANDSDOWN THE BEST ROM I'VE TRIED! Is it just me or "OK Google" voice command is not working? Hopefully that gets fixed in the next update but other than that this is perfect!
Also, ideas for future features: I'd like to have the option to customize number of columns and rows in the status bar, be able to adjust brightness with the status bar it self and have a way of turing on flashlight with the screen off as in other roms. But it doesn't matter, I'm staying with this rom! LOVED IT!
Click to expand...
Click to collapse
NVM about "Hey Google" thing. I just reinstalled google assistant app, restarted my phone and went through the voice match thing by erasing the previous one. It is working now! Amazing ROM!
Found a bug... or something like that. If you turn off the phone or try to restart under 10% battery, system wont load. It will get stucked at the "MI powered by android screen" in a loop. Not a big deal but yeah, just so you knowt that's there.
Still using this rom! Keep up the good work!
Compared to PE, how good is the gaming performance?
Sparkplug3000 said:
Compared to PE, how good is the gaming performance?
Click to expand...
Click to collapse
I don't game too much on the phone so I can't really tell, sorry