Related
I was playing around with adjusting and monitoring the CPU rate on my A43, and I discovered an oddity. I have the device set to overdrive, so normally it can do 1ghz. But I noticed that inside Netflix's video player (not just the Netflix app, the video player), the CPU speed was only 800mhz and there was some stuttering. Looking more carefully, I noticed that somehow as soon as the video player started up, the maximum scaling frequency went down to 800mhz. Exit, and it goes back to 1ghz. I then found that the same happens in Youtube and the Archos Video player.
How annoying, though maybe there is some good reason for it? Is it perhaps that the video hardware can't handle the greater speed? Does anybody know?
Anyway, I have a simple fix: You just have to turn off the write permissions on /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq after the values have been all set. I don't know if any of the CPU speed utilities like SetCPU let you do this.
I fix this by setting my CPU speed settings via a script that runs on boot. (I run it via a tiny utility I wrote which I am not presently releasing, but you could also run it via Script Manager.) The script I use is:
Code:
cd /sys/devices/system/cpu/cpu0/cpufreq
echo conservative > scaling_governor
chmod 644 scaling_max_freq
echo 1000000 > scaling_max_freq
chmod 444 scaling_max_freq
echo 300000 > scaling_min_freq
echo 150000 > conservative/sampling_rate
echo 70 > conservative/up_threshold
The crucial line is the "chmod 444 scaling_max_freq" which sets the scaling_max_freq file to read-only. (Of course, a determined app that wants to change it can just chmod 644 scaling_max_freq and write to it. But whatever is doing the switch 800mhz isn't THAT determined.)
The result is that Star Trek plays smoothly at 1ghz in Netflix, as it should, while the built-in video player when playing lower-resolution videos uses 800mhz, as it also should.
If you have a device with a higher top speed than 1000000, just change the 1000000 to whatever your top speed is.
If you want to check if your device has the issue, start up a video, and then while the video is playing, do:
Code:
adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
If it's less than the top speed of your device, you have the issue.
But maybe it's supposed to be like that?
arpruss said:
The script I use is:
Code:
cd /sys/devices/system/cpu/cpu0/cpufreq
echo conservative > scaling_governor
chmod 644 scaling_max_freq
echo 1000000 > scaling_max_freq
chmod 444 scaling_max_freq
echo 300000 > scaling_min_freq
echo 150000 > conservative/sampling_rate
echo 70 > conservative/up_threshold
Click to expand...
Click to collapse
Would I run this script verbatim for interactive mode? Or change 'conservative' in the script to 'interactive'?
EDIT I think I get it...... gonna play for a bit....
I think the stock ROM only supports ondemand, conservative and performance.
arpruss said:
I think the stock ROM only supports ondemand, conservative and performance.
Click to expand...
Click to collapse
I'm on Uruk 1.0, err, well both, but I dominantly run on Uruk
wokker666 said:
I'm on Uruk 1.0, err, well both, but I dominantly run on Uruk
Click to expand...
Click to collapse
I see. Then, yes, you do need to change things to set up whatever settings you want for interactive. Are you using any CPU-setting utility? I don't know how well my script will work with a CPU-setting utility. The one I tried automatically set read/write permissions to the files, which undoes the effects of my script.
I think I got it
I can confirm that SetCPU does reset the permissions, killing SU permissions to the app seems to fix that
I remade the script to go a little something like...
Code:
cd /sys/devices/system/cpu/cpu0/cpufreq
echo interactive > scaling_governor
chmod 644 scaling_max_freq
echo 1000000 > scaling_max_freq
chmod 444 scaling_max_freq
chmod 644 scaling_min_freq
echo 600000 > scaling_min_freq
chmod 444 scaling_min_freq
The scaling_min_freq part may seem useless, but it further sets what you want in stone
So far after a few reboots, everything seems to be working just fine, and the system dosen't scale the cpu to 800000 when in video!
Nice!
Thanks!
Any idea WHY Archos did that 800mhz scaling?
Maybe it's just a bug. I think they initially wanted the device to run at 800MHz, and then later added an Overdrive mode at 1000. So the 800 could be a leftover, no?
arpruss said:
Any idea WHY Archos did that 800mhz scaling?
Maybe it's just a bug. I think they initially wanted the device to run at 800MHz, and then later added an Overdrive mode at 1000. So the 800 could be a leftover, no?
Click to expand...
Click to collapse
I think they did it to help conserve the battery, if you use your unit for mostly video, it would make sense to not burn through your battery at 1ghz...
On that note, my system with the settings I just made, in video it REALLY scales to my settings.... it dominantly runs at 600mhz, not 1ghz - maybe it's the interactive mode kicking in, it just dosent see the demand - I can't test in real time right now though, no linux machine as of yet, but time in state shows mostly 600mhz, and some 1ghz
wokker666 said:
I think they did it to help conserve the battery, if you use your unit for mostly video, it would make sense to not burn through your battery at 1ghz...
Click to expand...
Click to collapse
But that's what the scaling is for. When the video doesn't need the higher speed, it scales it down, and when it needs it, it scales it up. Star Trek on Netflix needs 1000, while different xvid videos that I have need different speeds.
By the way, I noticed that they also set scaling_min_freq to 800 in the video player. So, my script also needs a line:
Code:
chmod 444 scaling_min_freq
at the end.
arpruss said:
But that's what the scaling is for. When the video doesn't need the higher speed, it scales it down, and when it needs it, it scales it up. Star Trek on Netflix needs 1000, while different xvid videos that I have need different speeds.
Click to expand...
Click to collapse
Most of what I was testing are .mkv's of all sorts of flavors, they probably dont need to bump up the speed - I should find a hd vid to test with.
By the way, I noticed that they also set scaling_min_freq to 800 in the video player. So, my script also needs a line:
Code:
chmod 444 scaling_min_freq
at the end.
Click to expand...
Click to collapse
I knew I threw that in for a reason
It looks like the writing of the modified frequencies is done by /system/bin/powerd, and it's requested by /usr/bin/avos when the DSP is called for.
arpruss said:
It looks like the writing of the modified frequencies is done by /system/bin/powerd, and it's requested by /usr/bin/avos when the DSP is called for.
Click to expand...
Click to collapse
I wonder if this is something that can be manually changed, or maybe Sauron take a look at it and implement the changes in the next Uruk?
On another note, I gotta say, after locking down my cpu with this script, plus a few other settings in an app I have (autokiller memory optimizer), my system has never run better, very snappy!!!
Android RAM Management
What's this thread about?
This is a brief account of some useful aspects of android memory management and what could be done to make it better or to suit our needs. This is arranged in two parts; A) RAM Management Lesson. B) RAM Management Tips. Whoever is familiar with the Android RAM management concepts can skip to the second part (2nd post). [highlight]Please read and understand carefully before applying anything to the phone. I'm not responsible for any unwanted effects thereby. Credits belong to respective authors of any MOD/APP discussed here.[/highlight]
A) RAM Management Lesson
Android uses a different way of handling processes. Instead of killing every process after its activity ended, processes are kept until the system needs more memory. The idea is to give speed improvements if you start that activity again. But how/when does Android kill a process if it needs more memory and and which process to kill first?
This is managed by the LMK (Low Memory Killer) driver of Android. You may already know that every app/process in Android is assigned an oom_adj value, which indicates the likelihood of it being killed when an out of memory (OOM) situation occurs. More higher it's value, the higher likelihood of it getting killed. Valid range is -17 to +15. (if in the -17 range means it won't get killed). According to that, there are six groups (OOM groups), into which apps/processes are categorised:
1. Foreground app
2. Visible app
3. Secondary server
4. Hidden app
5. Content provider
6. Empty app
Basically these could be described as..
FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it!
VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned.
HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.
EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go!
Click to expand...
Click to collapse
These groups are defined by oom_adj value limits, and apps would fall into one of those groups according to the oom_adj value assigned to that particular app. "Foreground apps" usually have an oom_adj value of 0 or less (so they are the least killable; i.e High priority). "Empty apps" have a higher oom_adj (they are killed early; i.e Low priority). Also, oom_adj value changes according to the state of the user app; it's 0 when the app is active in the foreground and assigned a higher value when the app goes to the background.
Why their "killability" differ? Apps belonging to these different groups (that have different oom_adj's), start to get killed at different levels of free RAM. These triggering RAM limits are defined by the LMK minfree values. Above 6 categories correspond with 6 RAM limits which are set in the LMK minfree. Eg: Stock Android 4.3 in our SP comes with the minfree values of 58,68,78,88,98,118. (these are in MB; see below how to check it). Practically what it means is, Empty apps will get killed when ram goes below 118mb, Content providers when it goes below 98mb, Hidden apps when it goes below 88mb and so on.. lastly starts killing Foreground apps when ram goes below 58mb. You may notice that this last value (58mb) is not desirable when using memory intensive apps like heavy games. The app might shutdown while we interact with it. It won't be a surprise if RealRacing3 would shutdown in the middle of a race with these minfree settings!
[Highlight]Notes:[/highlight]
1. In our SP (and newer kernels), oom_[highlight]score[/highlight]_adj is used instead of old oom_adj. (oom_score_adj valid range is -1000 to 1000). But oom_adj is also maintained for compatibility I think.
2. It is said that there are many OOM process categories that are assigned different oom_adj priorities by the ActivityManagerService, but eventually all of those would be considered under above six slots/groups (according to oom_limits), for the purpose of killing by the LMK minfree triggers. Therefore, those six are the importatnt ones for normal users like us.
[highlight]Now, to the practically important part...[/highlight]
# We can check the minfree values (also change them) and see the OOM groupings of apps/processes with this Memory Manager app easily.
a) LMK Minfrees:................... ......................................b) OOM groupings:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
....
If we click on an app in the list and select 'more info', we can see it's oom_adj value. In my case, System UI has -12 (foreground), Home Launcher has 1 (visible group) etc..
# We can check these manually in a terminal too..
a) LMK Minfrees:
Give the following command (without quotes) in a terminal emulator or adb shell: "cat /sys/module/lowmemorykiller/parameters/minfree"
Code:
$ cat /sys/module/lowmemorykiller/parameters/minfree
[b]15000,17532,20065,22598,25131,30263[/b]
** These are in pages; 1 page=4K. Therefore, converting these in to MB results in.. 58,68,78,88,98,118. (e.g: 15000 x 4 /1024 = 58,5938)
b) OOM_adj value of an app:
*This is not much useful. But nice to know where to get these values from.
E.g. take home launcher. Find out it's PID (process ID) like this.. (command with output posted)
Code:
$ ps |grep [b]home[/b]
u0_a26 1653 721 471408 78076 ffffffff 00000000 S com.sonyericsson.home
It's pid is 1653. To see it's oom_adj value..
Code:
$ cat /proc/[b]1653[/b]/oom_adj
1
It's 1 (foreground). You might get 6 (hidden). So, your home is easily killed than my home . See below why..
At the same time we can see the new oom_score_adj..
Code:
$ cat /proc/[b]1653[/b]/oom_score_adj
58
* To convert old oom_adj value to newer oom_score_adj..
oom_score_adj = (oom_adj x 1000)/17 (truncate the decimals). So, (1x1000)/17=58.823
*There's another value (0-1000) of oom_score (cat /proc/1653/oom_score), which is THE actual indicator of how likely a process will get killed. It changes according to the tunable oom_score_adj and other factors..? something like that.. forget it!
[highlight]## The above mechanism could also be described according to what is mentioned in kernel source files[/highlight], as below. Can skip if it's boring ..
It's from 'drivers/misc/lowmemorykiller.c' of kernel sources (4.3; .266)
* The lowmemorykiller driver lets user-space specify a set of memory thresholds
* where processes with a range of oom_score_adj values will get killed. Specify
* the minimum oom_score_adj values in
* /sys/module/lowmemorykiller/parameters/adj and the number of free pages in
* /sys/module/lowmemorykiller/parameters/minfree. Both files take a comma
* separated list of numbers in ascending order.
*
* [highlight]For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and
* "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill
* processes with a oom_score_adj value of 8 or higher when the free memory
* drops below 4096 pages and kill processes with a oom_score_adj value of 0 or
* higher when the free memory drops below 1024 pages.[/highlight]
*
* The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate
* and processes may not get killed until the normal oom killer is triggered.
Click to expand...
Click to collapse
If we take our phone values, "cat /sys/module/lowmemorykiller/parameters/adj" command returns: "0,58,117,235,529,1000". These are in (new) oom_score_adj values. If we convert them to (old) oom_adj values, these become "0,1,2,4,9,15". (eg:117x17/1000=1.989=2; The last value becomes 17, but oom_adj range ends with 15, so we take 15). Now, with our minfrees of 58,68,78,88,98,118, what it means practically is to kill processes with a oom_adj value of 0 or higher when the free memory drops below 58mb and kill processes with a oom_adj value of 1 or higher when the free memory drops below 68mb and so on... Therefore, it's clear that the adj values "0,1,2,4,9,15" (or score_adj values "0,58,117,235,529,1000") define the limits of each of 6 OOM slot described above.
Another point to note is what mentioned above in the kernel source file "..driver considers memory used for caches to be free..", which is described below.
[highlight]What is "Free RAM"?[/highlight]
What's reported in many apps as "free ram" is actually not free/empty. Linux/Android always tries to utilise the whole ram in some way, so the ram is not wasted. Ram which is not used by active apps, is used for caching apps and for some buffers. These caches and buffers can release memory for apps when needed. We can see the ram usage in detail with this command.. "cat /proc/meminfo" [giving "watch cat /proc/meminfo" would refresh the output every 2 seconds].
Code:
$ cat /proc/meminfo
MemTotal: 859764 kB
[B]MemFree: 26380 kB
Buffers: 2008 kB
Cached: 136600 kB[/b]
SwapCached: 0 kB
Active: 557312 kB
Inactive: 70520 kB
...blah.. ..blah...
....
Reported "free ram" was ~150mb when this was taken. Out of that, most (135mb) is already cached. ["Free RAM"=MemFree+Cached]. Actual free is very little. So, increasing "free ram" makes the phone much snappier because most of that "free" part of the RAM is used for caching things.
-->> RAM Management Tips
B) Tips for better RAM management.
Following is an account of which i benefitted from, sharing for others who may not be aware of these. Your milage may vary... Desired "RAM Management" differs depending on whether expecting more multitasking or a snappy phone with lot of free RAM. Nowadays, phones with better specs generally won't show any lag even if tuned for multi-tasking , although "free RAM" stays little lower. I prefer towards more multi-tasking
1. Change the minfree values to suit your needs. [highlight](Need Root access)[/highlight].
LMK Minfree values can be changed on the fly. Use lower values if you want more multitasking. Higher values if need more "free ram" for gaming etc.. . I use 8,12,45,65,95,165 for more multitasking and for foreground apps to stay until ram becomes much lower. Asphalt8 never crashed with this! If we use values like 15,25,95,145,195,245 "free ram" would be more but background apps (e.g. Hidden apps) would shutdown earlier. However, make sure NOT to increase the first 2 slots too high, so that the Foreground and Visible apps would stay even if RAM goes lower.
How to set/change them:
a) You can set those values with the above Memory Manager app and press Apply. (and tick 'apply at boot' for those values to be applied at every boot).
** There are many preset values you can experiment with.
b) Or can do the manual way.. Give the following command in a terminal/ADB shell:
Code:
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree
(That's after "su" command to get root prompt). ** Need to 'echo' them in pages; not in MBs. See first post how to convert them.
Note: This won't survive reboot. You can run this command as a script with init.d every boot. (For init.d support, check this). The script would look like this:
Code:
#!/system/bin/sh
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree ;
c) Can use Minfree Manager app. To set the minfrees, press Apply after entering the values. If we press 'Apply at Boot', it saves a script under init.d. No hassle.
** There are many apps that can do these kind of changes. Eg: Auto Memory Manager, Ram Manager(Free/Pro)-with other options. The above described ones are very easy to use.
2. Use 'App Settings' xposed module to make any app "stay" in memory (make it "Resident"). [highlight](Need Root access)[/highlight]
It would definitely help multitasking by keeping the needed apps in the background without getting killed, even if RAM becomes low. It possibly works by reduces the app's oom_adj value. That's why you can see Opera Mini in the 'Foreground app' list in my screenshot above (1st post). It's oom_adj value is 0. You can do this for your home launcher and any app you wan't to stay un-killed in the background.
Caution: Making apps to stay in memory would make them stay without being killed, even when e.g. a heavy game is starving for RAM. Therefore, indiscriminate use of this option is not advised. I think it's better to..
(i) Apply only to the apps which have an 'Exit' button/menu, so we can shut it down when needed.
(ii) If no exit button, Add to the 'Greenify' list to be hibernated when the app is not needed. But it asks for confirmation before hibernating these kind of apps with 'High Priority' oom_adj status.
How-to:
1. Get Xposed installer from here. Install it. Install the Xposed framework through it. Refer to the respective thread for more details.
2. Then download the 'App Settings' module through Xposed installer..
3. Open 'App Settings'.. App list will load.
4. Select the app you wan't to tweak.. It will lead to a page as seen in the screenshot above.
5. Select 'Resident' and save (upper right corner button). Can change any other setting if needed.
3. Use zeppelinrox's jar patcher tools to patch services.jar. [highlight](Need Root access)[/highlight].
It changes Home Launcher priority and many other LMK related tweaks. This is why you see my home launcher is under visible apps (oom_adj 1). No launcher redraws even after asphalt8! See the particular thread for details. In summary, patching services.jar results in (quoted from the thread):
- This will SuperCharge Your Home Launcher and ADJ/OOM Priorities! You pick launcher strength!
- This lets you run up to 70 hidden apps instead of the default 15 (RAM permitting) without breaking the lowmemorykiller!
- This tries to bypass the 30 minute service inactivity limit by increasing it to 24 hours.
Click to expand...
Click to collapse
** From ICS up, Android doesn't read ADJ values from build.prop or local.prop - they are hardcoded into services.jar! That is the reason for needing to patch services.jar to change OOM priorities. More details in the respective threads.
How-to (quoted):
Get Jar patcher tools from the thread. I used 'Ultimatic_Jar_Patcher_Tools_RC7_TEST6_ALL_DEX_ALL_OSes_NO_FLASH.zip'. Extract it in the PC. Make sure ADB drivers installed.
How to run -=Ultimatic Jar Patcher Tools=-
1. Connect your Android to your PC with Android Debugging ENABLED and Mass Storage DISABLED so your device has access to your sdcard.
2. Windows: Run either the zip's *.bat or the attached *.exe
If running the exe, you can put a different ultimate jar power tools script version in the same folder and it will use that one otherwise it uses the embedded version!
If you have cygwin installed, you can even use the zip's *.sh file at the cygwin prompt.
Linux/Mac OSX: run the zip's *.sh file
Just be sure to read everything and answer Yes or No as is your preference.
Example: The script allows you to choose the level of your Launcher's Super Strength! (BulletProof, Die-Hard, or Hard To Kill)
Click to expand...
Click to collapse
** Always keep a cwm backup before attempting this; might not get it correct in the first attempt..
4. With the above jar patching, can use zeppelinrox's supercharger script. [highlight](Need Root access)[/highlight].
It can be used to change the minfrees and it re-groups the OOM categories. It also has tons of other cool tweaks. If we check "cat /sys/module/lowmemorykiller/parameters/adj" after applying the SuperCharger scripts to our phone, it returns.. "0,176,352,588,705,1000". Converting to oom_adj values (see 1st post) it becomes "0,3,6,10,12,15". Comparing with stock values (0,1,2,4,9,15), we can see that the above described six OOM slots are re-arranged, sort-of categorising more processes towards higher priority. Can test those settings by echoing those values (this won't survive reboot):
Code:
echo "0,176,352,588,705,1000" > /sys/module/lowmemorykiller/parameters/adj
** Not advisable to meddle with this if no clear idea about what is being done. Use the SuperCharger script instead. Checkout the respective thread for more info.
[For me, this OOM regrouping made some task killings more difficult and it didn't relese RAM readily when needed for heavy games..(may not be same for others ). So I'm not using it at the moment. I'm setting up minfrees as described previously.]
How-to (briefly):
1) Get the latest SuperCharger script from the thread.
2) Make sure requirements are met. Eg: Rooted, Busybox installed.
3) Run the script through 'Script Manager-Smanager' app (with root access granted).
4) Read the output of the screen and reply to the prompts accordingly.
** Keep a cwm backup before attempting this, just in case..
5. Override the "Hidden app limit" of Android. [highlight](Need Root access)[/highlight].
In addition to the LMK driver mechanism described above, this is another parameter that leads to killing of Hidden and Empty apps. Apps are killed when the number of those apps go beyond the specified limits. (Traditionally it was 15, so no more than 15 hidden apps would stay in the background even if there's plenty of RAM). There's a build.prop setting which can control this in our SP. (Btw, services.jar patching mentioned above makes that limit to 70). With the build.prop setting mentioned, we could make it to even 150 ! (This way, we can maximize multitasking and app killing is fully handed over to LMK minfrees, which we can control).
How-to:
Code:
ro.sys.fw.bg_apps_limit=70
Add this line to end of build.prop file (in /system) and leave another blank line below that, and save the file. Then reboot.
Tip: Build Prop Editor is an easy way to edit the build.prop.
** Always keep cwm backups before doing these kind of things.
How to test:
a) Install CatLog app (need root) [This is for reading Logcat]
b) Run it and enter "longer" (without quotes) in the filter bar. Might get a filtered output like this:
It means that the 24th Empty app had got killed, because of exceeding the hidden app limit. This is after services.jar patching making the Hidden app limit to 70. Before it was #17 if I remember correctly.
c) Check the same output after applying the build.prop setting. Should get a little increase. (When I made Hidden app limit to 100, output was #34th empty app gets killed. So, I wen't upto 150 until that kind of output disappeared ).
## Credits to @zeppelinrox for finding that build.prop setting. You can read what happened here in his thread.
How it works:
By @zeppelinrox
In Android 4.2 the max hidden apps are divided into 2 parts (In AMS smali the value is stored in "mProcessLimit")
Part of it goes towards hidden apps.
Part of it goes towards empty apps.
So what happens is it gets the max apps limit (v2)
It gets multiplied by 2 so "v2" is doubled in value.
Now... that is divided by 3 and that value is assigned to empty apps (v13)
Finally, empty apps (v13) is subtracted from v2 to give you hidden apps (v17)
So by default, there are MORE empty apps than hidden apps!
2/3 are empty
1/3 are hidden
So your original config was probably...
max hidden apps = 25
empty apps = 17 (25x2/3)
hidden apps = 8 (25-17)
So normally (without jar patching), if the limit is 70 it would break down like this...
max hidden apps = 70
empty apps = 46 (70x2/3)
hidden apps = 24 (70-46)
** Services.jar patching reverses this ratio (to give more allowance to Hidden apps than Empty apps. Then it results in:
max hidden apps = 70
empty apps = [highlight]23[/highlight] (70x3/9)
hidden apps = 47 (70-23)
Click to expand...
Click to collapse
That's why my 24th Empty app was getting killed with app limit of 70. You might get a totally different value if this build.prop setting is applied without services.jar patching. Appreciate your feedback
[highlight]** Please Note: I'm no dev. I wrote this according to what i understood by reading around in the net. I'd be more than glad if anyone points out any shortcomings/improvements. Thanks.[/highlight]
Credits/Sources
@zeppelinrox for his supercharger thread with overwhelming info, for finding out the build.prop setting in our SP, for explaining things and many more!
@androcheck for his thread
Took more info from here, here, here, and here.
[Highlight]An interesting observation...[/highlight]
Many of us refer to 'Settings>Apps>Running' to see how much free RAM is available at a particular moment. Generally we believed that it shows the correct value. But, some observations makes that value doubtful. E.g: This value doesn't tally with /proc/meminfo values. Furthermore, 'Free RAM' indicated by other apps at times are totally different.
(1).CoolTool - 121 MB
(2).meminfo (watch cat /proc/meminfo) - Looks compatible with cooltool value.
(3). Android says - 23MB!!??
**(all 3 values were updating realtime..)
Sometimes it goes the other way:
(gave time to settle down of course)
Any thoughts?? Does anyone experience like this or only me?
Just in case..
mrhnet said:
@androcheck for his thread...
Click to expand...
Click to collapse
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!
@androcheck
Thanks for the encouragement..
nice tutorial with full descriptions...great..:good:
This is wonderfull! I will add this to the tutorial Index this weekend
mrjraider said:
This is wonderfull! I will add this to the tutorial Index this weekend
Click to expand...
Click to collapse
Thanks. That's nice of you
thx u very much for the detailed explanation, gonna try ur recommended values later
great bro can be a sticky thread
mrhnet said:
Just in case..
Click to expand...
Click to collapse
Nice thread dude.
Now I'm glad that I had patience with your patching issues lol
However I don't think I have the patience to go into every tiny detail which is why I link to @androcheck 's thread in my original Supercharger OP (which is now post #3)
And you may find useful the new tool that I'm finally on the verge of releasing...
androcheck said:
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!
Click to expand...
Click to collapse
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire
zeppelinrox said:
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire
Click to expand...
Click to collapse
Thanks.
I didn't take any offense, if not I would have written it, someone else would have. In the end the knowledge has spread.
@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..
mrhnet said:
@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..
Click to expand...
Click to collapse
Soon.
It's done but gotta write up an OP
Edit: Done http://goo.gl/9H58pS
This is a great thread, you've explained everything very well. :good:
In my experience, RAM management works best if I set very low LMK values, like this. Anything higher means processes will get closed sooner.
Multitasking is good with this, not very good, though, because this is a Sony ROM, but still way better than higher values.
But be warned, using these values on stock 4.3 made it unstable for me, but it works on stock 4.1 without any problems.
Also, I've read on some sites that Sony will release Kitkat for the SP in June, and Kitkat has ZRAM enabled and also some other memory management-helping changes are made by Google. So I really hope it will be released for our device.
Edit (05.23): Well, it seems after a few days of testing, that these low values don't do anything good. The phone slows down a lot. So, this post might be considered pointless. Anyway, it was a good experiment.
I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?
Lajbymester said:
I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?
Click to expand...
Click to collapse
200mb cached means it's included in "free RAM". But it changes according to RAM demand/usage by apps. (Give "watch cat /proc/meminfo" command [without quotes] in a terminal to see; "watch" command runs what comes after that every 2 seconds). Maybe, by the time you switch from Chrome to terminal, Cached amount might have changed. (I think Chrome is a memory hog btw; haven't used it much).
If you really want to see what was in meminfo while chrome is on, I suggest to "record" meminfo values to a file real-time. Can do like this:
*Open terminal emulator
*go to /sdcard
Code:
cd sdcard
*append output of meminfo to a file every 2 seconds
Code:
watch cat /proc/meminfo >> memlog.txt
*leave terminal emulator in background and do whatever in chrome. Meminfo values should be recording in the background; terminal is not easily shutdown because it has a notification (apps having a notification saying that it's running has a high priority I think).
*then come back to terminal emulator and do a "ctrl+c" to break the recording (see terminal settings to know what's assigned as ctrl button)
*now you have a memlog.txt file in sdcard with meminfo output every 2 seconds (might look overwhelming ). If 2 seconds is too frequent, can adjust "watch" command accordingly (eg: watch -n 10 cat /proc/meminfo). Just give "watch" command to see it's usage.
You can go through that file leisurely to see how Cached etc have changed with time. Can filter with "grep" to avoid other gibberish.
Eg:
Code:
grep -w Cached: memlog.txt
This command outputs only the "Cached:" line in the file. [Remember: everything is case sensitive in Linux]. You can even write that output to another file for ease (can do for other values also):
Code:
grep -w Cached: memlog.txt >> Cached.txt
grep -w MemFree: memlog.txt >> MemFree.txt
grep -w Buffers: memlog.txt >> Buffers.txt
Then can go through these files leisurely to see min/max values. I think you can do lot of things with "grep". A Linux geek might even arrange these data to make a graph! @zeppelinrox is the man for this I think
Thanks for the very detailed reply
Actually I was doing the "cat /proc/meminfo" command on the computer using adb on the computer, so switching apps wouldn't interfere. ("watch cat /proc/meminfo" doesn't work for some reason, it doesn't output anything but the actual date). And while looking at Chrome with 2 heavy desktop websites, it was showing ~220 MB at Cached. It doesn't ever go below 180 MB...
Ok.
Dunno exactly what's wrong there.. Just remembered a part from kernel sources I've mentioned in OP:
The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate...
Click to expand...
Click to collapse
Maybe part of Cached is "locked"?? Can do a reboot and see whether the situation persists (if not done already).
First, a short story
After installing a chroot debian on my s2 I noticed that vlc player isn't working.
Sadly it took me several weeks to notice that sound in general wasn't working at all.
Problem: There was simply nowhere to output the sound.
So I tried to get alsa working from chroot to get some form of audio output.
and here it is.
ALSA ON CHROOT LINUX
The bumpy road to half broken (and therefore other half working) linux audio
Once you have a working chroot (with correct mounts that is), download and install the following packages:
Code:
alsa-base alsa-oss alsa-utils
Now run
Code:
alsamixer
to open the alsa sound mixer.
There you should unmute
Code:
DL1 MM_EXT DL1 Mixer Multimedia DL1 PDM
Then set
Code:
HS Left
and
Code:
HS Right
to
Code:
HS DAC
This should enable headset output
ALso unmute
Code:
Earphone
to well....use the Earphone speaker.
To enable the Main speaker, unmute
Code:
DL2 Mixer Multimedia DL2 Mono
And set
Code:
HF Right
and
Code:
HF Left
to
Code:
HF DAC
For other devices, this section will be different. Just look through alsamixer and try to make sense of the countless options there.
Finished more or less.
Now you can play audio from chroot.:victory:
Notice: If you run any sound from android or plug the headset in/out, you need to reapply these settings.
To avoid that I run a script that continously re-enables the mentioned settings. (mainly the headset)
It looks something like this
Code:
#!/bin/bash
while true; do
[INDENT]
amixer -c 0 csent numid=74 1
amixer -c 0 csent numid=73 1
amixer -c 0 csent numid=35 1
amixer -c 0 csent numid=52 1
amixer -c 0 csent numid=33 1
sleep 0.5
[/INDENT]
done
This probably isn't the best way of doing it (it might actually be the worst), but it works.
It might put load on the cpu or it might not, but for me, running this decreases my SoD frequency. (idek why)
Also the best way to run the script is a few seconds after the system started using the "nohup" command. That way you can run it and close the terminal and it will still be active. To kill it, search its pid using
Code:
ps -x
and kill it with
Code:
kill (insert pid here)
If you want you can also run it as a start up script.
Though if you do that, you might see that it runs but doesn't do anything.
Don't panic. Or do if you want to.
But just restart the script anyways.
OPTIONAL: (because I force you to use the stuff above)
We can play no more than ONE audio source at a time
Soloution: PulseAudio
(I will fill this shortly....)
(there is also MPD which works...)
So for now we have
Solution 2: Dmixer
Dmixer is what it name sounds like. It downmixes multiple sources into a single audio stream.
And it works (sometimes).
So here is how to.
Simply copy the content of the file below into a new file called .asoundrc in /home/username
Code:
pcm.!default {
type plug
slave.pcm "dmixer"
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
}
bindings {
0 0
1 1
}
}
ctl.dmixer {
type hw
card 0
}
This one is mainly pulled directly from the alsa project site and should work most of the time.
hw:0,0 might need changing on different devices. Same with card 0.
run
Code:
aplay -l
and use that to find the correct card and device.
???
The standard: I am not responsible for anything that happens to you, your phone or anything else.
Also I didn't invent any of this stuff myself. All credit goes to the original developers.
I just wrote this guide (if you can call it that)
Oh...and if you can't understand my english, well.... I'm sorry but i can't do better.
ruleh said:
First, a short story
After installing a chroot debian on my s2 I noticed that vlc player isn't working.
Sadly it took me several weeks to notice that sound in general wasn't working at all.
Problem: There was simply nowhere to output the sound.
So I tried to get alsa working from chroot to get some form of audio output.
and here it is.
ALSA ON CHROOT LINUX
The bumpy road to half broken (and therefore other half working) linux audio
Once you have a working chroot (with correct mounts that is), download and install the following packages:
Code:
alsa-base alsa-oss alsa-utils
Now run
Code:
alsamixer
to open the alsa sound mixer.
There you should unmute
Code:
DL1 MM_EXT DL1 Mixer Multimedia DL1 PDM
Then set
Code:
HS Left
and
Code:
HS Right
to
Code:
HS DAC
This should enable headset output
ALso unmute
Code:
Earphone
to well....use the Earphone speaker.
To enable the Main speaker, unmute
Code:
DL2 Mixer Multimedia DL2 Mono
And set
Code:
HF Right
and
Code:
HF Left
to
Code:
HF DAC
For other devices, this section will be different. Just look through alsamixer and try to make sense of the countless options there.
Finished more or less.
Now you can play audio from chroot.:victory:
Notice: If you run any sound from android or plug the headset in/out, you need to reapply these settings.
To avoid that I run a script that continously re-enables the mentioned settings. (mainly the headset)
It looks something like this
Code:
#!/bin/bash
while true; do
[INDENT]
amixer -c 0 csent numid=74 1
amixer -c 0 csent numid=73 1
amixer -c 0 csent numid=35 1
amixer -c 0 csent numid=52 1
amixer -c 0 csent numid=33 1
sleep 0.5
[/INDENT]
done
This probably isn't the best way of doing it (it might actually be the worst), but it works.
It might put load on the cpu or it might not, but for me, running this decreases my SoD frequency. (idek why)
Also the best way to run the script is a few seconds after the system started using the "nohup" command. That way you can run it and close the terminal and it will still be active. To kill it, search its pid using
Code:
ps -x
and kill it with
Code:
kill (insert pid here)
If you want you can also run it as a start up script.
Though if you do that, you might see that it runs but doesn't do anything.
Don't panic. Or do if you want to.
But just restart the script anyways.
OPTIONAL: (because I force you to use the stuff above)
We can play no more than ONE audio source at a time
Soloution: PulseAudio
Or so I thought... I can't seem to get it working. If someone can, please tell me how to.
So instead we have
Solution 2: Dmixer
Dmixer is what it name sounds like. It downmixes multiple sources into a single audio stream.
And it works (sometimes).
So here is how to.
Simply copy the content of the file below into a new file called .asoundrc in /home/username
Code:
pcm.!default {
type plug
slave.pcm "dmixer"
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
}
bindings {
0 0
1 1
}
}
ctl.dmixer {
type hw
card 0
}
This one is mainly pulled directly from the alsa project site and should work most of the time.
hw:0,0 might need changing on different devices. Same with card 0.
run
Code:
aplay -l
and use that to find the correct card and device.
???
The standard: I am not responsible for anything that happens to you, your phone or anything else.
Also I didn't invent any of this stuff myself. All credit goes to the original developers.
I just wrote this guide (if you can call it that)
Oh...and if you can't understand my english, well.... I'm sorry but i can't do better.
Click to expand...
Click to collapse
To use Pulseaudio, I found someone who used the Simple Protocol module to get sound and I'm now able to use MPD + MPDroid to play music from my Arch Linux chroot. Unfortunately, the playback get choppy when I open a on a single core phone with less that 1GB of RAM so if you have a better device, I'm sure the playback will be way better!
The phone I'm using is a Samsung Galaxy Ace II X (GT-S7560M) with LinuxDeploy (and CM11)
http://kaytat.com/blog/?page_id=301
TheST4RL said:
To use Pulseaudio, I found someone you used the Simple Protocol module to get sound and I'm now able to use MPD + MPDroid to play music from my Arch Linux chroot. Unfortunately, the playback get choppy when I open a on a single core phone with less that 1GB of RAM so if you have a better device, I'm sure the playback will be way better!
The phone I'm using is a Samsung Galaxy Ace II X (GT-S7560M) with LinuxDeploy (and CM11)
http://kaytat.com/blog/?page_id=301
Click to expand...
Click to collapse
I wish you would have told me this yesterday.
I spend all of yesterday doing the simple protocol player method. (It works on a quadcore 4gb phone.)
However I still prefer the alsa method on low performance phones because it has nearly no latency and is very smooth.
I will try the MPD method and see how it goes.
ruleh said:
I wish you would have told me this yesterday.
I spend all of yesterday doing the simple protocol player method. (It works on a quadcore 4gb phone.)
However I still prefer the alsa method on low performance phones because it has nearly no latency and is very smooth.
I will try the MPD method and see how it goes.
Click to expand...
Click to collapse
I tried ALSA today and it's working but the playback is super choppy and when I listen to music the audio is slower when compared to the real one. Pulseaudio may have some latency but if you're listening to music, it doesn't really matters.
#NOTE: For quick taste go to post#4. That mini-guide -for the time being- only works on Samsung's Kitkat. For Best Performance running Samsung's KitKat is recommended
Also (just so that to be clear), no matter which version of this guide that you are going to follow, you'd need at least 5GB of free Internal Storage.
INTRO
Since the advent of the Microsoft Surface Pro line we had a great "great-computer/mediocre-tablet" combo on one hand, and through the already running iPad line we had a "great-tablet/bad-computer" on the other hand.
One of the primary reasons to buy into the Note tablet line is because I always thought that it conveniently sandwiches itself between the above categories hopefully avoiding the pitfalls of both. Sadly the reality was a bit further than that and our tablet seems to have taken equally the bad and the good of the above lines. I set to ameliorate part of those faults, since I mostly lack coding expertise or indeed deep knowledge of the Linux kernel I created a ... patchy solution.
Sooo the following is a ... rather monumental guide/tutorial to set up Gui - Linux with acceptable performance on top of android in our devices. Since I'm running it "on top" it relies to the chroot method (it's been detailed in quite many posts). For simplicity's (and ... repeatability's) sake I'm using the "LinuxDeploy" app which can be found here (buy a beer to the creator, don't forget that he's practically giving away his software).
Ook, let me say right out of the bat that I could have had released a ready-made Linux image so that everybody could benefit instantly, or alternatively write a script to automate the process that I'm going to detail next.
Instead I decided against it, firstly because (as you will soon find out) this guide is a work in progress, so through exposing each individual step it can/would actually become better (hopefully through the help of more talented/knowledgeable individuals than I). Secondly many of the steps would most certainly break down, down the road (continuously changing software tend to do that to tutorials), yet since all/most steps would be exposed a simple tweak to them would save it...
Important Note: This particular Guide is tested to work on both KitKat and Lollipop (Samsung) Roms for P600. Even a slightly different setup may cause it to misbehave. So that's one more reason why I chose to expose the relevant steps (what/how they do). Hopefully slight tweaks to some of the steps would make Linux perfectly functional on all variants of Note tablet and their many differing roms.
PREPARATIONS
Let me move to the particulars then:
You'd definitely need root and a "Virtual Terminal" enabled kernel (I can't stress this enough), xposed framework/modules is optional (only needed for one work-around). I'm sure a mere Google search can tell you how to achieve the 1st and the 3rd requirement but the CONFIG_VT enabled kernel is a tougher nut to crack. Therefore I'm willing to make a list with VT_Enabled kernels for out tablet, for the time being I'll only be offering kernel based on Samsung Roms (many thanks to @xluco). Non-P600 guys should find an equivalent kernel on their own (or compile one for their own usage).
KitKat: http://forum.xda-developers.com/attachment.php?attachmentid=3686507 , reportedly Disabl0w's version works better
Lollipop: http://forum.xda-developers.com/attachment.php?attachmentid=3686508
Marshmallow: I'm willing to post a VT Enabled kernel here when (and if) our device reach nightly status on CM13.
BEWARE those kernels are for P600 (wifi version of Note 10.1 2014). I take no responsibility if you've bricked your device by flashing it to the wrong device/setup.
Additionally those apps would be needed:
a) Meefik's Busybox v1.24.1 (Download the apk and install it, once installed, do as follows: open the app -> tap "install" in the lower right corner -> OK)
b) LinuxDeploy v1.5.6 (Download the apk and install it, once installed, open the app -> press the "menu" button -> tap "settings" -> tap "update env" -> OK )
c) Linux Deploy's companion app (LinuxCanvas I named it)
d) Privilege Terminal (Terminal Emulator is more feature packed but for the purposes of this guide Privilege Terminal is preferable as you can paste content coming from HTML pages, directly to it)
e) Lastly, certain Configuration Files are needed (download and extract the contents to the root of your internal storage)
THE GUIDE
The guide is really made out of 11 simple steps. You can "blindly" follow them and you'd get a fully working image. Preferably, though, you'd also read the explanations of each step. I've included them because (as mentioned above) this guide is a work in progress. So making you privy to what each step does would hopefully lead to a better guide. Probably one with less steps and even more functionality. The explanation part would also help you debug a step if (for some reason) it didn't work correctly to your device.
So on we go:
1) Copy xorg.conf:
a) Open Privilege Terminal
b) Run:
Code:
su;
cp /data/media/0/Linux/res/xorg.conf /data/data/ru.meefik.linuxdeploy/files/share;
echo"";
Explanation:
The xorg.conf file is basically where input-output devices are mapped. I've modified it to support as many as 8 input devices as well as to support the S-Pen (w right click function!). If you want to add more devices, or for some reason your S-pen does not work and/or you prefer the S-pen button to work as middle click you can modify by navigating to Linux/res/xorg.conf (you can open it with any text editor). To find to which events your devices are mapped you have to run cat /proc/bus/input/devices in Terminal Emulator. From that you could see to which event you can map your S-Pen and/or the rest of your external devices. As it stands I have S-pen as event8 (the default in most roms) and my keyboard and mouse as 10 and 11 respectively (that's how they get mapped in my devices, but they may get mapped differently to yours).
Note: Apart from S-pen everything else doesn't *have to* be mapped precisely (even if your mouse is called "keyboard" it would still work"). Also as a general heads up please connect your devices after device boot as if you have them connected already (say through OTG connection) as the device boots, the handler numbering would be messed up (for example the mouse could be event5 and s-pen event10)
2) Create a Linux image
a) Open Linux Deploy
b) Navigate to properties (Arrow showing "down") and choose the following Configuration:
Use the Default option to all except:
To Distribution Suite: Wheezy
To Installation Path: change the "/storage/emulated" part to "/data/media" (everything else stays as is)
To Select components: Tick X server, untick VNC server
To Graphics subsystem: choose Framebufer
To GUI settings: choose DPI = 230 (or anything higher if it suits you) and untick Force Refresh
To Custom Mounts: Tick it
To Mount Points: Delete the extant mount points (select them -> press "menu" -> delete) and add the following:
/data/media/0
/mnt/media_rw/extSdCard
/mnt/media_rw/UsbDriveA
/mnt/media_rw/UsbDriveB
If you want to add support for more External devices you can add up to 4 more ( /mnt/media_rw/UsbDriveC - /mnt/media_rw/UsbDriveF )
c) Return to Properties' main menu and Tap Install (first selection)
d) Wait (quite a bit) until it reads "<<< install". It should read "processing triggers" on the line just before it, if not, reboot and follow step (c) again (re-install)Explanation:
I was only able to make Debian and Ubuntu variants work with our device. In principle everything should (and can) work as well, but since I'm mostly accustomed to Debian's eco-system I never bothered to investigate. Similarly (from windows environments) only LXDE and XFCE reliably work (KDE and Gnome technically "work" with Debian too but they're ultra slow). For this instance I chose Debian Wheezy + LXDE due to GUI performance issues mostly, every other disto/window manager causes considerable lag in window placement. I used to use Debbian Jessie + XFCE, love XFCE's features (sessions, Window snap), but the ultra-slow window placement mostly killed the GUI experience that I was after. So I reverted to the less featured but lighter on resources LXDE.
Note: Our tablet's internal SDcard is/would be mounted to /mnt/0 when inside the chroot Linux environment ( similarly External SDcard -> /mnt/extSdCard , 1st external Storage -> /mnt/UsbDriveA , etc ). If you're on another device (not P600) running the command "mount" from Terminal is going to give you where in which paths your storage mounts to, in which case you'd have to change the mount points in LinuxDeploy accordingly.
3) After the linux image is created (Linux deploy says "<<< install") go to Linux's Shell:
a) Go back to Privilege Terminal
b) Run:
Code:
/data/data/ru.meefik.linuxdeploy/files/bin/linuxdeploy shell;
echo"";
Explanation:
It starts the Shell of the freshly installed image
3.5) This step is only relevant to those running Stock Samsung 5.1.1 rom. DO-NOT-RUN it if you're on any other version. Giving root permissions to the default user ("android"):
Run:
Code:
sed -i '/android/c\android:x:0:5000:x:/mnt/0/Linux/Home:/bin/bash' /etc/passwd;
echo"";
Explanation:
Due to complication with SELinux permission (from Android 5 and up most possibly), as a workaround I had to give root permissions to user "Android". See Issue "8" in Post #3 for more information.
4) Change Home folder's path:
Run the following commands:
Code:
usermod android -d /mnt/0/Linux/Home;
rm -rf /mnt/0/Linux/Home;
mkdir /mnt/0/Linux/Home;
cp -a /home/android/. /mnt/0/Linux/Home;
echo"";
Explanation:
Technically this step is optional but I would strongly advice against ignoring it as it allows an 1:1 communication between Android and Linux's user files. By choosing a folder that is visible by android file managers (/Linux/Home) it allows for the user to instantly manipulate the data he/she just created within Linux. For example a document file that is saved on (Linux) Desktop is easily visible by navigating to Linux/Home/Desktop or better yet it's automatically detected by the relevant app (for example a music app would "see" your music Folders, a video app your "Linux videos", etc). Additionally it uses the /sdcard partition which is close to 28GB in size, instead of the 4GB micro-partition that LinuxDeploy created (which is better used by the software that you're going to install there).
5) Apply basic HiDPI fixes:
Run:
Code:
cp /mnt/0/Linux/res/.gtkrc-2.0 /mnt/0/Linux/Home/;
echo"";
Explanation:
It solves basic issues that arise from the HiDPI environment of our devices. Things like CheckBoxes, ScrollBars, even Double Click behavior. The changes are only detectable on GTK2 software. Since all the software I've been using is based on GTK2, it is enough for me. However if you're using a GTK3 based application please by all means recommend of a way to make similar changes to GTK3 applications (I think equivalent -system wide- changes happen when one modifies the /etc/gtk-3.0/settings.ini file). Lastly if the dimensions/changes are not to your taste you can always try different ones by changing their numeric values on Linux/res/.gtkrc-2.0 file (editable by any text editor, beware it's a hidden file) and then rerun this step. What numeric value is controlling what, is rather straightforward due to the naming that it follows. So happy editing!
6) Enable GUI Repaint:
Run:
Code:
chmod +x /mnt/0/Linux/bin/logout;
echo"";
Explanation:
It fully enables the menu button within the LinuxCanvas app (it redraws the environment). I could bundle the script with my "LinuxCanvas" apps, but I wanted to make it modifiable (for example right now it kills the LXsession), but if you were to use a different Window manager you'd probably need to use a different command) and since my app creation powers are very (very!) basic, I simply exposed an internal part of my app. It can be found in "Linux/bin/logout". You can edit it with any text editor (again you'd have to rerun this step after editing is done).
7) Resize Windows Borders:
Run:
Code:
chmod +x /mnt/0/Linux/bin/resizeBorder; chmod +x /mnt/0/Linux/bin/revertBorder; /mnt/0/Linux/bin/resizeBorder;
echo"";
Explanation:
Another Fix needed due to the high DPI of our devices. It basically makes the borders of the windows that much thicker. Since it obviously makes the look of the environment less easy to the eyes I would welcome any work-around. Also you can run
Code:
/mnt/0/Linux/bin/revertBorder
(from within linuxdeploy's shell) to return the Windows borders to their initial size if you're so much bothered about the ... foul look (again I'd advice against it as it'd kill some of the ease of use of window placement/resize). If you want differently sized borders you can always edit the script (found in Linux/bin/resizeBorder) with the text editor of your choice. My current value is 10 pixels you can change it to whatever. Also you don't have to change it for every theme, just the one you're using. Again, I'm open to recommendations (for example what value do you think is better for usability?)
8) Fix Mouse Cursor size:
Run:
Code:
sed -i '/CursorThemeSize/c\iGtk/CursorThemeSize=58' /etc/xdg/lxsession/LXDE/desktop.conf;
echo"";
Explanation:
It makes the Cursor bigger. It doesn't always work. I have to investigate, but I can't be bothered since it rarely (ever) caused me any issues. Still I'd welcome it if someone is willing to investigate and see why it works only some of the times (it probably has to do with boot sequence/times).
9) Install basic Components:
Run the following:
Code:
apt-get update;
sudo -u android sudo apt-get install -y samba gvfs-bin gvfs-backends zip iceweasel xfce4-mixer dmz-cursor-theme gstreamer0.10-alsa;
echo"";
Explanation:
Though the above shell command we add some basic functionality to our Linux installation, like a Samba server (network places for the Windows guys), a browser (Iceweasel is called in Debian) and a virtual keyboard (very important for those using only the S-pen).
10) Exit:
Close Privilege Terminal (press "CLOSE" on the upper right of the app and then "OK")Explanation:
We're better off to shut down this particular shell instance as it may mess up with the booting of our Linux image later
11) Start Linux:
a) Open "LinuxCanvas"
b) Press Volume Up, wait a bit and voila! (if it doesn't work the first time, press the "menu" button to repaint)Explanation:
The App is included below this post. This is a veeery basic app (my app-creating prowess is close to zero) which acts as a companion to LinuxDeploy. LinuxDeploy was/is mostly created to fascilitate the XServer/VNC crowd, but the "Framebuffer" crowd has been left a bit in the cold. With as a result the "Framebuffer" functionality of LinuxDeploy to be quite basic (it only creates a black frame and that's it). So I added a bit more than that (it's the super-duper edition ). Orientation is locked, back, Escape buttons blocked (they cause issues). Also:
Volume up -> starts the chroot environment
Volume down -> kills it ("un-chroot")
Menu button -> "redraws" the graphical environment
And that's it. The caveat is of course (as a companion app to LinuxDeploy) that it is heavily dependent to LinuxDeploy, so any change that the developers would choose to make would -predictably- break functionality, so please PM me if/when that will happen. Also I'm a very un-creative person when it comes to App-creation so I would be veeery happy if another user was to take this task from me (someone who -hopefully- would make a much better featured and beautiful companion app), so updating this guide would be the only task that would remain to me.
As you may be able to see, by (as of) now you're good to go and you can fully work on your brand new Desktop environment. However I would like to add some less essential tips/fixes on my second post as well as a list with the remaining issues and workarounds to them (in my third post).
In my first post I described how you can get a relatively well performing Desktop envrironment working on our Samsung Note tablets. This post acts as a companion. Most of the tips here are either completely optional or easy to figure out. Still they may seem useful to many users so I include them here anyhow. As always any recommendations to improve on them or any additional tips would be well considered.
1) DPI Tips and seting up Volume Control :
a) Right click (S-pen button press) on Start menu -> Panel Settings -> Height: 70 and Icon: 70 -> Panel Applets (tab) -> Application Launch Bar (the first one) -> Edit -> Florence (extend Universal Access) -> Add -> Close -> Application Launch Bar (you have to scroll down for this one) -> Edit -> Mixer (extend Sound & Video) -> Add -> Close -> Close
b) LXDE Button -> Preferences -> OpenBox Configuration Manager -> Appearance -> change all to 13-15 (except Active/Inactive on-screen Display: 11-12 ) -> Close
c) File Manager (Black Icon) -> Edit -> Preferences -> Display (Tab) -> Size of Big Icons (96), Size of Small Icons (48), Size of Thumbnails (256), Size of Side Pane Icons (48) -> Close
d) Click the gear looking icon (in the lower-right part of the screen) -> Select Controls... -> Tick Speaker Digital -> Close -> QuitExplanation:
Those are easy-to-figure but I think essential changes that need to be done so that to make the LXDE enironment more functional on our HiDpi (and often keyboardless) screen. I would be glad to add more HiDPI changes accesible through LXDE's GUI (that you'd think that may be important).
2) If you want Linux's user data to be readable/writable/cacheable by/from your android apps:
Run the following from Privilege Terminal:
Code:
su;
find /data/media/0/Linux/Home -type d -exec chmod 777 {} \;
find /data/media/0/Linux/Home -type f -exec chmod 777 {} \;
echo"";
Note: This step has to be re-run if for whatever reason some of your Linux user-files are -again- not accessible from Android.Explanation:
While the folder Linux/Home contains all your personal data from Linux it's only accessible from within Linux. That's an obvious security feature, but it may also affect the practicality of running Desktop Linux side by side with Android. By allowing permissions to all "your" files they can be literally read by everyone/everything which also includes your android Apps (for example your edited photos could be "seen" from within your android gallery) which can be extremely useful to many, as well as an easy way to send/save files from Android to Linux, too.
3) In case you want to remove android's mouse cursor (for more experienced users, as inability to follow the steps will -well softbrick your device. BEWARE! )
a) If you're using Windows (if not equivalent steps have to be followed on your mac/linux) unzip the adb folder (included to the bottom of this post) to C:\ and install the samsung drivers (if you haven't already): http://developer.samsung.com/technical-doc/view.do?v=T000000117
b) Reboot your tablet to recovery and connect it to your PC
c) mount /system (from mounts and storage menu or similar). Disable MTP too, if applicable
d) On your PC navigate to C:\adb from command line
e) run:
Code:
adb pull /system/framework/framework-res.apk
f) Navigate to C:\adb, create a copy of framework-res.apk and rename it to framework-res.bak
g) Open the framework-res.apk (the original) with WinRar (or similar) and navigate to res\drawable-sw800dp-xhdpi or res\drawable-xhdpi-v4 and rename pointer_arrow.png to pointer_arrow.bak . Close Winrar
h) Back to the command line run the following
Code:
adb push framework-res.apk /system/framework
adb push framework-res.bak /system/framework
adb shell chmod 0755 /system/framework/framework-res.apk
adb reboot
After having followed the above guide succesfully you can restore the mouse cursor and then kill it again as easily as described below (those commands reboot the device, so beware)
To restore the cursor (after having it killed) in Privilege Terminal run:
Code:
su;
mount -o rw,remount /system; mv /system/framework/framework-res.apk /system/framework/framework-res ; mv /system/framework/framework-res.bak /system/framework/framework-res.apk ; chmod 0755 /system/framework/framework-res.apk; reboot;
echo"";
To kill the cursor (after having it restored) in Privilege Terminal run:
Code:
su;
mount -o rw,remount /system; mv /system/framework/framework-res.apk /system/framework/framework-res.bak ; mv /system/framework/framework-res /system/framework/framework-res.apk; chmod 0755 /system/framework/framework-res.apk; reboot;
echo"";
Explanation:
The above is to kill android's mouse cursor so that when you connect a mouse you won't have two mouse cursors on-screen. It would have been a far less dangerous endeavor if I was to include a flashable zip file doing those changes, but I much prefer to expose the way by which you can kill android's cursor, so that any user would be able to do the same on any other version of android that he or she is willing to run Linux on. Also as a bonus the user is just "one" shell command away from reverting his mouser cursor. Obviously any bricked devices resulted from this method is the user's responsibility and the user's alone (however it's a very recoverable situation)
4) Tips to make browsing easier when you'd want to use the Pen Exclusively:
a) Open the browser (Iceweasel) while in Linux
b) Type on the URL bar -> about:config-> "I'll be careful, I promise"
c) Search for: browser.search.showOneOffButtons . Change its Value from true to false (double click on it)
d) go to: ("hamburger" button ->)preferences -> privacy (tab) -> Iceweasel will: -> Use Custom settings for history -> Untick Remember search and form history
e) Right click on the search bar and untick "show suggestions"
f) Restart IceweaselExplanation:
It kills Firefox/Iceweasel's fancy search so typing on the search bar when using pen/virtual keyboard is twice as fast. When I found out about that it completely transformed my usage patters, now I often "quick boot" to Linux if I want to browse to a web-site that android's mobile browser refuse to have rendered. Oh BTW, if you followed the "DPI Tips" (tip No1) the virtual keyboard (florence) can be found to the left of the "start button" (for quick reference).
5) In case you want a multilanguage keyboard:
a) Enter LinuxDeploy's shell by running the following on Privilege Terminal:
Code:
su;
/data/data/ru.meefik.linuxdeploy/files/bin/linuxdeploy shell;
echo"";
b) Run the following command. Where xx your choice of language: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes (only 639-1 codes are applicable)
Code:
echo 'setxkbmap -option grp:ctrl_shift_toggle "us,[B]xx[/B]"' >> /etc/xdg/lxsession/LXDE/autostart
c) when back in Linux/LXDE do the following:
Right click on Start menu -> Add/Remove Panel Items -> Add -> Keyboard Layout Switcher -> Add -> CloseExplanation:
It allows to change keyboard's layouts in both your virtual keyboard (by tapping the flag icon) and physical keyboard (by pressing ctrl+shift). I have not tried any other key combinations other than ctrl+shift so I don't know how well they'll work but you're welcome to try/modify (just replace the ctrl_shift part of the command with any other combination, as you're following the steps).
6) Kernel level changes (Please read the expanation, those changes may well cause instability! BEWARE!):
To achieve those you'd need the Donate version of TricksterMod (much recommended app to own)
Ultra Aggressive OOM Values:
a) You can access them by navigating to General (tab) -> MinFree Control while in Tricker Mod
b) When there please save the default values ( tap on "untitled", then "save" and name it default -> ok )
c) Then proceed to change the values as follows:
Foreground = 384
Visible = 412
Secondary Server = 480
Hidden App = 512
Content Provider= 640
Empty App = 768
d) Again save them as "Aggressive" ( tap on "untitled", then "save" and name it aggressive -> ok )
e) Tap on the tick (that has just showed up) to validate the changes Undervolting
a) If your kernel does not support it you won't find it. If it does, you'd find it by choosing the "Specific" tab (MTU Voltages).
b) Similarly as above please save the default values ( tap on "untitled", then "save" and name it default -> ok )
c) Proceed to change the values. I won't include any here as every SoC is different, but typically the greatest clock the greatest undervolt is achievable. As an example I started by lowering my volts by around 100 mvolts in my highest clocks, and progressively less in my lower clocks (for example 1900Mhz was lower by 125 mvolts, 1800Mhz by 100mvolts, etc). You (the user) are the the only one who can find the best volts for your device (low yet stable). If your device starts to get unstable (restarts without notice) you'd have to choose higher volts (you went too low), etc.
d) Try different volt levels (Tap on the tick on each of your attemps)
e) When you found stable enough (hopefully low enough) voltages, save them ( tap on "untitled", then "save" and name it low -> ok ) As an add-on you can "tell" TrickerMod to boot with the settings you just chose (menu button -> tick on "Kernel Settings"). Else you'd have to manually choose "your profiles" with every reboot.Explanation:
I struggled very much before deciding to add the above section. I know it may cause instability to many users (the undervolt) and/or significantly lower the capacity of the device to keep apps on system's RAM (due to the high OOM values) but eventually I decided against not including it. The reason is that Linux/Desktop usage can be characteristically RAM and battery hungry. That makes the above tip(s) less of an often uneeded option and more of a necessity, especially to those willing to make heavy use of the Desktop environment. Basically what running a whole OS via chroot means is that you'd need most of the resources of the device. That can only be done by using uncharacteristically high "killing" thresholds.
The OOM values -above- basically mean that the device would kill significantly more background processes than it is expected. In fact I've experimented with many values and the above are the only ones that I've found to (still) be acceptably "low" yet allowing seamless use of the chroot/Linux environment. I could go lower but I start to see hits in performance. Also keep in mind that those values are also dependant on the rom one uses. There are other Roms that "react" better on low ram envrironments than mine. So -obviously- those values are not panacea, but I would be surprised if significantly lower values were not to harm the "Linux experience" no matter the rom.
So -yeah- background processes would be killed left and right. The upside is more RAM for Linux use, less battery leaking from background processes and surprisingly better responsiveness in Android too. In fact that's the other reason why I've kept those values, I've never seen my tablet being as responsive than after adopting those values.Still depending on your usage patterns it may start killing some important background process of yours, in which case I'd advice lowering those values (but not way too much as it would impact Linux performance).
For undervolting (if you can do it) the story is very similar. It may well cause a more unstable system, but it greatly helps with performance and battery life. On Linux there are processes that are characteristically harder to the Processor than most of anything that can be found to a "consumption OS" like Android. This means that the high clocks of our device are used much more frequently, leading to a very much lower battery life, but worse of all overheating which leads to throttling (low performance) and even possibly lowers the SoC's lifespan. Undervolting sets to aleviate those issue. After undervolting my processor I'm getting much better *sustained* performance and while on Linux quite better battery life too, about 30-40 minutes more! I like to say that undervolting is the "overclocking of mobiles", as it achieves the same end-result by aleviating or -even- eliminating throttling, one of the most important causes of low performance on mobiles.
7) Kill multi-window before starting Linux:
Well that's very straight forward, just toggle multiwindow off on quick settings.
Explanation: Ram (as explained above) is a precious commodity for "serious" Desktop work, so about ~100 MB of RAM is being freed in that way. But most importantly it disallows accidental activation of the multi-window panel which is a quite frustrating experience when it happens while "Desktoping".
This concludes my second post. The following (and final) one is all about the things that still have to be done (where I'd need you -guys- more) and also some work-arounds that I found to those.
With two posts above us, this guide is mostly concluded. Still it may probably be worth the while to read a bit more as in here I include a few workarounds. Which while they're not true solutions in any shape or form, they may make the experience juuust seamless enough...
BUGS/ISSUES
1) No Hardware Acceleration (Biggest)
Explanation:
This is pretty much the elephant in the room. Without a solution to this everything written here is/would be a waste for many guys. Especially those willing to use rendering software, or generally care about media consumption/creation. Unfortunately this is also (by far) the toughest nut to crack. It most probably requires knowledge far greater than my own (even though I must admit that I never seriously considered "solving" this issue). In fact it is here that I could use as much help as possible. If we solve this, suddenly our tablet is viable as a laptop replacement for most uses ... In sort: Solution pending, no workaround in sight, zip, nothing ... it's the Chuck Norris of our problems
2) No ability to redraw (Biggie)
Explanation:
Another big issue. Basically if you lose focus (say press home by mistake) you cannot regain it. Every process continues on the background, of course, your picture is lost forever though, and it's mostly non-recoverable. In the workaround section I have posted the very hacky solution that I'm using (which is no way, shape or form a true solution). This issue's importance is somewhat tempered -though- by the fact that our tablet already operates in a low-Ram environment so putting the chroot/Linux environment to the background for a bit would probably cause a lot of its processes to be eventually killed by Android's ram manager as it would try to regain Ram for the foreground app. Also it's probably easier to solve but -again- it requires knowledge beyond my own. The issue has to do with Android and chroot/Linux "fighting" for the framebuffer's exclusivity. Once Android gains it, it never gives it back (selfish dastard ).
3) Devices cannot be detected "on-the-fly"
Explanation:
A big issue still, but a lesser one than the above two. Again it has to do with the GNU/Linux lacking some kind of daemon constantly "sweeping the place" so that to detect changes. I have not looked deeply in this issue as the workaround has been enough for me. Maybe not that hard of an issue to be solved. Again I'd welcome any recommendation(s).
4) No touch support:
Explanation:
This is a big issue at first glance, I happen to think that it is one of the smallest ones, especially if you think about it: GNU/Linux GUI is/was created for a highly accurate pointing device and the finger(s) is certainly not it. Similarly right click is very hard to be performed by hand (probably via a gesture) with much accuracy. Both of those issues are solved by the pointing device we already own, the s-pen. I find the pen to be faster to a HiDPI Linux environment simply because you make less mistakes with it. Also it supports hovering, so it simulates a mouse pointer on-the-go, much better than a hand. Still touch support would help with typing on the virtual keyboard (it would have been faster due to multi-touch) and scrolling (again multi-touching). It's due to those issues that I include the lack of touch support as an issue. Again I'd welcome it if anyone was to come with (any) ideas regarding (adding) touch support. BTW simply mapping the relevant event on xorg.cong doesn't work, don't know why.
5) Pressing Middle mouse Button returns to Home (thus kills the picture)
Explanation:
It's connected to problem No2. This is more of an annoyance (though) than a true issue as pressing the middle button is not of much use on GNU/Linux's GUI environments. Still I'm using a workaround (posted below) that completely eliminates this issue (sadly it needs xposed).
6) No native way to control brightness (there's probably a solution, never bothered to investigate)
Explanation:
Again mostly an annoyance, as there are alternative ways to control those. A work-around is posted below
7) HiDPI is not well-supported by a lot of Linux's Software.
Explanation:
Depending on your kind of use you may find yourself facing with a software that does not scale well to the ultra-high resolution of our tablets. That would mean veeery small GUI elements and an almost inability to use it. Thankfully most have workarounds (to some it is in-built, to others it requires the installation of some HiDPI theme, to others yet editing config files would do the trick). I regard it less of a problem that it initially seems because by now many/most small laptops are offering a HiDPI screen with as a result forcing most Linux Software maintainers to get by the times and either fix the issue with their particular software, or at least offer a work-around. Obviously I'm not going to post any of those here as the list would be non-exhaustive. If someone wants to create a post (and maintain it) with HiDPI workarounds for many/most of the popular software I'd be glad to link it here (as a work-around)
8) SUDO cannot be be used by regular users on Samsung's Lollipop
Explanation:
Due to changes in SeLinux policy implemented from Android 5 and on permission is denied when a regular use is trying to use the SUDO command
WORKAROUNDS:
To Issue 2) Pressing the menu button. It re-draws the LXSession. The caveat is that you lose all your progress (it's a sort of a "soft-reboot").
To Issue 3) Input devices are detected with a simple redraw (pressing the menu button), but for external storage you have to wait a bit (around 10 seconds after you've connected it) and *then* redraw
To Issue 5) The solution to that is hacky (as it needs xposed) but it works: You'd need Xposed Additions Pro to disable home while on LinuxCanvas App, plus a gesture to get back home (you do that using the gesture navigation plugin)
To Issue 6) You can control brightness through the notification center as you would in any other app.
To Issue 8) Give root permissions to chroot's main user ("android"). Unfortunately that's an obvious security concern and I'm feeling quite uneasy to have to do that. I'd feel much better if this permission issue would be resolved.
FEATURES THAT I HAVEN'T CHECKED:
1) External devices apart from External Storage, Mice and Keyboards.
2) Bluetooth File transfer
3) Cameras
4) GPS
5) IrDA
Explanation:
The above are all tablet functionality that I have not checked.
If I was to venture a guess I would say that they won't work "out of the box", but everyone is free to check. I'm sure there's some workaround to let them work (at least partly), but I had no need of them so I have not investigated further.
INSTEAD OF CONCLUSION:
With the guide concluded I would like to write (instead of a conclusion) the reason that I chose to "run" a desktop environment as above (chroot with the GUI rendered on Android's framebuffer). It's obviously neither the easiest to setup (running the GUI on top of an android-bornt Xserver is far easier to set-up, 3 steps, literally) nor the most efficient (a dual boot setup would be the ideal as far as efficient use of the tablet's resources go).
Well let me "combat" the above arguments one by one. Firstly choosing to use the android's Framebuffer as the renderer: Obviously it's hard to setup at it needs a "Virtual Terminal" enabled kernel (not easy to be found for those who are not into kernel compiling), but, maybe most importantly, it disallows of an easy way to change the resolution (it uses the screen's native resolution) leading to HiDPI issues.
Well, the reason to render on the Framebuffer instead of an Xserver app (like Xserver XSDL) is ... frankly responsiveness. Rendering directly to the framebuffer bypasses all the "lag" caused by the android implementation running beneath. The greatest example is typing responsiveness. Typing on our Note (using a phtsical keyboard), as you may have found out, is a tedious process. There's a very visible latency which causes constant errors when fast typing. This is completely solved by directly rendering on the Framebuffer (hence directly taking input events from kernel events, bypassing Android's stack). For a guy who types a lot, the difference is day and night, it finally turned my Android Tablet into a work horse. Of course the great increase in responsiveness carries over to the rest of the GUI as well.
Let me, then, tackle the second source of scepticism to the solution that I recommended in here. To many a true dual-boot is the holy grail of their idea of how/what an android tablet doubling as a productivity machine is. To me it's not, I've bought an android tablet not because I want a Linux laptop. In fact I already have one. No, I bought it *because of* android and having to "kill" it so that to boot my "productive" environment doesn't really make any sense to me. Sure I can always boot back to Android, but actually most people are not into distinct "productivity" and/or "consuming" modes. In fact most of my usage patterns are all over the place. For example I'm writing something for my paper, but then I want to carefully study another paper, heck I may want to watch a movie in the middle of all this. Sure I can do those two on Linux, but what's the point if I have a far more capable "content consumption" OS lying just beneath? No, my ideal mobile machine is one that produces in the best way possible but one that also lets me consume information in the best way possible.
I bought a tablet *because* I want to consume information much more efficently than what my laptop/PC would had allowed me to. I want to use the "PocketBook" app to read and MxPlayer to watch a movie from my NAS collection, but then I also want to get back to my fully featured IDE. A dual boot absolutely kills the flow (having to constantly reboot). In fact Microsoft's vision in this (Project Continuum) is I think ideal. Still Project Continuum is far from being practical (for the time being) and it may never become, simply because Developers may not support it, so the next best thing is to have my "Productiviy OS" and "Consumption OS" side-by-side in fact that is very much the reason that I've included "step 4" to my guide as well as the "redraw" option. I think it gives flight to the experience (having different "scopes" of experience).
THANKS TO:
Pretty much to everyone from the Android scene that let us enjoy such high quality experience via rooting, kernel modifications, etc. People like @Chainfire, @rovo89 (and many, many others) are indispensable for their services, it goes without saying.
Similarly thanks to everyone from the Open Source community and in particular the Linux Kernel, starting from Linus Torvalds all the way down to the mere user who's recommending a fix. And of course to the guys developing the software running on the Linux kernel (without it, it would have been useless to most).
Also thanks to @xluco for providing a feature-packed (and lately very stable) kernel for me to play with.
Oh and thanks to you guys, hopefully helping to fix (on the longer or shorter run) this mess of a guide. *Any* input would be much appeciated.
OK. CYa. I'm signing off (pheewwww)
Mini-Guide
INTRO
While it kind of saddens me since I've tried (and I think succeeded) to make the guide as simple as possible all the while explaining the steps, the low interest to it lead me to decide to post also post a quick guide (instead of a full guide) that makes no use of shell commands.
There are good news and bad news due to this. The good news is that the guide has contracted further yet its end result really does give a quick taste of well running Linux on our tablet. To sweeten the deal the guide posted in this post gives a quick taste to most devices running a VT (virtual terminal) enabled kernel, no matter the brand and/or Android version.
The bad news is that due to the little interest expressed in here and my extreme lack of time most bugs and annoyances would most probably remain unsolved ... sadly. In no way or shape does that mean that I'm discontinuing support, just that I'll be lukewarm about it and I mostly expect from you / the users to find more workarounds / solutions and hopefully post them here...
Anyway on we go.
PREPARATIONS
Follow the Preparation Section from the First post of this thread. Steps (d) and (e) are not needed, so you can leave those out.
Additionally you'd need to download and place the following two files accordingly:
a) Config Files (you extract the contents to the root directory of your tablet's internal storage, don't change the directory tree)
b) Linux Image (you simply place it to the root directory of the internal storage)
THE "MINI"-GUIDE
For starters make sure that you have followed the "Preparations" Section Exactly. One mistake is enough to make this guide not to work. So without further ado:
1) Open LinuxCanvas and grant it root access (if asked)
2) Create a Linux image
a) Open LinuxDeploy
b) Tap the "Back" Arrow in the upper left corner of the app
c) Delete the extant profile ("Garbage Bin" Icon -> OK)
d) Import the downloaded Profile (3-dot icon -> Import -> OK)
e) Double-tap to the imported profile (its name is "linux")
f) Navigate to properties (Arrow showing "down") and Tap "Install" -> "OK"
g) Be patient. When it's done it will read " >>>install"3) Start Linux:
a) Go back to "LinuxCanvas"
b) Press Volume Up, wait a bit and voila! (if it doesn't work the first time, press the "menu" button to repaint)
...and that's it (really). If you want to know what you get by following this guide (instead of the full one), the answer is "basically everything from the first post plus the first step from the second post". Which means that if you want the full deal you *still* have to follow Posts #2 and #3 (workarounds), but of course it's completely up to you.
Again, report any issues, annoyances or even workarounds that you may have found. I'm counting on them to make the guide better.
Cheers!
Great Work Man ....
@Stevethegreat Great Work Man , it's just amazing ... but unfortunately , in Iran , I can't download from the Linux Deploy's Server ... is there anyway I could get the Image to do the Process ( I'm not that lazy ) Or even the ready image to try booting on my SM-P601 ( mybe a better Idea ) ? ... if there's some way , I'll work on the performance a bit ... also , maybe we can get the boot script used in my ARM-UEFI to get it sooner ... Also I have an idea that your ISO size can tell me if it's possible ( Dual Boot , I mean , like what MultiROM does , but much nicer and faster without the Android booted like a single ROM ) ... Great thanks for your effort ...
With Best Wishes
Hitman1376
I have to wonder if this will work for other Note devices. (for instance I have the note 3)
I'll give it a shot, and the changes I make to obviously match my device, I'll post here.
Thanks for this mate, well done
Sweet. I will try when I have time
Sent from my SM-P600 using Tapatalk
kevp75 said:
I have to wonder if this will work for other Note devices. (for instance I have the note 3)
I'll give it a shot, and the changes I make to obviously match my device, I'll post here.
Thanks for this mate, well done
Click to expand...
Click to collapse
Mate , It needs a Kernel with VT Support , don't forget to have one .... also with " Frame Buff " enabled , it's better .... Good Luck
With Best Wishes
Hitman1376
kevp75 said:
I have to wonder if this will work for other Note devices. (for instance I have the note 3)
I'll give it a shot, and the changes I make to obviously match my device, I'll post here.
Thanks for this mate, well done
Click to expand...
Click to collapse
It will, most probably without much/any tweaks to the individual steps as Note 3 is very similar hardware wise.
But I have to warn you. Firstly, you'd need a CONFIG_VT enabled kernel. That's fairly easy to get from Note3's kernel guys (it's just an extra option to enable). If they are not willing to provide you with one such kernel, you'd have to wait until I'd find the time to write a guide on how to create one from the sources.
Secondly, you'd have to be much more agressive with your DPI settings as a Note 3 screen is way smaller than our tablet's. Of course you can always opt to work on an external screen, in which case you'd have to be much more restrained with the settings that control the dpi/size of the elements (by contrast).
hitman1376 said:
@Stevethegreat Great Work Man , it's just amazing ... but unfortunately , in Iran , I can't download from the Linux Deploy's Server ... is there anyway I could get the Image to do the Process ( I'm not that lazy ) Or even the ready image to try booting on my SM-P601 ( mybe a better Idea ) ? ... if there's some way , I'll work on the performance a bit ... also , maybe we can get the boot script used in my ARM-UEFI to get it sooner ... Also I have an idea that your ISO size can tell me if it's possible ( Dual Boot , I mean , like what MultiROM does , but much nicer and faster without the Android booted like a single ROM ) ... Great thanks for your effort ...
With Best Wishes
Hitman1376
Click to expand...
Click to collapse
Hey, LinuxDeploy offers a way to use different servers than the Russian ones. Also you can fiddle with the DNS server options (maybe there's a DNS server in your country/provider that resolves the Russian address).
edit: Oh BTW (to the second part of your past). While I'd welcome anyone at all working on bringing truly native linux (in the form of dual-booting) I'm not too sure of it's usefulness. Still you're free to use parts of my guide towards that goal (if that's what you wish). You can read the final part of my guide ("Instead of Conclusion") to see why I'm not that interested to a true dual-boot.
YYYESSSS!!!!
http://screencloud.net/v/gz6h
I'll let you know how I make out with this! Man, it'd be great to get ubu-touch running on it...
kevp75 said:
YYYESSSS!!!!
http://screencloud.net/v/gz6h
I'll let you know how I make out with this! Man, it'd be great to get ubu-touch running on it...
Click to expand...
Click to collapse
Yeah , that's enough. All it takes now is to see whether my step will work as is. If not I'm sure small tweaks specific to your device will make them work (like changing some of the numeric values in xorg.conf and/or the other files). Keep us posted
Stevethegreat said:
Hey, LinuxDeploy offers a way to use different servers than the Russian ones. Also you can fiddle with the DNS server options (maybe there's a DNS server in your country/provider that resolves the Russian address).
edit: Oh BTW (to the second part of your past). While I'd welcome anyone at all working on bringing truly native linux (in the form of dual-booting) I'm not too sure of it's usefulness. Still you're free to use parts of my guide towards that goal (if that's what you wish). You can read the final part of my guide ("Instead of Conclusion") to see why I'm not that interested to a true dual-boot.
Click to expand...
Click to collapse
Sure ... thank in deed ... I'll take a look but I don't think it's possible cuz the servers were unreachable ( I tried almost all of them )
... God damn those useless guys who do the web infiltration ... why a Linux containing server should get filtrated ? ...
brilliant guide mate theres a new version of my VT enabled kernel here btw http://d-h.st/fr1s
xluco said:
brilliant guide mate theres a new version of my VT enabled kernel here btw http://d-h.st/fr1s
Click to expand...
Click to collapse
Yeah thanks. I made sure to update the OP :good:
Stevethegreat said:
Yeah thanks. I made sure to update the OP :good:
Click to expand...
Click to collapse
Here's the stock 5.1.1 kernel for the P600 with VT enabled, platform.xml fix for external stoarge and chainfire's modified sepolicy for rooting without disabling SELinux.
http://d-h.st/0ImD
Edit: it takes FOREVER to boot, so be patient and ignore the seandroid notice!
xluco said:
Here's the stock 5.1.1 kernel for the P600 with VT enabled, platform.xml fix for external stoarge and chainfire's modified sepolicy for rooting without disabling SELinux.
http://d-h.st/0ImD
Edit: it takes FOREVER to boot, so be patient and ignore the seandroid notice!
Click to expand...
Click to collapse
Thank you very much indeed! I've made some attempts to compile on my own, but it wouldn't boot properly (it would boot into Android and after a while reboot).
I'll now start working on porting my guide. Much appreciated!
So...
Followed to a T
Results: Now have a nice lightweight desktop on my phone
Nice job on the tutorial mate!
Sound problem.
Stevethegreat said:
6) No native way to control sound and/or brightness (there's probably a solution, never bothered to investigate)
Click to expand...
Click to collapse
A possible solution to your sound issue, but it is dependent upon your Linux distribution in use:
Most newer distros of Linux use Pulse Audio for sound. This will not work as you need dbus, udevd, and a few other background processes running which are not functioning properly (or at all) in LinuxDeploy. A work around for this that I have successfully used in the past with LinuxDeploy on a Motorola Flipside was to download ALSA in your Linux distro. In my case it was Debian so I followed these steps:
1. Using the aptitude package manager, I purged all PulseAudio.
2. Using the aptitude package manager, I installed all the alsa tools and libraries.
Be sure to get the Alsa mixer.
3. When I logged in, I could, as root, bring up the alsa mixer in the terminal (eventually I mapped it to a shortcut on the desktop), and once open I could adjust the sound there. Note, you have to turn on an output device in the mixer, such as the SPK_HP or BT_SPK and then set the volume. I usually would start a sound file playing, like music, and then enter into the mixer and adjust to satisfaction.
(NOTE: these are steps, not commands, because your Linux distro or version thereof may differ.)
One problem that I had there before was that the Android system, in an effort to preserve order, would turn off the output device channel I selected after there was no sound coming out of it. E.g. the song ended, then Android would set the SPK_HP back to 0 or mute. SO to avoid that, you need to adjust the permissions of the sound card with chmod and chown to prevent Android from touching it until you are done. You can use LinuxDeploy's start/stop script options to allow you to create scripts to "steal the device" and "give it back" when you start/stop. Or you can simply keep the mixer handy and set the volume/output device every time you play a sound file. I found in practice that I didn't use the sound too much, but your mileage may vary.
-AlaskaLinuxUser
kevp75 said:
So...
Followed to a T
Results: Now have a nice lightweight desktop on my phone
Nice job on the tutorial mate!
Click to expand...
Click to collapse
Glad to hear!
Still there are bugs to be solved, I pray to have them solved (with the help of others hopefully), so keep yourself tuned.
I have to ask though: Is everything working OK? What about the s-pen? Also is the DPI suitable to your phone, or did you have to play with it? (changing the numeric values in some of my files?).
Thanks for trying to out my guide.
Cheers.
is this tested on 5.1.1?
Custom kernel for Samsung Galaxy S Advance
Code:
/*
* Your (probably expired) warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this kernel
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Features:
Universal kernel for JB, KK, LP and MM-based ROMs
CPU, GPU and DDR OC support
more governors and I/O schedulers
Lite kernel - some kernel features moved as modules
F2FS support
ABB-charger tweaks
many others features and tweaks...
Credits:
@dh.harald and @hafidzduddin for contribution on U8500 platform sources
@ Team Canjica for a base for this kernel
@ Nova Fusion for F2FS implementation
@zwliew for contribution on TC kernel
@cocafe for LiveOPP, GPU OC, abbamp and abb-charger tweaks and many cool patches which I've used from his kernel
@faux123 for dynamic Fsync implementation
@Christopher83 for dynamic management of dirty page writebacks implementation
@KINGbabasula for contribution on TC kernel sources
@boype for SIOPlus tweaks and OndemandPlus governor
@Adi_Pat for abbamp, kernel tweaks
@PolishVodka for initramfs scripts for 4.2.x and 5.0.x
@Rox for help in fixing initramfs scripts for 4.1.2
@ace2nutzer for optimization CPU OC and for whatever scripts which I have used in my kernel
@Meticulus for BLN, Sweep2wake and Doubletap2wake
@mkaluza for huge LiveOPP/Mali improvements and Dynamic governor
@yanpol199 for help with F2FS support in TWRP
@ all users who tests this kernel and directs the development along the right path
@ all those users, who I forgot to mention (PM me if so)
Team Win for TWRP recovery
Samsung for opening kernel source
Linus Torvalds for Linux sources
Special Thanks:
@isaak, @enkflr, @Pdevo, @prometej-zg for donating this phone!
[*]@S.AMU for providing FTP-Server
Source Code:
LK 3.10.y based releases
r5.7.x (LK 3.4.y based releases)
Installation:
Flash temporary kernel (if coming from other recoveries than TWRP 3.1.1)
Reboot recovery
Flash kernel zip
Compatibility:
I only add those ROMs that are confirmed to work by me or someone else:
Stock 4.1.2 ROM
LineageOS 11
CyanogenMod 13
Notice: this kernel is not compatible with NovathorSettings app, be sure to remove it before installing a kernel!
Download:
FTP
XDA:DevDB Information
Chrono Kernel, Kernel for the Samsung Galaxy S Advance I9070
Contributors
ChronoMonochrome, cocafe, faux123, zwliew, mkaluza, Meticulus, KINGbabasula, ace2nutzer, TeamCanjica
Source Code: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commits/master
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: R5.7.1
Stable Release Date: 1974-11-11
Beta Release Date: 1974-11-11
Created 2018-03-09
Last Updated 2018-04-16
Changelogs and features
Changelog
R5.9.1
Resolved (hopefully) deepsleep issues *
Fixed touchkey not working issue **
* tested in about 24 hours so far with ~6 hours of deep sleep on UltimateROM 6.0.1 without any issues with wakelocks.
** It seems that in r5.9 was introduced a bug - touch keys weren't working (at least, on 6.0.1) after device wake up.
R5.9
Bring up all the latest CK code from Codina kernel
Fix a severe performance issue on r5.8.2 build
BLN is finally FIXED! *
* Apparently, issues with BLN were related to Janice touchkey driver that was putting the device to sleep (when the display is off) regardless of a BLN wakelock usage. Reverting this behavior seemed to enable BLN to work.
R5.8.2
In-kernel vibrator fix for Android 6.0+
R5.8.1
PowerHAL fixes for 4.4.4
Experimental fix for CPU governor issue on 4.4.4
LCDCLK: revert to TeamCanjica kernel implementation
R5.8
Memory management hugely improved (finally LMK works properly)
Fixed powersave interface on JB 4.1.2 stock
Experimental fixes to PowerHAL on 4.4.4
LiveOPP: merged changes from refresh kernel (removed some CPU freq steps)
Dynamic: adjust tunables (same like in refresh kernel)
Possible vibrator fix on 6.0+ (not tested)
(old changelog)
R5.7.1
Initial build for janice (kernel sources based on LineageOS 15.1 kernel for Codina)
Fixed bluetooth issue on 4.1.2
Squash-reverted GPU-related code logic from CPU governor Dynamic
J4FS module code cleanup
Reverted forcing minimum CPU freq to 800 MHz
Enabled CONFIG_CPUSETS (required by Android 6.0.x+ ROMs to function properly)
Kernel Tweaks:
(GPU/CPU undervolting and related tweaks)
Undervolting the CPU/GPU will bring battery savings but possible instability.
1) to undervolt CPU use ChronoKernel app or via init.d scripts:
Code:
echo *cpufreq* varm=xx > /sys/kernel/liveopp/arm_summary
for example, following sets voltage varm=0x10 for 200 MHz:
Code:
echo 200000 varm=0x10 > /sys/kernel/liveopp/arm_summary
or
Code:
echo 200000 varm-=10 > /sys/kernel/liveopp/arm_summary
(default varm voltage for 200 MHz is 0x1a but, code above sets 0x1a - 0xa(10) = 0x10 )
2) to undervolt GPU use init.d script:
Code:
echo x vape=yy > /sys/kernel/mali/mali_dvfs_config
Example:
Code:
echo 2 vape=0x1c > /sys/kernel/mali/mali_dvfs_config
"2" stands for DVFS idx (look at mali_boost_high/mali_boost_low).
To prevent overriding of such settings by ChronoKernel app, add line to your init.d script after GPU undervolting
Code:
chmod 444 /sys/kernel/mali/mali_dvfs_config
Don't change voltage of both GPU/CPU at the same time - otherwise if you'll get reboot if won't know what it caused. The same is for different frequencies - if you'll change voltage of too many steps you won't know which frequency caused reboot. It's not easy process, though, following method simplifies it: https://github.com/mkaluza/i9070_kernel_CoCore-E/wiki/Undervolting-janice .
3) Custom LiveOPP table.
By default some LiveOPP steps such as 100, 200, 500 ... MHz aren't used. You can re-enable those by following way:
Code:
echo 200000 enable=1 > /sys/kernel/liveopp/arm_summary
Or use CK app instead. Don't enable it unless it uses the same voltage as 400 MHz. The same is for the rest frequencies - until some of them uses same voltage, no point to enable steps with lower freq. I've added 100 MHz just to further make some tests with it once again. It can't use lower varm than 200 MHz - that's why it's disabled by default. Furthermore, not all phones well keep undervoltage, that's why 100-400 MHz steps uses same stock voltage varm=0x1a.
UPD. thanks to @borkins for this nice editor LiveOPP ARM steps: http://forum.xda-developers.com/showpost.php?p=60311291&postcount=2921
(CPU freq management tweaks)
CPU freq. limiter for screen OFF, adjust it via:
Code:
SYSFS=/sys/kernel/cpufreq/cpufreq_limits_on_suspend
echo min=100000 > $SYSFS
echo max=400000 > $SYSFS
echo on > $SYSFS
Too low frequency may cause freezes after wakeup and sound scrathes. If you use Dynamic govermor, it make no sense to use cpufreq limiter, because Dynamic already takes care about CPUfreq usage optimization. For more, read wiki.
Input boost
This feature has been originally written by zwliew.
Not all governors support input boost. Supported governors: ondemand, interactive, conservative, ZenX, lionheart and some others. Dynamic governor has its own boost interface.
Default boost frequency is 400 MHz.
Code:
echo 450000 > /sys/kernel/cpufreq/input_boost_freq # echo '0' to disable
echo 35 /sys/kernel/cpufreq/input_boost_ms
(BackLight Notification)
To configure time intervals of BLN blinking type(bln_ondelay stands for time of blink and bln_offdelay - delay between two blinks):
Code:
echo bln_ondelay=500 > /sys/kernel/bln/blink_mode
echo bln_offdelay=6000 > /sys/kernel/bln/blink_mode
Make sure BLN enabled:
Code:
echo 1 > /sys/class/misc/backlightnotification/enabled
# to enable bln_wakelock.
echo on > /sys/kernel/bln/bln_wakelock
Use /sys/devices/virtual/misc/backlightnotification/blink_mode to changes modes.
Blink modes:
0 = no blinking
1 = blink backlight only
2 = blink backlight + rear cam flash
3 = blink rear cam flash only
(Module autoload)
Now there is a simple way to load modules at boot. Just move needed modules to /system/lib/modules/autoload and reboot device(or execute /etc/init.d/00autoload)
(DDR overclock)
This feature has been developed by me and allows you to improve DDR and GPU performance. Please note, that DDR OC might work unstable and cause filesystem corruption. Though, DDR clock of 975 MHz has been highly tested and should work fairly stable on most devices.
Overclocking DDR over 975 MHz is highly NOT recommended, especially in case if you not sure that you can deal with possible consequences.
How to OC DDR:
1) by using
this script .
2) by using Terminal Emulator(in example below 975 MHz):
Code:
echo 0x5017f > /sys/kernel/liveopp/pllddr_oc_on_suspend
This setting will be applied right after disabling screen.
(Minimum APE/DDR OPP on screen on)
This feature has been developed by me and allows to set minimum APE/DDR OPP states which are used when screen is ON. APE controls many systems such as an image, video, audio system etc. DDR OPP determines performance of DDR. Default values are APE50 and DDR50. Lower states(APE25/DDR25) reduces power consumption, but may cause graphical glitches like screen blinking or filling it by vertical grey lines. If you don't have mentioned effects, it's recommended to use APE25/DDR25:
Code:
echo ddropp=25 > /sys/devices/pri_lcd_ws2401.0/mcde_screenon_opp
echo apeopp=25 > /sys/devices/pri_lcd_ws2401.0/mcde_screenon_opp
* if you don't have folder /sys/devices/pri_lcd_ws2401.0, use /sys/devices/pri_lcd_s6d27a1 instead.
(Screen refresh rate)
This feature has been developed by cocafe and modified by me. Lower lcdclk frequency cause less power usage, but too low values makes system unusable.
Following command allows to change screen refresh rate:
Code:
echo x > /sys/kernel/mcde/lcdclk
use
Code:
cat /sys/kernel/mcde/lcdclk
to see supported lcdclk modes. Default mode is 60 Hz which is recommended in most typical cases. If you've screen tearings, blinking etc. change resresh rate mode to "60+ Hz":
Code:
echo 0 > /sys/kernel/mcde/lcdclk
(ABB charger tweaks)
added tweakable interfaces for termination current. To adjust it type(just an example):
Code:
echo 90 > /sys/kernel/abb-chargalg/termination_curr_1st
echo 70 > /sys/kernel/abb-chargalg/termination_curr_2nd
curr_2nd should be less or same as curr_1st. Lower values prolongs battery lifetime, but also slows battery charging.
Default values are curr_1st == curr_2nd == 150 mA. Please note, too low values maybe aren't usable.
(Dynamic FSync)
This feature has been developed by Faux123 and allows to dynamically manage the synchronous writes performed on file system (FSync).
It uses asynchronous writes when the screen is on, instead of synchronous writes, to have better performance and a slightly lower battery drain, while when the screen is off the synchronous writes are re-enabled to flush all the outstanding writes and prevent possible data loss.
How to enable/disable the Dynamic FSync (default enabled):
1) By downloading and using Trickster MOD
2) By directly editing the file /sys/kernel/dyn_fsync/Dyn_fsync_active and setting 1 to enable the dynamic fsync, 0 to disable it (note that set value will be lost after a reboot/shutdown)
3) By using Terminal Emulator (note that set value will be lost after a reboot/shutdown)
- Open Terminal Emulator
- Run this command to disable the dynamic fsync feature
Code:
su
echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
- Or run this command to re-enable the dynamic fsync feature
Code:
su
echo 1 > /sys/kernel/dyn_fsync/Dyn_fsync_active
Click to expand...
Click to collapse
(Software CRCs)
Disabling software CRCs gives you a slight bump(10-30% is what they say) of MMC performance, at the cost of a possibility of your Ace 2 freezing randomly.
Code:
echo 0 > /sys/module/mmc_core/parameters/use_spi_crc
Click to expand...
Click to collapse
(Dynamic dirty page writebacks)
This feature has been developed by Christopher83 and allows to dynamically manage the dirty page writebacks with two different intervals, one when the screen is on and another when the screen is off.
It is based on a commit of Francisco Franco, but instead of using hard coded values and of disabling at all the dirty page writebacks while the screen is on (possibility of data loss).
By using a higher interval we have better performance and less battery consumption, with a very low risk of data loss.
How to customize the dynamic dirty page writebacks feature (default disabled):
Three new procfs parameters are exposed inside /proc/sys/vm path:
- dynamic_dirty_writeback is the activation status of this feature, set 1 to enable it, set 0 to disable it and use the standard behaviour
- dirty_writeback_active_centisecs is the interval for the dirty page writebacks when the system is active (screen on), the default value is 1500 centisecs (15 seconds)
- dirty_writeback_suspend_centisecs is the interval for the dirty page writebacks when the system is suspended (screen off), the default value is 500 centisecs (5 seconds)
1) By directly editing one of the file written above inside /proc/sys/vm and setting the preferred value (note that set value will be lost after a reboot/shutdown)
2) By using Terminal Emulator (note that set value will be lost after a reboot/shutdown)
- Open Terminal Emulator
- Run this command to disable the dynamic dirty page writebacks feature
Code:
echo 0 > /proc/sys/vm/dynamic_dirty_writeback
- Or run this command to re-enable the dynamic dirty page writebacks feature
Code:
echo 1 > /proc/sys/vm/dynamic_dirty_writeback
- Run this command to set customize the two intervals (30 seconds while the screen is on, 10 seconds when the screen is off)
Code:
echo "3000" > /proc/sys/vm/dirty_writeback_active_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_suspend_centisecs
(Tweak app)
ChronoKernel settings
Thanks mars_army for this app!
Bug reports:
after experiencing a random reboot, type in terminal:
Code:
su
cat /proc/last_kmsg > /storage/sdcard0/last_kmsg.txt
report it in the thread and attach the last_kmsg.txt
Misc
Storages switch
By default, this kernel comes with internal and external storages switched. You can revert this behavior, by changing the line
Code:
use_swap=1
to
Code:
use_swap=0
in file /ramdisk/fstab_specs.txt and flashing the kernel package. This setting will remain until you format /ramdisk partition.
@ChronoMonochrome
I tested "chrono_kernel_r5.7.1-test-40-g169a68f4f29d-janice.zip" on Lineage OS 11.
Result: I have the same hiccups in the youtube video like before.
I think that you can revert the LCDCLK frequency to the default 60 Hz value, because I didn't notice any significant difference.
And I had an isolated crash while I was navigating in settings.
My usual running apps & services are: Should I answer?, Nova Launcher, Tesla Unread, Google Play Services 11.9.75, Ginger Keyboard, Skype 7.46.0.596 (old version from apkmirror), Quickpic, Terminal Emulator, CCleaner, Google Play Store 9.0.15, Tubemate 3.0.11, My Vodafone, Naked Browser, Titanium Backup, Fx File Explorer, Gmail, Google News & Weather, MX Player.
I hope that these logs can help you.
isaak said:
@ChronoMonochrome
I tested "chrono_kernel_r5.7.1-test-40-g169a68f4f29d-janice.zip".
Result: I have the same hiccups in the youtube video like before.
I think that you can revert the LCDCLK frequency to the default 60 Hz value, because I didn't notice any significant difference.
And I had an isolated crash while I was navigating in settings.
My usual running apps & services are: Should I answer?, Nova Launcher, Tesla Unread, Google Play Services 11.9.75, Ginger Keyboard, Skype 7.46.0.596 (old version from apkmirror), Quickpic, Terminal Emulator, CCleaner, Google Play Store 9.0.15, Tubemate 3.0.11, My Vodafone.
I hope that these logs can help you.
Click to expand...
Click to collapse
Thanks for the report! Unfortunately, the last_kmsg log appears to be taken from MaxiCM kernel, so the crash isn't captured here. In the meantime I'll install some of those apps to test how it goes under increased memory pressure. Was /proc/meminfo log taken before or after reboot? It would be useful to check this sysfs interface when the phone is encountering laggs (if it does), but after reboot this info won't help. About lowmemorykiller changes: were apps running faster / slower? So far Youtube playback is the only issue or phone laggs too?
ChronoMonochrome said:
Thanks for the report! Unfortunately, the last_kmsg log appears to be taken from MaxiCM kernel, so the crash isn't captured here. In the meantime I'll install some of those apps to test how it goes under increased memory pressure. Was /proc/meminfo log taken before or after reboot? It would be useful to check this sysfs interface when the phone is encountering laggs (if it does), but after reboot this info won't help. About lowmemorykiller changes: were apps running faster / slower? So far Youtube playback is the only issue or phone laggs too?
Click to expand...
Click to collapse
/proc/meminfo log was taken before the reboot. Youtube playback is not the only issue. I can just say that the best way to reproduce a crash or a slowdown is switching from an app to another as quick as possible and/or try a cleaning with CCleaner. Ah, in that list I forgot some apps, so I've updated my previous post.
So far I've tested as much as possible on stock 4.1.2 rom and everything is working fine.
-Bluetooth is definitely fixed, working like a charm.
-CRC, FSYNC and other tweaks give me no issue at all and work good.
-Tested a bit of undervolting, firstly cpu, then gpu, and DDR OC, and here too, no problems.
-Really great the supension min and max cpufreq, tested it with some init.d scripts.
Overall stability and responsiveness of the system is impressive, really positive, you really made a big surprise
These instead are the few things I noticed not working, I think the first two are really not a major problem at all and maybe I am messing with something:
1. I have noticed that trying to set governor by init.d script doesn't seem to take effect and at boot completed I find performance setted as governor:
busybox echo dynamic > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor;
Click to expand...
Click to collapse
Running then the script manually set dynamic as governor correctly.
(SOLVED WITH A BUSYBOX CHMOD COMMAND BEFORE EVERY PARAMETER SET)
2. I tryed using exfat support, loaded fuse.ko and exfat.ko modules on boot, then used the same binary from cocafe twrp kernel I was using fine (and here I think there is the issue) with this command:
exfat-fuse /dev/block/mmcblk1p1 /storage/extSdCard;
Click to expand...
Click to collapse
Sdcard isn't recognized and android is asking to format it as usual.
3. I guess should be the number one: Recovery doesn't seem to work, tryed many times, also removing battery first, but I can't enter in recovery. Next time I flash kernel I will do it manually from terminal, or Universal Kernel Flash app
EDIT1:
I found that the path where lcd parameters are located would be:
/sys/kernel/s6e63m0/panel/lcd_clk
Click to expand...
Click to collapse
instead of:
/sys/kernel/mcde/lcdclk
Click to expand...
Click to collapse
EDIT2:
Seems like deepsleep is broken, because in my situation phone doesn't enter in deepsleep mode and having a look at /d/supsend_stats and d/suspend directory confirm my issue.
I found at first strange the absence of /d/cpuidle directory and so the deepest_state configuration file, like something is missing here.
EDIT3:
I think I found another last issue, BLN is not working, but I think could be again something to do with files and folder structure, for example I can't find:
/sys/class/misc/backlightnotification/enabled
Click to expand...
Click to collapse
Again, this is still something not so important tough
EDIT4:
I was experiencing before issues with phone calls, making phone app freezing and signal loss, going to "no service" mode. Had to flash backup kernel for now, tomorrow as I get some time again I will provide logs
Pdevo said:
So far I've tested as much as possible on stock 4.1.2 rom and everything is working fine.
-Bluetooth is definitely fixed, working like a charm.
-CRC, FSYNC and other tweaks give me no issue at all and work good.
-Tested a bit of undervolting, firstly cpu, then gpu, and DDR OC, and here too, no problems.
-Really great the supension min and max cpufreq, tested it with some init.d scripts.
Overall stability and responsiveness of the system is impressive, really positive, you really made a big surprise
Click to expand...
Click to collapse
Thanks for a review!
2. I tryed using exfat support, loaded fuse.ko and exfat.ko modules on boot, then used the same binary from cocafe twrp kernel I was using fine (and here I think there is the issue) with this command:
Sdcard isn't recognized and android is asking to format it as usual.
Click to expand...
Click to collapse
Honestly I didn't test exfat for a long time. These issues might come due to the filesystem driver updates. Anyway I need to test things myself before I'll have clues on how to fix it.
3. I guess should be the number one: Recovery doesn't seem to work, tryed many times, also removing battery first, but I can't enter in recovery. Next time I flash kernel I will do it manually from terminal, or Universal Kernel Flash app
Click to expand...
Click to collapse
Are you sure you have followed the installation guide to flash the kernel? Especially, using TWRP is required to flash a kernel (other recoveries aren't tested and can be a cause for a bugs) I was returning to a stock for a short time to test if bluetooth works and recovery was working for me when I was returning to UltimateROM 6.0.1 afterwards.
Don't use manual flashing or UKF app to flash the kernel! The installation method is quite complicated (compared to installation of other kernels), so a full and proper installation is only possible if you flash it from recovery.
EDIT1:
I found that the path where lcd parameters are located would be:
instead of:
Click to expand...
Click to collapse
I have moved the interface to match the implementation of LCDCLK management on codina.
EDIT2:
Seems like deepsleep is broken, because in my situation phone doesn't enter in deepsleep mode and having a look at /d/supsend_stats and d/suspend directory confirm my issue.
I found at first strange the absence of /d/cpuidle directory and so the deepest_state configuration file, like something is missing here.
Click to expand...
Click to collapse
This is entirely possible due to deepsleep driver changes in a kernel. I never tested if it works on stock, I guess I'll have to return to stock once again.
EDIT3:
I think I found another last issue, BLN is not working, but I think could be again something to do with files and folder structure, for example I can't find:
Again, this is still something not so important tough
Click to expand...
Click to collapse
I was thinking BLN isn't working on this phone at all, so I disabled the kernel support. Is the stock ROM only where BLN works?
Yes sir, I flashed your kernel exactly from twrp, coming from cocore refresh24, I referred to UKF or terminal emulator to say I would use that method now that I can't enter recovery mode, but I never use these ways at all, always from recovery, because I know that kernel come with scripts and other files that without recovery wouldn't be installed
Tomorrow I will do further testing
ChronoMonochrome said:
I was thinking BLN isn't working on this phone at all, so I disabled the kernel support. Is the stock ROM only where BLN works?
Click to expand...
Click to collapse
As far as I know no dev on Janice introduced BLN, but I don't see any reason why it shouldn't be technically possible if it works on Ace II.
Please don't give up on this unless you're sure at 100%.
@cocafe had it on his todo list, but at the end he didn't implement it for unknown reasons. I asked to him but he never explained it.
ChronoMonochrome said:
I was thinking BLN isn't working on this phone at all, so I disabled the kernel support. Is the stock ROM only where BLN works?
Click to expand...
Click to collapse
Until now, BLN never been working or supported on custom and stock roms, as said by @isaak, the reason behing that I think is properly known by developers such as cocafe.
Yesterday I made a little try using the commands you point in the thread, a little go, but in fact is not working. Would be a cool feature, but nothing so important at all for me, at least for now
UPDATE:
I flashed again the kernel, starting from freshly downloaded zip, and I got an infinite bootloop trying to get to recovery, the only way to go back working was flashing stock rom with odin.
I can now safely say there is an issue with recovery using the stock rom.
UPDATE 19:30
I took two logs, one for incoming call and one for outgoing call, reproducing the issue I was referring in previous post.
In the first case, incoming call, notification appear but scrolling to accept call make phone unusable and I could just shutdown it to solve the situation.
In the second case, outgoing call, after I start the call the phone app isn't responding, I see the notification widget but tapping on every possible button, to terminate call or enter in dialog, doesn't work and phone is very unstable until a sort of a timeout is running out and call stop itself.
Hi @ everyone!
Because of th numerous issues found with the current release, I'm starting to work on a fresh kernel sources (3.0.101), almost from scratch. My primary focus for now will be a multitasking, that is the main issue with the current release. Because of yet unknown root cause of the issue it could take a while to reveal it, but I hope to release a new build these days (and after playing with some kernel configuration find out more appropriate one for a multitasking). Stay tuned!
For sure we stay tuned!, thank you so much for the efforts and take all the time you need Chrono
isaak said:
My usual running apps & services are: Should I answer?, Nova Launcher, Tesla Unread, Google Play Services 11.9.75, Ginger Keyboard, Skype 7.46.0.596 (old version from apkmirror), Quickpic, Terminal Emulator, CCleaner, Google Play Store 9.0.15, Tubemate 3.0.11, My Vodafone, Naked Browser, Titanium Backup, Fx File Explorer, Gmail, Google News & Weather, MX Player.
I hope that these logs can help you.
Click to expand...
Click to collapse
I have set up all these apps about 10-12 days ago. I should say, removing CCleaner seemed to help a lot to increase the phone performance. It's doing a lot of background CPU and I/O work, making the phone almost unusable on r5.7.1 and severely affects performance on r4.1 / r4.6.
ChronoMonochrome said:
I have set up all these apps about 10-12 days ago. I should say, removing CCleaner seemed to help a lot to increase the phone performance. It's doing a lot of background CPU and I/O work, making the phone almost unusable on r5.7.1 and severely affects performance on r4.1 / r4.6.
Click to expand...
Click to collapse
The new CCleaner version is on the heavy side, so I had to freeze some background services with My Android Tools app. Anyway I've just uninstalled it definitively.
New build r5.8 is up!
R5.8
Memory management hugely improved (finally LMK works properly)
Fixed powersave interface on JB 4.1.2 stock
Experimental fixes to PowerHAL on 4.4.4
LiveOPP: merged changes from refresh kernel (removed some CPU freq steps)
Dynamic: adjust tunables (same like in refresh kernel)
Possible vibrator fix on 6.0+ (not tested)
ChronoMonochrome said:
R5.8
Memory management hugely improved (finally LMK works properly)
Fixed powersave interface on JB 4.1.2 stock
Experimental fixes to PowerHAL on 4.4.4
LiveOPP: merged changes from refresh kernel (removed some CPU freq steps)
Dynamic: adjust tunables (same like in refresh kernel)
Possible vibrator fix on 6.0+ (not tested)
Click to expand...
Click to collapse
I tried 5.8.5 and I have still issues with LineageOS 11:
1) I've got a screen flicker issue while I was browsing in Naked Browser with the new LCDCLK frequency.
Tried to set echo 1 > /sys/kernel/mcde/lcdclk, but I've noticed that this value is not kept after a reboot.
Very annoying, because I can't restore 60 Hz permanently.
2) There are still issues about some values not kept in the performance UI of Lineage Os.
For example:
- Try to set Zenx as governor, min. 200 max 1000, Noops scheduler. Reboot. Scheduler will be resetted to Deadline.
- There is still a bug with max clock value of Dynamic governor (I can reproduce it with ZenX governor too). I set it to 800 MHz, I go back to the settings screen, then I return to the Performance -> Processor section to check if the 800 MHz value is maintained. But the UI automatically restored the max clock to 1000 MHz without my consent.
For your information, these issues occur only randomly and with particular combinations. So, if you can't reproduce them, the best way is to set these, one at a time:
1) Zenx as governor, min. 200 max 800, Noops scheduler. Reboot.
2) Zenx as governor, min. 200 max 800, Fiops scheduler. Reboot.
2) Zenx as governor, min. 200 max 800, Sioplus scheduler. Reboot.
After the first, the second or the third reboot, some of these values you've set will change spontaneously on their own.
"Set on boot" options are correctly set for both Processor and I/O Scheduler.
And I keep "Enable per-app profiles" option turned off.
3) On the Performance UI, performance profile results automatically set on Balanced after any reboot. But if you cannot fix it, I can live with that, don't worry. It doesn't keep "Power save" or "Performance" profile between reboots.
PS: I would appreciate if you could update the installation steps in this thread with the same steps of the refresh topic:
Flash temporary kernel (if coming from other recoveries than TWRP 3.1.1)
Reboot recovery
Flash kernel zip
isaak said:
I tried 5.8.5 and I have still issues with LineageOS 11:
1) I've got a screen flicker issue while I was browsing in Naked Browser with the new LCDCLK frequency.
Tried to set echo 1 > /sys/kernel/mcde/lcdclk, but I've noticed that this value is not kept after a reboot.
Very annoying, because I can't restore 60 Hz permanently.
Click to expand...
Click to collapse
Sorry, I thought I've reverted this change. Can you confirm that setting old LCDCLK freq fixes issue? As a temporary solution you can use init.d script to set the appropriate LCDCLK freq index.
2) There are still issues about some values not kept in the performance UI of Lineage Os.
For example:
- Try to set Zenx as governor, min. 200 max 1000, Noops scheduler. Reboot. Scheduler will be resetted to Deadline
Click to expand...
Click to collapse
Can confirm now. I have a guess for that, for now the solution as follows:
remove /ramdisk/modules/autoload/sioplus-iosched.ko, reboot. I have to test this a bit more time to be sure 100%, but so far I couldn't reproduce an issue after removing this module (no other CPUfreq governor or I/O scheduler must be loaded as well).
- There is still a bug with max clock value of Dynamic governor (I can reproduce it with ZenX governor too). I set it to 800 MHz, I go back to the settings screen, then I return to the Performance -> Processor section to check if the 800 MHz value is maintained. But the UI automatically restored the max clock to 1000 MHz without my consent.
Click to expand...
Click to collapse
It's not a bug, but rather intended behavior - due to PowerHAL changes implemented, CPUfreq can only be changed via script (see /ramdisk/perf.sh). I've previously asked if anyone would prefer to adjust CPUfreq usual way, In this case I can just remove the corresponding lines from the PowerHal script. This will make PowerHAL settings a bit more useless, but will gave easier control over CPUfreq.
3) On the Performance UI, performance profile results automatically set on Balanced after any reboot. But if you cannot fix it, I can live with that, don't worry. It doesn't keep "Power save" or "Performance" profile between reboots.
Click to expand...
Click to collapse
The script actually works, though you're right, it works buggy and everytime shows the default profile (you can set, e.g. Powersave profile and check min/max CPU freq, to check if it actually works).
PS: I would appreciate if you could update the installation steps in this thread with the same steps of the refresh topic:
Flash temporary kernel (if coming from other recoveries than TWRP 3.1.1)
Reboot recovery
Flash kernel zip
Click to expand...
Click to collapse
Done!
isaak said:
I've got a screen flicker issue while I was browsing in Naked Browser with the new LCDCLK frequency.
Tried to set echo 1 > /sys/kernel/mcde/lcdclk, but I've noticed that this value is not kept after a reboot.
Very annoying, because I can't restore 60 Hz permanently.
ChronoMonochrome said:
Sorry, I thought I've reverted this change. Can you confirm that setting old LCDCLK freq fixes issue? As a temporary solution you can use init.d script to set the appropriate LCDCLK freq index.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Yes, I can confirm that setting old LCDCLK freq fixed the flicker issue for my screen. I think it would be better to set it as default in the next release.
isaak said:
There are still issues about some values not kept in the performance UI of Lineage Os.
For example:
- Try to set Zenx as governor, min. 200 max 1000, Noops scheduler. Reboot. Scheduler will be resetted to Deadline
etc etc....
ChronoMonochrome said:
Can confirm now. I have a guess for that, for now the solution as follows:
remove /ramdisk/modules/autoload/sioplus-iosched.ko, reboot. I have to test this a bit more time to be sure 100%, but so far I couldn't reproduce an issue after removing this module (no other CPUfreq governor or I/O scheduler must be loaded as well).
Click to expand...
Click to collapse
Click to expand...
Click to collapse
I tried your steps, unfortunately they didn't work for me.
ChronoMonochrome said:
It's not a bug, but rather intended behavior - due to PowerHAL changes implemented, CPUfreq can only be changed via script (see /ramdisk/perf.sh). I've previously asked if anyone would prefer to adjust CPUfreq usual way, In this case I can just remove the corresponding lines from the PowerHal script. This will make PowerHAL settings a bit more useless, but will gave easier control over CPUfreq.
Click to expand...
Click to collapse
Personally I would prefer more control over CPUfreq. Could you list the main advantages to limit CPUfreq changes only via script? Is it a sort of auto-optimization? This point is not clear to me. If you think that any change to this mechanism would affect negatively the battery life, then don't change anything.
isaak said:
On the Performance UI, performance profile results automatically set on Balanced after any reboot. But if you cannot fix it, I can live with that, don't worry. It doesn't keep "Power save" or "Performance" profile between reboots.
ChronoMonochrome said:
The script actually works, though you're right, it works buggy and everytime shows the default profile (you can set, e.g. Powersave profile and check min/max CPU freq, to check if it actually works).
Click to expand...
Click to collapse
Click to expand...
Click to collapse
I tried Powersave and Performance profiles, in both cases the maximum freq varies between 400 MHz and 1000 MHz, rarely reaching 800 MHz. Minimum freq is always 200 MHz and it doesn't change visually like the maximum freq. Balanced profile is always shown visually after a reboot.
isaak said:
Personally I would prefer more control over CPUfreq. Could you list the main advantages to limit CPUfreq changes only via script? Is it a sort of auto-optimization? This point is not clear to me. If you think that any change to this mechanism would affect negatively the battery life, then don't change anything.
Click to expand...
Click to collapse
Because of some CPUfreq scaling tunables were changed (in the case of Dynamic governor), it makes sense to implement a PowerHAL profiles, which would limit / restore the max CPUfreq. But I think I've found a solution - I will make it possible to change CPUfreq for a Balanced profile.
I tried Powersave and Performance profiles, in both cases the maximum freq varies between 400 MHz and 1000 MHz, rarely reaching 800 MHz. Minimum freq is always 200 MHz and it doesn't change visually like the maximum freq. Balanced profile is always shown visually after a reboot.
Click to expand...
Click to collapse
Ok, I found some logical errors in the script, should be fixed in upcoming release.