Just wanted to let you guys know I got some kernel modules up for testing. These are unverified on nook tablet. So far reports are that "0.1 modules" with top frequency manipulation only work pretty flawlessly on devices tested. "0.2 modules" with top frequency and voltage manipulation, seem to work on Motorola Droid RAZR & Droid 3. Motorola Bionic & Atrix 2 don't like voltage manipulation at this point. I need beta testers.
opptimizer.googlecode.com
More info can be found and the original thread on RootzWiki:
http://rootzwiki.com/topic/14511-op...g-kernel-modulesofficial-thread/page__st__200
I downloaded and installed this. I ran linpack a few times and had a moderate jump in scores. I have not been able to play with it much more, however. I can do some more testing too.
Thank u for this post. I had been asking this question in a few other threads and people were naysaying that it couldn't be done. Im glad to see that I was on the right track.
Any idea on how to make if persistent? All is lost on reboot, however works well with setcpu. No noticeable battery drain or heat in beta 0.2 with 1200000000 1388000. Linpsck 57, Antutu 5390. Excellent discovery! Anything. Above 1200mhz is not stable and may crash. I had one crash the tablet froze; held down the power button 10 seconds to power off and then reboot.
Works very well. A permanent solution would be great.
Sent from my Nook Tablet using XDA Premium App
You need init.d to run at startup. There is a thread on how to get init.d scripts working here:
http://forum.xda-developers.com/showthread.php?t=1390093
You don't need all the build.prop stuff to overclock, just the init.d support at the top.
I have a post on where the file should be put, and what it should look like here:
http://rootzwiki.com/topic/14511-op...g-kernel-modulesofficial-thread/page__st__190
The init script was created by frostincredible for running at boot on Motorola Droid Bionic. His thread is here:
http://rootzwiki.com/topic/14698-in...or-tekahunas-omap4-overclock-modules-1-10-12/
Using the last link in your post, here is what I found to have the Nook Tablet boot persistently into the desired overclocking speed.
1. Extract the init.d folder from the init scripts created by frostincredible and using ES File Explorer, copy to /system/etc directory
2. Download tekahuna version 1.0 files, (symsearch.ko and opptimizer.ko) and extract and copy them to /system/lib/modules directory. Create the modules directory if it does not exist.
3. Reboot and use Rom Tool or Setcpu for your desired CPU speed. I'm using 1.2GHZ on the Nook Tablet. I did try to flash the files using CWM, however the system partition identified in the zip file is not correct for the Nook Tablet.
4. I thank everyone involved for their work on this as this mod really perks up the Nook Tablet. See my previous post above on the new benchmarks at 1.2GHZ.
UPDATE I broke the persistence and caught He** trying to figure out what I did wrong. A step not mentioned above requires you to edit clrbootcount.sh located in /system/bin. You must add the init.d code below to end of the code in the file. From that point forward the tablet will boot at the script speed you have placed in /system/etc/init.d. I do not recommend anything above 1200. Set permissions on clrbootcount.sh to rwxrwxrwx. You can shrink the permissions once you get it running.
bb=/system/xbin/busybox
if [ -f $bb ]; then
/system/bin/logwrapper $bb run-parts /system/etc/init.d
else
for i in $(ls /system/etc/init.d/*); do
sh $1
done
fi
rapcon said:
Using the last link in your post, here is what I found to have the Nook Tablet boot persistently into the desired overclocking speed.
1. Extract the init.d folder from the init scripts created by frostincredible and using ES File Explorer, copy to /system/etc directory
2. Download tekahuna version 1.0 files, (symsearch.ko and opptimizer.ko) and extract and copy them to /system/lib/modules directory. Create the modules directory if it does not exist.
3. Reboot and use Rom Tool or Setcpu for your desired CPU speed. I'm using 1.2GHZ on the Nook Tablet. I did try to flash the files using CWM, however the system partition identified in the zip file is not correct for the Nook Tablet.
4. I thank everyone involved for their work on this as this mod really perks up the Nook Tablet. See my previous post above on the new benchmarks at 1.2GHZ.
Click to expand...
Click to collapse
I followed instructions using the1200 package, but setcpu and rom toolbox still show 1008 max frequency. What else can I be missing?
I had this problem and I can only suggest the following:
*Ensure you are using version 1.0 of the kernel modules
*check all permissions on the init.d folder in /system/etc and /system/lib/modules
If all goes well after the reboot, the tablet should be reporting 1200 in the Rom Toolbox CPU panel.
Version 2 of the kernel modules allow for voltage manipulation and the scripts in the init.d directory are not written to take advantage of that and therefore will not run. The scripts can be modified however.
rapcon said:
I had this problem and I can only suggest the following:
*Ensure you are using version 1.0 of the kernel modules
*check all permissions on the init.d folder in /system/etc and /system/lib/modules
If all goes well after the reboot, the tablet should be reporting 1200 in the Rom Toolbox CPU panel.
Version 2 of the kernel modules allow for voltage manipulation and the scripts in the init.d directory are not written to take advantage of that and therefore will not run. The scripts can be modified however.
Click to expand...
Click to collapse
It runs great from the command line, but the init.d fix isn't working for me. I've set all permissions to 777. I'll have to fiddle around with it some more. I'm running at 1.2GHZ until I reboot.
I actually didn't get mine to stick at boot until i set the permissions on the file in the init.d folder (00cpufreq_modules) to rwxr--r--. I believe thats what did the trick for me. (I had it at rw-r--r-- before).
Can we OC the GPU as well? Thanks
Awesome, it works and it does seem snappier. I also couldn't get it to stick at boot, but I made the /system/lib/modules/*.ko files with full permissions (777 I think?) The rest of it, the init.d file, the 0.1 files, etc are all as posted. What did people set the .ko files permissions as?
UPDATE:
Tried it with rwxr--r-- and rw-r--r-- on both the ko files as well. Still didnt stick at boot. Also then tried to make a script in Rom Toolbox to run, and it said it ran successfully, but didn't show any change when I checked it (still at 1008). Using Rom Toolbox because SetCPU wouldn't install btw. And Script Manager just hangs and force closes after a while.
Any ideas?
I'm all for development and "lets see what this puppy can do" but I have to ask - Isn't this puppy fast enough? How fast do you want it? Any faster and it would be answering the questions before your asked.
It's a dual core. It's just a question of how much you want out of it, same as the Nook Color before it. I'm 100% behind overclocking because of the principle - if it's possible, why not?
neoage said:
It's a dual core. It's just a question of how much you want out of it, same as the Nook Color before it. I'm 100% behind overclocking because of the principle - if it's possible, why not?
Click to expand...
Click to collapse
My only thought is, how much actual difference would it make? Will things run smoother? Will graphics be sharper, flow more easily?
Sent from my rooted Nook Tablet using Tapatalk 8)
What about if you find out you can have 2x1.2Ghz without any battery penalty or thermal problems?
rapcon said:
UPDATE I broke the persistence and caught He** trying to figure out what I did wrong. A step not mentioned above requires you to edit clrbootcount.sh located in /system/bin. You must add the init.d code below to end of the code in the file. From that point forward the tablet will boot at the script speed you have placed in /system/etc/init.d. I do not recommend anything above 1200. Set permissions on clrbootcount.sh to rwxrwxrwx. You can shrink the permissions once you get it running.
bb=/system/xbin/busybox
if [ -f $bb ]; then
/system/bin/logwrapper $bb run-parts /system/etc/init.d
else
for i in $(ls /system/etc/init.d/*); do
sh $1
done
fi
Click to expand...
Click to collapse
...I haven't tried this, but looking at this script I'm wonderingif the "sh $1" should really be "sh $i" ...this should make it run all init.d scripts if busybox is not installed at the expected location.
(As it was written it will instead try to execute $1 which is probably the first argument passed to the clrbootcount.sh script unless otherwise defined in the script... without my suggested change the for loop doesn't do anything with the init.d scripts)
I hope the project's going well! Took a look at the rootzwiki site and saw how it was going for the other devices...Just wondering if it's still happening for the Nook Tablet, since CM7 is right around the corner...
neoage said:
I hope the project's going well! Took a look at the rootzwiki site and saw how it was going for the other devices...Just wondering if it's still happening for the Nook Tablet, since CM7 is right around the corner...
Click to expand...
Click to collapse
Cm7 is OUT mh friend, and its AWESOME
Sent from my CM7 Nook Tablet
Related
DROID X2 init.d hack
This is an alternative to a certain 2nd init functionality, because with 2nd init you could do this just as easily if you know how. This is not an init. This is for the folks running stock 2.3.3 for the Droid X2, who want to "performance tune" their phone while working with what they have. This will allow you to use any init.d performance scripts on your phone. If you don't know, an "init.d" script is special in the sense that they are run when the phone is booting up. This way, when you are using your phone, you can enjoy performance benefits.
The "hack" runs the BusyBox "run-parts" binary and searches the /system/etc/init.d directory for scripts. Additionally, if for whatever reason you don't have BusyBox, it will fall back to a for loop and run that instead! This functionality is added through "install-recovery.sh" script in /system/etc which is run every time the phone boots by default. Normally this script tries to install the default recovery every time you boot your phone, so that you can't install any other recovery. I've hijacked that script for the init.d task instead. As is common practice, any script actions can be viewed in your logcat upon boot if you have USB debugging enabled.
This hack includes default enhancement scripts (outlined below). You can choose to use these scripts, or delete them and replace them with whatever you want. I would advise against running the default scripts with other tweak scripts!
Requirements:
Root - follow the guides
Bootstrap Recovery - follow the guides
Knowledge of CWMR/Bootstrap Recovery use, and how to install a zip with it
Default Enhancements:
sysctl tweaks - try to speed up OS/virtual machine/kernel
lowmem tweaks - try to limit low memory so as to keep more memory available
sd read ahead - increase KB read ahead on SD reads
cpu/governor tweaks - set scaling_min/max_freq and governor
disk scheduler - optimize disk scheduler for flash memory across all blocks
---
Changelog
0.1
Initial release to public
0.2
Tweaked scheduler and send errors to null
0.3
Fixed scheduler bug
Added additional scheduler tweaks
Changed min_free_kbytes to 32mb
Changed bdi read_ahead_kb to 2048kb
Added system r/w mount
Added sync
0.4
Added quantum to scheduler tweak
Switch to noop scheduler
Added conditionals
Change CPU tweak to support cpu1
Change scaling_min to proper freq
0.5
Split script into 3 versions
Battery - most power savings
Midrange - balanced power savings/performance
Performance - all out speed
0.6
Combined script back into one generic version
Includes separate scripts for all purposes
Enhances prior scripts functionality
Rewrote init.d hook to work in all scenarios
Included BusyBox 1.19 with installation
0.6b
Updated script to fix unique error
---
Version 0.6b FINAL
Download: http://www.multiupload.com/FI1D93TV6Y
Mirror: http://www.mediafire.com/?71geufr3754j6be
amazing! should usher in a ton more dev for the X2
Great to hear from you again navenedrob! Loved your work on the fascinate.
Sent from my DROID X2 using XDA Premium App
Will this have any ill effects with the eclipse rom?
Sent from my DROID X2 using XDA App
Its for stock roms as stated in the 1st post
Sent from my DROID X2 using XDA App
Getting ready to run this but just want to clarify:
Install like any other. zip?
Use script manager to tweak values?
How to revert, if necessary?
Remove v6 supercharger before installing?
Thanks again.
Sent from my DROID X2 using XDA Premium App
garywojdan81 said:
Getting ready to run this but just want to clarify:
Install like any other. zip?
Use script manager to tweak values?
How to revert, if necessary?
Remove v6 supercharger before installing?
Thanks again.
Sent from my DROID X2 using XDA Premium App
Click to expand...
Click to collapse
Yes
Yes
Delete scripts from /system/etc/init.d, that's it
Optional
Kanibull said:
Its for stock roms as stated in the 1st post
Sent from my DROID X2 using XDA App
Click to expand...
Click to collapse
You can use this on Eclipse ROM. That is a stock ROM. A non-stock ROM would be a stock ROM with this or 2nd init already included, CM7, or MIUI.
Thanks man. Gonna load it as soon as I get back home.
Sent from my DROID X2 using XDA Premium App
Would using this allow zepplelinrox's 98kickasskernel to work as it should?
So are these scripts already optimized or are they stock values waiting to be tweaked? Is there some kind of guide as to exactly what the numbers mean or could you recommend some? Thanks!
Sent from my DROID X2 using XDA App
ashclepdia said:
Would using this allow zepplelinrox's 98kickasskernel to work as it should?
Click to expand...
Click to collapse
Wow, yeah it should indeed.
This should be posted at droidforums and droidxforums!
I have a few questions.
Using Script Manager I had to modify/change most of my scripts because Script Manager would try to run them and simply state there were syntax errors, which was simply not the case because on my oringial droid I could verify they would run using init.d and they would work.
So my question there is what's with the syntax error in script manager, and will my original scripts work? Second, are these automatically run as root...or?
zeppelinrox said:
Wow, yeah it should indeed.
This should be posted at droidforums and droidxforums!
Click to expand...
Click to collapse
If it hasn't already been done by the time im done eating ill get to linking up to share the goodness. Thanks for quick reply zepp.
Good stuff...
I know for a fact that they will be all over this like brown on poo at droidx...
0vermind said:
I have a few questions.
Using Script Manager I had to modify/change most of my scripts because Script Manager would try to run them and simply state there were syntax errors, which was simply not the case because on my oringial droid I could verify they would run using init.d and they would work.
So my question there is what's with the syntax error in script manager, and will my original scripts work? Second, are these automatically run as root...or?
Click to expand...
Click to collapse
Which busybox version?
That Rom you where talking about
What kind of Rom would it be, would be an aosp?
zeppelinrox said:
Which busybox version?
Click to expand...
Click to collapse
v1.19.0.git.adrynalyne
Installed in /system/xbin
0vermind said:
I have a few questions.
Using Script Manager I had to modify/change most of my scripts because Script Manager would try to run them and simply state there were syntax errors, which was simply not the case because on my oringial droid I could verify they would run using init.d and they would work.
So my question there is what's with the syntax error in script manager, and will my original scripts work? Second, are these automatically run as root...or?
Click to expand...
Click to collapse
I'm not sure what Script Manager is, so I can't really answer. All I can say is that I write all my scripts by hand, and they are all common shell scripts using bash language. As long as your shell scripts are written according to those specs, then I don't think you'd have any problems.
Anyone else, remember that you can use whatever init.d scripts you want, it shouldn't really matter as long as they somewhat pertain to the phone. Feel free to delete the included scripts.
Okay I set it all up and none of the scripts ran, so I did
Code:
/system/xbin/run-parts /system/etc/init.d > /data/initd.log
in adb and got back
run-parts: applet not found
Click to expand...
Click to collapse
What am I doing wrong?
After many hours of screwing around, I figured out how to get around your busybox run-parts thing which doesn't seem to be working on my phone. In it's place I put:
Code:
if [ -e /system/etc/init.d ]
list=`ls /system/etc/init.d/*`
for script in $list
do
sh $script
done
fi
Everything is working awesome now!! They really do seem to be running at start up!
So, this doubles as a root kernel (might as well keep the scripts in there since I already made 'em!), custom boot animations (/system/media/sanim.zip), init.d support.
Max speed is 1.94GHz. Max speed I've benchmarked stable at is 1.83GHz. Reboots at higher.. YMMV with voltage adjustments etc.
Stock speed on this kernel is 1566MHz, I have removed a lot of scaling overrides that Samsung added, so this should be a bit smoother than the stock kernel without OCing more than the slight default.
GPU is also OC'ed from 3d speed 266 -> 300 and 2d speed 200 -> 266.
I will be releasing a GUI soon with more advanced tweaking options for the kernel (it is compatible with existing tools like system tuner, fauxclock, setcpu, etc.)
Version 0.2 CWM Zip: http://m-s-j.net/dagnarf/cwm-sgh-i717-dagkernel-oc-v0.2.zip
Version 0.2 CWM Zip (with KALLSYMS + KALLSYMS_ALL for debugging) http://m-s-j.net/dagnarf/cwm-sgh-i717-dagkernel-oc-v0.2-kallsyms.zip
Version 0.2 CWM Zip (No root script, su, busybox in ramdisk) http://m-s-j.net/dagnarf/cwm-sgh-i717-dagkernel-oc-v0.2-nosubusybox.zip
New stuffs:
* BLN Support (Use BLN Control from market)
* XZ Compression
* CFQ Scheduler
* New CPUFreq governors: smartassv2, lagfree
Code:
CWM Zip 0.1 [url=http://m-s-j.net/dagnarf/cwm-sgh-i717-dagkernel-oc.zip]Available here[/url]
Odin Tar 0.1 [url=http://m-s-j.net/dagnarf/pda-overclocked-dagkernel-v01.tar]here[/url]
Modified libraries 0.1 [url=http://m-s-j.net/dagnarf/modded-libs.tar.gz]here[/url].
Stock CWM zip (Stock Kernel and Libraries) Available here
CWM Flashing Instructions:
CWM Install Instructions said:
1.) Install CWM from http://forum.xda-developers.com/showthread.php?t=1517134
2.) Copy the cwm zip to your /sdcard/
2.) Reboot into CWM either by issuing "adb reboot recovery" from command line, or loading ROM Manager app and choosing "Reboot into recovery", or by powering the device off and holding vol up+vol down and powering on.
3.) From CWM, choose "install zip from internal sd card" then navigate to the cwm zip you copied in, select it
4.) Select "reboot system"
Click to expand...
Click to collapse
Souce code available at: https://github.com/dagnarf/sgh-i717-dagkernel
Don't forget the donate link in my sig if you find this useful
Excellent work as always!
Sent from my SGH-I717R using XDA App
You're on a roll. Thanks so much for your work!
wow so fast!
Da_G said:
So, this doubles as a root kernel (might as well keep the scripts in there since I already made 'em!)
Max speed is 1.94GHz. Max speed I've benchmarked stable at is 1.83GHz. Reboots at higher.. YMMV with voltage adjustments etc.
Stock speed on this kernel is 1566MHz, I have removed a lot of scaling overrides that Samsung added, so this should be a bit smoother than the stock kernel without OCing more than the slight default.
GPU is also OC'ed from 3d speed 266 -> 300 and 2d speed 200 -> 266.
I will be releasing a GUI soon with more advanced tweaking options for the kernel (it is compatible with existing tools like system tuner, fauxclock, setcpu, etc.)
You can find the Odin tar here, follow the flashing directions from my Root kernel here
You will need modified libraries to take full advantage of this kernel as they override speeds at times, you can find these here.
You'll have to push them over adb for now after flashing the kernel, when CWM is up I will make a CWM zip for it.
From the directory with adb and the three .so files:
Code:
adb remount
adb push libhardware_legacy.so /system/lib/
adb push librpc.so /system/lib/
adb push libandroid_runtime.so /system/lib/
adb shell chmod 0644 /system/lib/libhardware_legacy.so
adb shell chmod 0644 /system/lib/librpc.so
adb shell chmod 0644 /system/lib/libandroid_runtime.so
adb reboot
Souce code available at: https://github.com/dagnarf/sgh-i717-dagkernel
Click to expand...
Click to collapse
straight fire... phone's not even officially released and everything needed for awesomeness is available.
Da_G said:
You will need modified libraries to take full advantage of this kernel as they override speeds at times, you can find these here.
You'll have to push them over adb for now after flashing the kernel, when CWM is up I will make a CWM zip for it.
From the directory with adb and the three .so files:
Click to expand...
Click to collapse
are the .so files located in the boot.img file? Or am I missing them somewhere in the .tar file?
Thanks for all your hard work.
You are a beast man.
I havent aquired a note yet but i am curios...CIQ present? it is one of the things I failed to check for when I had one in hand
Sent from my SGH-T989 using XDA App
00mred00 said:
You are a beast man.
I havent aquired a note yet but i am curios...CIQ present? it is one of the things I failed to check for when I had one in hand
Sent from my SGH-T989 using XDA App
Click to expand...
Click to collapse
Doesn't look like it.
Da_G said:
Don't forget the donate link in my sig if you find this useful
Click to expand...
Click to collapse
I actually haven't found this useful as I have to wait until the morning to get my phone at bestbuy but I have faith. Hopefully this gets you some more gogo juice. Thank you for your dedication!
69360830PL846881R
AllTheWay said:
are the .so files located in the boot.img file? Or am I missing them somewhere in the .tar file?
Thanks for all your hard work.
Click to expand...
Click to collapse
http://m-s-j.net/dagnarf/modded-libs.tar.gz
breakingspell said:
http://m-s-j.net/dagnarf/modded-libs.tar.gz
Click to expand...
Click to collapse
Thank you sir.
Flashed, libs pushed, and ready to roll! Woot woot! I'm so glad that i got my phone a day before most everyone else, muahahaha!
EDIT: HOLY CRAP ON A STICK. I laugh at the Engadget review that told us the Quadrant score was lower than the International model. This was at 1.83ghz, performance scaling.
I use on-demand governor, also 1.83Ghz. Hope this doesnt rape battery. Would be nice to have some static undervolting or even better - HAVS. SBC for the battery could be awesome too (am I getting greedy? lol)
How is your Quads 3900...
Posted using AT&T Samsung Galaxy Note
No love for roger's ??
Sent from my GT-I9000 using xda premium
Also no Undervolting shows on this kernel take it as its not enabled yet?
Posted using AT&T Samsung Galaxy Note
How nice, these scores are the same or better than int version most with custom roms and kernal. Good job man
Sent from my INFUSE powered by ZEUS
Nobody out there with some Rogers talent lol
So nice to see high scores with just minor adjustments. I get near 4k on quadrant now.
Seems like it charges a little quicker or is it my imagination?
Sent from my GT-I9100 using xda premium
This should be applicable to any ROM on devices which share internal storage for applications and the internal "sdcard" (Note II, SGS3, probably others). Symptoms may include inability to take screenshots and other failures, and will usually show a "Permission denied" in logcat for files under /data/media/. The underlying problem is that permission is denied to the filesystem, even by the root user when the ROM is booted (this is strange and I still don't understand why). Running "Fix permissions" did not fix this issue for me (that script doesn't change any permissions on the sdcard).
When booted into recovery (ClockworkMod was tested in my case), root has the ability to reset the permissions properly. To fix the problem, connect with adb while booted in recovery and run the following commands to correct the permissions:
Code:
chown -R media_rw:media_rw /data/media/
find /data/media/ -type d -exec chmod 775 {} ';'
find /data/media/ -type f -exec chmod 664 {} ';'
UPDATE (Credit to @Quinny899) If that does not work, you may also want to reset the SELinux contexts for the media partition with this command:
Code:
restorecon -FR /data/media/
Hope this helps! :victory:
I recently restored a Nandroid backup of my old Nexus 7 on a replacement Nexus 7. Most everything worked okay, but screenshots, deleting certain files and directories, and other basic operations weren't really working, and "Fix permissions" didn't help.
Running the commands here worked like a charm! I used TWRP and I have JellyBeer 4 on my Nexus 7. Thanks!
skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!
xak944 said:
skoshy,
I'm glad this helped you. JellyBeer is a fantastic ROM. Cheers!
Click to expand...
Click to collapse
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!
Yeah it's kinda funny. I had that script posted up in the ADBsync thread back in February because I noticed things could start acting funny when I restored an entire sdcard backup to one of my devices. But hey, great minds think alike! Good work all around!
Thanks @TheByteSmasher for bringing another use for the zip to my attention! I didn't know those things had a tendency to go awry on their own as well!
Edit:
Here's the edify script equivalent of the above, plus the proper original perms for /data/media itself, and the special perms that CWM likes its subfolder to have (root + all). TWRP keeps its backups under the primary user subfolder (/data/media/0) and doesn't seem to care as much.
cwm-sdcard.Fix.Permissions.zip/META-INF/com/google/android/updater-script:
Code:
ui_print("");
ui_print("sdcard Fix Permissions Script");
ui_print("by osm0sis @ xda-developers");
show_progress(1.34, 0);
ui_print("");
ui_print("Mounting...");
run_program("/sbin/busybox", "mount", "/data");
set_progress(0.2);
ui_print("");
ui_print("Setting /data/media to media_rw and fixing...");
set_perm_recursive(1023, 1023, 0775, 0664, "/data/media");
set_perm(1023, 1023, 0770, "/data/media");
set_progress(0.8);
ui_print("");
ui_print("Setting /data/media/clockworkmod perms...");
set_perm_recursive(0, 0, 0775, 0777, "/data/media/clockworkmod");
set_progress(1.0);
ui_print("");
ui_print("Unmounting...");
unmount("/data");
set_progress(1.2);
ui_print("");
ui_print("Done!");
set_progress(1.34);
Available over in my Odds and Ends thread as TheByteSmasher mentioned before.
Nice. Good to know this is a well known issue, I thought I was nearly alone (and it drove me up the wall for a while until I figured it out).
Does anyone know what is technically causing even the root user not to be able to write? I'm curious.
Probably because even root apps only run root commands when they need to, so for simple stuff could run into the same issue. Just a guess, but makes sense.
I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').
xak944 said:
I'm not talking about root apps. When I had the issue I couldn't modify any files with a shell over adb as the root user. Write operations always resulted in 'permission denied' errors. Generally in Linux, the only way this can occur is with filesystem permissions (root user bypasses this), the immutable bit (not set), or if it's a read-only filesystem (didn't appear to be based on the output of 'mount').
Click to expand...
Click to collapse
Osm0sis actually states in the description of his zip, that when you use ADB push to put some stuff on the SD it can mess with the permissions... that's what did it for me.. but I guess a nandroid restore can cause it too depending on how it performs the action.
Sent from my Nexus 4 using Tapatalk 4 Beta
I'm ditching the idea of editing fix_permissions. The way they do all the system files is extremely intelligent and done on-the-fly based on the contents of certain system files to trace through. Adding something specifically for internal sdcards, even with the appropriate checks, would be a hack compared to all the really great work they've done to make the script device-nonspecific.
Deleted
1990mustafa said:
Deleted
Click to expand...
Click to collapse
Could somebody point me in the direction of how to do this for the Note 3 SM-9005 please?
I have an internal SD permissions issue and the flashable zip doesn't work, I presume because the directories are located slightly differently.
Many thanks
i m also stuck in same boat as none of scripts work for note 3... need some help / guidance here ..
You saved me, i was playing with ubuntu touch and i forgot that symbolic links and chown always modify the original directory and twrp could not fix the permissions!
Thank you! Works like a charm! :highfive:
Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
[email protected] said:
use for fixing access
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Worked a dream, might be useful for anyone else
Quinny899 said:
Following using this, I found that the internal SD wouldn't be mounted
Googling the logcat output's lines, I found this, specifically:
Worked a dream, might be useful for anyone else
Click to expand...
Click to collapse
worked perfectly!
Hey, big THANKS to everyone who contributed to this thread. I restored by SD a different way than I used to do it and had this issue. I figured it was a permissions issue but couldn't get the 'Fix Permissions' function in TWRP or ROM Manager to fix it (now I know why). This saved me, much appreciated!
Quinny899 said:
Code:
su
restorecon -FR /data/media/0
Click to expand...
Click to collapse
Oh man, so it was SELinux causing these issues all along!? I wonder why my original fix worked then since it didn't reset the SELinux context... Oh well, good to know.
Thanks @TheByteSmasher for leading me to the right solution
TheByteSmasher said:
Well, I created a ZIP of this for people to flash in Recovery, ADB sideload or in an App like Fashify... Only to realize that XDA superstar @osm0sis had already done pretty much the same thing with his sdcard Fix Permissions Script Found here. His script uses pure edify whereas mine uses linux commands.. Both work but his Was First so I will only leave the link for his.
Cheers!
Click to expand...
Click to collapse
Thanks again
osm0sis said:
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc.
General Information
In a nutshell, I just wanted a single thread to gather links to some of my other, larger projects, but also serve as a spot I could put some smaller scripts and zips I've created that I don't think merrit their own separate threads. This is partially for my own sanity and will hopefully make it easier for others to find some things as well. A lot of the stuff here was developed with the GN or N7 (my devices) and Windows in mind, but could generally be applicable to most devices either out-of-the-box or with some slight modification. If you see something that inspires you, go ahead and mod it, just let me know and give me some credit somewhere. If anyone would like to know the specifics of what's in a particular script that I haven't already linked to more information on, just let me know and I'll post that in here as well. Thanks!
Misc./Batch Tools
AnyKernel 2.0 (many devices) - link
AnyKernel was a simple template for an update.zip that could apply any kernel to any ROM, regardless of ramdisk to reduce the chance of any issues arising from the custom kernel pairing. The drawback to this is that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. AnyKernel 2.0 pushes the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables to customize the install experience.
Android Image Kitchen (many devices) - link
A collection of Windows/Android ports of the necessary Linux utilities for Android image (kernel+recovery) mod work, and my own automation script to unpack, edit and repack the ramdisk. Other guides/scripts exist but none of them are universal for target device, compression and/or developed for Windows/Android. Now also Linux builds to bring my improved featureset back to where it came from. Has been extremely useful for me in my messing around with kernel ramdisks.
ADB Screenshot (all devices) - attached
Take screenshots while in recovery. Useful for development of recovery apps or error reporting. Original method had lots of different threads around with the general method for various devices but I figured out a couple tricks required for getting it working on the Galaxy Nexus and then automated the process. Tested and confirmed working with both pixel formats of CWM and TWRP. More information in this GN Q&A FFmpeg thread. New method uses fb2png and should work on all devices.
ADBsync sdcard Backup (many devices) - attached
Backs up the entire sdcard so that you can have a complete snapshot of your device when you make periodic backups, and be able to restore things exactly as they were. Automates the sync process of Renate NST's great ADBsync utility which makes only newer files get pulled, significantly decreasing backup time for the sdcard compared to "adb pull". Original version posted in the old ADBsync thread. Defaults for devices with /data/media/ internal sdcards (Nexus devices, etc.), but is easily customizable to backup other mountpoints.
Flashable Zips
Nexus BootUnlocker script (GN, N4, N5, N7 '13, N10) - attached
I don't know about everyone else but sometimes I find I've rebooted into the bootloader only to realize I've forgotten to unlock it in segv11's excellent BootUnlocker App beforehand. Well, I decided to make a BootUnlocker Script for my Galaxy Nexus so I could just boot to recovery quickly, unlock, then adb reboot-bootloader (or use my Reboot To Bootloader script below) to get back without having to fully boot the OS to make the change. Also extremely useful in the case you aren't able to boot. As with the app there is no data loss like there would be with fastboot, allowing you to relock for safety. Originally posted in the GN EDIFY Scripting thread. Modified for the newer Nexus devices and combined into a single Nexus BootUnlocker zip with tamperbit reset support added using information from the BootUnlocker App Dev thread.
N7 BootUnlocker script (N7 '12) [creation guide] - link
The Nexus 7 2012 is a special case. Per-device encryption of an entire partition makes it impossible to support the N7 '12 in a simple root app, or flashable zip as above, however using my guide and included script you can now create a working BootUnlocker Script Zip for your specific device. As with the above scripts there is no data loss like there would be with fastboot, allowing you to relock for safety.
Flashify script (many devices) - attached
This script zip makes flashing boot.img (kernel), recovery.img, and radio.img/modem.img (baseband) files via recovery simple. Inspired by cgollner's powerful and visually stunning Flashify App, it aims to save the average user the hassle of repacking their own image zip, or using the command-line or fastboot to flash it. Place an appropriately named file in the same directory as the zip and flash away! Should work on all emmc devices with normal partition naming ("boot", "recovery" and "radio" or "modem") which accept Android standards-compliant images. Extremely handy when used with amarullz' brilliant AROMA Filemanager, and/or my Android Image Kitchen: Mobile Edition (linked above).
Kernel Emergency Reset script (many devices) - link
Basically a go-to cure-all for custom kernel users experiencing issues after an upgrade due to old settings left over in a kernel control app (eg. franco.Kernel updater, Trickster, etc.), or problematic init.d/userinit.d scripts. It's also useful if you just want to make sure you're running clean defaults without conflicts.
Reboot To Bootloader script (all devices) - attached
Those who prefer using CWM may have noticed a couple of things missing that the other popular custom recovery, TWRP, has built-in. One of these is a file explorer/manager, which is answered by amarullz' brilliant AROMA Filemanager. Another thing I found myself wanting is a way to reboot back to the bootloader once I'm in recovery, so I created this very very simple flashable zip script. (No longer required on CWM >=6.0.3.5). Note: Once in the bootloader, "Start" will boot you back to recovery. Not sure why, but it's not a big deal, just reboot normally from recovery at that point.
sdcard Fix Permissions script (many devices) - attached
A little flashable zip script to fix ownership and permissions of files and directories on the sdcard to what they would be if Android OS had put them there itself, since some apps can't access pushed files that have root.root as owner/group. This is useful when restoring to your sdcard backup, as with my ADBsync sdcard Backup batch script above, since generally, pushed files get root.root from adb shell and higher permissions than usual. Also a solution for a bug where sdcard files get lower permissions somehow, resulting in similar access problems. Currently written for devices with /data/media/ internal sdcards (Nexus devices, etc.), but could easily be modified for other mountpoints.
nano Terminal Editor v2.2.6 Installer (all devices) - attached
A simple installer to push bgcngm's great Android port of the nano editor binary to /system/xbin/ along with the required files in /system/etc/terminfo/. It can then be used from Terminal while booted from that point on. Each time you flash it also temporarily enables use in recovery by pushing a script to /sbin/nano with the required environment variables, so you can then trigger it from recovery shell or the console in amarullz' brilliant AROMA Filemanager. Makes it extremely easy and worry-free to tweak and mod on the go, knowing you can edit the faulty build.prop or init.d script if something goes wrong. This script could also be added to recovery to make the functionality permanent.
odex Script Installer (all devices) - attached
Based on the great work and binaries from this thread, a simple installer to push my odex script along with the required dexopt-wrapper and zip binaries to /system/xbin and set the appropriate permissions. Automates the procedure to odex any apk or jar from the commandline to potentially improve performance. Dalvik runtime only. Also uses cut from busybox.
Kernel init.d Support Injector (many devices) - attached
Following from great ideas by Captain_Throwback in my AnyKernel2 thread and using script from my Flashify script above, this AK2 zip will inject basic init.d bootscript support into any kernel ramdisk on any emmc device with normal partition naming and using the Android bootable image standard, without having to bloat a ramdisk using a busybox binary. This zip is also signed, so could potentially be used with stock recovery on a locked bootloader, but that depends on the stock recovery supporting grep, etc. for the zip script to perform the required file changes.
Dev Team init.d Pack Installer (all devices) [see "950iosettings, etc." below] - link
A simple installer I wrote to create the /system/etc/init.d/ directory, extract the latest init.d scripts as published by the "Franco's Dev Team" tuning collective (of which I'm a member), then set correct owner, group and permissions to the entire init.d directory. Link points to my Dev-Host since these may still be subject to change from time to time. If you are a developer and would like to include these tunables/scripts in your kernel or ROM please provide credit. A lot of time and effort has gone into this project and that's all we ask.
Credits & Thanks: All authors of any included binaries and libraries for their amazing work. Anyone who's helped me with these projects along the way.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
XDA:DevDB Information
osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc., Tool/Utility for the Android General
Contributors
osm0sis
Version Information
Status: Stable
Created 2013-11-13
Last Updated 2015-03-30
Click to expand...
Click to collapse
Tried every method...but I'm unable you protect my backups in titanium backup
To protect*
How I solved this problem on my Moto G LTE
Shantanu Baviskar said:
Tried every method...but I'm unable you protect my backups in titanium backup
Click to expand...
Click to collapse
I carefully read this thread: [Help] Titanium Backup PRO - protected archive not working.
So I modified file /system/etc/permissions/platform.xml according http://jrummy-apps.com/fix-sdcard-on-kitkat/ and make new file /data/local/userinit.sh with this content:
Code:
#!/system/bin/sh
busybox mount -o remount,rw /
chmod 770 /mnt/media_rw
See the attached archive root.zip which I made for you it is pretty straightforward.
You should have move your TiB backup folder on this path: /mnt/media_rw/sdcard1/TitaniumBackup
You will be able to protect backup archives in Titanium Backup Pro then.
PS: If /data/local/userinit.sh doesn't start automatically in your ROM you can use for example Scripter feature in ROM Toolbox Pro and import userinit.sh script and set it as Start at boot.
_jis_ said:
I carefully read this thread: [Help] Titanium Backup PRO - protected archive not working.
So I modified file /system/etc/permissions/platform.xml according http://jrummy-apps.com/fix-sdcard-on-kitkat/ and make new file /data/local/userinit.sh with this content:
Code:
#!/system/bin/sh
busybox mount -o remount,rw /
chmod 770 /mnt/media_rw
See the attached archive root.zip which I made for you it is pretty straightforward.
You should have move your TiB backup folder on this path: /mnt/media_rw/sdcard1/TitaniumBackup
You will be able to protect backup archives in Titanium Backup Pro then.
PS: If /data/local/userinit.sh doesn't start automatically in your ROM you can use for example Scripter feature in ROM Toolbox Pro and import userinit.sh script and set it as Start at boot.
Click to expand...
Click to collapse
Although in the case of Note 4 it didn't work right off the bat, I made it work a little different thanks to your idea. For some weird reason the script just doesn't get executed at boot (neither the *.sh file, nor as a script, through ROM Toolbox) but I was able to use the 2 lines in the script and made a task (in Tasker) which executes the shell command at boot. Everything else is straight forward and TiBu can now protect backups.
As a mention for those interested in replicating all these: the suggested SD card fix made by rummy applies EXACTLY the same changes as the SDFix so you can use either of them. Again, thanks for your reply and the great idea! :good:
nacos said:
I was able to use the 2 lines in the script and made a task (in Tasker) which executes the shell command at boot. Everything else is straight forward and TiBu can now protect backups.
Click to expand...
Click to collapse
Great, this is another example how to execute script at boot
I solved this problem on all my phones (Moto G LTE and Samsung Galaxy Note 2 and Samsung Galaxy W) but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk. This is example where pure Stock Google Android ROM sucks
_jis_ said:
Great, this is another example how to execute script at boot
I solved this problem on all my phones (Moto G LTE and Samsung Galaxy Note 2 and Samsung Galaxy W) but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk. This is example where pure Stock Google Android ROM sucks
Click to expand...
Click to collapse
This update addresses the issue mentioned before about init'd scripts not executing at boot. OK, here is the issue (specific to Qualcomm's Snapdragon) and the working solution - thanks to alexndr. I've tested it and it's working, however it doesn't work directly with <X.sh> text files, instead the script must be packaged in a flashable zip and flashed from recovery. Once I did that, it worked like a charm! The 98mediarw file in the screenshot uses the same script as previously mentioned; The 98 before the file name assigns a higher execution priority - I used 98 for testing purposes, it clearly doesn't need that. :good:
nacos said:
OK, here is the issue (specific to Qualcomm's Snapdragon) and the working solution - thanks to alexndr.
Click to expand...
Click to collapse
Oh, at first I thought that you post something what helps me with my tablet:
_jis_ said:
I solved this problem on all my phones but not on my tablet Nexus 7 2013 nor on internal emulated SD card nor on attached OTG USB flash disk.
Click to expand...
Click to collapse
But this is just another example how to execute script at boot
none of these methods are working. Is it because I'm using a Custom ROM?
What are you trying to achieve? What exactly is your environment?
nacos said:
What are you trying to achieve? What exactly is your environment?
Click to expand...
Click to collapse
I have Motorola Moto E (CM11 Stable build by percy_g2) and I'm trying to protect my backups in TiB but I'm getting error "Sorry, the operation failed." It used to be the same in stock ROM. And one more question, is this bug fixed in Lollipop versions of Android?
To answer you questions, no, this is not a bug, it's by design, also it's not happening because you're using a custom ROM, but rather because all OEM's (Google being probably the worst of all) are pushing towards more and more restrictive software & hardware environments, also supported by laws meant to discourage the users from modifying original configurations. Why? Dirty politics, I won't get into that but if you keep your eyes wide open you'll see and understand A LOT! Oh, by the way...to expect for Lollipop to be less restrictive and more fun (to customize) would be naive! Nuff said, let's have some fun!
There are multiple parts to this fix/diagnostic. Don't skip any point and follow these instructions rigorously, otherwise it won't work!!! Let's take them one by one:
Is you platform.xml file (under system/etc) modified to allow read/write access to media_rw (mnt/media_rw)? If not, apply the patch using SDFix from Google Store.
TiBu backup folder must be set to mnt/media_rw/externalSD/Titaniumxxx (if you don't have externalSD than use your internal storage instead, pointing to TiBu folder) - but, for right now, you won't be able to set this path because currently TiBu doesn't have access to media_rw, due to media_rw not being given the right permissions by the system. That's exactly what mediarw script does.
In order for init.d to execute the mediarw script at every boot, you need to insure that you do have init.d support AND it's working. This is how you verify:
(3a) Do you see the folder system/etc/init.d? If yes, go to (3b), if no, you don't have init.d support! That's another fix entirely.
(3b) If you see the 00test file in the init.d folder navigate to /data and open up the file called Test.log - that tells you that init.d is installed and working. If you have a Qualcomm's Snapdragon and you do have the init.d folder but it doesn't execute any script at boot, see the fix in post #6.
(3c) If you don't care about setting up init.d support, you can still run the script at boot, as a shell command using Tasker - see post #4
Once you're sure that all the above are set correctly, flash the attached file from recovery. Reboot, navigate to system/etc/init.d and confirm the presence of the mediarw script in the init.d folder
Reboot again, then navigate to mnt/media_rw and check that permissions for media_rw have been set to 770 - :fingers-crossed: mission accomplished, my friend! :fingers-crossed: If, on the other hand, the permissions for media_rw are still set at 700, then something went wrong. Go back and check every step again, otherwise...
Open up TiBu, set the backup folder path as instructed in #2 and verify that your backups can be protected. Voila!!
nacos said:
To answer you questions, no, this is not a bug, it's by design, also it's not happening because you're using a custom ROM, but rather because all OEM's (Google being probably the worst of all) are pushing towards more and more restrictive software & hardware environments, also supported by laws meant to discourage the users from modifying original configurations. Why? Dirty politics, I won't get into that but if you keep your eyes wide open you'll see and understand A LOT! Oh, by the way...to expect for Lollipop to be less restrictive and more fun (to customize) would be naive! Nuff said, let's have some fun!
There are multiple parts to this fix/diagnostic. Don't skip any point and follow these instructions rigorously, otherwise it won't work!!! Let's take them one by one:
Is you platform.xml file (under system/etc) modified to allow read/write access to media_rw (mnt/media_rw)? If not, apply the patch using SDFix from Google Store.
TiBu backup folder must be set to mnt/media_rw/externalSD/Titaniumxxx (if you don't have externalSD than use your internal storage instead, pointing to TiBu folder) - but, for right now, you won't be able to set this path because currently TiBu doesn't have access to media_rw, due to media_rw not being given the right permissions by the system. That's exactly what mediarw script does.
In order for init.d to execute the mediarw script at every boot, you need to insure that you do have init.d support AND it's working. This is how you verify:
(3a) Do you see the folder system/etc/init.d? If yes, go to (3b), if no, you don't have init.d support! That's another fix entirely.
(3b) If you see the 00test file in the init.d folder navigate to /data and open up the file called Test.log - that tells you that init.d is installed and working. If you have a Qualcomm's Snapdragon and you do have the init.d folder but it doesn't execute any script at boot, see the fix in post #6.
(3c) If you don't care about setting up init.d support, you can still run the script at boot, as a shell command using Tasker - see post #4
Once you're sure that all the above are set correctly, flash the attached file from recovery. Reboot, navigate to system/etc/init.d and confirm the presence of the mediarw script in the init.d folder
Reboot again, then navigate to mnt/media_rw and check that permissions for media_rw have been set to 770 - :fingers-crossed: mission accomplished, my friend! :fingers-crossed: If, on the other hand, the permissions for media_rw are still set at 700, then something went wrong. Go back and check every step again, otherwise...
Open up TiBu, set the backup folder path as instructed in #2 and verify that your backups can be protected. Voila!!
Click to expand...
Click to collapse
(Please ignore that screenshot. I didn't properly read your msg in blue text)
I couldn't understand post #4 so can you please describe it more deeply? :crying: btw I don't have 00test but a file named 00banner. And can you tell me how to use tasker properly?
Sorry for butting in on this thread. I found it by searching because I too can no longer protect a backup in my tibu Pro. I used to be able to but not anymore and I'm not sure why.
I'm on a rooted nexus 5 running stock 4.4.4.
Reading your instructions I went looking for platform.xml and found it. When I checked its properties I got, see screenshot. Don't know what to modify to mount it as you say. I'm in ES Explorer.
Can you help?
Thanks.
And here is a screenshot in root Explorer
Update your tb to 7.0.1 and now you can protect backups ? this thread should get closed now
Closed? Why? Just because a shortcut is available doesn't mean there is nothing to learn from wondering around, my friend!
After all, this is exactly what XDA is: a huge data base available to those who are willing to learn and dare to wonder around, wouldn't you agree?
Hello all! If you're familiar with KCAL and suffer from symptoms such as a locked bootloader or non-loadable kernel modules then you may be interested in KCAL Post-Processing Daemon, or KPPD - the all-in-one display tuning tool that you can use to customize your color calibration on the fly!
This does NOT require an unlocked bootloader, custom kernel, or even a kernel that supports module loading, just run the daemon and you're good to go!
To install on a device with a locked bootloader, you'll need to download the kppd release below, and unpack it to prep for some adb fun... (If you have TWRP, you can also flash this in recovery)
Code:
adb push /path/to/kppd /data/local/tmp/
adb push /path/to/postproc.conf /data/local/tmp/
adb shell
su
mount -o rw,remount /system
cp /data/local/tmp/kppd /system/bin/
cp /data/local/tmp/postproc.conf /system/etc/
chmod 0755 /system/bin/kppd
chmod 0644 /system/etc/postproc.conf
reboot
Now at this point, you can use any scripting app to start the daemon on boot, I use ROM Toolbox... http://i.imgur.com/0juzfug.png
And you're done! To edit your display settings, just edit the postproc.conf file... http://i.imgur.com/pjOPbIr.png
Download KPPD
Thanks, works great. Now we need some custom configs
any chance you can update your KCAL Color Control app to support KPPD? Easy way to set the values
Thanks Savoca! I have followed all of your work fairly closely and am very glad we have you around the forums!
This is amazing. Would it work for other LG tablets such as the LG X8.3 with the snapdragon 610?
My G4 is pretty decent but my tablet is super red. Once you get it setup, you constantly have to have Rom Toolbox installed to make this work or do you only need the app for the initial setup?
I think I can answer the second part of this. The rom toolbox thing is just one of many ways to run this script on boot. But you will need SOMEthing to start it no matter what. This could be init script (I think that's what its called, which some roms have built in) Or any custom rom could include it by default.
So no, Rom toolbox isn't really necessary, its just the way he recommended to get it running on boot if you don't know another way.
I am more curious to seen if it will work on my LG tablet. I'll just have to test it out. I guess worst case scenerio is you dont have it auto start on boot. If you mess it up you just reboot.
player911 said:
I am more curious to seen if it will work on my LG tablet. I'll just have to test it out. I guess worst case scenerio is you dont have it auto start on boot. If you mess it up you just reboot.
Click to expand...
Click to collapse
Yes it should work, however it depends on each device's version of the MDSS (Qualcomm display driver). If it doesn't work, let me know so I can add support for it.
I'm wondering if this would work on my G Flex 2 ? Is there any chance that it can break anything if it doesn't work?
---------- Post added at 03:37 PM ---------- Previous post was at 03:05 PM ----------
I've just installed it on my G Flex 2 and it works great. Thanks a lot!
how control this mod with KCAL apk???
armsar1978 said:
how control this mod with KCAL apk???
Click to expand...
Click to collapse
You can't (yet?). Only via the config.
New version uploaded significantly reduces CPU load and removes any delay between modifying the postproc.conf and applying the display settings.
I've read a little and I remember making rgb adjustments regularly with my old gnex years ago...
Wondering if there are suggested settings/values one can recommend for use with the G4 please.
I second this g4 question, any recommended values?
dontbeweakvato said:
I second this g4 question, any recommended values?
Click to expand...
Click to collapse
I'm using these right now: http://imgur.com/UKkOt7x
If you're editing the file at runtime, I recommend you use either FX File explorer or ES File Explorer to edit the config, root explorer and ROM toolbox editors delete the original file and rewrite a new one for some reason (maybe they can fix this in their apps) and kppd looses the original from the kernel.
Does this have an option for sharpness?
"su" doesnt work -> not found
Z900 said:
"su" doesnt work -> not found
Click to expand...
Click to collapse
You need to root your device.
savoca said:
I'm using these right now: http://imgur.com/UKkOt7x
If you're editing the file at runtime, I recommend you use either FX File explorer or ES File Explorer to edit the config, root explorer and ROM toolbox editors delete the original file and rewrite a new one for some reason (maybe they can fix this in their apps) and kppd looses the original from the kernel.
Click to expand...
Click to collapse
"Error occurred while trying to save file. File will not be saved." - using es file explorer. I seem to not have issues with rom toolbox. What's the deal with it not saving after editing?
dontbeweakvato said:
"Error occurred while trying to save file. File will not be saved." - using es file explorer. I seem to not have issues with rom toolbox. What's the deal with it not saving after editing?
Click to expand...
Click to collapse
Sounds like an issue with the app. You could always move the config file to somewhere on /data where you would have write access. Just point kppd to the config location in the init script.