Related
INFO:
Let me save you the time of reading all this. In it's current form, this is impossible. An inside connect at Qualcomm has told us we can't change the GPU clock from userland or kernel. That mean's we're screwed basically. Here is the post by Jack_R1:
Checked, as promised. Bad news. If I sum it up in one sentence - GPU overclock w/o touching the rest of the system is plain impossible, and GPU overclock while trying to play with the whole system is most probably still impossible (pending further deeper check), and it's definitely impossible for anyone that doesn't have the clock diagram, which is NDA, thus won't be available. The reason isn't software, and don't ask, what it is - I won't give direct explanations.
I've written a long post with some explanations of clock networks, to educate those that want to learn and prevent some of big mistakes that I've seen along this thread, and it's pending approval, since I don't want to accidentally spill more than I can share. I hope it gets approved and I'll post it. It should give some more insight.
The only good news is - global overclocking that affects 1GHz CPU clock will affect GPU too.
Click to expand...
Click to collapse
I'm sure we all heard about being able to overclock the GPU on some of the old MSM devices, but the Snapdragon handles the graphics chip in a different way. The goal of this thread is to try and overclock the GPU on Snapdragon devices as well.
There is nothing GPU related in acpuclock-scorpion.c at least for setting clock speed as far as I can tell.
In board-mahimahi.c there is some kgsl init code, but so far as I can tell it isn't setting the clock there, instead it seems to be pointing to PWR_RAIL_GRP_CLK to set the clock. It defines the variable in board-mahimahi.c but I'm not sure where that variable is set, since it doesn't seem to be in any of the other board files as far as I can tell. I could be completely off here too though.
In drivers/video/msm/gpu/kgsl/kgsl.c there is a method called kgsl_clk_enable that seems to be called whenever the GPU is enabled. It looks like this:
Code:
/* the hw and clk enable/disable funcs must be either called from softirq or
* with mutex held */
static void kgsl_clk_enable(void)
{
//clk_set_rate(kgsl_driver.ebi1_clk, 128000000);
clk_set_rate(kgsl_driver.ebi1_clk, 245000000);
clk_enable(kgsl_driver.imem_clk);
clk_enable(kgsl_driver.grp_clk);
}
The line that's been commented out is the original value, I replaced it with my value on the line below it in a failed attempt to overclock it. Probably a stupid effort on my part, I doubt it's that simple, but it was worth a shot.
According to the clk.h files in the standard linux kernel, clk_set_rate is obviously a method to set the clock rate. The first variable is a struct that tells it which clock to set, and the second variable is a long value that is the rate you want it set at. Is it setting the right clock there for Snapdragon chips? Or is it only the clock for older chips? Actually I've looked again, the kgsl files are ONLY for the newer Qualcomm chips, the QSD8x50 Snapdragons & the midrange MSM7x27 series that replaced the old MSM7x00a chips like in the Dream & Magic. At least thats the way it seems to me judging from what Qualcomm & AMD have written in the source.
I'm in way over my head with this source, I'm but a lowly Java dev , but I really wanna solve this. Can anyone with a little more experience than me throw in a little more info? Sorry if it doesn't make much sense, if it isn't clear just ask me & I'll try to explain a little more.
Regards,
Jesse C
EDIT: Okay I did a little more digging and those kgsl settings should work for QSD8x50 chips. In the config file, under Drivers, Graphics Support, it allows you to enable 3D accelleration for QSD8x50 & MSM7x27 chips. The tag for that is CONFIG_MSM_KGSL_MMU. If you check in kgsl.c it checks to see if that is enabled in the config, and if it is then it compiles and uses kgsl.c & all of the kgsl code. That tells me that the clock is either not being set, or the wrong clock is being set. I'm adding some debug code right now so I can see in dmesg what code is actually being run.
EDIT 2: Another status update. Adding the debug code showed that it is setting the clock at my level whenever the kgsl initializes. Also, as IntersectRaven pointed out, clocks.h in arch/arm/mach-msm nicely lays out what each clock is:
Code:
grp_clock = Graphics clock
ebi1_clock = External Bus Interface 1 clock
imem_clock = Internal Graphics Memory clock
If you want to add your own debug code to it, calling the method "pr_info" and passing it a string with the message you want will output it to the kernel logs you can view with dmesg. An example would be "pr_info("kgsl: clock set at 245mhz\n");"
EDIT 3: I now know the values for all the GPU related clocks.
Code:
<6>[ 70.681793] kgsl: grp_clock= 256000000
<6>[ 70.682464] kgsl: imem_clock= 256000000
<6>[ 70.683441] kgsl: ebi1_clock= 128000000
If you want to get these values yourself, the following code in the kgsl_clk_enable method will output them to the kernel log:
Code:
int clkg = clk_get_rate(kgsl_driver.grp_clk);
int clki = clk_get_rate(kgsl_driver.imem_clk);
int clke = clk_get_rate(kgsl_driver.ebi1_clk);
// this will get the clock rate & print it in the kernel log
pr_info("kgsl: grp_clock = %d", clkg);
pr_info("kgsl: imem_clock = %d", clki);
pr_info("kgsl: ebi1_clock = %d", clke);
Just add that into the function I mentioned and it will output it to the kernel log, quite often in fact, so I wouldn't leave it in there except to see the values
EDIT 4: 7-2-2010
Qualcomm has now released a new driver. It looks a lot better for our purposes. I'm looking through it today but I have other stuff I need to do. I will look at it, but I can't promise I can devote much time to it until at least Sunday.
EDIT 7-7-2010:
I've collaborate with storm99999 over GTalk and things aren't looking good. Here's what it comes down to:
If we try and lock it with any of the clk_set_rate methods, there is no effect. Not matter how we change it, it just stays at the original value. This either means it's set in the radio (impossible for us to change) or that it's set one time on boot and never changes, but we just don't know where it's actually set (more likely, but I'm not sure either way)
If we try and change it with msm_proc_comm, which is a direct interface to the hardware, it causes the kernel not to boot at all. This is really really strange. We can monitor the clock with pr_info as before, and if we read the data1 argument, it prints to the kernel fine, but if we try and read the data2 arg passed to msm_proc_comm, it also freezes on boot.
We seem to be out of ideas here. We're open to any reasonable suggestions, so if you have any, PLEASE let us know in this thread or PM one of us. Or you can email me at [email protected]
This is a great idea for sure. I will certainly lend a hand where I can.
That being said don't know if it is possible to OC the GPU. I remember discussing this with kmobs in the past and he didn't think so. Perhaps tweaking Open GL might prove more fruitful. All of this is definitely worth thinking about.
jlevy73 said:
This is a great idea for sure. I will certainly lend a hand where I can.
That being said don't know if it is possible to OC the GPU. I remember discussing this with kmobs in the past and he didn't think so. Perhaps tweaking Open GL might prove more fruitful. All of this is definitely worth thinking about.
Click to expand...
Click to collapse
Hmm well that may be kind of a downer...
I know it sets the values somewhere, but I can't seem to find anywhere it could be setting them other than the kgsl stuff, and that doesn't have any effect on performance at all. Unless it could be set in hardware?
I don't really care about harming my Nexus at this point, now that I've upgraded to an Evo, so I'm willing to try dangerous kernels on my Nexus (read: any kernel changes I make ).
If someone could give me any more ideas about where to look, I'd be greatful. I've gone through everything I can think of and it doesn't seem to be getting me anywhere closer.
P.S. I love your avatar jlevy! Simpsons FTW!
This is definitely for the kernel masters like Cyanogen, pershoot and kmobs to weigh in on. In the meantime I am going to rip through the code to see what I can find (if anything). To bad you are moving on to the EVO. We'll miss all of the great ideas/solutions you provide (well N1 user will)
jlevy73 said:
This is definitely for the kernel masters like Cyanogen, pershoot and kmobs to weigh in on. In the meantime I am going to rip through the code to see what I can find (if anything). To bad you are moving on to the EVO. We'll miss all of the great ideas/solutions you provide (well N1 user will)
Click to expand...
Click to collapse
Thanks! I'll still be hanging around the N1 forums, since so much of the code is interchangeable with them both having the QSD chips and all. If you're looking through source, can you get with me on GTalk or Wave & we can work together on it. Also I've updated the first post with a little more info.
Geniusdog254 said:
Thanks! I'll still be hanging around the N1 forums, since so much of the code is interchangeable with them both having the QSD chips and all. If you're looking through source, can you get with me on GTalk or Wave & we can work together on it. Also I've updated the first post with a little more info.
Click to expand...
Click to collapse
Sounds good, I will PM you my gtalk address.
So I added the debug code. It shows that it is calling my code every time the GPU is initialized. This means it is setting the EBI1 clock to 245mhz instead of the original 128mhz. However I guess that is the wrong clock. it also defines 2 other clocks along with the EBI1 clock, however EBI1 is the only one that it sets a value for, the other 2 it just turns on (hardware values?).
After looking at the code, the clocks seem to be initialized at kgsl_platform_probe by clk_get. (correct me if I'm wrong since I'm a newbie at tracing through the GPU... )
*Nope...wrong analysis...that was the clock SOURCE instead of clock RATE...
**After looking through a bigger part of everything, I think you can't specifically overclock it. The way I see it, the clock source used by kgsl is unified with different clocks being set elsewhere. This is why you're not getting it to work. When it calls the kgsl part you modified, it sets to the modified clock BUT the moment it exits, some other part which uses the same clock source will reset it to 128Mhz. If you want to modify that, you'll pretty much have to modify everything which uses the same clock source. (again, correct me if I'm wrong but I think that pretty much describes what I'm seeing with the code...)
Geniusdog254 said:
So I added the debug code. It shows that it is calling my code every time the GPU is initialized. This means it is setting the EBI1 clock to 245mhz instead of the original 128mhz. However I guess that is the wrong clock. it also defines 2 other clocks along with the EBI1 clock, however EBI1 is the only one that it sets a value for, the other 2 it just turns on (hardware values?).
Click to expand...
Click to collapse
Yeah, I think the other two value are hardware related. To find the right clock...
intersectRaven said:
After looking at the code, the clocks seem to be initialized at kgsl_platform_probe by clk_get. (correct me if I'm wrong since I'm a newbie at tracing through the GPU... )
*Nope...wrong analysis...that was the clock SOURCE instead of clock RATE...
**After looking through a bigger part of everything, I think you can't specifically overclock it. The way I see it, the clock source used by kgsl is unified with different clocks being set elsewhere. This is why you're not getting it to work. When it calls the kgsl part you modified, it sets to the modified clock BUT the moment it exits, some other part which uses the same clock source will reset it to 128Mhz. If you want to modify that, you'll pretty much have to modify everything which uses the same clock source. (again, correct me if I'm wrong but I think that pretty much describes what I'm seeing with the code...)
Click to expand...
Click to collapse
I think you are reading it correctly and that one would have to manipulate all the other values to ensure it won't reset to 128mhz. However, even if you do modify all that, there could be a master over-ride that controls the clock set at a pre-set value.
One interesting thing I did come across is one can write their own Open GL code. http://android-developers.blogspot.com/search/label/OpenGL ES
So if one could manipulate the values for Open GL, it would almost be equivalent to OC the GPU. Just a thought.
jlevy73 said:
Yeah, I think the other two value are hardware related. To find the right clock...
Click to expand...
Click to collapse
I know for sure 2 of the 3 are set in the kernel. The EBI1 clock of course is the one I'm trying to modify now, it has no effect. Then there is the "imem" clock which I haven't seen any code to set it, and then there is the "grp" clock.
If you see my first post, in board-mahimahi.c it defines PWR_RAIL_GRP_CLK which is the GRP clock. It is set at 8 as I just discovered. Here is that code:
Code:
#define PWR_RAIL_GRP_CLK 8
static int mahimahi_kgsl_power_rail_mode(int follow_clk)
{
int mode = follow_clk ? 0 : 1;
int rail_id = PWR_RAIL_GRP_CLK;
return msm_proc_comm(PCOM_CLKCTL_RPC_RAIL_CONTROL, &rail_id, &mode);
}
The only thing that leaves is the imem clock which may be a memory clock? I haven't found it set anywhere, but it could be in the kgsl_sharedmem.c & .h files. I haven't checked there yet. That covers 2 of the 3 clocks. I don't know what the 8 value on the grp clock means, or even what the grp clock is. But so far, those 2 are for sure set in the kernel...
I forget his username, but maybe the guy who got use all the mem hacks would be of great service? I think it's c00l something
Who got us* damnit I hate these typos. I'm going to bed. Too tired, and tapatalk has no flipping edit button lol
dictionary said:
I forget his username, but maybe the guy who got use all the mem hacks would be of great service? I think it's c00l something
Click to expand...
Click to collapse
Coolbho3000. He posted in the original thread or the MSM7500 chip about how it was handled differently on Snapdragon chips and that we may be able to change it, but that's all he said.
Yup him. I see. I'll have my bro look over this and see if he can find anything relevant, or help in any way
I'm not so advanced with my dev
Geniusdog254 said:
I know for sure 2 of the 3 are set in the kernel. The EBI1 clock of course is the one I'm trying to modify now, it has no effect. Then there is the "imem" clock which I haven't seen any code to set it, and then there is the "grp" clock.
If you see my first post, in board-mahimahi.c it defines PWR_RAIL_GRP_CLK which is the GRP clock. It is set at 8 as I just discovered. Here is that code:
Code:
#define PWR_RAIL_GRP_CLK 8
static int mahimahi_kgsl_power_rail_mode(int follow_clk)
{
int mode = follow_clk ? 0 : 1;
int rail_id = PWR_RAIL_GRP_CLK;
return msm_proc_comm(PCOM_CLKCTL_RPC_RAIL_CONTROL, &rail_id, &mode);
}
The only thing that leaves is the imem clock which may be a memory clock? I haven't found it set anywhere, but it could be in the kgsl_sharedmem.c & .h files. I haven't checked there yet. That covers 2 of the 3 clocks. I don't know what the 8 value on the grp clock means, or even what the grp clock is. But so far, those 2 are for sure set in the kernel...
Click to expand...
Click to collapse
According to clock.h, imem_clk is the clock source for the internal graphics memory so that seems right.
intersectRaven said:
According to clock.h, imem_clk is the clock source for the internal graphics memory so that seems right.
Click to expand...
Click to collapse
Hey look at that! It just nicely lays out what all those clocks are!
grp_clock = Graphics clock
ebi1_clock = External Bus Interface 1 clock
imem_clock = Internal Graphics Memory clock
Not sure what the ebi1_clock is linked to, but kgsl sure sees it as important enough to set it every time it runs. It's the only one set in a recognizable format (hz).
I'm not sure where the imem_clock is set or if it even is. Intersect, did you happen to see it set anywhere? It may be important to change though, it would allow more memory throughput and we could increase the graphic memory size in the board file and that may boost performance.
The grp_clock seems to be actually the real GPU clock according to clock.h. It's set 8 in board-mahimahi.c but I'm not sure what the 8 means. But then it may be that PWR_RAIL_GRP_CLK is setting a voltage or other power level to the graphics bus? Maybe the clock is set somewhere else. That'll take some more digging.
Geniusdog254 said:
Hey look at that! It just nicely lays out what all those clocks are!
grp_clock = Graphics clock
ebi1_clock = External Bus Interface 1 clock
imem_clock = Internal Graphics Memory clock
Not sure what the ebi1_clock is linked to, but kgsl sure sees it as important enough to set it every time it runs. It's the only one set in a recognizable format (hz).
I'm not sure where the imem_clock is set or if it even is. Intersect, did you happen to see it set anywhere? It may be important to change though, it would allow more memory throughput and we could increase the graphic memory size in the board file and that may boost performance.
The grp_clock sleeps to be actually the real GPU clock according to clock.h. It's set 8 in board-mahimahi.c but I'm not sure what the 8 means. But then it may be that PWR_RAIL_GRP_CLK is setting a voltage or other power level to the graphics bus? Maybe the clock is set somewhere else. That'll take some more digging.
Click to expand...
Click to collapse
The EBI clock is the external bus interface clock so I don't think we should mess with it. Anyways, it's set I think to ensure that it's working when the GPU is rendering something. If you'll look at the things that set it, it's usually set to 0 when entering suspend or sleep. Anyways, the variables in clock.h are used as sort of pointers to where the system will actually try to set the clock. (from what I can read at least) As for the imem_clk, I didn't find it set anywhere so it may be that it's on the radio or hardcoded. As for the graphics memory size, I think coolbho3k already knows more about resizing it since he's studied the N1's memory layout in further detail. (he did create that mod which increased the size of the available memory AND also figured out how to get charansingh's camera more memory) Anyways, I'll take a look further.
Interesting, but can we activate hardware acceleration in the device? i think if you can think of a way to do that you will be able to overclock the GPU just like on a PC and easily access the clocking just like the CPU.
I'm no expert on overclocking Phones only PC's.
intersectRaven said:
The EBI clock is the external bus interface clock so I don't think we should mess with it. Anyways, it's set I think to ensure that it's working when the GPU is rendering something. If you'll look at the things that set it, it's usually set to 0 when entering suspend or sleep. Anyways, the variables in clock.h are used as sort of pointers to where the system will actually try to set the clock. (from what I can read at least) As for the imem_clk, I didn't find it set anywhere so it may be that it's on the radio or hardcoded. As for the graphics memory size, I think coolbho3k already knows more about resizing it since he's studied the N1's memory layout in further detail. (he did create that mod which increased the size of the available memory AND also figured out how to get charansingh's camera more memory) Anyways, I'll take a look further.
Click to expand...
Click to collapse
I just woke back up. I guess I will remove the EBI1 overclock since I'm not sure what it does. I'm also not sure what increasing the GPU memory will do, but it's worth a shot.
I had noticed EBI1 is being set to 0 whenever it's diabled, and then setting it back at the time it's enabled. I'm gunna go back through and try to find another setting for the grp clock & a setting for the imem clock.
Okay thought about a approach I wanna try with this device using Android Virtual Device to learn and have an environment I can trash before I mod approach the Atrix thanks to the dumps already posted in the development thread this approach might be useful since their isn't any head way on the boot loader yet. So what Ive got so far...
Target
Android 2.2
SD card
Size 16384
Skin
960 x 540
Hardware
Property Value
SD Card support yes
Abstracted LCD density 120
Accelerometer yes
Maximum Horizontal camera pixels 640
Cache Partition Size 66MB
Audio Playback support yes
Maximum vertical camera pixels 480
Proximity Support yes
Camera Support Yes
Battery Support yes
Audio Recording Support Yes
Touch-Screen Support yes
GPS support yes
Cache Partition Support yes
MAx VM application Heap size 24
GSM modem support yes
Device ram size 1024
The spec in red I need help with, Any input would be helpful, and yes I already know it would be limited but still would have an environment to bash none the less.
Please close in favor of this thread
http://forum.xda-developers.com/showthread.php?t=983116
Way more informative and the best way to start off with this approach, Thank you.
AOKP (Android Open Kang Project) is a free, community built distribution of Android 4.1 (JB)
This is an Unofficial release.
AOKP Homepage
Code:
#include
/*
* 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.
*/
Installation:
install kernel
full wipe
flash rom
flash gapps
reboot into rom
ALWAYS flash the boot.img from the zip
If you have already flashed my CM10 kernel you dont
need to do it. The kernel is compatible
Kernel Download
JB gapps download(20121011)
2012/12/31
This contains BLADE 201212301352 kernel
http://goo.im/devs/maxwen/AOKP-enrc2b/AOKP-20121231.zip
Changelog:
-fixed wifi direct - thanks to atheist93 for testing - MUST use new kernel in zip!
-added hardware key mapping from CM
2012/12/28
This contains BLADE 201212271409 kernel
http://goo.im/devs/maxwen/AOKP-enrc2b/AOKP-20121228.zip
Changelog:
-fixed USB OTG storage handling
-updated to latest AOKP sources
2012/12/20
This contains BLADE 201212180032 kernel
http://goo.im/devs/maxwen/AOKP-enrc2b/AOKP-20121220.zip
Changelog:
-NFC fixed
-Music app added
-CMFileManager app added
-Video recording fixed
-updated to latest AOKP sources
2012/12/17
This contains BLADE 201212180032 kernel
http://goo.im/devs/maxwen/AOKP-enrc2b/AOKP-20121217.zip
Changelog:
-fixed Torch
-added goo.im app support - install app and you will be notified on new
builds and can download them
-complete Bluetooth support - MUST use the kernel in the ROM or 201212180032
-bugfixes
-updated to latest AOKP source
2012/12/12
This contains BLADE 201212122240 kernel
http://goo.im/devs/maxwen/AOKP-enrc2b/AOKP-20121212.zip
Thanks to Lloir for getting all of this started and "pulling" me to the HOX+
Reserved
oh god no
maxwen said:
Code:
#include
/*
* 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.
*/
Click to expand...
Click to collapse
your header has a syntax error, good luck compiling with that. =P
nice work will try .Thanks
Yep ! I really missed the AOKP since my old HOX.
Looking forward on this one
Thank you
Lloir said:
oh god no
Click to expand...
Click to collapse
Why no ?
Just flashed it & it's working great. Only thing i noticed is that it was a bit choppy the first minutes but i always deactivate animations and also i raised the max clock up to 1700 (it was at 1300??). Now it's awesome. I used the boot.img which is in the zip. Thanks maxwen and Lloir :thumbup:
Sent from my HTC One X+ using xda app-developers app
[email protected] said:
Why no ?
Click to expand...
Click to collapse
Don't worry it's just banter
Sent from my HTC One X+ using Tapatalk 2
Thread cleaned
I did a little cleaning.
@ the guy who started this all and ppl that have an attitude like him:
When do you people understand that these devs owe you NOTHING, ZIP, NADA, RIEN, ZERO, NIENTE, NICHTS in whatever language you want to hear it. They develop what they want, when they want. If you don't have the right phone for the rom, your problem. This is called xda-developers forum not *****ing users forum.
So to come here and complain on a rom devs thread about the lack of roms for your phone is not only off topic (and alone for that a violation of xda rules) but also an unfriendly act against that developer.
We will not tolerate that in the future.
Way to blow that all out of the water...I respect u all chill
Sent with my fast aZZ [email protected] Android.....hox+ is waiting rooted for none stock roms
s3nsation said:
and also i raised the max clock up to 1700 (it was at 1300??)
Click to expand...
Click to collapse
That is actually "expected" by default
Since I use the "staging" cpu frequency "designed" from nik3r
So CPU0 is limited to 1.3 and CPU1-3 are set to stepwise
increased values up to 1.6
I didnt see a effect on performance so far on the long "run"
(just better battery )
but you are maybe right that after a reboot or initial flash
there are maybe some effects on performance since lots
of things are done there
maxwen said:
That is actually "expected" by default
Since I use the "staging" cpu frequency "designed" from nik3r
So CPU0 is limited to 1.3 and CPU1-3 are set to stepwise
increased values up to 1.6
I didnt see a effect on performance so far on the long "run"
(just better battery )
but you are maybe right that after a reboot or initial flash
there are maybe some effects on performance since lots
of things are done there
Click to expand...
Click to collapse
Ok, so it should be fine when I leave it (just untick the "Set on Boot" right?) ? Good.
Hell yeah! Unicorn porn!
Just FYI I did some benchmarking to compare the "staging" CPU frequencies with full 204-1700MHz, the difference was less than 7% on CPU and 2% on GPU which more then justifies the increase in battery life and decrease in temperatures
So the choppiness you experienced was probably due to media scanner mapping your music or some similar one-time task.
And I can't stress enough: don't use SetCPU or similar on One X+. They are not designed for tegra and do things wrong by only setting up the active cores. Most of the time you only have one core active, so the others are not set and that results in very unpredictable behaviour.
nik3r said:
Hell yeah! Unicorn porn!
Just FYI I did some benchmarking to compare the "staging" CPU frequencies with full 204-1700MHz, the difference was less than 7% on CPU and 2% on GPU which more then justifies the increase in battery life and decrease in temperatures
So the choppiness you experienced was probably due to media scanner mapping your music or some similar one-time task.
And I can't stress enough: don't use SetCPU or similar on One X+. They are not designed for tegra and do things wrong by only setting up the active cores. Most of the time you only have one core active, so the others are not set and that results in very unpredictable behaviour.
Click to expand...
Click to collapse
Ok, thanks for that. I wont use SetCPU or similar amymore :thumbup:
Sent from my HTC One X+ using xda app-developers app
Installed & running fine so far
Only minor thing I've noticed is the flashlight toggle doesn't switch it on. Tried with Notification Toggles + TeslaLED as well with no luck either.
Other than that it's working well :thumbup:
I do have a large number of Google Maps wakeups showing in BetterBatteryStats alarms, but that could be my fault so I'll keep my eye on it.
Sent from my HTC One X+ using xda premium
I can confirm nonworking flaslight, but it was the only problem i met, rest was perfect...
Wlk said:
I can confirm nonworking flaslight, but it was the only problem i met, rest was perfect...
Click to expand...
Click to collapse
ok thanks to both of you - will take a look
EDIT: fixed by using the Torch app from CM10
Will be in next build
Working great on my One X+, had some problems (a lot) with the usb debug connection with the sense roms, all solved with this excellent rom!
OP updated for new build 20121217
Changelog:
-fixed Torch
-added GooManager support - install GooManager app and you will be notified on new builds and can download them from now on
-complete Bluetooth support - MUST use the kernel in the ROM or 201212180032
-bugfixes
-updated to latest AOKP source
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
STEP 1 : install resolution changer pro on any h2os rom from play store (kinmaricans i preffer).
STEP 2 : First do not enable it just put height = 1440 and width = 2560 and then density to 538.
STEP 3 : ENABLE IT. ENJOY
Can't it be in oxygen or any other cm based custom rom
You can't change your phone's screen resolution ahahaha that depends on the hardware. That app is just changing your DPI to change the size of UI elements.
If you could change your phone screen resolution with a simple app, why would any OEM make phones with 4k screens?
The OP2 was, is, and will always remain 1920x1080. You can always change the DPI to get smaller icons or whatever (I prefer 380, stock is 480). More the DPI, bigger your UI elements.
jash2909 said:
STEP 1 : install resolution changer pro on any h2os rom from play store (kinmaricans i preffer).
STEP 2 : First do not enable it just put height = 1440 and width = 2560 and then density to 538.
STEP 3 : ENABLE IT. ENJOY
Click to expand...
Click to collapse
That is just absolute nonsense, sorry to say that. You just make the device believe to have a 2k display, which means the GPU will have to push even more "virtual" pixels, while everything is just "downscaled". You won't get any benefits from that, in contrary you will just introduce more cluster****, by letting it run on a virtual resolution instead of it's native.
There's a reason why people with 2K phones set the virtual resolution down to 1080p, so that the GPU doesn't have to work as hard.
How this differ from changing dpi, it comes to my mind that oos doesn't like changing dp
Sent from my ONE A2005 using Tapatalk
OP, you may want to alter your thread title in the advanced edit menu to something more accurate. You will see what I mean if you read the comments here.
And members, it's fine to try to educate someone or correct them, but do it respectfully. Or don't post otherwise.
Thanks,
Darth
Forum Moderator