Since I'm not allowed to post in the dev forum, I'll just leave this here:
The light sensor code on the HTC vision is out of date. It can only return 10 light levels, which range from 0..1024. I've been told this is apparently a Froyo standard and that modern phones return from 0..10240.
github dot com/CyanogenMod/android_device_htc_vision/blob/gingerbread/libsensors/LightSensor.cpp
wtf, can't even link to things as a new user?!?
On line 143, you can see the 10 constants that the light sensor code picks between. They are supposed to be in "Lux", but can anyone with a photography rig confirm this? Looking at this chart,
engineeringtoolbox dot com/light-level-rooms-d_708.html
1024 lux is an overcast day. If that's the maximum it can report, that seems like a particularly ****ty light sensor.
Is the hardware that bad, or is the Cyanogenmod code not taking full advantage?
Once we can figure out what the light sensor readings should be, I'll submit a patch to fix the default Automatic Brightness settings (which right now are totally out of sync with the hardware light levels). See line 40 here.
github dot com/CyanogenMod/android_device_htc_vision/blob/gingerbread/overlay/frameworks/base/core/res/res/values/config.xml
Anyhow, only 9 more posts to go before I can participate in the CM9 dev thread
Definitely submit a CM bug report explaining this. Then when you can post links, post a link to the issue thread and everyone will happily plus 1 it.
Hardware is not that bad - this is a CM problem. I've patched mine so it works properly, also, don't use CM. My recommendation.
Thanks for the encouragement. I've filed a bug here. My etiquette may or may not get a warm reception there, so +1s would be appreciated.
code.google [dot] com/p/cyanogenmod/issues/detail?id=4796
I agree with the comment, you should submit it as a patch on gerrit cm review
code.google.com/p/cyanogenmod/issues/detail?id=4796
Alright, installing git now, let's see if I can use it properly.
I might just submit the easy update to the default config.xml AutoBrightness values. My C++ is pretty crap and I doubt I can tell what's going on with the light sensor code.
That seems like an ugly kludge, but it is an open source project after all...
ERROR - JOKES NOT ALLOWED AS NEW USER
What a pain to sync the entire CM source with my crappy internet connection... the 'repo' script recommended in the Gerrit howto hangs overnight.
Code:
repo init -u git://github.com/CyanogenMod/android.git -b gingerbread
repo sync -j16
Killing and restarting the script seems to start again from scratch, so I'm making no forward progress.
I wonder if there's a way to submit patches to gerrit by way of github or some other remote git hosting service?
While setting up git / repo to submit a change to Gerrit, I learned two things - the G2 / Desire Z has a Capella Microsystems CM3602 Light sensor, and the reason the lux values are screwed up - cyanogen did it!
https://github.com/CyanogenMod/andr...mmit/2b53447ec6b2a3fd3e299428d359b3603db19025
Why, I don't understand. The change reason is "Match lightsensor values to kernel". Anyone know more?
Nice, I saw your gerrit submission here http://review.cyanogenmod.com/#change,12845
I hope it gets some good feedback!
Thanks c00ller, I wish I could have added some explanation to the change submission. It would make it a lot easier for a reviewer to figure out what's going on. The real fix would be to change the Vision's lightsensors values to the standard 10..10240 . But without knowing why cyanogenmod reverted them to 1..1024, there's a lot of potential confusion.
The reason for the change is, like the commit message says:
"Match lightsensor values to kernel"
If you look at the kernel source,
Code:
github.com/CyanogenMod/htc-kernel-msm7x30/blob/android-msm-2.6.35/arch/arm/mach-msm/board-vision.c#L317
you can see that these are exactly those levels:
Code:
static struct microp_function_config microp_lightsensor_function = {
.name = "light_sensor",
.category = MICROP_FUNCTION_LSENSOR,
.levels = { 0x1, 0x3, 0x5, 0x13, 0x1A, 0x45, 0xDB, 0x135, 0x1F2, 0x3FF },
.channel = 3,
.int_pin = 1 << 9,
.golden_adc = 0xC0,
.ls_power = capella_cm3602_power,
};
He probably just forgot to adjust the sensor <-> display level mappings in the config.xml (which is what you did in your patch):
Code:
review.cyanogenmod.com/#change,12845
I tried it and it works fine, and I gave it +1
Aha, thanks for the explanation m0viefreak!
I still don't understand exactly where in the code the hardware sensor outputs should be translated into engineering "lux" units. Libsensors seems like the right place to me (naiive non-programmer).
I'd like to advocate for migrating to the gingerbread light sensor standard, since some cyanogenmod auto brightness functionality assumes its 1..10240 lux light sensor range. For example, the "reset threshold".
Is the kernel code using the obsolete 1..1024 range for reverse-compatibility with froyo?
Thanks for bringing this up. I was actually just wondering if the kb backlight issue on Vision keeps coming up because of incorrect light sensor range.
..although this would seem to suggest that the backlight would be on all the time, rather than never on...anyway
I was going to talk to somebody about this but didn't know who to tell about this issue. The brightness can be right at times but the brightness can be changing every few seconds.
Sent from my HTC Vision using xda premium
Any update on the submitted Gerrit change?
Sent from my HTC Vision using Tapatalk 2 Beta-5
azrash said:
Any update on the submitted Gerrit change?
Sent from my HTC Vision using Tapatalk 2 Beta-5
Click to expand...
Click to collapse
Was wondering the same thing.
Same here.
Would anyone be willing to file a glitch/issue in the CM7 github for me?
Any news on this one?
When the light sensor can work properly, than battery life would also get a boost.
Can someone maybe post a link to a (flashable)file to get the right readings from the light sensor? Or tell me if there's a editable file on the system partition I can manually edit?
Related
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.
I wish to turn off continous autofocus when i take videos, the only thing this continously does is - it continoutly ruin my videos with excessive amout of blur that makes it impossible to use in many cases.
Interior videos, even outside it tends to totally mess up any attempts to make a decent video.
I saw some custom roms have a option to disable it in options, but i would like to keep the original rom - Root it and change whatever magic inaccesible settings i need to change (like the silent camera shutter ro.camera.sound.forced=0 setting).
I saw Potatoman's camera.apk mod but that does not have any options regarding video autofocus.
totally useless
i am with you on that problem, i don't even film anymore. all movies with moving objects or even if i move my camera are useless. i don't know why they made it this way. hope for a quick and reliable solution.
Its annoying as hell. I also dont bother recording! . Sad really.
Sent from my porn shoot using GT-I9100.
+1 for this problem.
I saw some custom roms have a option to disable it in options
Click to expand...
Click to collapse
Can you provide a link to a such rom?
It is miui for galaxy s2, i saw this in action and it has a option to disable auto-bluring of videos but i dislike the rest of gui. Plus i lose stuff like usb otg if i put that rom on so i'm searching for another solution:
http://forum.xda-developers.com/showthread.php?t=1130951
No luck Tried the camera apk from miui and it doesn't work on my kf3 stock rom.
I think our best hope is that Potatoman fixes this, i cannot reply in his topic (10 posts limit), but i sent him a private message about this and i hope he reads it.
I looked into disassembly tools for apk files and so far had no success taking apart the camera app myself, otherwise if i had a working way to disassemble and reassemble it i would do this myself (baksmali fails on me with a "Could not find the main class: R:\Internet\baksmali-1.2.7.jar. Program will exit." message).
JernejL said:
I looked into disassembly tools for apk files and so far had no success taking apart the camera app myself, otherwise if i had a working way to disassemble and reassemble it i would do this myself (baksmali fails on me with a "Could not find the main class: R:\Internet\baksmali-1.2.7.jar. Program will exit." message).
Click to expand...
Click to collapse
You should extract the classes.dex file from the Camera.apk (using WinRar) and put it to the same folder with baksmali-1.2.7.jar.
I managed to do that, and found the magic command line parameters for running it, i have the smali files but this looks like one big mess.
I found startTimer in onVideoRecordingStart
and .method public handleMessage(Landroid/os/MessageV in camera main handler, this contains text such as "AF_WAIT_TIMER_EXPIRED" and calls to restartTouchAutoFocus, it could be the timer which continously calls autofocus, but it's not in camcorder classes but the camera class - i am not sure how the classes are interconnected and if this is really what i was looking for, i wish potatoman can help better with this.
I found something else, it looks like continous focus is a camera property - focusing mode:
.method public static getFocusModeString(I)Ljava/lang/String;
it has modes: "auto, fixed, macro, facedetect, continuous-video" and is saved to preferences as "pref_camera_focus_key" (this is my guess based on what i am seeing)
It seems that android api confirms this:
developer.android.com/reference/android/hardware/Camera.Parameters.html#FOCUS_MODE_CONTINUOUS_VIDEO
called with:
developer.android.com/reference/android/hardware/Camera.Parameters.html#setFocusMode%28java.lang.String%29
camcorderengine:
.method public doPrepareVideoRecordingAsync()V
const-string v3, "continuous_af"
this goes into..
const-string v1, "continuous_af"
const/4 v1, 0x0
invoke-virtual {v0, v3, v1}, Lcom/sec/android/seccamera/SecCamera$Parameters;->set(Ljava/lang/String;I)V
useful info here too:
pastebin.com/V94HYCnk
Code:
// Parse continuous autofoucs into a format the driver understands
conAf = pars.get("enable-caf");
if (conAf != 0 && strcmp(conAf, "on") == 0) {
mContinuousAf = true;
}
else {
mContinuousAf = false;
}
pars.set("continuous_af", mContinuousAf ? 1 : 0);
I hope this research opens up the possibility that potatoman fixes this for us, i can barely read this .smali assembly and i'm afraid i'll break everything if i change anything.
note: i had to cripple all the http links because i have too few posts to link to things externally.. :/
Hey guys, just a heads up that I'm working on v2 of my mod now, so while I'm doing that I'll take a look at this too. I don't usually film video though, so just to be clear, do you guys want it to just stop adjusting the focus entirely, or adjust the focus faster so that it isnt blurry for so long (since atm it takes like 5s before refocusing.) Personally I think the best solution would be to refocus on tapping the screen like the camera does, but I'm not sure if that's possible during capture, so I'd have to look into it.
Please post telling me which, so I know what I'm trying to implement here. I don't want to make it worse!
Refocus when tapping the screen will be the best way i think...
Sent from my GT-I9100 using XDA App
Based on the code and documentation that i saw, it's not even possible to adjust the focusing speed.
I would prefer that any automatic focusing is simply disabled during video recording / camcorder mode.
If tap to focus works can be done that would be brilliant, but no automatic adjustments as this ruined every video i took so far.
The phone simply starts refocusing / enters blur mode for no reason while the picture is already totally crisp and then ruins 3-5 seconds of video with blur while it tries to find "focus".
we need touch to focus
is the best solution
today i read online that choosing for a lower resolution then the full had filming wil fix the problem, i havent got any time yet to test it ........
Tap2Focus would be awesome! BUT simple disabling continuous af would be enough for start
I wish the operation is as following:
1, The focus start and lock when I touch the Record icon.
2, The focus is disable and start to record when I release my finger from the Record icon
mrky said:
today i read online that choosing for a lower resolution then the full had filming wil fix the problem, i havent got any time yet to test it ........
Click to expand...
Click to collapse
I tried this - one of first things i tried, it doesn't really help at all in my case (tested this outside in a clear well sun lit scene)
stev2010 said:
I wish the operation is as following:
1, The focus start and lock when I touch the Record icon.
2, The focus is disable and start to record when I release my finger from the Record icon
Click to expand...
Click to collapse
+1 Yes please!
But I would settle for ANYTHING to disable auto-focus because it make videos totally useless.
I actually have no problem with autofocus itself... but my issue is that auto focus does not work at ALL on any resolution lower than 1080... Anyone else have this issue?
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
Is there any way to control the LEDs with Cyanogen installed?
AstroPuls3 said:
Is there any way to control the LEDs with Cyanogen installed?
Click to expand...
Click to collapse
i noticed that too. Seems to be missing a service that qremote uses.
I would just at least like it to pulse different colors, or at the very least I would like to have control over which color the ring is..I wonder if anything is in the works
AstroPuls3 said:
I would just at least like it to pulse different colors, or at the very least I would like to have control over which color the ring is..I wonder if anything is in the works
Click to expand...
Click to collapse
i know anthony was talking about leaving them pink when he was developing cm10 for the q. might search or ask him. there are (or were) some commands that could be issued to change the colors.
I'd also like to be able to just turn them off. I'm pretty sure LightFlow is able to control the LEDs as normal because I noticed the other day my ring was white from a notification.
I think setting it to 255 255 255 might do the trick if we can figure out a way to set a persistent value.
Sent from my Nexus 4 using Tapatalk 2
Malnilion said:
I'd also like to be able to just turn them off. I'm pretty sure LightFlow is able to control the LEDs as normal because I noticed the other day my ring was white from a notification.
I think setting it to 255 255 255 might do the trick if we can figure out a way to set a persistent value.
Sent from my Nexus 4 using Tapatalk 2
Click to expand...
Click to collapse
So I tried Lightflow, and it disabled the Q from adjusting the volume with the sphere, and it didn't change any colors. I have to find something..
LEDs
Actually, looking at the CM 10.1 source for steelhead - there's some pretty easy to understand code in there for the LEDs - and even a clue about the LEDs - try doing a setprop on 'persist.sys.ringcolor' - set the value to the _integer_ value of the RGB you want (default is 14428 - aka 0x00385C - pale blue in RRGGBB) - and reboot. I'm going to start work on something a bit more interesting - maybe even an audiotap that will let you know the audio on the LEDs (like the Q did) - or set them with a visual tool (child's play).
---------- Post added at 11:07 PM ---------- Previous post was at 10:51 PM ----------
BitVenom said:
Actually, looking at the CM 10.1 source for steelhead - there's some pretty easy to understand code in there for the LEDs - and even a clue about the LEDs - try doing a setprop on 'persist.sys.ringcolor' - set the value to the _integer_ value of the RGB you want (default is 14428 - aka 0x00385C - pale blue in RRGGBB) - and reboot. I'm going to start work on something a bit more interesting - maybe even an audiotap that will let you know the audio on the LEDs (like the Q did) - or set them with a visual tool (child's play).
Click to expand...
Click to collapse
Actually - I just did the tests - and indeed, you can just live set that prop and it will change. I wish the author had thought to support 0xRRGGBB format (dude, check the string for 0x!) - but it's a start. All kinds of fun projects will come from this...
BitVenom said:
Actually, looking at the CM 10.1 source for steelhead - there's some pretty easy to understand code in there for the LEDs - and even a clue about the LEDs - try doing a setprop on 'persist.sys.ringcolor' - set the value to the _integer_ value of the RGB you want (default is 14428 - aka 0x00385C - pale blue in RRGGBB) - and reboot. I'm going to start work on something a bit more interesting - maybe even an audiotap that will let you know the audio on the LEDs (like the Q did) - or set them with a visual tool (child's play).
---------- Post added at 11:07 PM ---------- Previous post was at 10:51 PM ----------
Actually - I just did the tests - and indeed, you can just live set that prop and it will change. I wish the author had thought to support 0xRRGGBB format (dude, check the string for 0x!) - but it's a start. All kinds of fun projects will come from this...
Click to expand...
Click to collapse
I have no idea how to do that, is there a link that can help me, or a tutorial? lol Sorry, not that skilled with code yet.
AstroPuls3 said:
I have no idea how to do that, is there a link that can help me, or a tutorial? lol Sorry, not that skilled with code yet.
Click to expand...
Click to collapse
If you were able to install CM10.1 - you shouldn't have any issue with that...
Just in a terminal prompt - much like installing CM10.1 - with adb:
adb shell
su
setprop persist.sys.ringcolor 14428 (DEFAULT color!)
setprop persist.sys.ringcolor 8288 (0x2040 - so in RGB - that's blue with a bit of green)
Experiment with the values you set to get the right color for you. I'll be working on an app for this soon enough...
Thank you!
If anyone wants to turn the LEDs off:
setprop persist.sys.ringcolor 0
I think I'm going to make a Tasker toggle on my phone to connect to my Q via network ADB and change the color.
Sent from my Nexus 4 using Tapatalk 2
I am glad I am not the only one who sort of wanted to do something with the LEDs. I get you can customize it and flash, but are there any apps that allow you to change it on the fly? Are any apps Q enabled such that they can manipulate the LED ring? I was hoping Play Music would at least have a visualization that might do it.
I love the added functionality of CM (google pretty much killed what little was there out of the box by now) but I kind of feel the ring might as well not even be there as it doesn't do anything anymore.
Ben
I use Lightflow to control the LED.
Sent from my Nexus Q using XDA Premium 4 mobile app
Does that app mimic the original functionality of the visualization of the LEDs while music is playing?
Sent from my DROID RAZR using xda app-developers app
BitVenom said:
Actually, looking at the CM 10.1 source for steelhead - there's some pretty easy to understand code in there for the LEDs - and even a clue about the LEDs - try doing a setprop on 'persist.sys.ringcolor' - set the value to the _integer_ value of the RGB you want (default is 14428 - aka 0x00385C - pale blue in RRGGBB) - and reboot. I'm going to start work on something a bit more interesting - maybe even an audiotap that will let you know the audio on the LEDs (like the Q did) - or set them with a visual tool (child's play).
---------- Post added at 11:07 PM ---------- Previous post was at 10:51 PM ----------
Actually - I just did the tests - and indeed, you can just live set that prop and it will change. I wish the author had thought to support 0xRRGGBB format (dude, check the string for 0x!) - but it's a start. All kinds of fun projects will come from this...
Click to expand...
Click to collapse
is there anything to set other than ring color? maybe the individual ring leds or the mute button?
animal24 said:
is there anything to set other than ring color? maybe the individual ring leds or the mute button?
Click to expand...
Click to collapse
So... About that. There is a binary called "avrlights" that exists in standard CM10+ that allows for settings LEDs, but it's far from perfect. Seeing the flaws with this, I've rewritten avrlights (source file lightsctl.c) to allow for the setting of each LED in the ring along with the mute LED. For now, this is just a program you run from a shell.
My end goal is to basically have the original LED functionality of the Q restored. To this end, I'm working on some other handy bits. If you're interested in trying it out, you can pull the changes from my Github and build yourself. I'll throw up a link to a few build zips some time.
mcsaucy said:
So... About that. There is a binary called "avrlights" that exists in standard CM10+ that allows for settings LEDs, but it's far from perfect. Seeing the flaws with this, I've rewritten avrlights (source file lightsctl.c) to allow for the setting of each LED in the ring along with the mute LED. For now, this is just a program you run from a shell.
My end goal is to basically have the original LED functionality of the Q restored. To this end, I'm working on some other handy bits. If you're interested in trying it out, you can pull the changes from my Github and build yourself. I'll throw up a link to a few build zips some time.
Click to expand...
Click to collapse
Ah, so just avr lights from a prompt or adb shell? Is there an avrlights help in shell?
Also, throw up a link, I want to buy you a beer for even trying.
animal24 said:
Ah, so just avr lights from a prompt or adb shell? Is there an avrlights help in shell?
Also, throw up a link, I want to buy you a beer for even trying.
Click to expand...
Click to collapse
There is no help functionality, unfortunately. I think I'll add that in today. I'll put up a link once I can actually post them.
EDIT:: just added a usage message complete with examples
EDIT #2:: and now that I can post links, you can find my current build at http://daedalus.csh.rit.edu (uptime not really guaranteed). The most up-to-date version is in "untested" and includes the help documentation.
EDIT #4:: I've started marking the most up-to-date version current for the sake of convenience. Play with avrlights and hsv2rgb if you're feeling it.
mcsaucy said:
There is no help functionality, unfortunately. I think I'll add that in today. I'll put up a link once I can actually post them.
EDIT:: just added a usage message complete with examples
EDIT #2:: and now that I can post links, you can find my current build at http://daedalus.csh.rit.edu (uptime not really guaranteed). The most up-to-date version is in "untested" and includes the help documentation.
Click to expand...
Click to collapse
10.2?
animal24 said:
10.2?
Click to expand...
Click to collapse
Yup. I plan to take a stab at CM11 next.
mcsaucy said:
There is no help functionality, unfortunately. I think I'll add that in today. I'll put up a link once I can actually post them.
EDIT:: just added a usage message complete with examples
EDIT #2:: and now that I can post links, you can find my current build at http://daedalus.csh.rit.edu (uptime not really guaranteed). The most up-to-date version is in "untested" and includes the help documentation.
Click to expand...
Click to collapse
Thanks for this, I am having way too much fun! Hope this can get merged in the CM source tree.
Heres a nice bouncing rainbow script for anyone who wants to mess around.
http://pastebin.com/nd0Bpnus
So, I could not find the answer to this, when is it exactly the doze mode activated (becoming active).
All articles only mention, after some time when the device is stationary (no movement).
How long is that some time?
After some read, found this article:
https://newcircle.com/s/post/1739/2015/06/12/diving-into-android-m-doze
And here is the source code of the DeviceIdleController:
http://tools.oesf.biz/android-MNC/xref/com/android/server/DeviceIdleController.java
It looks like, the doze mode will be activated after 1 hour (2 times 30 minutes).
But again, I am not Java developer, probably there are much more detail in the process.
What if the device is moved? Will the doze mode "cancelled"?
Well, it would be nice if custom ROM developer could add some customization in this, like shorten the activation time. Or even better, after the doze mode activated, it will stay active even if the device is moved (inside pocket), until the user do something (e.g. waking up, pressing button).
We need a developer to perform doze!!!!!
Enviado desde mi Nexus 6 mediante Tapatalk
I had these exact same questions. How long does it take to enter doze and how much does it take to wake from doze? Like if I bump my phone on desk is it going to hop out of doze mode? Would be cool to alter the time limits. Glad someone is looking into this!
And what parameters are measured for "stationary"? If the GPS is involved then truckers, EMTs, highway patrols and there like will never hit doze.
Sent from my Nexus 6 using Tapatalk
Hoyt Thompson said:
And what parameters are measured for "stationary"? If the GPS is involved then truckers, EMTs, highway patrols and there like will never hit doze.
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
I would really hope Google would have considered that when making doze.
Sent from my Nexus 6
Mr Patchy Patch said:
I would really hope Google would have considered that when making doze.
Sent from my Nexus 6
Click to expand...
Click to collapse
I am sure they did but it would be easier for the devs to tweak it or us to use it to its potential if a more descriptive instruction is given rather than "stationary"
inquiring minds want to know and searches are turning up few results
Hoyt Thompson said:
And what parameters are measured for "stationary"? If the GPS is involved then truckers, EMTs, highway patrols and there like will never hit doze.
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
If I am not mistaken, the doze will detect "significant motion" for that stationary checking.
Code:
void startMonitoringSignificantMotion() {
if (mSigMotionSensor != null && !mSigMotionActive) {
mSensorManager.requestTriggerSensor(mSigMotionListener, mSigMotionSensor);
mSigMotionActive = true;
}
}
void stopMonitoringSignificantMotion() {
if (mSigMotionActive) {
mSensorManager.cancelTriggerSensor(mSigMotionListener, mSigMotionSensor);
mSigMotionActive = false;
}
}
However, how much significant? That's up to the manufacturer implementation. At least this is not defined in the software. That's what I understood. This is an explanation I found:
http://stackoverflow.com/questions/...-of-type-significant-motion-sensor-in-android
But again, I am not Android developer.
I guess, to know about that significant motion, you can install this app (FREE) and then test with some motions
https://play.google.com/store/apps/details?id=com.axelk.sensorapp
From the app description:
Android Sensors is an very useful and simple application.
With Sensor Test for Android on your device you can view and read ALL AVAILABLE android-sensors. (similar to Sensor Box for Android or Phone Tester)
Additionally, you'll receive via the info button other useful information such as the sensor works and what it does.
I'd appreciate a good rating and a +1 (Google+)!
Sensor Test for Android is tested on different devices and versions.
I was not able to test all 8000 different types of Android devices, it´s possible that on some devices appear errors.
Affected people with a not working Sensor-Test-App should reboot and run it again.
Sensor Test for Android is still under construction!
If you have any troubles with your device, please send me an e-mail with the problem (Device-type, Android version, screenshot) before submitting a bad rating.
[email protected]
List of available sensors: (not all sensors will be present in your device)
- ACCELEROMETER
- MAGNETIC FIELD
- ORIENTATION
- GYROSCOPE
- LIGHT
- PRESSURE
- TEMPERATURE
- PROXIMITY
- GRAVITY
- LINEAR ACCELERATION
- ROTATION VECTOR
- RELATIVE HUMIDITY
- AMBIENT TEMPERATURE
- MAGNETIC FIELD UNCALIBRATED
- GAME ROTATION VECTOR
- GYROSCOPE UNCALIBRATED
- SIGNIFICANT MOTION
- STEP DETECTOR
- STEP COUNTER
- GEOMAGNETIC ROTATION VECTOR
- HEART RATE
About me:
Sensor Test for Android is my technicians work I programmed in the summer holidays of my training as a technician (electrical engineering).
Before starting programming, I knew just how to spell JAVA.
I only had contact with LabView, a "painting by numbers" for programmers. For this application a documentation will be created, with which following students can easily incorporated into the Java programming language.
I'd appreciate a good rating and a +1 (Google+)!
Downloaded the sensor app @gogol seems a good amount of movement is needed for significant motion be counted(walking a few steps). Gonna do some more testing... Thanks for the info!
anthonyg45157 said:
Downloaded the sensor app @gogol seems a good amount of movement is needed for significant motion be counted(walking a few steps). Gonna do some more testing... Thanks for the info!
Click to expand...
Click to collapse
Good to know!
I am wondering if putting the phone inside our pocket would trigger significant motion. Otherwise, we need to put it lay down stationary on the table
Thanks for the experiment.
This is interesting, "Agressive Doze" mode from Greenify!
http://forum.xda-developers.com/apps/greenify/aggressive-doze-experimental-feature-t3223731
This isn't based on anything code related but Pebble users are reporting that on marshmallow their pebble's lose connection to the phone app almost 15 minutes on the dot after the phone screen turning off so that's my guess
Seriously 1 hour for doze mode to be activated? Sounds flawed. I'm still hesitating whether to buy Nexus 6...
How is the experiment goes?