This thread is meant for (technical) discussion of OT-995, notably ICS-based (e.g. CM9 and AOKP) OS and kernel development.
Any non-technical questions/discussion belong in the general OT-995 thread.
Status quo
There's an ongoing effort bring CM9 and AOKP to the OT-995. Although neither is anywhere near complete, basic functionality (graphics/audio/gsm (non-data)/wifi/sensors) is present.
Both iuss and fonix232 currently maintain Android repositories related to OT-995. A common kernel is maintained by iuss, based on the 2.6.35.11 release by Alcatel.
Updates will likely be posted in this thread, but this topic start may not be fully up-to-date.
Source repositories
kernel: https://github.com/ius/tct_cocktail_kernel
android/bootable/recovery: https://github.com/ius/android_bootable_recovery
android/device/tct/cocktail: https://github.com/ius/android_device_tct_cocktail
(on top of the CM 'ics' branch)
android/device/alcatel/cocktail: https://github.com/fonix232/android_device_alcatel_cocktail
android/vendor/alcatel/cocktail: https://github.com/fonix232/android_vendor_alcatel_cocktail
Flashable releases
fonix232 has provided flashable builds of CM9 and AOKP: http://goo.im/devs/fonix232/OT995/ICS
(Be aware that these might not always be up to date with the repositories listed above)
Other bits of interest
iuss' slightly outdated README for his repositories.
fonix232 said:
Possibly, couldn't really boot yours though :\
Also, some more info about liblights. The tempfix works (keyboard lights up with screen), but apparently when the keyboard file is set in liblights, it won't call the keyboard function. If I set it to e.g. the notification LED, it is called, but bails out with error 13 (no access to notification LED control).
Click to expand...
Click to collapse
I just found some spare minutes and had a look at it as well (had to run & was working on writing the topic start for this thread, so I didn't get to posting about it).
It suddenly struck me that there's both a buttons and keyboard light; our virtual keys are buttons, I suppose keyboard is reserved for the backlight of a hardware keyboard.
Alcatel/TCT labeled the buttons backlight 'keyboard-backlight' in kernel, which it isn't.. I've fixed this; now the backlight works as expected. The notification light doesn't work with the CAF/AOSP liblights (different device paths), for now the stock (binary) liblights should work - it probably requires a chmod of the sysfs files in init.rc.
iuss said:
I just found some spare minutes and had a look at it as well (had to run & was working on writing the topic start for this thread, so I didn't get to posting about it).
It suddenly struck me that there's both a buttons and keyboard light; our virtual keys are buttons, I suppose keyboard is reserved for the backlight of a hardware keyboard.
Alcatel/TCT labeled the buttons backlight 'keyboard-backlight' in kernel, which it isn't.. I've fixed this; now the backlight works as expected. The notification light doesn't work with the CAF/AOSP liblights (different device paths), for now the stock (binary) liblights should work - it probably requires a chmod of the sysfs files in init.rc.
Click to expand...
Click to collapse
That makes sense - however, if you check my files, I've clearly made it so even if it there's a keyboard or buttons device, both calls the keyboard code - what never happens. I've logged it, every device open, every call of write_int, every device light setting, everything, and keyboard only showed up when:
a, Not the proper keyboard brightness path was given (in my case, it was the notification LED)
b, Moved the keyboard control to the lcd-backlight controller function - as it is currently.
And apparently yes, I've forgot to chown the whole LED folder's content to system
Also, our biggest problem is: this LED acts like as a battery/attention/notification LED, while keeping the modes of a trackball - slow pulse, fast pulse, constant on, constant off, and breathe. What would be the best way to approach?
(Just a sidenote: setting the notification LED's brightness to 0 will lead to the crash and reboot of the phone)
handy tool for making logs...
This app runs the following commands:
dmesg
logcat -v time -d
logcat -v time -b radio -d
getprop
uname -a
ps
Click to expand...
Click to collapse
Download : dl.dropbox.com/u/2889810/apps/getlogs_v1.1.apk
Thread : http://forum.xda-developers.com/showthread.php?t=1123129
I do it by hand, but thanks ;D
maby its a good thing to copy the apk to system/app
there will be a lot of people installing the build and then complain here that some stuff dont work (also bugs u didnt even realize they where there cuz u cannot test alone)
and when u ask them for logs some of them dont even know how to do it..
fonix232 said:
That makes sense - however, if you check my files, I've clearly made it so even if it there's a keyboard or buttons device, both calls the keyboard code - what never happens.
Click to expand...
Click to collapse
If I interpreted things right, you mean neither was ever called? If you had wired buttons-to-keyboard it should've worked, the reason why set_keyboard_light was never called is because TCT hacked the Java framework (by making the turn-on-screen-backlight-and-buttons event turn on the keyboard light as well).
Also, our biggest problem is: this LED acts like as a battery/attention/notification LED, while keeping the modes of a trackball - slow pulse, fast pulse, constant on, constant off, and breathe. What would be the best way to approach?
Click to expand...
Click to collapse
The monkey approach - I checked out the code for Nexus; it doesn't provide a battery light at all (which is probably only useful if you have a green/red led); attention and notification are routed to the same led.
The stock liblights seems to work quite well, e.g. notification (sms/mail) causes a blink, attention (USB inserted) a constant light.
Let's just copy stock liblights for now, we can rewrite/reverse it later.
(Just a sidenote: setting the notification LED's brightness to 0 will lead to the crash and reboot of the phone)
Click to expand...
Click to collapse
Good catch. Fixed in my kernel tree (no-op instead of a null fptr call)
iuss, I understand your concerns, and most probably will stick to it, but I've already began writing liblights Actually, it's like, around the fifth revision, fifth try, and still no worky. Just finished up my test-package (ultimate AOKP-CM9 with GApps installer, will post it separately), will test that and check back.
EDIT:
Tried your new kernel, but somehow, wifi fails to connect. DHCP timeouts, etcetera.
Works fine here (and I didn't touch anything related). For reference, a built zImage.
iuss said:
Works fine here (and I didn't touch anything related). For reference, a built zImage.
Click to expand...
Click to collapse
Egh, turns out it was my fault, something frikked up with my installer. Still working on the small quirks tho
Also an idea about BT - why not use the same module that the Galaxy Tab P4 series used? They are all BCM4330, so theoretically it should work!
question is it possible to make 3 point multitouch? (or more?)
The controller appears to be able to detect > 2 fingers, but doesn't return data for more than two.
In other news, I pushed a fix to make the ts driver once again support 2 fingers.
iuss said:
The controller appears to be able to detect > 2 fingers, but doesn't return data for more than two.
In other news, I pushed a fix to make the ts driver once again support 2 fingers.
Click to expand...
Click to collapse
The 5306 can detect up to 5 distinct touches, but apparently either the chip was locked down to two (or via baseband, and might be unlocked in ICS), or just the communication signal is processed in a wrong way.
But nice addition with the multitouch support!
EDIT:
First drawback of the stock liblights: the buttons light won't come alive after unlocking the screen, but needs to set the brightness manually. Does not occur if brightness is set to auto.
fonix232 said:
EDIT:
First drawback of the stock liblights: the buttons light won't come alive after unlocking the screen, but needs to set the brightness manually. Does not occur if brightness is set to auto.
Click to expand...
Click to collapse
Odd. Works just fine for me. I don't see how it's related to brightness either.. (what brightness? screen? I didn't touch it, nor have I any auto-brightness-control related overlay, if that's relevant).
iuss said:
Odd. Works just fine for me. I don't see how it's related to brightness either.. (what brightness? screen? I didn't touch it, nor have I any auto-brightness-control related overlay, if that's relevant).
Click to expand...
Click to collapse
I don't see either, but when brightness is on manual, I have to modify the value for the keyboard lights to show up.
Performance issue
I know, my question is maybe premature.
But what about the performance. Do you feel it could be faster than the stock rom?
Maybe some quadrant test would give us some idea?
it feels amazing
I think I might know a way to have 5-point touch, but it won't be easy...
Looking at the source code of the ft5306, you can see that in the firmware upgrade part, it points to a header file: FTS0094P430_CockTail_V1d_20111123_app.h
This header is nothing else, but an actual FT5306 firmware file, dissected into bytes. Basically, they took the hexa code of a binary firmware, and pasted it into a text file byte by byte! Sounds stupid, but actually a good way to integrate a firmware into the kernel.
However, the function can be overwritten so instead it reads bytes from an actual binary firmware file, located on the filesystem. Doing that, plus acquiring a 800*480 FT5306 firmware image (so far I've only found an 1024*600 one) would result in unlocking the whole capacity of the panel!
Also gave a try at the camera HAL. I can't make it work sadly :\
What happens if you write bogus firmware to ft5306, though? :x
The panel will most probably won't work, although the firmwares are pretty similar in all the ft5x06 series.
Aaaalthough, if you reflash a proper firmware, it should work again
Related
In Hermes I loved one feature: possibility of turning on the LEDs (called boldly a flash) with one of Vijay's apps. Of course I could not resist to test in on our (beloved) Rapahael but... Yes, you guessed right: marche pas/does not work/nie działa (choose the one you prefer). Anybody tried to work on this "problem of a person moving often in the dark areas with keys that must be inserted in always-too-small hole in the door"?
Of course you could just go in to camera settings to turn it on or off, it is only 3 or 4 screen taps away...
I mailed the author of the software, and he says that he will try to adapt to software as soon as he has some time, which would be in a few weeks. He says that there are people that already have modified his software to make it compatible with other devices. Anyone that can do this for the TP? I REALLY need that software too.
count me in on that one
i have been looking for it for 2 years now and it still dont look like there is gonna be an app for turning the flashlight on and off
as far as i know it is controlled by the cameradriver
Two years? It's been long available for wizard (vario) and hermes (vario 2). However, in case of my wizard I needed a rom update which included the correct htccamera1.dll (one that exports camera_flashlight method).
On a seperate note. I've been trying to get the flashlight to work on the touch pro, but no luck so far. Seems there is indeed (read it in diamond forums) at least one new parameter to the camera_init method. After debugging the dll it seems there may even be a lot more new parameters to the camera_init.
Anywayz, if I get anything to work I'll let it be known.
Waiting impatiently to test the results amd/or help in the process.
You could always try this:
http://www.artamata.com/pocketlight/
That doesn't work on the Raphael. It doesn't turn on the camera LED.
If you mean to use the screen blanker of that software, I sure hope you looked further, as there are other developers that made free versions, which are even more advanced (i.e. turning up backlight to full capacity at startup). Search the diamond forums for flashlight to find it.
Yay! I've just got it to work.
I'll build a small app for it to make it usable and post it on the forum.
Update:
http://forum.xda-developers.com/showthread.php?p=2588623#post2588623
NetRipper said:
Two years? It's been long available for wizard (vario) and hermes (vario 2). However, in case of my wizard I needed a rom update which included the correct htccamera1.dll (one that exports camera_flashlight method).
On a seperate note. I've been trying to get the flashlight to work on the touch pro, but no luck so far. Seems there is indeed (read it in diamond forums) at least one new parameter to the camera_init method. After debugging the dll it seems there may even be a lot more new parameters to the camera_init.
Anywayz, if I get anything to work I'll let it be known.
Click to expand...
Click to collapse
cheers mate ur the best
havent seen it for the vario only app i know off is vjay candela and that didnt work neither does all other applications for the flashlight..
and now i have a new phone and the flashlight application you just made ..
i cant be happier right now .. you made my miserable day a very illuminating one
flashlight
now that i've downloaded the code how do i implement the flash light?
jakubd said:
In Hermes I loved one feature: possibility of turning on the LEDs (called boldly a flash) with one of Vijay's apps. Of course I could not resist to test in on our (beloved) Rapahael but... Yes, you guessed right: marche pas/does not work/nie działa (choose the one you prefer). Anybody tried to work on this "problem of a person moving often in the dark areas with keys that must be inserted in always-too-small hole in the door"?
Click to expand...
Click to collapse
you should try hTorch 3.2 as well,
which has a very elegant interface:
http://forum.xda-developers.com/showthread.php?t=440405
As I said in another thread; lately I have been using TourchButton in combination with G-Trigger, I'm really pleased with how well it works.
The G-Trigger program runs in the background all the time, so now I just shake my phone a bit and I get light, shake it again and the TorchButton program runs again (thus turning it off).
And in the event the light should somehow accedentaly turn itself on, it will turn off after 60 sec as per the TorchButton code.
Continuing my quest of using the LED as flashlight for my new HD2, I updated TorchButton to support the HD2 as well.
Dropped your keys? Finding something behind the bench? Performing surgery on a computer and need to find that jumper on the mainboard?
This is a simple application built for some HTC devices that have a hardware LED, normally used to take pictures in the dark. However I found the LED to be perfect to be used as a handy pocket flashlight.
Usage
There is no GUI for this application. Just start TorchButton to enable the LED on the back of your device. Start TorchButton again to turn it off.
Check out the readme if you're an advanced user and wish to change some registry settings, i.e. to allow a longer maximum time the LED is enabled.
Known issues
- [Fixed] New icons are not working when TorchButton is installed to Storage Card
Todo
- Create an app to configure the registry settings
- See if support for Omnia Pro (B7610) is feasible (someone should send me the related dlls...)
- [Done] Add a seperate timeout for bright mode
- [Done] Add blink mode with bright led
- [Done] Use new icons provided by tnyynt
- [Done] Add support for Omnia (the one found here)
- [Impossible] See if it's possible to control leds seperately ('economic mode') Sorry, this is not possible. (Tech-talk: setting a single GPIO enables both LEDs. There doesn't seem to be a GPIO for each LED seperately.)
Wishful thinking
- Camera app to interpret the morse
History
Version 2.3
- Fix icons not showing in HTC Sense or WM 6.5 start menu when installed to Storage Card.
Version 2.2
- New icons for all TorchButton apps (thanks tnyynt!). These only work in WM6.5 and up. Older OS's will still see the old icons.
- Added registry setting to use bright setting in blink mode (see BlinkUsesBrightMode).
- Bright mode now has a seperate timeout, configurable in registry (see BrightModeTimeout).
- Added support for Samsung Omnia i9x0 devices (hopefully they all work). Thanks to raph/zemrwhite2/PaSSoA. Thanks to Chainfire for testing on his Omnia i900L.
- [edit] Shortcut names have changed. I found them nicer this way, no two-line icons. And the text is now also not cut-off when added as shortcut in the home screen.
- [edit] Improved handling of bright mode. It should stop immediately now when pressed again, instead of waiting for a 500ms interval. This makes BlinkUsesBrightMode possible combined with low intervals for blink mode.
- [edit] Soft-reset your phone after upgrading from an older version! Else the new icons will not show.
Version 2.1
- Bright mode is now support on the HTC HD2 (Leo).
- Added a one-time warning message when bright mode is used for the first time.
Version 2.0
- Initial version with support for the HTC HD2 (Leo) (bright mode is not supported on the Leo)
Version 1.x
- Support for the Touch Pro
Dont think about something. Untill i read your post. This could be handy sometimes. Thnx
Awesome man I was just thinking how I missed that
Btw what's missing for bright mode to work? If I'm not mistaken there is a brighter mode just before taking a pic.
Thanks! I was dissapointed that hTorch didn't work on the HD2 now I got this. Wonderful!
Great ! thanks
Have it on my Omnia and was hoping to have it for my future HD2 !
You're all welcome! Glad to hear you like it.
12aon said:
Awesome man I was just thinking how I missed that
Btw what's missing for bright mode to work? If I'm not mistaken there is a brighter mode just before taking a pic.
Click to expand...
Click to collapse
The mode is there, but it's not as easily called as it was on the Touch Pro. In fact I haven't found the API call at all yet. May need some hacking around the API to get that to work. The normal mode produces _quite_ the amount of light though, it's even more light than the bright mode of the Touch Pro thanks to the dual led.
Zero Masamune said:
Thanks! I was dissapointed that hTorch didn't work on the HD2 now I got this. Wonderful!
Click to expand...
Click to collapse
hTorch will work again once I update the C# wrapper to support the Leo, as hTorch makes use of my C# library. I'll do that somewhere in the upcoming week.
Great, works perfect ! Txs
Can anyone confirm this don't burn anything out? On the X1 the light modules weren't heatsinked properly and caused vibrator motor to screw up after 15secs use as a torch.
Thanks!
kinnyfaifai said:
Can anyone confirm this don't burn anything out? On the X1 the light modules weren't heatsinked properly and caused vibrator motor to screw up after 15secs use as a torch.
Thanks!
Click to expand...
Click to collapse
I can't confirm it won't ever burn out. However, realise that enabling the LED is actually the same as using your camera with the lights on in the dark. This _shoud_ be possible for prolonged times as well.
Were you using the 'bright' setting on the X1? (If that's possible there.) That might explain it better... otherwise you could just send in the device for repair, as it's normal use of the device. Especially if it's after only 15 seconds.
NetRipper said:
I can't confirm it won't ever burn out. However, realise that enabling the LED is actually the same as using your camera with the lights on in the dark. This _shoud_ be possible for prolonged times as well.
Were you using the 'bright' setting on the X1? (If that's possible there.) That might explain it better... otherwise you could just send in the device for repair, as it's normal use of the device. Especially if it's after only 15 seconds.
Click to expand...
Click to collapse
It was a known problem that the LEDs weren't heatsinked properly on the X1 and there was a huge warning on using hTorch. I've not installed hTorch and never used the LEDs on my X1 as a torch cos of this oversight by the manufacturer. I do miss being able to use the LEDs as a torch though, it's very handy.
Heej nice, i come from oud-Beijerland
nice app, but bright mode doesn`t work for me..
NetRipper said:
Continuing my quest of using the LED as flashlight for my new HD2, I updated TorchButton to support the HD2 as well.
Dropped your keys? Finding something behind the bench? Performing surgery on a computer and need to find that jumper on the mainboard?
This is a simple application built for some HTC devices that have a hardware LED, normally used to take pictures in the dark. However I found the LED to be perfect to be used as a handy pocket flashlight.
Usage
There is no GUI for this application. Just start TorchButton to enable the LED on the back of your device. Start TorchButton again to turn it off.
Check out the readme if you're an advanced user and wish to change some registry settings, i.e. to allow a longer maximum time the LED is enabled.
History
Version 2.0
- Initial version with support for the HTC HD2 (Leo) (bright mode is not supported on the Leo)
Version 1.x
- Support for the Touch Pro
Click to expand...
Click to collapse
20mihalko said:
nice app, but bright mode doesn`t work for me..
Click to expand...
Click to collapse
Isn't it clearly stated that brightmode doesn't work.......jeez....dude...read
ET said:
Isn't it clearly stated that brightmode doesn't work.......jeez....dude...read
Click to expand...
Click to collapse
sorry, my mistake
kinnyfaifai said:
It was a known problem that the LEDs weren't heatsinked properly on the X1 and there was a huge warning on using hTorch. I've not installed hTorch and never used the LEDs on my X1 as a torch cos of this oversight by the manufacturer. I do miss being able to use the LEDs as a torch though, it's very handy.
Click to expand...
Click to collapse
The vibrate function does not work at all on my X1 after installing and using hTorch. User beware..!
This is my next phone when O2 decide to put it on their shelves, and hopefully its built better than the X1.
Any chance of some source code?
I've been looking through the HD2 camera drivers, and have found a few things that should be the LED (can't test it as I have no device), but am wondering if it's the same method as yours!
l3v5y said:
Any chance of some source code?
I've been looking through the HD2 camera drivers, and have found a few things that should be the LED (can't test it as I have no device), but am wondering if it's the same method as yours!
Click to expand...
Click to collapse
Here are the important code snippets of the API that I'm using. The methods were pretty obvious (luckily).
typedef int (__stdcall *LEO_INIT)();
typedef int (__stdcall *LEO_SETCURRENT)(DWORD dw1);
...
LEO_INIT InitFlashLight;
LEO_SETCURRENT PMICFlashLED_SetCurrent;
...
hCamera=LoadLibrary(L"CameraPlatform.dll");
...
InitFlashLight = (LEO_INIT) GetProcAddress(hCamera, L"InitFlashLight");
PMICFlashLED_SetCurrent = (LEO_SETCURRENT) GetProcAddress(hCamera, L"PMICFlashLED_SetCurrent");
...
InitFlashLight(); // must be called before SetCurrent has any effect
...
PMICFlashLED_SetCurrent(0); // turns it off
PMICFlashLED_SetCurrent(1); // turns it on
There's also a PMICFlashLED_SetMode(x); but I haven't been able to figure out what it does. As far as I could see when disassembling it wants one parameter.
If you have any ideas on the bright mode, they'd be more than welcome. If you want the full source to make some modifications or to toy with it, let me know.
NetRipper said:
Here are the important code snippets of the API that I'm using. The methods were pretty obvious (luckily).
typedef int (__stdcall *LEO_INIT)();
typedef int (__stdcall *LEO_SETCURRENT)(DWORD dw1);
...
LEO_INIT InitFlashLight;
LEO_SETCURRENT PMICFlashLED_SetCurrent;
...
hCamera=LoadLibrary(L"CameraPlatform.dll");
...
InitFlashLight = (LEO_INIT) GetProcAddress(hCamera, L"InitFlashLight");
PMICFlashLED_SetCurrent = (LEO_SETCURRENT) GetProcAddress(hCamera, L"PMICFlashLED_SetCurrent");
...
InitFlashLight(); // must be called before SetCurrent has any effect
...
PMICFlashLED_SetCurrent(0); // turns it off
PMICFlashLED_SetCurrent(1); // turns it on
There's also a PMICFlashLED_SetMode(x); but I haven't been able to figure out what it does. As far as I could see when disassembling it wants one parameter.
If you have any ideas on the bright mode, they'd be more than welcome. If you want the full source to make some modifications or to toy with it, let me know.
Click to expand...
Click to collapse
That's what I'd come to as a conclusion, so glad that works!
Is there any need to un-init the flash light?
PMICFlashLED_SetMode will probably need some playing around, though might enable your "bright" mode. Will have a play with that when I get an HD2!
l3v5y said:
That's what I'd come to as a conclusion, so glad that works!
Is there any need to un-init the flash light?
PMICFlashLED_SetMode will probably need some playing around, though might enable your "bright" mode. Will have a play with that when I get an HD2!
Click to expand...
Click to collapse
There doesn't seem to be an un-init function. However, the debug console shows that it detects when the DLL is being attached to or detached from, so there's probably some cleanup code there.
I also haven't found any side-effects yet. TorchButton works fine even when the camera app is running. They don't interfere with eachother (other than toggling the LED to their own behalf). On the Touch Pro it wasn't possible to run TorchButton and the camera app at the same time. Not that I ever wanted to, but still.
In regard to that mode function. It must be for something. I tried using it in various ways already but it didn't matter. Maybe you'll have more luck
might be confused right now, but seems that when in camera mode, and battery is below 50% you cant use the flash - anybody know if this will affect the app?
haven't got my hd2 yet so cant help you out, but there's a thread under the Leo -- > Leo sub-forum
cheerios!
PLEASE NOTE THE FOLLOWING:
This is BETA code. Some things do not work and you should assume there will be BUGS. I am not responsible if you brick your phone with this or any other firmware. You are your own warranty once you start loading firmware. Please do NOT post about anything that's in the "broken" list; I will ignore you if you do.
If it's not listed as working or broken below then that particular feature has likely not been tested at all.
Kernel: Mine, built from Motorola's released source. Includes Smartassv2 governor and ext2, ext3 and ext4 filesystems plus MSS clamping support.
Codebase and credits: Originally sync'd from Isaac's work, heavily modified at this point. Isaac deserves the credit for getting the base code to boot and getting me interested in hacking on it.
What's working
Pretty much everything, except what's listed below.
What's known BROKEN:
Hdmi non-functional
The is an interrupt storm if you enable both Wifi and Bluetooth at the same time. Don't.
Front camera does not mirror snapshots or video, but does on preview.
Occasional force-closes when switching cameras front-to-back.
What's Intermittent: Nothing.
Included Apps:
Essentially nothing. Load GAPPS for Google apps (yes, you want them) by flashing these AFTER you flash the ROM:
http://goo-inside.me/gapps/gapps-gb-20110828-signed.zip - Base Google Apps
http://goo-inside.me/gapps/gapps-gb-20110828-newtalk-signed.zip - Google Talk (if you want it)
NOTE: You cannot provision on the CM7 ROM (the "Activate" apk, if you grab it from the Triumph, will not work - it appears to run, but does not function.) You must be provisioned using the stock ROM before you load this code. I am attempting to fix that, but am not confident it can be fixed as it appears to want things in the framework that I have no way to discover or duplicate.
To install:
1. MAKE A NANDROID BACKUP! I cannot emphasize this enough - and make sure you keep that backup somewhere SAFE. Most notably there is no way to activate the phone on CM7 at this time, and there may never be. If you need to change your phone number or similar you need to swap back to stock firmware. If you lose the ability to do that you will be pissed. Consider yourself warned.
2. Place the file in the below post on your SD card in the root.
3. Boot to clockwork by turning your phone off and then hold BOTH volume buttons while pressing POWER. Release power when the phone vibrates and continue to hold both volume rockers until Clockwork comes up.
4. Important: Clear the cache and data ("factory reset") If you fail to do this CM7 will blow up on boot unless you are coming from previous RECENT build. You've been warned! If you're coming from an OLD build (or stock) format /system as well.
5. Select the ZIP file from the SD card (about halfway down on the top screen of Clockwork to get to that menu, then the first entry and point at it.)
6. Commit the update.
7. If you formatted /system (and if you're coming from STOCK) flash GAPPS (below; the first is the standard GAPPS apps, the second is Google Talk) using the same procedure in #5 and #6.
On first boot it will take about 2 minutes before it comes up; if you have lots of apps it may take longer. Provided you see the little CM7 guy with the rotating arrow, it's working - be patient.
Current code download link(s)
11/19 - vB.08 http://www.mediafire.com/?bhmitbx7weqf8g2 - Wifi Tethering / FINAL
11/06 - vB.07 http://www.mediafire.com/?eqdfo7ktmtuq281 - Haptic soft keys / light sensor
10/30 - vB.06 http://www.mediafire.com/?qj28ip6o09j1ai6 - Screenshot / restore GB Launcher
10/29 - vB.05 http://www.mediafire.com/?rjf20vb74oc0irb - Cleanup release; see below
10/26: http://www.mediafire.com/download.php?wwj1l5lzjb4glfy - Wifi/PRL/Prox Sensor
10/22: http://www.mediafire.com/download.php?nssofns6sljfj33 - CIFS/Prox Sensor/USB Tether
10/16: http://www.mediafire.com/?jg5matblx1d7bq2 - First BETA
10/12: http://www.mediafire.com/download.php?wtwvx80ccsz8vfi - Last ALPHA build
Note: Loading this version requires a Clockwork that understands ext4. The following version is recommended: http://www.mediafire.com/download.php?acpcd9xtlpzqge1
Expected to be fixed in the NEXT build -
Work continues on the list in the first post along with tracking bugs that have been posted to GitHub.
Change Log (tracking as of 9/5), reverse chronological order:
11/19:
Wifi tethering is now built into the code (from Isaac's work); untested other than the fact that it does come up and is believed working. No other changes. FINAL RELEASE.
11/06:
Haptic feedback on soft keyboard now works and is treated as any other "virtual key" off the screen. Kernel modified to multiply light sensor readings by 30; this "sorta" aligns them with actual lux values (not really, but I don't have a light box that can get me a closer integration formula) and makes possible the CM7 options for "jump" settings, hysteresis and such to work as designed. No other material changes against b.06.
10/30:
Screenshot from power menu fixed and Gingerbread default launcher restored.
10/29:
Cleanup release. 2.3.7 codebase merge with CM7 upstream completed. "99memory" file added - see the notes below for how to tune this if you want to. Significant change to power management was made in the kernel; if you have Wifi turned off the phone will enter deep sleep, but if it's loaded then the sleep state is held at one level higher to prevent Wifi lockups. Note that data, when active, is a major power pig, even if nothing appears to be using it. It looks like Sprint has some "keep alive" processing going on either at the network level or in the actual CDMA driver code (which we don't have) that plays hell with power consumption. In short, with a data connection up I can't get materially under 30ma when idle and it's either the carrier or the CDMA radio code doing it - either way, I have no way to change it as there's no source to the chipset code available. Juice Defender, assuming Wifi is off, does a amazingly excellent job in conjunction with this release in shutting down the data connection and "waking it" once every 15 minutes or so to check for new notifications. It makes a huge difference in power burn with the phone in your pocket. You decide if its worth losing "instant" data notifies. I noted the same battery behavior on stock (Froyo) when I first got this phone, so my best guess is that this is in the radio firmware itself. Last alpha release pulled.
10/26:
Wifi wakelock problem is fixed. PRL now comes out of the radio and proximity sensor has more changes made. Note that the prox sensor may "flash" if you put the phone to your head before the call connects (before the "vibrate" after you dial); it should stop as soon as the phone goes into the "active" state.
10/22:
CIFS support via kernel loadable (.ko); NOT loaded by default as its very large. You can enable this in the startup scripts if you want it. USB tethering fixed. Proximity sensor "blinking" fixed. Various other minor changes as well.
10/16:
Data drop detection/correct code added. Front camera options that were unsupported in the hardware (and which could cause lockups) removed. Memory management changes made to improve performance. Soft keypad now PWM controlled (change levels under the CM7 options if you don't like my defaults) and other cleanup. Note: This release was early as there's a problem with some of the dependencies in the GIT servers, and as such I could not do a clean "verify builds from zero" run. Note that front camera mirror mode is enabled for preview but is NOT on snapshots and taken videos; this is being investigated as the mirroring should be on but doesn't work when the actual picture is taken.
10/12:
GAPPS removed from base build, front camera fixes complete, rear camera will now video record in HD. Tunneling support now internal to the kernel (no longer requires a loadable) for VPN users. Previous versions REMOVED.
10/2:
Partial front camera support is now available. The camera functions properly in video calling software such as Skype. Note that the "hacked" Froyo-capable Skype does not work properly; the one in the market, however, does. Other video calling applications may work but have not been tested. The Camera application itself will display the preview on the front camera but it is flipped 180 degrees (top to bottom), attempting to switch to video mode force-closes and a snapshot attempt hangs. Don't do that, basically. These are on the list to be fixed but progress is slow due to the very hacksterish way I had to implement the camera (no thanks to Motorola on that with no source access.) Kernel has the smartassv2 governor available for those who wish it and the build tree was synced up from CM7 to incorporate their fixes and updates.
9/25
Bluetooth tethering and MSS clamping implemented. Bluetooth tether is native; the MSS clamping, if recognized by other tethering applications (e.g. wireless tether) will also function to get rid of the need to set the client's MTU.
9/21
GPS now functional
9/10 morning:
Compass/geomagnetic sensors now working properly
Lights code now honors CM7's customization screens
9/5 morning build:
Market problems with apps not showing up repaired.
To file a BUG report
Use the Bugtracker Git at https://github.com/ikarosdev/CM7_Triumph_bug_tracker/issues?sort=created&direction=desc&state=open
Filing a new bug will require that you set up a login ID on Github if you don't have one. Please note that bugs reported in this thread (as opposed to discussion, which is always welcome) may or may not be noticed and tracked; if you care about whatever you're reporting, please use the GITHub system. Bugs filed on Github must include steps to re-create the problem if you're able to do so and if you can obtain one, a logcat or other trace is very helpful. You can also look at the above link to see what issues are open (please do not duplicate already-reported bugs, although if you have comments on them adding them is fine) as well as what has bene closed which may be of interest if you're looking for what is likely to show up in the next code turn.
Notes
Do NOT tamper with the following lines in build.prop:
ro.telephony.ril_nid=97
ro.telephony.ril_prl=1115
ro.telephony.ril_class=Triumph
ro.ril.def.preferred.network=4
ro.telephony.default_network=4
rild.libpath=/system/lib/libril-qc-1.so
rild.libargs=-d /dev/smd0
If you do there is a high probability that the radio will break. In particular the ril_class is required to deal with the oddities in the Qualcomm radio code. If you are running a different PRL you can change the prl line but it should remain present.
If you are updating from previous releases and have problems format the /system partition before you load the update. You should not need to format the data partition ("factory reset") and reload your applications, but no promises can be made at this point in development.
Custom backlight options (Settings->Cyanogen Mod->Display->Automatic Backlight) are available; you can change the behavior of the LCD backlight, including thresholds and illumination settings, the number of steps, whether averaging is used, whether hysteresis is operational and whether the button backlight is on or off as desired. Please note that unlike many devices the sensor value returned to the code is not in "lux"; it is a raw value and tops out in full sunlight somewhere under 100, with "0" being a fairly dim (but not dark) room. The default table I have loaded has the button backlight OFF for very dim ambient conditions (I like to use the phone as an alarm clock and want the buttons off at night), ON for low-but-present ambient conditions, and then OFF again (power saving) for ambient light high enough that the backlight has no real purpose. You may change this to suit yourself and your desires; some people will want the buttons on for zero-ambient conditions.
Note: As of 9/24 this load is using the "ext4" filesystem. Alternative kernels must support both that filesystem and the options CONFIG_NETFILTER_XT_TARGET_TCPMSS and CONFIG_IP_NF_MANGLE. If they do not MSS clamping will not function. If ext4 is not supported the kernel will not boot.
3g/1x data lock
If you are in a place that often switches down to 1xRTT for data due to questionable signal levels it is possible to lock the RIL to 3g mode. Note that doing so means you either get 3g speed or nothing. You need to access the "Phone Info" menu to do this using either AnyCut (from the market) or from the "Battery Monitor" Widget (go to "Tests" in the selected screen from there.) Note, however, that doing so (1) will not survive a reboot and (2) disables SMS/MMS and inbound phone calls during the time it is active. SMS/MMS will come through if you make a phone call but the EVDO-only mode for data blocks something in the radio that is required to receive and send SMS messages and the notifications of an inbound call. Since this "mode change" is actually a request to the radio ROM (which we do not have source for) this probably can't be worked around. However, I am looking into what this mode select does in the hope of being able to detect the 1x switch (which I can easily do with the existing RIL support code) and temporarily force a 3g switchback - which may or may not be highly-disruptive to data transport (if it is it's not worth doing at all, but if not...)
Note: There is an apparent memory leak in the base CM7 code somewhere. This is the cause of sensor slowdown (e.g. rotation is not immediately recognized) as the system becomes memory-constrained and ultimately will fault and reboot. I do not have isolation of this problem as of yet and have no reasonable expectation on when or if I may; for the time being I recommend a reboot on a daily basis to avoid the worst of these effects. The impact becomes particularly-severe if you use things like CoPilot that require large working sets of RAM. My instrumentation leads me to believe the problem is not in the kernel nor in the user application side of the system, but rather is in the base CM7 load. Investigation continues.
A note on overclocked kernels:
I will not be supporting these in my builds. They work, and some people want them. Isaac has built one that can (theoretically) go to 1.9Ghz.
Here's the issue in a nutshell: It's pretty easy to exceed thermal limits in a CPU doing this, and if you do, the best thing that happens is that the device becomes unstable and reboots. The worst thing that can happen is that the internal junctions in the CPU can be damaged or even destroyed. This damage is not always immediately apparent and can in fact be cumulative.
I understand some people want to overclock, but nobody really knows where "the wall" in this regard, and if you find it you're going to be very unhappy. As such if you want to have fun of this sort you'll need to load your own overclocked kernel over what I build. I respect those who are willing to take the risk but I just don't see the potential reward as being worthwhile and I don't want to be the guy that hands you a build that smokes the CPU in your phone.
Sweet man, keep up the good work! CM7 is gonna be great on the triumph.
Market fix in the latest build - please update.
Just flashed the updated ROM and so far so good. As long as the calls come through then I can wait for a full port. Thanks for your hard work =)
And on a side note, it seems like I'm getting better reception after I flashed this. (-85dBm vs ~ -95dBm to -105dBm)
The two big problems are the GPS and MMS. The MMS is a matter of hacking and time (Virgin's MMS is... odd...), the GPS is pissing me off. Again a lack of documentation strikes; it appears there's a versioning problem with the RPC stuff and the chipset and driver in question do not expose the NMEA port (which sucks.)
Awesome work!
Here is a random question. Does that lock/unlock flickering issue go away with this? What about the sometimes unresponsive back capacitive key?
Sent from my MOTWX435KT using XDA App
The auto-brightness code was completely re-implemented (by me); it's DIFFERENT in its behavior, but I like how it behaves.
I haven't had a back key problem with either this rom or the original....
HDMI bug report
I'm just trying to help out. HDMI out does not seem to be working just wanted to report this minor bug. Overall I'm loving this rom. Great job.
Great work Genesis!
Sent from my NookColor using xda premium
Anyone experiencing issues with data?
Seems like my data is intermittent and goes in and out randomly. I still see the 3G icon (and the signal status) but it goes white (no Google services) and I have no data access.
Yeah I've been losing data. Easiest fix is to turn on airplane mode on the off. Should come back on.
I've also noticed that email 2.3 keeps force closing. Got around this buy restoring email 2.2 with titanium backup.
stock video player bug
When playing videos with the stock video player the video comes out slightly glitchy. The same thing happens with YouTube videos.
I have not noticed the problem when watching flash videos or using arc media video player (have not had a chance to test others)
Love the ability to use the different themes with theme Chooser.
Agai appreciate all the hard work. Can't wait for a custom kernel
my review
ok i would like to start this off by saying that i love you for all the work you have done, you and Isaac. this is not asking you to fix anything this is just my first impressions after using this rom for two days.
*market: i believe this was already addressed in the original post of this rom. i updated market to the newest version and ever sense it has been force closing at random times. it still works to download things and browse but it will randomly force close.
*battery life has greatly decreased since i flashed cm7. even with juice defender pro it was still a much shorter life span.
*screen auto brightness: this has already been addressed i know but i am trying to do a very in depth review. it takes a while after i turn the screen on for it to brighten up enough to be clearly visible. another thing i just recently noticed was that while i was in a call and holding the phone up to my ear, the screen would repeatedly turn on and off. i believe this may have been the way i was holding the phone but it happened more than once so this is why i thought to address it.
*head set volume dropping issue. i have addressed this in a previous thread as a fix. i was hoping this would be fixed in cm7 but it must be a deep hardware issue. what happens is, when you are listening to music through the headset port and a text comes in, the phone will ring and then the music will come back on but at a significantly lower volume. the only way i have found to bring the volume back up is to make a call and then play your music again.
*music and calling: i have noticed that if you answer a call and have music playing, when you hang up the music will stay paused. i dont know if this can be fixed but i thought i would just throw it out there.
*wifi will work untill the screen goes off. the phone will not rewake and you will have to do a batt pull.
*swype fails hard. with froyo swype worked just fine but now it has very bad lag and doesnt even register when im swyiping sometimes. this is not that big of an issue because i use swype as personal preference.
*wifi wireless teather for root users. this works now! only with google web pages -_-
*mms: wont work at all. just a heads up though you can go to message settings and switch it to split messages so you can send longer messages.
as of now this is all i have but i will update this if i come up with more. as i said before i am not trying to nag you at all i just want to get my views out there and hopefully help with feature development of cm7 for the triumph.
keep up the great work guys! i cant thank you enough.
1. Market - if you loaded over the first load, you need to format /system before you do that. You've got pieces of old things laying around.
2. Battery - it's wrong (charge state) until you fully cycle it. I'm getting battery life roughly equal to the stock load (and I am off-charge a LOT)
3. Auto-brightness - This will be adjustable in the next load - the issue is that the phone turns in with the screen in the "dimmed" state and there's a smoothing period before it reacts. You can set that with the next load to make it behave however you'd like (defaults are close to, but not identical to, how it behaves now.)
4. Headset. I think this is a hardware problem.
5. Music and calling: This is a common issue with Android; when the output and input sources get reassigned the current stream is interrupted. Same thing happens if you're on speakers and plug in a headset. I doubt it's fixable (I know why it happens, but preventing the switching task from throwing the exception upstream could have extremely bad results - I'll look at it at a later date, but this is common to a LOT of Android devices.)
6. Wifi is a documented issue.
7. Swype works fine. Download the CURRENT beta. If you're using a hacked version, all bets are off. I use Swype exclusively for my keyboard on this ROM. Ditto if you're trying to sideload it from somewhere (e.g. restore from Titanium) - don't do that.
8. MMS: Documented as broken.
The thread over on Androidforums is more current than the one here, but I will endeavor to at least mirror MAJOR updates here.
richiehd said:
Here is a random question. Does that lock/unlock flickering issue go away with this? What about the sometimes unresponsive back capacitive key?
Sent from my MOTWX435KT using XDA App
Click to expand...
Click to collapse
Yes, that was something I found with CM7. The screen flickering issue is not present. YMMV.
platypuss94 said:
* another thing i just recently noticed was that while i was in a call and holding the phone up to my ear, the screen would repeatedly turn on and off. i believe this may have been the way i was holding the phone but it happened more than once so this is why i thought to address it.
Click to expand...
Click to collapse
on this note i will say it is in fact how you hold the phone. it happens to me all the time on my stock triumph. no big deal and nothing to worry about. but thank you for saying something about it none the less.
This is a no-frills thread.
Okay here it is.
cm_satsuki-Nega_Spork.zip
For dsds testing: cm_satsuki_dsds_test_boot.img Note: you will see the Sony Bootanimation instead of CM13, this is intentional. Also detection may take a minute or two. Provide clear reports.
For dsds model owners, flash rom clean, then in recovery reboot to bootloader and flash this test boot.img with fastboot
Code:
fastboot flash boot cm_satsuki_dsds_test_boot.img
fastboot reboot
NegaSpork
Working:
Sim [single]
Storage
NFC
Audio record fixed
The rest is the same.
What doesn't work:
Since the camera is still not "fixed" we will just say it doesn't work, deal with it.
Next on my todo list is fmradio
DSDS support is still being worked out by the project members. [see test boot image above]
NOTE: OpenGapps may bug out quickpanel/pulldown menu. This may be related to version used.
I experienced this with pico and nano. [see note below]
Click to expand...
Click to collapse
Thanks @KbaB.BroS for testing :good:
Everything from before works, cell, mobile data, nfc, etc.
Internet speeds are good.
It feels snappier than before, so smooth
The pulldown bar works, I can interact with the toggles without any force closes. If somebody complains about their devices, let them know to use OpenGAPPS. I use the mini version
Click to expand...
Click to collapse
Cyanogenmod Source
Thanks to/for
@CTXz Sources and convincing me to get a Z5P instead of another Sammy device.
Sony Kitakami Platform Developer Organization
@zacharias.maladroit For answering questions, many questions. :silly: [ still have more... xD ]
Those of you without a sense of humor, go away.
Okay current features i'm working on and stuff that works/doesn't work
UVC support enabled in kernel. probably need to build rom-side support still. libuvc avutils etc.
- This is for plugging in camera devices in conjuction with apps like LegitDashcam.
USB Gadget functionality as per pelya's work ,
- pelya/android-keyboard-gadget Use in conjuction with the include USB Keyboard app to utilize your phone as a keyboard/mousepad.
I am working my kernel source here toward net-huntery goodness.
The rest you tell me, and you tell me properly. Messages like
"waahhh my whatchamhoozit is all floompy"
are not acceptable.
This is not a random discussion thread either. Idle chatter belongs in general.
This is also NOT a discussion thread for Xposed,Viper, etc..
Thank you.
m
Notes and Updates
NOTE
I have been running this build for two days now and so far , meh it's alright.
Audio [mic] and Camera issues are definitely annoying.
SELinux is COMPLETELY disabled on this build. If You want security go back to stock.
SELinux enforcing is the goal though.
I strongly recommend using a "traditional" root os SuperSU over systemless-root.
Reasons:
Opengapps requires a factory-reset or fresh install to set up correctly!
Privacy Guard based root sucks. It forgets alot of permissions granted.
Use BETA-SuperSU-v2.52 , I wil attach below as it seems hard to find by conventional means.
Would have posted earlier but needed a smoke break *>cough<* :silly:
Updates and Notes
Reserved
Attached UPDATE-SuperSU-v2.46.zip for another option ,
since that worked the best for me in the past.
Thanks for the input. I get error: 7 to install the .zip file
any solution?
Rubensss said:
Thanks for the input. I get error: 7 to install the .zip file
any solution?
Click to expand...
Click to collapse
You need to use the recovery @moonbutt74 compiled from his other thread.
Sent from my Z5 Premium using XDA Labs
KbaB.BroS said:
You need to use the recovery @moonbutt74 compiled from his other thread.
Sent from my Z5 Premium using XDA Labs
Click to expand...
Click to collapse
Thanks , I have already installed.
@moonbutt74
Would be easier to keep the ROM as daily and test if it supported the dual sim version phones too
Apart from that, some of my observations during a small period of usage :
Pardon me if these are already mentioned.
Screen brightness doesn't reach full capacity
Speaker volume is low I think
For me, I felt the display had some slight glitches. Enabled GPU rendering in developer settings and felt it got better , can't guarantee on this though
Had to revert to stock based since sim functionality for me wasn't available ( I have a dual sim phone)
Ashray_Vk
Okay good deal, umm let me try compiling a seperate kernel package.
Yep brightness is currently HORRIBLE
I didn't notice any glitches display-wise, do you actually mean lag in some screen transitions?
I only tested with radioball and raging thunder.
The build i just tested out had full WOW, HOW THE HELL DO I TURN THIS DOWN BRIGHTNESS. :silly:
So either atm i get crappy brightness as max level which is like 75% of stock.
Or i get the nice stock brightness but the slider breaks/doesn't work.
The speaker volume is limited to where it actually should be. Use a mediaplayer that has an option for software decoding, that is a 100% [double] boost. It's not the idea to bomb out the speakers by default, each user can find their own tweak.
m
On the "daily build" thing, my upload time is horrible, so i will not be pushing out excessive/pointless builds. when i have something else fixed, then i will upload another build. Currently i'm boxing with the brightness issue and getting the mic working for audio recording.
moonbutt74 said:
Ashray_Vk
Okay good deal, umm let me try compiling a seperate kernel package.
Yep brightness is currently HORRIBLE
I didn't notice any glitches display-wise, do you actually mean lag in some screen transitions?
I only tested with radioball and raging thunder.
The build i just tested out had full WOW, HOW THE HELL DO I TURN THIS DOWN BRIGHTNESS. :silly:
So either atm i get crappy brightness as max level which is like 75% of stock.
Or i get the nice stock brightness but the slider breaks/doesn't work.
The speaker volume is limited to where it actually should be. Use a mediaplayer that has an option for software decoding, that is a 100% [double] boost. It's not the idea to bomb out the speakers by default, each user can find their own tweak.
m
On the "daily build" thing, my upload time is horrible, so i will not be pushing out excessive/pointless builds. when i have something else fixed, then i will upload another build. Currently i'm boxing with the brightness issue and getting the mic working for audio recording.
Click to expand...
Click to collapse
By screen glitches, I meant that I saw a few glitches when I scrolled down menus ( like even settings app).
Might be just my sleepy eyes too, lol. And in the beginning, everything was feeling laggy, till I enabled those GPU options in the developer settings and turned the screen off and turned it back on.
Don't rely on this data though, I hope someone else verifies this thing before you take it up as an issue .
-Ash
Ashray_Vk said:
By screen glitches, I meant that I saw a few glitches when I scrolled down menus ( like even settings app).
Might be just my sleepy eyes too, lol. And in the beginning, everything was feeling laggy, till I enabled those GPU options in the developer settings and turned the screen off and turned it back on.
Don't rely on this data though, I hope someone else verifies this thing before you take it up as an issue .
-Ash
Click to expand...
Click to collapse
No problem I'm just looking for clarification, are you talking about lag or screen tearing?
moonbutt74 said:
No problem I'm just looking for clarification, are you talking about lag or screen tearing?
Click to expand...
Click to collapse
There was lag in the beginning, no doubt. Lag was there since the boot animation itself.
Yes! Screen tearing is the term i was searching for. I felt like I saw minor issues of screen tearing along with the lag. ( especially when I scrolled down the settings )
I'm so sorry if I am not able to make things clear.
Nice. My question is does it work well with xposed? Other rom gives me random soft reboot randomly
Sent from my E6853 using XDA-Developers mobile app
Killastyle said:
Nice. My question is does it work well with xposed? Other rom gives me random soft reboot randomly
Sent from my E6853 using XDA-Developers mobile app
Click to expand...
Click to collapse
K,
right now we are working on an Alpha build, self evident in thread title. Xposed being superfluous/unecessary is not being discussed in this thread. Of course later on in the release/beta level thread it will most likely be covered.
@KbaB.BroS
On the good side got brightness and auto brightness sorted.
@Ashray_Vk , give me a bit on the dsds kernel, from what I'm understanding SS an DS were supposed to have been combined, so I am running a fresh build after resync, which on my comp will take a day :silly: adn probably not as long as the actual upload
:laugh:
m
moonbutt74 said:
K,
right now we are working on an Alpha build, self evident in thread title. Xposed being superfluous/unecessary is not being discussed in this thread. Of course later on in the release/beta level thread it will most likely be covered.
@KbaB.BroS
On the good side got brightness and auto brightness sorted.
@Ashray_Vk , give me a bit on the dsds kernel, from what I'm understanding SS an DS were supposed to have been combined, so I am running a fresh build after resync, which on my comp will take a day :silly: adn probably not as long as the actual upload
:laugh:
m
Click to expand...
Click to collapse
Normally, if I'd flash a stock based ROM which was meant for single sim, one sim would work in the dual sim models but the memory card would be not detected . sadly, that wasn't the case with cm though. Not even a single sim gets detected.
Ashray_Vk said:
Normally, if I'd flash a stock based ROM which was meant for single sim, one sim would work in the dual sim models but the memory card would be not detected . sadly, that wasn't the case with cm though. Not even a single sim gets detected.
Click to expand...
Click to collapse
you tried enabling only single SIM mode in Sony's (or other) "Stock" ROM and then flashing this ROM ?
Then at least one SIM might work - unless of course the Z5 devices handle things entirely differently
zacharias.maladroit said:
you tried enabling only single SIM mode in Sony's (or other) "Stock" ROM and then flashing this ROM ?
Then at least one SIM might work - unless of course the Z5 devices handle things entirely differently
Click to expand...
Click to collapse
Um, actually, was running rom aur and then had disabled one sim ( just because i didnt want to use that sim) and then had flashed this.
Unfortunately, not even a single sim worked in this.
Killastyle said:
Nice. My question is does it work well with xposed? Other rom gives me random soft reboot randomly
Sent from my E6853 using XDA-Developers mobile app
Click to expand...
Click to collapse
No problem with XPosed for some time here
Updated Build
CM13 Z5P E6853 Somehwere in Alpha -- Updated DragonLady
see OP , OH! and READ IT. grrrrrrr
Please verify communications are functioning, sim detection, in-call mic working etc.
Is your model SS or DS? Please state model number.
Brightnes and auto brightness should be fixed.
External storage fixed
Re-introduced kcal support in kernel
Included system apps [free, and free versions] - as we are testing , some creature comforts.
Adaway.apk
HKB.apk <--- hacker's keyboard
HKNDCTRU.apk <--- hacker's keyboard cyrillic/russian support
KernelAuditor.apk
NetworkDiscovery.apk <--- fairly useful network discovery app, find it on fdroid
NovaLauncher.apk
OpenCamera.apk
PicuriRam.apk
Quickpic.apk
Rebooter.apk
Superuser.apk <--- enable developer options and root access via that way first, then run supersu and update.
Terminal.apk < jackpal terminal
TotalCommander.apk
USB-Keyboard.apk
USBKB.apk < this one and the one above are the same app, i dun goofed.
Wifitoggle.apk
i am working a vanilla cm13 as well as my own custom build in the same turn, the custom utility in sbin is ccrypt, if you want to know how to use it, pm me and i'll give you a break down. do not use it to encrypt a block device !! single files only, and do not use a generated key, use a memorizable alpha-numeric password, else leave it alone.
m
@zacharias.maladroit WHAT HAPPENED TO PERRY !?!?!?!? :crying:
@moonbutt74
I'm sort of wiping the slate clean in several areas of my life - and that (unfortunately) was part of it :angel:
Hi,
It's been a while since I've been trying to increase the brightness of the LED, which unfortunately in our XZP is very low. I tried increasing the value of the file "flashed_calc_parameters.cfg" as in the picture, but I did not get any results. :crying:
Does anyone know how to help me?:victory:
Thanks.
I had the same thought last weekend and I tinkered around a little - without success...
In my Z5 Prem, this file was much more complex and I searched for any comparable values but found nothing.
the_brad said:
I had the same thought last weekend and I tinkered around a little - without success...
In my Z5 Prem, this file was much more complex and I searched for any comparable values but found nothing.
Click to expand...
Click to collapse
I do not understand why sony decided to lower the brightness in the top of the range. I had z5compact and had the same problem, while on m4 aqua the flash was perfectly in line with the other phones.
Nothing?
I mean the brightness of the torch...
Nobody can help me?
Maybe you have to mod kernel to increase current:
https://github.com/AndroPlus-org/an...ot/dts/qcom/msm8998-yoshino-common.dtsi#L3637
I'l try when I have time.
[EDIT]
Tried and didn't work...
AndroPlus said:
Maybe you have to mod kernel to increase current:
https://github.com/AndroPlus-org/an...ot/dts/qcom/msm8998-yoshino-common.dtsi#L3637
I'l try when I have time.
[EDIT]
Tried and didn't work...
Click to expand...
Click to collapse
Editing the file flashed_calc_parameters, I realized that this increases the brightness of the flash fording the photos ...
Now you got my curiosity again...
I tried several things and the most important one seems: The device even boots and the torch stays the same low brightness with an empty flashed_calc_parameters.cfg
I modded it using magisk and it's automount magic.
I also tried the old modded version of my Z5 Premium, which was modded the same way like your Z2 but again nothing.
the_brad said:
Now you got my curiosity again...
I tried several things and the most important one seems: The device even boots and the torch stays the same low brightness with an empty flashed_calc_parameters.cfg
I modded it using magisk and it's automount magic.
I also tried the old modded version of my Z5 Premium, which was modded the same way like your Z2 but again nothing.
Click to expand...
Click to collapse
I edit the file flashed_calc_parameters with "X-plore", granted permission writing, and now I entered the parameters as well as you can view. I think they are too high ... anyway I haven't noticed no difference, if not that of the brightness when shoot a picture with flash, in this case the intensity of the light is definitely increased. the problem is that to me interested only a flashlight ...
I can't find any solution please help me....
I'm still looking for...
Help ?
the torch is utterly pish. if you put a white page up on the screen and ramp up the screen brightness, you get a better flashlight then the one on the back. doesn't help for photos but it might help someone
dazza9075 said:
the torch is utterly pish. if you put a white page up on the screen and ramp up the screen brightness, you get a better flashlight then the one on the back. doesn't help for photos but it might help someone
Click to expand...
Click to collapse
I do not care about the photos, anyway Editing the file you'll have more brightness using flash for photos not for torch, But I often use the flashlight ... The problem is that this sony is really useless for the amount of light ...
AndroPlus said:
Maybe you have to mod kernel to increase current:
https://github.com/AndroPlus-org/an...ot/dts/qcom/msm8998-yoshino-common.dtsi#L3637
I'l try when I have time.
[EDIT]
Tried and didn't work...
Click to expand...
Click to collapse
Is this getting called as well?
https://github.com/AndroPlus-org/an...m/msm/camera_v2/sensor/flash/msm_flash.c#L335
pbarrette said:
Is this getting called as well?
https://github.com/AndroPlus-org/an...m/msm/camera_v2/sensor/flash/msm_flash.c#L335
Click to expand...
Click to collapse
I changed it to LED_FULL but it seems nothing changed...
https://drive.google.com/file/d/1f8BJYYh-srujpLPD8meIDpgol5MgVY_B/view?usp=sharing
AndroPlus said:
I changed it to LED_FULL but it seems nothing changed...
https://drive.google.com/file/d/1f8BJYYh-srujpLPD8meIDpgol5MgVY_B/view?usp=sharing
Click to expand...
Click to collapse
Note that I'm looking at the XZ1c files, because that's what I've got downloaded and extracted, but..
The problem appears to be in libcameralight.so itself.
The flashlight is calling on the function chip_vr_torch_turnon(), which takes no parameters and simply makes a call to chip_torch_set_current(25000).
The camera is instead setting the current first, then calling chip_torch_turnon() which uses the existing, hopefully pre-set, current value.
You can see there difference between the camera flash and the torch from logcat logs:
PHP:
adb logcat -b all | grep libcameralight
Camera Flash:
03-12 20:49:47.430 928 30064 D libcameralight: msm_flash_v2.cpp chip_torch_set_current: current 125000
03-12 20:49:47.430 928 30064 D libcameralight: msm_flash_v2.cpp chip_torch_turnon: start
Torch:
03-12 21:45:29.302 928 1524 D libcameralight: msm_flash_v2.cpp chip_vr_torch_turnon: start
03-12 21:45:29.302 928 1524 D libcameralight: msm_flash_v2.cpp chip_torch_set_current: current 25000
So the camera flash is pushing 125mA (125,000uA) to the LED, while the torch is only pushing 25mA.
Someone would have to shim the chip_vr_torch_turnon() function to read a parameter from a file or setting.
You could probably also hexedit the libcameralight.so files (lib and lib64), but that would have to be a static, non-user-configurable value.
Either would likely still require the mod in msm8998-yoshino-common.dtsi because it also appears to be doing sanity checks against the max brightness values configured in the kernel.
EDIT:
Now that I actually think about it a bit, those values of 125mA and 25mA have got to be wrong.
That's what logcat is reporting, but they have to be much higher than that because there's no way the flash LED is efficient enough to be putting out that much light at 25mA.
So there must be some additional mapping going on beyond what the function calls for to get to what the hardware is actually delivering to the LED.
Still, that mapping is irrelevant to the issue. Shimming the function or modding the libraries is still the only real way forward.
pbarrette said:
EDIT:
Now that I actually think about it a bit, those values of 125mA and 25mA have got to be wrong.
That's what logcat is reporting, but they have to be much higher than that because there's no way the flash LED is efficient enough to be putting out that much light at 25mA.
So there must be some additional mapping going on beyond what the function calls for to get to what the hardware is actually delivering to the LED.
Still, that mapping is irrelevant to the issue. Shimming the function or modding the libraries is still the only real way forward.
Click to expand...
Click to collapse
Nah, that looks about right. The LED is not that bright in Torch mode, you can get better brightness from those cheap button cell torches.
LEDs nowadays are pretty darn efficient.
Looks like you are on the right track for this!
Ok,
So here's a hex-edited mod for the vendor/lib/libcameralight.so and vendor/lib64/libcameralight.so files that changes the call to the chip_torch_set_current() function from chip_torch_set_current(25000) to chip_torch_set_current(65535).
That's the highest value I can do without a shim (or better knowledge of ARM assembly) because the x32 version of the library is using a MOV function to stuff a register with a 16-bit value (0xFFFF).
Standard disclaimer applies: This could literally, physically break your phone.
pbarrette said:
Ok,
So here's a hex-edited mod for the vendor/lib/libcameralight.so and vendor/lib64/libcameralight.so files that changes the call to the chip_torch_set_current() function from chip_torch_set_current(25000) to chip_torch_set_current(65535).
That's the highest value I can do without a shim (or better knowledge of ARM assembly) because the x32 version of the library is using a MOV function to stuff a register with a 16-bit value (0xFFFF).
Standard disclaimer applies: This could literally, physically break your phone.
Click to expand...
Click to collapse
ok pbarrette
i will try it @night
hope it works
edit: working. torch is better led light is brighter now
pbarrette said:
Ok,
So here's a hex-edited mod for the vendor/lib/libcameralight.so and vendor/lib64/libcameralight.so files that changes the call to the chip_torch_set_current() function from chip_torch_set_current(25000) to chip_torch_set_current(65535).
That's the highest value I can do without a shim (or better knowledge of ARM assembly) because the x32 version of the library is using a MOV function to stuff a register with a 16-bit value (0xFFFF).
Standard disclaimer applies: This could literally, physically break your phone.
Click to expand...
Click to collapse
Wow that's really cool ?. It works great... You're super.
Thanks.