okay, so apparently SCEF02 FW users r stuck with video recording fps drop when recording in low light conditions (and no official solution from samsung yet)
more about the problem here:
http://forum.xda-developers.com/showthread.php?t=1443658
the only FW that seems to fix the problem is the SIEG03, which indicates that the problem is software related and CAN be fixed
however it disables flash in video recording mode & LED torch
so can't the devs figure a way to edit SIEG03 firmware to give us flash support?
links that may help (thanks bartekaki for providing it):
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
personally, I'll pay 10$ if it happens (or more if necessary)
who else???
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
suzaku said:
https://github.com/GalaxySII/samsung...a/video/m5mo.c
Click to expand...
Click to collapse
Dude, you can't even copy/paste links from others's posts...
I'll chip another 10$.
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
bartekaki said:
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
Click to expand...
Click to collapse
thx man
radkor said:
Dude, you can't even copy/paste links from others's posts...
Click to expand...
Click to collapse
I thought that since I linked to the original whole thread then it's ok...sorry I'll fix it
karendar said:
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
Click to expand...
Click to collapse
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
suzaku said:
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
Click to expand...
Click to collapse
SIEGE03 is a firmware. This firmware is required to run the camera... To access the camera functions, we need a driver. This driver is compiled from source code which is what the link above is...
What probably happened here is that the Infuse uses the same camera module and interface. The flash though might use a different register or address scheme in the source code of the Galaxy S2 to interface with the firmware. So someone would have to figure out the difference between the m5mo.c source code from the Galaxy S2 and the I997 to see if it can be fixed through driver. Otherwise we'd have to reverse engineer the firmware which is too much energy wasted.
The problem with this method is that we'll need to compile a new version of the camera driver. And that, I am not the person to do it.
Another solution would be to pull the camera driver from a stock I997's ROM and overwrite it on our phone to see if it works.
I got a galaxy s2 here last friday (coming from a htc desire), and this week i got around to using the camcorder function. Immediately noticed the stutter issue, checked the forums and the current firmware situation, and switched out my SCEF02 for the SIEG01. Of course it fixed the stutter but broke the flashlight, so i spent an evening looking into fixing it. Here's how far i got...
The firmware binary
First of all the SIEG01 firmware binary itself. I did a hex compare with SCEF02 and there are so many differences (hundreds when set to 16 byte difference comparison) it'd be almost impossible to find the incorrect memory address for the flashlight function control (at least in my limited ability).
Next up i tried looking for seperate sections within the firmware to frankenstein a fix. There was only one certain boundary i found with an identical address, that's around the 166FF area, where both files are padded with FF's to the same position (following is ASCII denoting the firmware version). That's a pretty clear indicator that it's a seperate part of the rom, so, i switched out the bottom half of SCEF02 into SIEG01. The result was no stutters, no flashlight. Likewise replacing the bottom half of SCEF02 with that of SIEG01 resulted in stutters and a working flashlight.
So in short, regarding the firmware itself, the section controlling the flashlight function is somewhere before 166FF in the binary. Everything in that first half of the firmware is reasonably similar between the two firmwares, but not identical. Mostly it's single byte changes (probably just the same variables stored in different addresses), and most of the similar sections are offset by roughly a word of data or more. I didn't spend hours looking through to discover where the extra words of data crept in though.
The driver
You could spend weeks tinkering with values within the first 1300KB of the binary trying to find the flashlight section alone, never mind the specific variable/register for the flashlight mode itself, so i moved on to checking the right values were being set by the driver (m5m0.c).
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
the relevant function appears to be m5mo_set_flash on line 858, and the function works pretty simply. First there's a case switch to set the values of two variables called flash and light which will be sent to the firmware. The final case is the one for the flashlight function, and needs flash to be -1 and light to 0x03:
Code:
case FLASH_MODE_TORCH:
light = 0x03;
flash = -1;
break;
If flash is less than 1 then no control command is sent to the firmware for the flash, so we can disregard that (i think). That just leaves the light function. i'll just quote the code here:
Code:
m5mo_writeb(sd, M5MO_CATEGORY_CAPPARM,
M5MO_CAPPARM_LIGHT_CTRL, light);
m5mo_writeb is the function sending (writing) the command to the firmware, sd i believe is the device itself, M5MO_CATEGORY_CAPPARM and M5MO_CAPPARM_LIGHT_CTRL are describing where to send the value of light to, on the device. I think it's safe to say M5MO_CATEGORY_CAPPARM is correct since the flash works fine and the same constant is used for the flash control code directly below the light code. It's also used for a bunch of other functions such as capture size etc.
In C code, variables that're defined in all uppercase are usually constants, so you need to go into m5m0.h to find the value for M5MO_CAPPARM_LIGHT_CTRL. line 272 will show you "#define M5MO_CAPPARM_LIGHT_CTRL 0x40". For the sake of being sure, line 180 also has "#define M5MO_CATEGORY_CAPPARM 0x0B".
Time to check out the Infuse source code and compare...
https://github.com/Entropy512/linux_kernel_sgh-i997r/tree/master/drivers/media/video
first of all m5m0.c, line 1411 you'll find m5m0_set_flash. The layout of the function is slightly different, it's still a switch case, but instead of using temporary variables to hold the values to send the flash and light, the values are just sent within the cases themselves. Anyhow, the light control section:
Code:
case FLASH_MODE_TORCH:
err = m5mo_writeb(client, M5MO_CATEGORY_CAPPARM, M5MO_CAPPARM_LIGHT_CTRL, 0x03);
CHECK_ERR(err);
break;
Again no command is sent to the flash, only the torch, and that value is 0x03 again. The same function and arguments are being sent as with the i9100 code earlier, so all that's left is to check the constants being used. Time to hop to m5mo.h for the infuse.
Line 183 "#define M5MO_CATEGORY_CAPPARM 0x0B" matches our i9100 driver. Line 282 "#define M5MO_CAPPARM_LIGHT_CTRL 0x40" matches our i9100.
Now there are some differences between the m5m0_set_flash functions and also in the m5m0_writeb functions for the two devices, but the values they're using to control the light are the same in both cases.
One thing of interest is that the infuse doesn't support autoflash which is light 0x04 and flash -1. However if you hook up the phone to your pc, run ADB and use the camcorder in low light or any flashlight apps, you can use dmesg to verify 0x03 is being sent, as the dmesg output will contain "m5m0_set_flash: E, value 0x03".
Essentially i think this rules out it being a driver issue. I mean i could be wrong, but it looks like the flashlight control values are identical for both devices. It seems like the issue is within the first section of the firmware binary, somewhere.
Hopefully this is of some use to anyone looking into a fix for the SIEG01 flashlight problem.
Thanks for share your investigation Myshkinbob. Very interesting.
I do believe is an "easy" firmware fix too.
As you did, i compared both firmwares binaries and took the hope for finding the flash part in the code. Without a reference there is too many unknown data for a trial and error. I mean i tried to copy-paste some code differences in the firmwares but no succes.
Since nothing looks broken i will keep trying...
It'd be good to get SGS II simulator on Windows. Without it, it's PITA to load every time APK into phone and reboot it to test one variable lol
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
wish i could help somehow...
Myshkinbob said:
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
Click to expand...
Click to collapse
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
suzaku said:
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
Click to expand...
Click to collapse
I'm pretty sure that's how samsung codes anyway, we're just lending them a hand in doing so. haha
how's it going guys? any news?
wish I could help but I'm a complete noob
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
blunted09 said:
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
Click to expand...
Click to collapse
Well this firmware really improves the overall quality of the pics but in shooting vids it really shines. Only thing so far missing is flash light during video capturing.
I would have moved to SIEG03 if it had had support of LED
me too, flashlight is a little bit to important for me
Related
I have seen other methods of removing the gesture or pattern lock but with this method you can remove the lock temporaley and apply it again without knowing the key.
Check it out here http://sud0x3.net/?p=5
What... you mean this: http://forum.xda-developers.com/showthread.php?t=536352
???
Nice find, just a little late.
lbcoder said:
What... you mean this: http://forum.xda-developers.com/showthread.php?t=536352
???
Nice find, just a little late.
Click to expand...
Click to collapse
I did do a few searches, but only found the method that changes settings in the sqlite3 database.
Suppose the method of recovering the pattern from gesture.key file is on here somewhere too then.
sud0x3 said:
I did do a few searches, but only found the method that changes settings in the sqlite3 database.
Suppose the method of recovering the pattern from gesture.key file is on here somewhere too then.
Click to expand...
Click to collapse
As far as I know, it is encrypted.
However, should be fairly easy to brute force given the low number of possible combinations.
lbcoder said:
As far as I know, it is encrypted.
However, should be fairly easy to brute force given the low number of possible combinations.
Click to expand...
Click to collapse
There are a lot of combinations and im not sure how you would go about brute-forcing it, unless you mean by making a comparison list of common gestures then referencing it.
sud0x3 said:
There are a lot of combinations and im not sure how you would go about brute-forcing it, unless you mean by making a comparison list of common gestures then referencing it.
Click to expand...
Click to collapse
This research could be of use but i cant get it to work yet http://moshe.nl/android/
My idea was to hex a load of key files, store them in a db and then compare. But this guy may have really cracked it.
sud0x3 said:
There are a lot of combinations and im not sure how you would go about brute-forcing it, unless you mean by making a comparison list of common gestures then referencing it.
Click to expand...
Click to collapse
Think about it;
There are precisely 9 points. You can't cross a point more than once, and each point you connect to has to be adjacent to the previous one. Each gesture can therefore be mapped to a tree, which you can traverse recursively until the proper pattern has been identified. You identify the proper pattern by encrypting the current pattern using the same encryption used by the phone (which we have source for and therefore KNOW), and comparing that against the contents of gesture.key.
Implementation:
We number each point 1 through 9.
From each point, you can go on to specific "next" points, which include all the adjacent points to that point except for any point that has already been traversed. You recursively test each of the possible next points until all possibilities are exhausted.
Lets say that point 1 is the upper left, counting across (3 is upper right), and then down (4 is below 1), etc.
Your function will basically do this (pseudocode):
Code:
boolean test(gesture_list){
if (encrypt(gesture_list)==gesture.key){
print(gesture_list);
return true;
} else {
for (nextmove in potential_next_moves){
if (test(gesture_list+nextmove)) return true;
}
return false;
}
Do you see how that works?
This is a simple brute force algo for this problem.
The main thing left to you in this is the computation of potential next moves. You can do this manually using a table. The value for potential_next_moves will be the contents of the table MINUS any point that is already within (gesture_list).
I believe that given the small scope of the problem, this will probably take under one second to brute force any key.
What makes this problem much easier for brute forcing is that there are a finite number of possible NEXT values, and this list of possible next values decreases very quickly as the gesture gets longer. For example, when you have 7 spaces filled, there may be AT MOST 2 possible next moves (as few as ZERO -- for example, using this gesture: 1,4,5,6,9,8,7 -- there are no possible next moves from there, so if that gesture doesn't compute, that branch will immediately return false without trying anything further.
Take a more complex brute force.... you have a 512 bit key, then you have 2^512 possible keys to test. Thats 1.34x10^154 -- an unimaginably big number. Even if your CPU could run 1 key per cycle (which it can't, not even close) at 2GHz, that would take you 6.7x10^144 seconds = 2x10^137 years!!! http://en.wikipedia.org/wiki/Brute-force_attack
But again, we have the advantage of no repeated numbers and a fixed/finite selection of next_steps.
sud0x3 said:
This research could be of use but i cant get it to work yet http://moshe.nl/android/
My idea was to hex a load of key files, store them in a db and then compare. But this guy may have really cracked it.
Click to expand...
Click to collapse
Ha ha. Yes. Nice find.
He's doing exactly what I said right above.
BTW: It works perfectly.
And as I predicted, takes under a second to compute.
You will note one thing about it though; if you throw in random data, it will calculate a gesture that is impossible. This is because he is ignoring one of the characteristics that I mentioned: adjacency! It would be much more efficient if he included this characteristic.
lbcoder said:
Ha ha. Yes. Nice find.
He's doing exactly what I said right above.
BTW: It works perfectly.
And as I predicted, takes under a second to compute.
You will note one thing about it though; if you throw in random data, it will calculate a gesture that is impossible. This is because he is ignoring one of the characteristics that I mentioned: adjacency! It would be much more efficient if he included this characteristic.
Click to expand...
Click to collapse
If i were to write something to recover the gesture i would probably either md5 the keyfile or the hexcode then generate a kind of rainbow table list.
example
md5:1234
md5:2345
md5:5321
Then you could compare md5 hashes to find the correct key. This would eliminate the problems in the script above.
lbcoder said:
Think about it;
There are precisely 9 points. You can't cross a point more than once, and each point you connect to has to be adjacent to the previous one.
Click to expand...
Click to collapse
You can cross a point more than once, I do it in my unlock.
So it looks like the Samsung Mesmerize has now been released on US Celluar and can be rooted via the same method as the Fascinate. According to initial reviews there is no Bing and very little bloat.
Has anyone managed to get their hands on any of the Mesmerize files / apks yet? Maybe this could finally de-Bing our stock browser? Would also be nice to see what their Touchwiz and calendar are like. Also, wonder if they have a cardock app that works with Google Navigation instead of the junk VZNavigator?
What are your thoughts? What other apps should we be looking at from the Mesmerize ROM?
Crazy thought - Could one back up service programming in QPST on their Fascinate, then flash the Mesmerize ROM, then restore service programming?
Martian21
Non-informative reply...
I was just posting the same info.
Glad someone else is thinking this too.
I hope we can get someone with the "balls" to try it.
And them someone with the "brains" to make it work.
Looks like this guy may have already tried by accident:
http://forum.xda-developers.com/showthread.php?t=781315
nitroxeno said:
Looks like this guy may have already tried by accident:
http://forum.xda-developers.com/showthread.php?t=781315
Click to expand...
Click to collapse
Lol. We don't need to flash the whole thing. Just need a few choice apk's
Sent from my SCH-I500 using XDA App
Haha. I too have been wondering about this. I always have to remember when I'm in the browser to back out and press the search button to look up things, or else I'll get Binged. I wonder if they tweaked any apps for that phone in comparison to ours? It seems like Sammy made subtle differences in the os between each Galaxy phone. This could be a potential gold mine.
The source is nearly identical
Did a diff and wadded through the results, mostly removal of source for BTL-IF driver under platform and addition of consecutive/rapid shot that was not in the original release and a few minor grammatical changes. Other than that (changes to approx 64 files, they are nearly identical. I will attempt to compile and flash later today.
SirGatez said:
Did a diff and wadded through the results, mostly removal of source for BTL-IF driver under platform and addition of consecutive/rapid shot that was not in the original release and a few minor grammatical changes. Other than that (changes to approx 64 files, they are nearly identical. I will attempt to compile and flash later today.
Click to expand...
Click to collapse
saweet!!!!!
I rooted my Mesmerize yesterday with the help of oneclick. I needed USBDeview to get my foot in the door, though.
I swear to god at one point my phone had me do the little puzzle piece unlock deal after it hibernated, but for the life of me I can't find where to get that to happen again.
Anyway, I'm pretty much a noob when it comes to smart phones, but I rooted no problem (because it is no problem) and I'm now familiar with my file system (via terminal emulator and linux commands).
What next? Should I use my new root ability to make a backup? Does the Mesmerize have any ROMs that can help me get rid of the U.S. Cellular splash screen on start up? Cyanogenmod?
I will make a relatively willing software tester for this group.
I'd recommend installing ClockworkMod Recovery and getting a full backup.
Do you know for certain that Fascinate's cwm will work for the Mesmerize?
System Dump...
Mods delete this if I'm not supposed to do this...
Someone on AndroidCentral.com posted the system dump for the Mesmerize.
(In case link doesnt work google: Androidcentral mesmerize rom dump)
http://forum.androidcentral.com/u-s-cellular-mesmerize/41974-req-rom-dump.html
Attached are two patches that add the changes from USCC source to VZW source, and a second patch that adds the kernel changes to the jt1134 kernel I pulled from git last night. I still haven't attempted to compile the updated kernel yet but for those who have a free minute and would like to try it before I can here are the changes:
Addition of continuous photo shot to kernel (videodev2-samsung)
Changes to timing in RTC section (rtc-max8998,rtc-s3c)
Addition of Voice Recognition routines (wm8994)
Changes to volume levels (wm8994)
Changes to pin status in S5PC110 (mach-jupitorm)
Change to head jack status (sec_jack)
SD card check routines (setup-sdhi)
IRQ status change from RANDOM to DISABLED (s3c-keypad)
Addition WRITE_COMMAND_CONFIG/command processor/IRQ changes to (qt602240/touchscreen)
Add ram dump to POWER+VOLUP (input)
Possible better checking and fix for for BATT missing/temp error (power)
Addition of FSA9480 JIT gadget drivers (not sure what for yet s5pc110_battery)
Addition of FSA9480 JIT gadget drivers (not sure what for yet fsa9480_i2c)
Addition of includes (plat-s3c24xx, too many to list in config)
Change tcp input define from 1 to 0 (tcp_input)
Removal of BTL-IF driver source from platform tree
It is possible I may have missed something so please do not consider this 100% complete.
I Hope this has helped someone else out.
Check page 3 post 28 of Memorize source discussion for updated patch and compiled kernels with and without voodoo. Enjoy, been running mine for about 6 hours now, no problems thus far.
Mesmerize Restore
Does anyone have a CW or Odin restore image for a USCC Mesmerize?
madtowner11 said:
I swear to god at one point my phone had me do the little puzzle piece unlock deal after it hibernated, but for the life of me I can't find where to get that to happen again.
Click to expand...
Click to collapse
The puzzle only comes up when you have an email or sms/mms.
Weeds2000 fixed the orientation on our Folio100 to work with games like Asphalt5 and now its possible to play, although graphics are still kinda messed up. but other games like the 3d tilt works nearly perfect now too.
you might find it useful, and VEGAn mod might be able to include this as my FolioTntMod is based of the TNT framework...
Find the download patch i made for our folio in this thread.
it also include a full 360 rotation fix, if you need it
As we all share the same Tegra2 platform and can nearly swap experience here, im posting this to share the fixes weeds2000 made for us...
Hope you find it useful..
Note:
The patch i made might actually work fine as update.zip on your tablet as well, or might need minor adjust to install, but let g tablet modders fix this if needed.
at least now you know its available.
Thank you! One question - do you know what file(s) were altered for the 360 rotation fix? Was it a lib file, for example?
EDIT: Also, to any other modders looking at this, the system.img is a ext2 filesystem image, NOT a yaffs2 image.
roebeet said:
Thank you! One question - do you know what file(s) were altered for the 360 rotation fix? Was it a lib file, for example?
EDIT: Also, to any other modders looking at this, the system.img is a ext2 filesystem image, NOT a yaffs2 image.
Click to expand...
Click to collapse
Roeby wan Kanobi, is this something that could work and be added to TnT Lite? My Clockwork back up just completed
Yes, I can package it as a supplement - I just need to know what to package.
Getting my dev unit ready with TnT Lite 3.1.2. There's also a new music player apk I need to test out.
roebeet said:
Yes, I can package it as a supplement - I just need to know what to package.
Getting my dev unit ready with TnT Lite 3.1.2. There's also a new music player apk I need to test out.
Click to expand...
Click to collapse
This could be another watershed update Also- with the accelerometer corrected, folks will be getting exercise by holding up the G while playing games
added:
Perhaps the one extra update that would be nice is a DSP manager so dB level or gain increases can be made. Modders released a DSP manager on the Incredible that allows increases to 3.5mm and speaker output. Hardware based EQ too.
Perhaps being too picky, but louder speakers would be nice.
Did you see.. they provided the SOURCE!!!!! This is what we need!
roebeet said:
Yes, I can package it as a supplement - I just need to know what to package.
Getting my dev unit ready with TnT Lite 3.1.2. There's also a new music player apk I need to test out.
Click to expand...
Click to collapse
What does the patch change? Would is break things when the application developer fixes the orientation code in their game.
We saw this problem fixed in the application in the Gallery 3D application by google, not in framework. http://android-developers.blogspot.com/2010/09/one-screen-turn-deserves-another.html
roebeet said:
Yes, I can package it as a supplement - I just need to know what to package.
Click to expand...
Click to collapse
okay here are some details.
the framework.jar modified comes from this file: update-smb_a1002-3338-user.zip
the library should be generic, but is required for the gsensor/rotation/orientation fix as part of the new framework.jar changes.
the 2 primary folders in the framework.jar changed are /android/hardware /android/view
you should be able to easily spot the differences in filesizes..
do note: there is another change android\os\Environment.smali as i modified it to work with /mnt/sdcard and /mnt/sdcard/sdcard-disk0 and /mnt/usbdisk-disk0 for compatibility with folio mount functionality.
here is the "vold" also different but works fine with the tap'n'tap framework.
remember that /etc/vold.fstab needs changed to support the more new mount devices if you wish to use that one too.
360 rotation fix is in android\view\WindowOrientationListener$SensorEventListenerImpl.smali
orientation fix is
android\hardware\SensorManager*.smali
but again, the framework.jar is Tap'n'Tap based, so works directly on top of r3338 edition.. and i made a patch in my section with just framework + lib files included.
rothnic said:
We saw this problem fixed in the application in the Gallery 3D application by google, not in framework. http://android-developers.blogspot.com/2010/09/one-screen-turn-deserves-another.html
Click to expand...
Click to collapse
No, as far as i understand, weeds2000 only made the hardware swap sensor reading, so now it acts like a portrait mobile phone, where our Tegra2 has the chip rotated once 90degree.
Dexter_nlb said:
No, as far as i understand, weeds2000 only made the hardware swap sensor reading, so now it acts like a portrait mobile phone, where our Tegra2 has the chip rotated once 90degree.
Click to expand...
Click to collapse
Hmm, so it does a 90 degree rotation. And the device is still a default landscape device. We definitely need to make sure there are no negative effects on games that utilize the acceleromether and worked fine before.
I would assume that the android developers would recommend making this change to framework, instead of handling it in applications if there weren't implications.
Thanks for the explanation - this is something I suspected would fix it, but it's good to see that someone had pushed the idea all the way through to an actual fix.
So, I suspect that when the device boots up, it should be in portrait mode initially (until the sensor kicks in).
roebeet said:
So, I suspect that when the device boots up, it should be in portrait mode initially (until the sensor kicks in).
Click to expand...
Click to collapse
That makes more sense to me if that is true.
I read through the code ... Prior to the code change they were performing the rotation either for Acceleration minus Gy on the y-axis
or Acceleration minus Gz on the z-axis and NOT Acceleration minus Gx on the x-axis. Now the axis swap is always occurring... under all 3 conditions irregardless of sensor.
Dont know why there was an exclusion in the first place for Acceleration minus Gx on the x-axis...
When I get back I will look through the code some more...
rothnic said:
Hmm, so it does a 90 degree rotation. And the device is still a default landscape device. We definitely need to make sure there are no negative effects on games that utilize the acceleromether and worked fine before.
I would assume that the android developers would recommend making this change to framework, instead of handling it in applications if there weren't implications.
Click to expand...
Click to collapse
rothnic said:
I would assume that the android developers would recommend making this change to framework, instead of handling it in applications if there weren't implications.
Click to expand...
Click to collapse
if Google didn't "invent" the different way of reading sensors, there would only be one way of doing it, so developers would not be able to see it, so an update to like 2.2 or higher is now an requirement, right? but if older games do not check, it would work with them, so this fix solves it as i see it.
putting back androidos orientation handling to its original state, as many developers should be reading it.
I have ported the fix for both TnT stock and lite. As well as Vegan beta 4.
http://forum.xda-developers.com/showthread.php?t=892345
gojimi said:
I have ported the fix for both TnT stock and lite. As well as Vegan beta 4.
http://forum.xda-developers.com/showthread.php?t=892345
Click to expand...
Click to collapse
remember its all done by weeds2000 , i cannot/will not take credits for his effort here, i am just sharing the good work done on this fix.
I have released a new version of the fix, this should clean up all the remaining issues with the accelerometer/compass. Code is also much cleaner now. Some weird hacks you may have seen were caused by the legacy API which was used by my test game.
Only known issue up to now is that the mouse coordinates are also rotated.
The source can be found in the zip file attached to the original post, I hope that all changes are prefixed with // XXX:
The source files are based on the nvidia-froyo tree.
Link:
http://forum.xda-developers.com/showpost.php?p=10209624&postcount=38
Doodle jump doesn't work. Game loads upside-down with home buttons on top. If you tilt left you go right...Any fix for this?
Does this work for the VegaN Ginger Edition, or is that fix built into the ROM, I think I am having issues with some games on that ROM.
bmw4aaron said:
Doodle jump doesn't work. Game loads upside-down with home buttons on top. If you tilt left you go right...Any fix for this?
Click to expand...
Click to collapse
I think you can write the developer and tell , that the games is not working normally.. all other games work fine, so why would one game stand out, only reason, bad programming, or misunderstanding of androidOS and orientation. maybe developer thought he should fix the "orientation" in his game on tablet, and forgot other trying to make it reverse.. so: bad programming and choice of developer..he should follow guidelines and not his ideas.
So, I'm running MDJ's CM7 2.6. I've fixed almost any issue I've had. But there's something really annoying me, my g sensor has a small offset. And as far as I know there is no built in calibration tool. I've tried some I found in the market, but those didn't work, still an offset. I was reading a lot and found AngelDeath's thread about a possible fix. http://forum.xda-developers.com/showthread.php?t=902129
But this is only for Froyo. So I was asking myself if there is any possible solution for Gingerbread?
And if possible, would you mind to add your AK8973Prms.txt? It can be found under /data/misc. Maybe this is a possible solution..
Edit: Please only if you have 2.3
Thx anyway
Cheers
The g-sensor from what I know has been fixed since I posted about the fix, the first question I have for you is what kernel are you using? I know that MDJ had removed the calibration setting from most of his roms, I dont know if this rom he did also, but when you say there is a offset, can you explain what type of offset and also if you compensated for the slight angle that the phone has due to the camera?
Frm what I read in another thread, the ak8973prms.txt values can be altered, and saved. also you can delete this file and upon reboot I believe it gets recreated..Also did you happen to backup your bma150_usr file and try adding mine in place? Or is that whats giving you the small offset?
http://forum.xda-developers.com/showthread.php?t=803242
This thread has info about the offset. It's a little old but offset adjustment still works. (freeze was fixed in kernel)
AngelDeath said:
The g-sensor from what I know has been fixed since I posted about the fix, the first question I have for you is what kernel are you using? I know that MDJ had removed the calibration setting from most of his roms, I dont know if this rom he did also, but when you say there is a offset, can you explain what type of offset and also if you compensated for the slight angle that the phone has due to the camera?
Frm what I read in another thread, the ak8973prms.txt values can be altered, and saved. also you can delete this file and upon reboot I believe it gets recreated..Also did you happen to backup your bma150_usr file and try adding mine in place? Or is that whats giving you the small offset?
Click to expand...
Click to collapse
Thanks for your reply
I'm using the stock MDJ 10.4. And he did, I'm pretty sure.
Well when I am playing for example doodle jump I have to tilt my phone to the right, right side to the floor (not very easy to explain, hope you know what I mean ) otherwise, if I hold my phone normal this doodle thing always jump to the left. It's not very much, but it is annoying..
Yes, that was already told somewhere, but in fact i dunno what values should be in there. It gets recreated, but if I am not wrong it will be wrong again.
Haha, I've read your thread, my problem is that such a file doesn't even exist, so I was not sure if I it is a good idea to just copy it in there.
memin1857 said:
http://forum.xda-developers.com/showthread.php?t=803242
This thread has info about the offset. It's a little old but offset adjustment still works. (freeze was fixed in kernel)
Click to expand...
Click to collapse
Well, I've tried.. but it seems not to work, still this f***in offset
Thanks anyway
Obviously you would know this but if your phone isnt rooted I dont think you will see it, its located in data/misc
Here is the contents of my file, unzip it and use a root explorer and go to data/misc and drop this in, let me know if it works, if not I have another idea for you Guaranteed to work
AngelDeath said:
Obviously you would know this but if your phone isnt rooted I dont think you will see it, its located in data/misc
Here is the contents of my file, unzip it and use a root explorer and go to data/misc and drop this in, let me know if it works, if not I have another idea for you Guaranteed to work
Click to expand...
Click to collapse
I think you have to tell me your other idea
Download GPS Status from Market (Its free), hit the home key then tools then pick calibrate pitch and roll. See what that does for you.
AngelDeath said:
Download GPS Status from Market (Its free), hit the home key then tools then pick calibrate pitch and roll. See what that does for you.
Click to expand...
Click to collapse
I gave up, even your second idea didn't work. I think I have to live with this annoying offset. I could try to change the kernel, but afaik that's no good idea, because everytime it was working like it should I changed something and boom, eveything was f***ed up again
But thanks for your help mate
Hi,
Have you found a solution to this, or am I too late? I seem to be having the same problem on an otherwise fast and stable build. I'm using TyphooN CyanogenMod 7 v3.7.0
For the info, the parameters and some values in the said file are completely different, so I don't know if I should replace them.
Thanks,
jk
Hi All,
i found solution for unlimited recording on android device, it has pros and cons so hopefully some programmer will come and modify the buildin camera apk.
here are solutions they are working perfects but the problem is the quality is no where close to the buildin cam apk.
1. lgCamera
2. Snap Camera HDR
3. moto x camera apk its free and in my opinion its quality better than the other 2.
so the problem of limited recording is not due to format fat32, because htc on buildin cam apk record 30 minutes and stops and its size is 4gb, but i have tried lgcamera was recording over an hours and its size was 5.7gb.
i do not keep it long, i hope some programmer modify htc one cam apk to record unlimit or auto splitted to 30 minutes duration, also modify its zoom default to the value of 50% because htc one cam is way zoomed out.
so if any genius person modify the camera apk then it will be best solution, it just need to override the default camera apk setting when some one modifying its camera apk.
some time when we have party i do not like to go and modify zoom setting and start record again every half an hour.
Thanks for any programmer who modify this and good luck with the rest for temporary solution.
Hi,
snap camera records 30fps with 20mbit in low light, but the result is darker then htc stock camera.
regards
starbase64
I could be off here, but since you said recording stops at 30 minutes, I think I have a solution:
In /system/etc/media_profiles.xml, there is a "duration=" setting for each encoder profile. This can be set to either 30 or 60, and currently all profiles except qvga are set to 30. You may be able to set this to 60 and be able to record up to 60 minutes. Report back.
zindu said:
i do not keep it long, i hope some programmer modify htc one cam apk to record unlimit or auto splitted to 30 minutes duration, also modify its zoom default to the value of 50% because htc one cam is way zoomed out.
Click to expand...
Click to collapse
You do realise that routinely changing the zoom is a terrible idea on the One?
It's a digital zoom, not an optical one, so all you are doing by zooming in is losing pixels - this is fine if you are shooting something and wish to zoom in for effect, but as a general rule if you want to get the best quality out of the camera, you should leave zoom well alone. This is especially true of the One as it doesn't have that many pixels to play with in the first place.
See here for more info - http://www.tfpsoft.com/fun/digitalcameraguide/digitalversusopticalzoom.html
Regards,
Dave
unlimited video recording android
In /system/etc/media_profiles.xml, there is a "duration=" setting for each encoder profile. This can be set to either 30 or 60, and currently all profiles except qvga are set to 30. You may be able to set this to 60 and be able to record up to 60 minutes. Report back.[/QUOTE]
hello homeslice976
Thank you very much for the information you have provided. i have uploaded 2 screen shots of the xml file you have stated and also uploaded 2 xml file which are original xml file on my htc device, but i think the device must be rooted to replace those xml files? am i wrong?
if i need to root my device then i will try to do it later today as my connection is very slow right now.
Regards,
zindu
unlimited video recording htc one
It's a digital zoom, not an optical one, so all you are doing by zooming in is losing pixels - this is fine if you are shooting something and wish to zoom in for effect, but as a general rule if you want to get the best quality out of the camera, you should leave zoom well alone. This is especially true of the One as it doesn't have that many pixels to play with in the first place.
Regards,
Dave[/QUOTE]
Thank you Dave,
i will test to video one with zoomin at let say 40% and other will let zoom alone but i will crop the video to equivalent of 40% zoomin video, i will compare the 2 side by side and will report back the result.
Regards,
Zindu
zindu said:
In /system/etc/media_profiles.xml, there is a "duration=" setting for each encoder profile. This can be set to either 30 or 60, and currently all profiles except qvga are set to 30. You may be able to set this to 60 and be able to record up to 60 minutes. Report back.
Click to expand...
Click to collapse
hello homeslice976
Thank you very much for the information you have provided. i have uploaded 2 screen shots of the xml file you have stated and also uploaded 2 xml file which are original xml file on my htc device, but i think the device must be rooted to replace those xml files? am i wrong?
if i need to root my device then i will try to do it later today as my connection is very slow right now.
Regards,
zindu[/QUOTE]
yes you'll need to be rooted. you don't need to do anything with media_codecs.xml. Just media_profiles.xml.
unlimited video recording android
yes you'll need to be rooted. you don't need to do anything with media_codecs.xml. Just media_profiles.xml.[/QUOTE]
Thank you, i will try to rooted later on today and report back if i succeed.
regards,
zindu
zoomin htc one
hello Dave,
i have tested the video, i captured 2 video phone was at stable position, one without touching zoom and the other shoot was zoomed about 60%
then i cropped the one with 0 zoom to the same frame as the one with 60% zoom.
the result is as follows:
after cropping the video file from 1920 x 1080 became 775 x 425 well if i keep this size the file remain same quality but when i cropped back to
1920 x 1080 the quality is blury and no where near the original or the video was shooted with 60% zoomin.
so i believe the zoomin in htc one does not effect its quality as long as you are not zoomed extreme.
when you crop video and resized you will lose quality the same as zoomin, but all camcorders allow certain zoom without affecting quality, so i believe htc one zoomin is the same, but some video camera have advanced zoomin to go beyond limited for instance 72x advanced zoomin and the normal zoomin is 20x, so if you go beyond 20 you still zoomin further but you will lose quality and shaky footage.so the safe is to stay with 20x range.
all edited with after effects and even i did not export the out put, but after editing them compared them side by side, it is like day and night the quality differences between the 2 videos.
thank you though for information, i will try first to root my device and see if i can go beyond the limited recording.
homeslice976 said:
I could be off here, but since you said recording stops at 30 minutes, I think I have a solution:
In /system/etc/media_profiles.xml, there is a "duration=" setting for each encoder profile. This can be set to either 30 or 60, and currently all profiles except qvga are set to 30. You may be able to set this to 60 and be able to record up to 60 minutes. Report back.
Click to expand...
Click to collapse
hello again
i have changed those number to 60
i started from
<!ATTLIST EncoderProfile duration (60|60) #REQUIRED>
and each
<EncoderProfile quality="cif" fileFormat="mp4" duration="60">
so as you see all are in 60 minutes but no luck sofar i tried twice
1st record 25:39
2nd attempt records 26:04
both size are 3.79 gb in size
now i started recording again to see what is the the outcome if it is the same then i have to try to changed back to 30 at least its 30minutes, so i think it is the size limit thing
update: it is size limit issue, i checked again it says video size limit is reached.
i think it is be useful if some one try to write a code to state when ever the video reach limited time then start again automatically.
but thanks for the advice, i will let you know if i come with better solution..
thank you.
regards,
zindu
update: it is size limit issue, i checked again it says video size limit is reached.
zindu said:
update: it is size limit issue, i checked again it says video size limit is reached.
Click to expand...
Click to collapse
Sorry - that was just a theory anyway. I'll keep looking around for something else that might be limiting the file size.
homeslice976 said:
Sorry - that was just a theory anyway. I'll keep looking around for something else that might be limiting the file size.
Click to expand...
Click to collapse
Hi guys, this seems to be the only real discussion on this issue going on at all.
Has anyone been able to find a way around this limitation?
the problem is there are many know how to solved but they do not shared with us.
only who does not know and they spread a word over the net and same crap like, it is due to format type, let me tell you i have solved mine on htc one no problem what so ever until i stopped manually.
i am not a programmer but currently when i have time i try to learn java then i will after that develop simple app and progressing from there and will help the community but that take up to 1 to 2 years.
any way how i solved mine? i do not know my self but i did 2 things will shared with all of you.
1. i rooted my htc one device, there is plenty guide on this forum.
2. i decompile my camera apk and i change a picture and i can not remember if i mess little with codes or not but i doubt i did, so i deleted the original camera apk and replaced with my modification.
i will be glad to share my camera apk with you if you think it might be due to this modifications, i tell you what? i never update the system software now, because i am afraid i will lose the unlimited recording, so it works for me but i do not know how, but in future when i understand java programming i will help every one in this community.
zindu said:
the problem is there are many know how to solved but they do not shared with us.
only who does not know and they spread a word over the net and same crap like, it is due to format type, let me tell you i have solved mine on htc one no problem what so ever until i stopped manually.
i am not a programmer but currently when i have time i try to learn java then i will after that develop simple app and progressing from there and will help the community but that take up to 1 to 2 years.
any way how i solved mine? i do not know my self but i did 2 things will shared with all of you.
1. i rooted my htc one device, there is plenty guide on this forum.
2. i decompile my camera apk and i change a picture and i can not remember if i mess little with codes or not but i doubt i did, so i deleted the original camera apk and replaced with my modification.
i will be glad to share my camera apk with you if you think it might be due to this modifications, i tell you what? i never update the system software now, because i am afraid i will lose the unlimited recording, so it works for me but i do not know how, but in future when i understand java programming i will help every one in this community.
Click to expand...
Click to collapse
Zindu, thank you so much for sharing.
I emailed Google about this here is the response I got:
"Thank you for contacting Google. I appreciate your patience with me as I look into this issue. It seems as though the limit placed on the video data file of 2gb is written into the android operating system. This is in effect on all types of android devices.
I have researched a few video control apps, they follow the same rule and stop at 1.9-2gb. At this time I do not believe there is a work around for this issue. I do not have software update information available either. Some of the research I have done points to a possible legislative law that limits the video recording time of mobile devices as it takes away from video recorders."
pal first thing you do undock the cam apk from the bar dock on your phone, see if it is working, what i mean by the dock is the bar on your phone on the bottom which have space for 4 or 5 applications, so undock cam apk from this dock and used on the main windows view.
if that does not work root ur phone and undock cam apk from dock bar.
if both does not work then if you have htc one i will upload my cam apk so you can install it on urs.
mine was limited to 4gb now its unlimited in size and durations, a programmer can develop application to over ride the camera system settings, so if i learn java in future my first apk will be try to over ride system setting.
zindu said:
pal first thing you do undock the cam apk from the bar dock on your phone, see if it is working, what i mean by the dock is the bar on your phone on the bottom which have space for 4 or 5 applications, so undock cam apk from this dock and used on the main windows view.
if that does not work root ur phone and undock cam apk from dock bar.
if both does not work then if you have htc one i will upload my cam apk so you can install it on urs.
mine was limited to 4gb now its unlimited in size and durations, a programmer can develop application to over ride the camera system settings, so if i learn java in future my first apk will be try to over ride system setting.
Click to expand...
Click to collapse
I have a Nexus 5. My camera app is not docked. What should I do next?
if its not docked then rooted anyway see if it works?
what i did i undocked, rooted, modified a pick and some codes in xml file, and it works for me so i do not know which step caused the fix, but you need to root your device if you want to replace system application on your phone.
try to root your device first and try to modify xml file see if it works, if it was htc one i could help because i can upload xml and apk file.
that is all i know for now hope someone who have better knowledges to help you out but i hope i learn java within a year or too then i be able to fix this issue.
m__singh said:
Zindu, thank you so much for sharing.
I emailed Google about this here is the response I got:
"Thank you for contacting Google. I appreciate your patience with me as I look into this issue. It seems as though the limit placed on the video data file of 2gb is written into the android operating system. This is in effect on all types of android devices.
I have researched a few video control apps, they follow the same rule and stop at 1.9-2gb. At this time I do not believe there is a work around for this issue. I do not have software update information available either. Some of the research I have done points to a possible legislative law that limits the video recording time of mobile devices as it takes away from video recorders."
Click to expand...
Click to collapse
So far this has been the most insightful information. Still, no idea how to overcome something this stupid.
joint.striker said:
So far this has been the most insightful information. Still, no idea how to overcome something this stupid.
Click to expand...
Click to collapse
Ikr, it is pretty ridiculous. Zindu is right though, it's simple enough but the people who can figure it out don't care. Most people just don't seem to need their phone for our purpose.
My workaround has been SVR Pro:
-Upsides -It will record in fragments until your storage is full.
-You can use your device while recording
-You can record with the screen turned off !! which is epic for battery life!
-Downside -you loose like a second of video between the fragments
Link: play.google.com/store/apps/details?id=com.zeronoiseapps.secretvideorecorderpro