Database Users

Suggestions for Dexmod

Hi all, specifically Dexter. I am posting in General as I cannot post in Dev just yet.
I am a linux sysadmin by trade and I have a couple of filesystem performance mods that I use on SSD that I have ported to my A7. I was wondering about the chances of adding them into a future Dexmod, should there be one.
- Set default scheduler to deadline
I have seen posts about using 'noop' which works fine, but using 'deadline' optimizes the reads over writes which bumps performance slightly. Note using deadline slows down sync's a bit on unmount (more data to sync).
This needs a change to the kernel boot options if you are able to mod the boot loader, the option is:
elevator=deadline
Or it could be done after boot with
echo deadline > /sys/block/mmcblk0/queue/scheduler
echo deadline > /sys/block/mmcblk3/queue/scheduler
- Add trim support to the filesystems
This will enhance garbage collection and extend SSD life. Simply add the 'discard' option to the mounts.
- Possibly change the mount option to noatime?
I am not actually sure if this will work on an android device, it all depends on how heavily the system makes use of file access times. I would say none, but since android actively puts a lot of tasks to sleep it may need atime for some reason. I have not tried it yet, just in case. If it will work this will speed things up and extend SSD life by reducing disk writes.
So if this will not bork the system, change the mount option from 'relatime' to 'noatime'.
Cheers!
Domito

domito said:
- Set default scheduler to deadline
I have seen posts about using 'noop' which works fine, but using 'deadline' optimizes the reads over writes which bumps performance slightly. Note using deadline slows down sync's a bit on unmount (more data to sync).
This needs a change to the kernel boot options if you are able to mod the boot loader, the option is:
elevator=deadline
Or it could be done after boot with
echo deadline > /sys/block/mmcblk0/queue/scheduler
echo deadline > /sys/block/mmcblk3/queue/scheduler
Click to expand...
Click to collapse
this can be done.. the "echo" solution is probably the easiest one, as boot.img somehow is different to add kernel args to.
but if it helps we will see..
domito said:
- Add trim support to the filesystems
This will enhance garbage collection and extend SSD life. Simply add the 'discard' option to the mounts.
- Possibly change the mount option to noatime?
Click to expand...
Click to collapse
ill check up on these options.

Dexter_nlb said:
this can be done.. the "echo" solution is probably the easiest one, as boot.img somehow is different to add kernel args to.
but if it helps we will see..
Click to expand...
Click to collapse
You are probably right, I had the same issue when I was trying to mod my Gentouch. It would be much easier if the kernel source was available (wishful thinking).
Dexter_nlb said:
ill check up on these options.
Click to expand...
Click to collapse
Thanks!
Domito
P.S. Love the mod, thanks for all the hard work.

domito said:
This will enhance garbage collection and extend SSD life.
Click to expand...
Click to collapse
TY for bringing your expertise to the Elocity world
I was just curious, are the SSD's used in the EA7 really subject to such quick degradation? How can you tell if your SSD is having issues? I dont have that much experience with them yet, I did notice my Desktop SSD had a MTBF of 2,000,000 hours (228 years)...but I know MTBF isnt the same thing as losing blocks.

TheZedo said:
TY for bringing your expertise to the Elocity world
Click to expand...
Click to collapse
I like to help when I can.
TheZedo said:
I was just curious, are the SSD's used in the EA7 really subject to such quick degradation? How can you tell if your SSD is having issues? I dont have that much experience with them yet, I did notice my Desktop SSD had a MTBF of 2,000,000 hours (228 years)...but I know MTBF isnt the same thing as losing blocks.
Click to expand...
Click to collapse
The key issue is not 'how long does the drive last' but 'why not make it last longer'. All SSD are subject to degredation over time due wear caused by write amplification (check wikipedia, the forum will not let me post external links).
I think I saw someone post the actual make/model of the SSD in another thread, it might be fun to look up the specs at the manf. site (if available).
Normally on a linux system I would watch for signs of issues in the logs, dmesg in particular. I think it would be much like ECC memory, it'll just happily go along without the bad blocks in use. There could be a better way, I'll look into it. Smartctl may show something. The only clue you'll get on android is the dmesg output.
I just had to restore my desktop because a 2 month old OCZ SSD failed on me. It did not outright fail though, that would be too easy. It worked for a while, then failed, then worked after reboot, then failed. Very annoying. I am not sure if this was caused by write amplification, or just a crappy SSD. YMMV.

Getting info about framebuffer

Hi, I am thinking of buying Nexus 7, but I would really like to have some way to stream it's display to at least computer. That can be most easily (well, more like the most primitive way) by sending content of framebuffer via wifi. That however requires the framebuffer to be accessible and reasonably big (eg. small).
Now, I do not have it yet, and I do not know anybody who has it, so I am asking you to get some info about framebuffer for me. It will not take more than 5 minutes and only things you need is ADB and root.
So, if you decided to help me, thank you, and let's get started.
I want you to just run several commands on your device under root and then send me the result files.
1. Device permissions
Code:
ls -l /dev > /sdcard/xda_tass.txt
ls -l /dev/graphics >> /sdcard/xda_tass.txt
These two commands will tell me what device files are available on N7 and their permissions. The output is saved to file on sdcard (well, I hope the memory in N7 is called /sdcard. If not, just change it to some existing path).
2. Testing the framebuffer
Code:
time (cat /dev/graphics/fb0 > /dev/null) >> /sdcard/xda_tass.txt 2>&1
This command will tell me how long does it take to read framebuffer. Run it 3-5 times, so that I have some average values. If "/dev/graphics/fb0" does not exist, try "/dev/fb0".
Code:
cat /dev/graphics/fb0 > /sdcard/xda_tass.dat
Copies the framebuffer into file, so that I know how big it is and which format does it have. This is like taking screenshot, so make sure there is not something embarrassing on your display
3. Send me the files
Take files "xda_tass.txt" and "xda_tass.dat", ZIP em' up and put it somewhere. That is all.
I would be really glad if somebody could do that for me, thanks

Here you go
http://db.tt/3WBr5BWK
Also the sdcard is now /storage/sdcard0, yeah idk why
Sent from my Nexus 7 using Tapatalk 2

Thank you
Looks okay, even though the framebuffer is huge. Well, I suppose it is not a problem to compress it on that quad-core craziness. And, it has two framebuffers (fb0 and fb1) - I wonder why.
Also, I cannot decode data from that framebuffer. Could you please get me also the second framebuffer?
Code:
cat /dev/graphics/fb1 > /storage/sdcard0/xda_tass_fb1.dat

Tasssadar said:
Thank you
Looks okay, even though the framebuffer is huge. Well, I suppose it is not a problem to compress it on that quad-core craziness. And, it has two framebuffers (fb0 and fb1) - I wonder why.
Also, I cannot decode data from that framebuffer. Could you please get me also the second framebuffer?
Code:
cat /dev/graphics/fb1 > /storage/sdcard0/xda_tass_fb1.dat
Click to expand...
Click to collapse
Here you go
http://db.tt/Nt6kBM83
Sent from my Nexus 7 using Tapatalk 2

Data from fb1 look about as random as those from fb0 to me. Gonna need some more samples, but I can do that by myself once I'll have my own N7.
Thanks for helping me

Tasssadar said:
Data from fb1 look about as random as those from fb0 to me. Gonna need some more samples, but I can do that by myself once I'll have my own N7.
Thanks for helping me
Click to expand...
Click to collapse
No problem lol
Sent from my Jelly Nexus S

@Tasssadar how did you decode the framebuffer? I'm actually trying to get a screenshot of MultiROM, but I can't figure out how to decode it. I'm trying to open it with GIMP by changing the settings and moving the width value, but I can't get a clear image.

Your signature says you have the 2013 Nexus 7. MultiROM doesn't use framebuffer on that device because of severe kernel driver bug. You can still take screenshots though - tap on the screen with four fingers at once. The screen should flash and screenshot will be saved to /sdcard/multirom/ (accessible in Android only with root in /data/media/0/multirom).
The format should be RGB Alpha and the dimensions should be 1200x1920.

Tasssadar said:
Your signature says you have the 2013 Nexus 7. MultiROM doesn't use framebuffer on that device because of severe kernel driver bug. You can still take screenshots though - tap on the screen with four fingers at once. The screen should flash and screenshot will be saved to /sdcard/multirom/ (accessible in Android only with root in /data/media/0/multirom).
The format should be RGB Alpha and the dimensions should be 1200x1920.
Click to expand...
Click to collapse
Damn, you put so many easter eggs in MultiROM
That's interesting though... That's why when pulling the framebuffer I only got a black screen. In the recovery, instead, I could get something "visible" (still not the actuall image, though).

@Tasssadar Is it still possible to take screenshots on the new multirom for flo? When I tap with four fingers nothing happens.

Since v27, screenshots are taken with power+volume down combo like in Android ( you have to press power button first though, cause I'm lazy). They are also saved as PNG instead of raw data, and they are in folder /sdcard/Pictures/Screenshots like Android screenshots. I mentioned it in the changelog

[HOW TO] Install GNU/Linux on Samsung Galaxy Note 10.1 2014 (Updated 03/17)

#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 -> Quit​Explanation:
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 Iceweasel​Explanation:
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 -> Close​Explanation:
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?

5/1/2017 || V10 (msm 8992) || CPU, GPU, IO, RAM "Tweaks"

So the dev section here has been active recently with some high quality work, and I am looking to add to the fun
**SEE POST 2 FOR CHANGE LOG**
***VERY IMPORTANT IF YOU ARE GOING TO USE THIS MOD, you need to navigate to the /system/etc folder on your device, and rename the file "init.lge.zramswap.sh" to "init.lge.zramswap.sh.bak" so it does not run at boot.
This is a step by step instruction on how to replace the /system/etc/init.qcom.post_boot.sh file for the LG V10. Be it known, however, that this instruction (and file) can be used with any device running the Snapdragon 808 SoC combo.
What does this do?
Simple. It turns your device into an even more efficient powerhouse. Here are is a list of everything done:
-Interactive Governor tuning for performance and better battery life, a quick description of what I did...
-low load, quick response, low frequency
-high load, quick response, higher frequency
-modified input boost settings for Interactive
-Adjusted GPU target load values
-Switched IO scheduler to noop, and tuned accordingly
-Adjusted minfree values (RAM management, it is a little more multi-tasking friendly)
-Adjusted VM parameters - swappiness, dirty ratios, cache pressure, centisec values, etc (again to complement multi-tasking... your data will hang out a little bit more before being written to disk, but house cleaning won't happen all at once, so there is still good performance and your system won't bog down while it is flushing the toilet)
-DISABLED zRAM!!! - I have no idea why a device with 4 GB of RAM has zRAM enabled. This is purely a waste of CPU cycles and other system resources. You want physical memory, not compressed memory.
-Changed congestion algorithm to cubic (better network performance... assuming the network bandwidth is already there
-Cleaned up the shell file and fixed some errors.
-More to come!
How to do this, we'll just get right to it.
Download this app https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en
Download this file https://drive.google.com/open?id=0BzM9W6qUvx-gcm1SVDhsTDVWZ3M
And while you are here, check this out, decide which one you want.
http://forum.xda-developers.com/showpost.php?p=66792862&postcount=109
Very important you put the file on the root of your INTERNAL SDCARD!!!
Do not forget to do this.
After you do that, open terminal emulator, and type the following commands in the order they are presented (I would highly recommend just copying them from this post and switching back and forth between your browser and the terminal app):
Code:
su
Code:
cd /
Code:
mount -o remount,rw /system
Code:
cd /system/etc
Code:
rm init.qcom.post_boot.sh
Code:
cd /sdcard
Code:
mv init.qcom.post_boot.sh /system/etc
Code:
chmod 0644 /system/etc/init.qcom.post_boot.sh
Double check the file has been replaced with a file explorer of some sort, double check permissions, then reboot. Good to go.
Some of this stuff explained http://forum.xda-developers.com/tmo...nux-virtual-machine-explained-part-1-t3386956

CHANGE LOG***
May 1, 2017
-Pretty major overhaul of the file. I've done some stuff on the Axon 7 that has been pretty effective. Rolling those changes out to other devices. https://drive.google.com/open?id=0BzM9W6qUvx-gcm1SVDhsTDVWZ3M
May 31, 2016
-Replaced corrupted files. Good to go now!
Dangerously version (fixed) https://drive.google.com/open?id=0BzM9W6qUvx-gVHBGWEp3QkpURVE md5sum: a632c866e22114c0e18fa335f005293e
May 25, 2016
Quite a bit of changes here...
-VM completely readjusted. vfs_cache_pressure set back to default 100 to fairly reclaim memory pages that have been allocated to block specific data about file location, etc.. there are tons of write ups on this stuff if you guys want to investigate more into what this setting does, how it works. It's basically a fairness multiplier centered around a value 100. + or - that value increases or decreases the probability that the kernel will reclaim those certain memory pages relative to swap.
-Swappiness reduced drastically... from 80 to 40 (default is 60 depending on which kernel you are running)
-dirty ratio and dirty background ratios reduced drastically to avoid massive amounts of data being flushed and causing system hangups when that ceiling is hit. (lol this happened to me... system ran out of mem... *shrugs* I go hard bros)
-Increased the probably of the system to reclaim memory pages, and made a pretty big adjustment to writeback_centisecs and expire_centisecs
-Changed functional aspects of the interactive governor again - it is perfect. Nominal user experience. Same with touch input_boost. This system definitely has a sweet spot, and I'm pretty sure we've found it now.
-Decided to ditch the laptop mode idea and not mess with the RAM console outputs, the functional loss wasn't returning enough reward. So, here we are.
-Adjusted minfree once more, to
-It is important to note that the system will, admittedly, not multitask quite as aggressively. I had to do this, however, for myself mostly. As I was achieving OOM conditions and hitting the high ceilings set in other parameters like dirty_ratio and when it hits that wall, man it hits hard. Complete lock up for a good 40 seconds while everything is getting dumped from memory. I need a phone with more RAM lol. Didn't think that would ever happen on my mobile set up with 4 GB of it but here we are. I suppose I could re-enable zRAM for myself? But that would hardly help as compression ratios aren't going to yield me an extra gigabyte. Ok now I'm rambling. DOWNLOAD THE FILE!

Very interesting, I'll be trying this in the next hour or so! Thanks for posting.
Edit: Made changes as per the instructions and rebooted successfully. No issues so far, we'll see! Thanks again.

Nice...
Desde V10 (LG-H901)

For all variants? Is it compatible with H961N LP?
Looks promising and wanted to try.

How do I know it worked? I followed the steps
Sent from my LG-H901 using XDA-Developers mobile app

roosxter said:
How do I know it worked? I followed the steps
Sent from my LG-H901 using XDA-Developers mobile app
Click to expand...
Click to collapse
After every line he explains what it does, you would recognize the changes through your usage or maybe non-usage (as far as battery life and RAM management goes)

When I try to move the file it's giving me this error. I have BusyBox and pretty sure it's on read/write access. What am I doing wrong -_-
1|[email protected]:/ # mv init.qcom.post_boot.sh /system/etc
mv: init.qcom.post_boot.sh: remove: Read-only file system
1|[email protected]:/ #

iamtheon said:
When I try to move the file it's giving me this error. I have BusyBox and pretty sure it's on read/write access. What am I doing wrong -_-
1|[email protected]:/ # mv init.qcom.post_boot.sh /system/etc
mv: init.qcom.post_boot.sh: remove: Read-only file system
1|[email protected]:/ #
Click to expand...
Click to collapse
i got problem with the !!!!!!cd /sdcard , writing
i tried cd /storage/emulated/0
and worked for me

11868 said:
i got problem with the !!!!!!cd /sdcard , writing
i tried cd /storage/emulated/0
and worked for me
Click to expand...
Click to collapse
I tried that, but doesn't hurt trying again.
Edit: It worked. I did the same thing lol oh well thanks @11868

Can this be done with the root explorer instead of terminal emulator?

So this can be used on the G4? And does this overwrite settings within the kernel? If I push this file and I don't like the results can I flash a kernel to get rid of the changes?

iamtheon said:
When I try to move the file it's giving me this error. I have BusyBox and pretty sure it's on read/write access. What am I doing wrong -_-
1|[email protected]:/ # mv init.qcom.post_boot.sh /system/etc
mv: init.qcom.post_boot.sh: remove: Read-only file system
1|[email protected]:/ #
Click to expand...
Click to collapse
Your system wasn't mounted as rw when you executed the command
agrenwa said:
Can this be done with the root explorer instead of terminal emulator?
Click to expand...
Click to collapse
It can, yes, I just prefer the old school way. You can manually drop the file in the /etc folder after deleting the previous one. Just need to make sure the permissions are set appropriately.
klbjr said:
So this can be used on the G4? And does this overwrite settings within the kernel? If I push this file and I don't like the results can I flash a kernel to get rid of the changes?
Click to expand...
Click to collapse
Yes, this can be used on the G4 and any other device using the Snapdragon 808. Overwrite settings within the kernel? No, I wouldn't say that. sysfs is more of a userspace / virtual file system that allows you to interact with the hardware... but the parameters we are working with here are completely writable, not permanent, and more important, will reapply AFTER boot. So, no, flashing a kernel will not revert the changes. If you want to go back, you'll need the original file to replace mine with.
Hope this answers your questions.

Since the file is hosted on Dropbox, anyone who has a dropbox account please choose the login option, and transfer the file to your dropbox before downloading it from your own storage to avoid OP's dropbox being blocked for too many downloads in a row.
Good Job OP, nice to see Junior Members doing something great in the dev section

So I did it last night, and so far battery life seems to be much worse than before when nothing has changed but these tweaks. Any idea why? Battery stats is the same for me as usual with the exception of Android System being at 6% and Android OS at 6% use each.

So far so good, not sure what battery usage will be like. I had terrible lag in a game called Underworld Empire and that has disappeared! How badly was the kernel/system coded before?!
Question , how come your file is smaller than the original? Was there a lot of excess code that was useless?
Sent from my debloated rooted LG V10 using Tapatalk

rirozizo said:
Since the file is hosted on Dropbox, anyone who has a dropbox account please choose the login option, and transfer the file to your dropbox before downloading it from your own storage to avoid OP's dropbox being blocked for too many downloads in a row.
Good Job OP, nice to see Junior Members doing something great in the dev section
Click to expand...
Click to collapse
I'll try to upload the file elsewhere, didn't consider that. However, it is a very small file and dropbox might not notice/care. Good observation.
danstheman7 said:
So I did it last night, and so far battery life seems to be much worse than before when nothing has changed but these tweaks. Any idea why? Battery stats is the same for me as usual with the exception of Android System being at 6% and Android OS at 6% use each.
Click to expand...
Click to collapse
Coincidence maybe? Keep monitoring, report back.
Also, bear in mind: rebooting your system causes a little more activity within the OS the first day or so (particularly google services) and it does have an effect on battery drain.
amoot329 said:
So far so good, not sure what battery usage will be like. I had terrible lag in a game called Underworld Empire and that has disappeared! How badly was the kernel/system coded before?!
Question , how come your file is smaller than the original? Was there a lot of excess code that was useless?
Sent from my debloated rooted LG V10 using Tapatalk
Click to expand...
Click to collapse
Yes, it is smaller because I removed everything that was not relevant to the msm8992 SoC. Qualcomm uses common files for just about everything and anything they can - saves them time, hassle and consolidates work somewhat.
Most of the content removed from the stock file is for other platforms not relevant for us.

warBeard_actual said:
I'll try to upload the file elsewhere, didn't consider that. However, it is a very small file and dropbox might not notice/care. Good observation.
Click to expand...
Click to collapse
I recommend Google Drive or Box

@warBeard_actual
Great job buddy on this.... @freeza mad af!
To everyone else I've been using this for a while and am happy to report my buddy warBeard_actual has been killing it!

bencze, proof or it didn't happen

[9.0 r1] Is 'dalvik.vm.heapsize = 36m' a mistake?

Hi Essential Phone owners,
Can someone confirm that the Essential Phone has set dalvik.vm.heapsize to 36m instead of... 512m?
The build.prop in the vendor partition of the phone has this line:
dalvik.vm.heapsize=512m
// line 29
But the build.prop in the system partition has:
dalvik.vm.heapsize=36m
// line 68
Any devs know which one gets applied last? I think at the current state it would be heapsize=36m which is unusual.
For anyone that can edit build.prop on their own phone you can try this,
1. Remove dalvik.vm.heapsize=36m in system's build.prop
Or
2. Add dalvik.vm.heapsize=512m at the bottom of the system's build.prop
:angel:

this is extraordinarily interesting due to the fact that ive seen reports on reddit claiming this makes scrolling smoother. i deleted the heapsize=32 line and noticed maybe a slight difference. nothing night and day but a small improvement. granted i am running stock with elementalX kernel but its still worth noting that in my case it seems to yield a slight improvement

JBlaze05 said:
this is extraordinarily interesting due to the fact that ive seen reports on reddit claiming this makes scrolling smoother. i deleted the heapsize=32 line and noticed maybe a slight difference. nothing night and day but a small improvement. granted i am running stock with elementalX kernel but its still worth noting that in my case it seems to yield a slight improvement
Click to expand...
Click to collapse
Where did you find reports on reddit?
Anyways thanks for your input!

TFutoMaki said:
Where did you find reports on reddit?
Anyways thanks for your input!
Click to expand...
Click to collapse
this would be the thread

This means nothing...
su
getprop|grep heapsize
It's all placebo

Heap size and scrolling? Wtf. No, just no. I have a thread on here that actual helps with the scrolling. Add the following to your build prop in /system to improve scrolling lag and stutters.that other stuff would do nothing.
#Property to enable touch optimizations
persist.vendor.qti.inputopts.enable=true
persist.vendor.qti.inputopts.movetouchslop=0.6.
The 0.6 can be changed to your liking. 6 works well. Don't go past 8 or **** gets weird.

Thanks you all, I got with me the Essential phone now so yeah seems like it is system build.prop, and then vendor build.prop applies over it. Interesting stuff that I should remember

Dalvik heapsize
36mb heap size is use before for low memory devices that have only 512mb of physical memory or ram, Running in gingerbread os etc. that uses only small amount of physical memory and not much features added on the Android operating system, The answer to your question is 36mb heap size is not gonna work in newer Android devices and it can cause bootloop, because the newer Android Operating System requires higher usage of physical memory for full functionality.
"vendor_build.prop and system_build.prop Is the same list in functionality they only have different location, the system combining them in to one build.prop, to check your full system combined build.prop install terminal emulator and enter- "getprop"
vendor.prop is should be for Rom versions and the system.prop is for manufacturer default Android features and device features configuration.

marvinxxx said:
36mb heap size is use before for low memory devices that have only 512mb of physical memory or ram, Running in gingerbread os etc. that uses only small amount of physical memory and not much features added on the Android operating system, The answer to your question is 36mb heap size is not gonna work in newer Android devices and it can cause bootloop, because the newer Android Operating System requires higher usage of physical memory for full functionality.
"vendor_build.prop and system_build.prop Is the same list in functionality they only have different location, the system combining them in to one build.prop, to check your full system combined build.prop install terminal emulator and enter- "getprop"
vendor.prop is should be for Rom versions and the system.prop is for manufacturer default Android features and device features configuration.
Click to expand...
Click to collapse
You answered a 2 year old post...