Database Info

Mer linux for kaiser.

EDIT:
Magister2k7 said:
Please update first post of a thread, as Mer should run X with a latest kernel from git.
You just need to disable FB_MSM_DOUBLE_BUFFER ("Enable MSM Framebuffer double buffering") and enable framebuffer refresh thread.
Click to expand...
Click to collapse
Yeah, I kinda doomed myself from the start with how I structured this post. I'll restructure it later to be more able to show you good information.
Old start:
Mer is a more community-led version of the Maemo phone and internet tablet operating system. See http://wiki.maemo.org/Mer/ .
I was in contact with a member of that project (Stskeeps on freenode#mer), who gave me some information about porting this to phones such as the kaiser. He and I thought it would be a great way to benefit both communities (we get a good, not google-owned linux-based os for our phones, they get developers helping them make mer better). We also agreed that it would take a bit of effort.
First of all, Mer is completely designed for landscape-only, 800x480 phones at this point. It has been run well at 640x480, but that's still 4 times our native resolution, and 2 times what we can fake without crashes. The resolution problem is easily fixed by skilled theme-makers. The landscape/portrait problem should be fixed soon, given that the upcoming n900 will be a portrait/landscape phone. He said wait for the maemo conference for more on that.
The other problems we might hit basically are just the standard problems of molding the userspace around the kernel (get a phone app working, get the modem to work, etc.).
If you are serious about helping, please come to #mer and/or #htc-linux on freenode. At this point, the mer folks are probably more help to what we need to do.
INSTRUCTIONS:
At this point, quite literally nothing works, but it all almost works. Here's what I did to get that far:
1. Partition your sd card into two partitions, and make the second one ext2.
2. Unpack (with the -p option of tar) the rootfs (http://wiki.maemo.org/Mer/Releases/0.16testing , pick the q5 rootfs) to the ext2 partition. Make sure that it's not in any subfolders, but as the root of the drive.
3. Grab a zImage (or build your own) using the instructions we had in place from android. Put it on the fat side.
4. Set up HaRET on the fat side - Use a default.txt from android, get rid of the initrd, get rid of your ppp stuff (for now), and add "root=/dev/mmcblk0p2 rootwait" to the kernel cmdline.
5. mknod /dev/fb0 c 29 0 (this was my number, check using the terminal in android, cat /proc/devices for the major, and /proc/fb for the minor). Also make sure that it's within the root, not on your disk .
That should boot, giving you a ton of messages about an "incorrect resolution png" or something - that's the splash screen unable to load. Simply rename /lib/init/splash-* (two files) to something else. Once you get a terminal later, there's an actual package to remove, but this lets it go a bit further.
You also need to keep X from starting at this point - all it does is hang. I have not yet done this myself, but it should be an initscript that you just un-link.
EDIT: It wasn't X that caused the issues. It was the combination of failed splashes and consolefont. Comment out the lines with "splash" in them in /etc/init.d/check{fs,root}.sh, and re-run.
I do not know if X actually fails - doing that test now.
EDIT: hitting framebuffer issues... no X yet.
So, if you're adventurous, and preferably a dev at this point (this is completely useless to users), please try this out and make it better!
Okay, just a note: the password is "rootme".

First reply!
this is relevant to my interests. I'll take a look. I remember seeing that Maemo was made on top of Gnome. Do you know if there's a chance to get Debian apps on here? That's the big thing for me to get me working on it-- some type of desktop compatibility. Having an X-server is perfect. Looks like you're saying the resolution issue is purely theme based? How open are the devs for it for suggestions and feedback?

2nd reply
This does sound cool

already made some read about this in the new nokia n900..
its cool.. it free.. but i dont like the ui :\
lets see where this goes.. but.. for now.. for me... android (L)

Ok, just saw it's Jaunty based which is what I've been looking for in a phone.
Is there a list of features/bugs/issues and what's been developed so far? Seems like if the kernel brought to us in part by dzo will work maybe it won't be so hard to get wifi and other features working. A list is good.

I'll admit I haven't put much effort into it, but at this point X won't work, for one thing - probably have to change the resolution in a config somewhere.
Indeed, most of the hardware should be fine - I imagine, for example, once we are able to load the firmware, wifi should be good. Some code will have to change (a few things are built android-specific in the kernel), and some of the RIL stuff especially (phone, data, etc.) will have to be ported by someone who has that code and some time.
Indeed, Mer is Ubuntu-based, and so, according to their site, 95% of ubuntu apps should work perfectly. This is really nice for getting software on (aren't just limited to any applications in an app store or market.).
At this point, all we need to do is everything .
I'm going to try now to disable X and see if I can't get a few more things working.
EDIT: in response to your question about how open the mer-folk are to suggestions? The idea that I got from talking to them was that they are more than happy to get this extra help, and since they are trying to bring this to more devices, they are willing to put up with our requirements, to make this more readily available in general.

Alright, as I edited, I got some more success.
By removing the splash calls and the X starting, I can get a terminal. I edited the /etc/shadow file to have a password that I knew for root. Now, I can log in as root on the console (/dev/tty1).
I tried to start X, and I'm getting some strange framebuffer errors.
I'll keep you posted.

Wow, if we could get this working, it'd be sick! Thanks for posting, formatting now.

with all the hard work already done for the Android port, seeing devs being interested in Mer is REALLY PROMISING! Waiting for Google to open up Android even more, is frustrating...
Porting Mer and thus having a REAL linux (kernel+software stack) is what we need to leverage the dev capacity of the great XDA community. At least, this is what I feel like .
Owning both a Kaiser and 2 N800s, I'll probably try out the stuff posted here... I was keeping an eye on Mer for my N800s anyway, but using it on the Kaiser is more triggering
so devs, have courage and good luck!

Frame Buffer and X server
Unfortunately I've been quite busy lately and haven't been following the Android development as closely as I would like. (I don't think I've updated my git repo for months)
If I remember correctly, the frame buffer code in the kernel wasn't finished. That would prevent X from running. Can anyone say whether that was completed? I just wanted to mention this in order to avoid people wasting their time if it is in fact the problem.
It would be great to *eventually* see X running with hardware acceleration, can anyone point me to info about how DZO got that working? Was it reverse engineered, or did he figure out how to make some binary blob happy?
It will be nice to have some choice of Linux based distros the Kaiser and Vogue. Keep up the good work everybody, I appreciate it!
-Mysteryvortex

I've been looking at the n900 for quite some time just waiting for its release to the US next month. I know nothing about developing but I am very excited about this one, and I hope that there is a quick start to the apps that are put out for it. I was curious myself as well at how this would port to the kaiser so I could get a good hands on before I went and bought one. I would be more than happy to be a tester. I bought an iphone cause cause the little green guy is really starting to piss me off and my tilt's about to give up the ghost. I quickly gave it to my wife as the signal strength and battery life just sucks so I hope this maemo can give me what I want

mysteryvortex, Android does not use an X server at all. This was my disappointment when issues arose trying to run Ubuntu in a chroot. This is different though. We should be looking at troubleshooting the X server as top priority I think. The rest should flow. Bear in mind the kernel for Android, like I said, has nothing to do with X compatibility since Android uses its own display so the kernel should need some serious work.
poly, is the build you linked to hardware specific? Looks like a generic one. If so, then the only outstanding difference should be the kernel and if that's the case we should be able to use this on any phone we happen to have a kernel for right?

enatefox said:
mysteryvortex, Android does not use an X server at all. This was my disappointment when issues arose trying to run Ubuntu in a chroot. This is different though. We should be looking at troubleshooting the X server as top priority I think. The rest should flow. Bear in mind the kernel for Android, like I said, has nothing to do with X compatibility since Android uses its own display so the kernel should need some serious work.
poly, is the build you linked to hardware specific? Looks like a generic one. If so, then the only outstanding difference should be the kernel and if that's the case we should be able to use this on any phone we happen to have a kernel for right?
Click to expand...
Click to collapse
The build has a kernel and stuff, but don't use it. Use the regular stuff from android (or build yourself from htc-vogue).
mdrobnak from irc got mer up on his raph - thanks to the vga screen, with a quick kernel patch and some xorg.conf modification, he got X working great.
Within the next few days, I'll do some tests of the data connection and such.

enatefox said:
mysteryvortex, Android does not use an X server at all. This was my disappointment when issues arose trying to run Ubuntu in a chroot. This is different though. We should be looking at troubleshooting the X server as top priority I think. The rest should flow. Bear in mind the kernel for Android, like I said, has nothing to do with X compatibility since Android uses its own display so the kernel should need some serious work.
Click to expand...
Click to collapse
Yes, that's correct. Android doesn't use X. Many, many months ago, it was mentioned that the framebuffer in the Vouge/Kaiser kernel (which X will use) was broken. Nobody was planning to fix it since Android doesn't need it. I was just trying to point people who have time to work on supporting our phones in the right direction.
poly_poly-man: Looks like the Raphael kernel is being developed on another branch, but it sounds like the FB patch helps us?
-Mysteryvortex

poly_poly-man,
I have setup my second partition of sdcard to 512MB and extracted there Mer preserving permissions.
What I did also is to modify the x config and change resolution and also resize the Mer-logo.jpg so it fits.
After I tried to boot I went successfully through all steps (at least I think so) and a blank screen appeared to me.
Can you tell me what was the parameter to output the Haret boot sequence to a file, so I can check what passes and what fails?
Another question: The following "mknod /dev/fb0 c 29" have to be performed on root of second permission, right? If so I think the command should be ""mknod ./dev/fb0 c 29", am I correct?
Regards,
Borkata

Borkata81 said:
Another question: The following "mknod /dev/fb0 c 29" have to be performed on root of second permission, right? If so I think the command should be ""mknod ./dev/fb0 c 29", am I correct?
Click to expand...
Click to collapse
'./dev/fb0 c 29' does only work if you are in "/" (root of the filesystem) otherwise (and in all other cases) 'mknod /dev/fb0 c 29' is correct.
bye...

Borkata81 said:
poly_poly-man,
I have setup my second partition of sdcard to 512MB and extracted there Mer preserving permissions.
What I did also is to modify the x config and change resolution and also resize the Mer-logo.jpg so it fits.
After I tried to boot I went successfully through all steps (at least I think so) and a blank screen appeared to me.
Can you tell me what was the parameter to output the Haret boot sequence to a file, so I can check what passes and what fails?
Another question: The following "mknod /dev/fb0 c 29" have to be performed on root of second permission, right? If so I think the command should be ""mknod ./dev/fb0 c 29", am I correct?
Regards,
Borkata
Click to expand...
Click to collapse
It seems that even set to the right resolution, our fb does not work with X. Needs more patching than just the patches I got from the other branch. We may need to move up to the other branch, I'm not sure.
the /dev/fb0 should be replaced with /path/to/sdcard/root/dev/fb0, of course. And it's better to just get rid of all the splash references - that way, you don't get the blank screen issue.

toasty_ said:
'./dev/fb0 c 29' does only work if you are in "/" (root of the filesystem) otherwise (and in all other cases) 'mknod /dev/fb0 c 29' is correct.
bye...
Click to expand...
Click to collapse
Yes, but poly has written that user have to be in root so that was what I have asked
Question: our fb driver is msm_fb?
poly can you share which patches you tried from raph branch?

Borkata81 said:
Yes, but poly has written that user have to be in root so that was what I have asked
Question: our fb driver is msm_fb?
poly can you share which patches you tried from raph branch?
Click to expand...
Click to collapse
Oh yes, you're right. I should first read the full post before answering questions that havn't been asked

Borkata81 said:
Yes, but poly has written that user have to be in root so that was what I have asked
Question: our fb driver is msm_fb?
poly can you share which patches you tried from raph branch?
Click to expand...
Click to collapse
http://people.openezx.org/tmzt/
the msmts and vres patch. Didn't work, because there are more problems in our older kernel.
I'm interested in finding out why we aren't on 2.6.27 already...

[DEV][SUGG] On dock lid states and kernels

So the thing is, most JB ROMs for TF101 (I think that's actually all ROMs but AOKP) use a userspace hack to invert the dock lid state before propagating it to the power management code in the framework. It is, of course, a solution, but it's rather ugly and it clutters the global framework with code that's actually needed for one or two devices in total.
So I suggest that instead of messing around with the userspace, we need to fix the bug in device specific code, i.e. the kernel. I've made a kernel patch long ago for AOKP, but now I'm experiencing problems with other kernels on unmodified userspace, so I decided to post it here and see if other developers/ROMs accept it.
There is already a framework for 'inverting' the result in the kernel, so I reused that, and that made a very simple patch. All it does is check for any switch input (a.k.a. the dock lid) and set its active_low flag to 1, which makes the kernel invert the received data. Since the code is in gpio-keys, it's very unlikely to conflict with any external devices.
The source for the patch is available on my GitHub, it should work with kernel, though I built it for AOKP kernel, which is stock .39 + bcmdhd.
So, framework hacks vs. kernel hacks, discuss.

K900 said:
So the thing is, most JB ROMs for TF101 (I think that's actually all ROMs but AOKP) use a userspace hack to invert the dock lid state before propagating it to the power management code in the framework. It is, of course, a solution, but it's rather ugly and it clutters the global framework with code that's actually needed for one or two devices in total.
So I suggest that instead of messing around with the userspace, we need to fix the bug in device specific code, i.e. the kernel. I've made a kernel patch long ago for AOKP, but now I'm experiencing problems with other kernels on unmodified userspace, so I decided to post it here and see if other developers/ROMs accept it.
There is already a framework for 'inverting' the result in the kernel, so I reused that, and that made a very simple patch. All it does is check for any switch input (a.k.a. the dock lid) and set its active_low flag to 1, which makes the kernel invert the received data. Since the code is in gpio-keys, it's very unlikely to conflict with any external devices.
The source for the patch is available on my GitHub, it should work with kernel, though I built it for AOKP kernel, which is stock .39 + bcmdhd.
So, framework hacks vs. kernel hacks, discuss.
Click to expand...
Click to collapse
Nice to see you again, old friend.
I have already developed like the same hack for my new CyanogenMod kernel, just that I am using a seperate c class to perform the switch each time the native asus code does receive a signal requesting to change the dock status.
So, generally, I would say this is a good idea and the way this problem should be solved.
The whole problem should stay in a low-level kernel space and never ever even require a userspace fix.
We just have to keep this on track, and maybe do a collection of how to-compile-kernels and some collection of tweaks, e.g. I can share my governor's code and so on. This should be a sticky then, so no developer for the TF101 can ever miss it.
If people request this I can do this. Just need some opinion.
So, after all, +1 to your (and mine, not yet shared) solution.

RaymanFX said:
I have already developed like the same hack for my new CyanogenMod kernel, just that I am using a seperate c class to perform the switch each time the native asus code does receive a signal requesting to change the dock status.
Click to expand...
Click to collapse
The logic's already there, just use my patch, seriously. Also, that's why you read kernel docs before coding stuff, toldya
Also I never really disappeared, you have my GTalk and I have the thread on Rootz. Don't want to post it here though, because XDA is, well, messy. And Rootz, at least for now, is less messy. Kinda. That's what I was thinking. Also keeping close to AOKP official forums.

[Security] fb0 world read- and writeable on Samsung Galaxy S2 with CM9.1.0 galaxys2

Hello,
the device /dev/graphics/fb0 is word read- and writeable on my device (Samsung Galaxy S2 with CM 9.1.0). I suspect it is the same way on many other devices.
Every app can read the whole framebuffer and make screenshots. If the app would do that it could also monitor the softkeyboard. The results wouldn't need to be saved because it could extract the pressed key on the fly.
I have tested a short loop in the Terminal and it worked. I was able to get screenshots from an app with the FLAG_SECURE set. Which should disallow the ability to make a shot. ( I wasn't root. ) I was able to get the fb dumps with the keyboard and the keys pressed.
You can manualy set the Permissions to 660, then only root and graphics users can use it.
Can someone please confirm this configuration on other devices?
I don't think it is intendet that every app can play keylogger.
And before you ask I havn't posted/informed anyone. Because if you look at the /dev/exynos-mem hole you want to check every other file in /dev for similar errors. So that is what I did and i can't be the only one. So I figure the blackhats are two steps ahead.

blulantern said:
Hello,
the device /dev/graphics/fb0 is word read- and writeable on my device (Samsung Galaxy S2 with CM 9.1.0). I suspect it is the same way on many other devices.
Every app can read the whole framebuffer and make screenshots. If the app would do that it could also monitor the softkeyboard. The results wouldn't need to be saved because it could extract the pressed key on the fly.
I have tested a short loop in the Terminal and it worked. I was able to get screenshots from an app with the FLAG_SECURE set. Which should disallow the ability to make a shot. ( I wasn't root. ) I was able to get the fb dumps with the keyboard and the keys pressed.
You can manualy set the Permissions to 660, then only root and graphics users can use it.
Can someone please confirm this configuration on other devices?
I don't think it is intendet that every app can play keylogger.
And before you ask I havn't posted/informed anyone. Because if you look at the /dev/exynos-mem hole you want to check every other file in /dev for similar errors. So that is what I did and i can't be the only one. So I figure the blackhats are two steps ahead.
Click to expand...
Click to collapse
I'm 90% certain this file was copypastaed from a Samsung initramfs - so some Samsung releases most likely have this setup too. I'll ask codeworkx which one.
I'm in the process of cleaning up ueventd, unfortunately this mess happened just as I was getting ready to leave for the holidays.

Entropy512 said:
I'm 90% certain this file was copypastaed from a Samsung initramfs - so some Samsung releases most likely have this setup too. I'll ask codeworkx which one.
I'm in the process of cleaning up ueventd, unfortunately this mess happened just as I was getting ready to leave for the holidays.
Click to expand...
Click to collapse
I was unable to locate the same issue in stock devices, maybe CM is using copypasta from old firmware ramdisks.

jcase said:
I was unable to locate the same issue in stock devices, maybe CM is using copypasta from old firmware ramdisks.
Click to expand...
Click to collapse
Yeah, there's a good chance it predates XWLPM. We swapped kernel sources but not ramdisks with Update7.
What builds have you looked at? I'm going to try and see if codeworkx remembers which build he pulled those from.
I'm going to attempt to do a ueventd cleanup before I leave for the holidays. It may be an "axe everything and let the rest of the team figure out what broke and needs repair" approach...

I think this may have been in a samsung leak that never got removed, it dates back to the very first commit of this file in ICS, but isn't in one of my initramfs dumps from one of the first ICS official releases.
http://review.cyanogenmod.org/#/c/28759/
If no observed regressions it will be backported to CM10/CM9 time permitting, but could take some time as I'm unavailable from tomorrow onwards until the new year.

Hi,
I did a little code search on github, this issue seems more widespread than I thought.
I can't post external links here, because I'm new
If you search on Github in Code for:
/dev/graphics/fb repo:CyanogenMod/*
You will find
CyanogenMod/android_device_htc_click » init.bahamas.rc (Rust)
CyanogenMod/android_device_geeksphone_zero » init.zero.rc (Rust)
If you don't restrict the search on a repo you will get many results for different devices, the once i checked had the permission set to 666 or 777 (in the latest revision). But I didn't find the result with the galaxys2 so i figure my results are far from complete.
Is there a mechanism to let the owners know without searching through every projekt and opening an issue there?
Thanks.

Entropy512 said:
Yeah, there's a good chance it predates XWLPM. We swapped kernel sources but not ramdisks with Update7.
What builds have you looked at? I'm going to try and see if codeworkx remembers which build he pulled those from.
I'm going to attempt to do a ueventd cleanup before I leave for the holidays. It may be an "axe everything and let the rest of the team figure out what broke and needs repair" approach...
Click to expand...
Click to collapse
Recent builds (im lazy and in bed so ill look later)
Sent from my SGH-I317M using xda premium

Entropy512 said:
I think this may have been in a samsung leak that never got removed, it dates back to the very first commit of this file in ICS, but isn't in one of my initramfs dumps from one of the first ICS official releases.
http://review.cyanogenmod.org/#/c/28759/
If no observed regressions it will be backported to CM10/CM9 time permitting, but could take some time as I'm unavailable from tomorrow onwards until the new year.
Click to expand...
Click to collapse
Makes sense since leaks often have more relaxed permissions due to debugging.
Sent from my SGH-I317M using xda premium

[Q] Help editing Android Kernel to remove backlight restrictions

I've managed to successfully compile the kernel and flash it on to my Samsung Galaxy Note 10.1 (GT-N8010) and am now in the process of editing the kernel to remove the limitations on the backlight.
Short story: I would like to be able to drag the brightness fader all the way down and have the screen go to zero backlight.
Longer story:
No, I do not want to use an app to get this functionality, I would like to implement it in the kernel. I have a vague idea of what I'm doing, but I'm getting confused because there are SO many different files that could be applicable and I can't seem to find the right one. Here's what I've done so far:
- Looked in drivers/video/backlight and tried to find a limitation there (most of them are generic/for limiting the top value).
- Looked in drivers/video/samsung and found the driver for the specific LCD in my device (lcd_type: SEC_LTL101AL01-002/003 - driver file: s3cfb_s6c1372.c) but I don't think that is for the backlight as well...
- Rooted around in many other folders, but think drivers/video/[SOMETHING] is going to be where I change this.
I'm not looking for someone to give me a solution, just a tip in the right direction because this is my first time working at the kernel level and it's a lot of information to take in at once.
Thanks in advance and please ask for clarifications if you are confused, I'm happy to provide them!

[ROM][7.1.2][i9305]Unofficial LineageOS 14.1 with modifications

Hi,
I am back with one of my builds. Again this is just result of my hobby, feel free to use it, but do it on your own risk. Also any updates will be probably sporadic.
I wanted to publish my build as quickly as possible, becasuse I promised in another thread. So I simply took, what I have (and I am using right now). As a result there some detail I`d like to change for public release like this for the future (e.g. all the special feature enabled by default, the big dmesg buffer). Be careful. I`ll try to do better version as soon as possible. I don`t recomend this for begginers. Be sure you have backup.
This build is based on the official LineageOS code and contains several of my changes. In some cases it could be considered as fix, improvement, but sometimes a hack or even even security risk, so please read carefully following list. All the changes I did because I wanted the system on my device behave that way (at least time to time). Take it or leave it. Please note, that all the features are enabled by default. Be careful.
- built-in root support
- RIL is based on stock KitKat version (works better for me than the official version)
- the sensors libraries are also from stock KitKat (same reason as above )
- barometer sensor is correctly recognized by the system
- the menu button does, what it always did
- notification led brightness can be configured by user
- entering safe mode by holding specific keys during boot can be disabled by setprop persist.safe_mode_disabled true (this has always only annoyed me, but be sure you know you are doing)
- device wakeup by power button can be disabled when proximity and light sensors are blocked (e.g. in a pocket). Execute setprop persist.pwrbtn_proximity_block true
- external sdcard can be made world writeable by setprop persist.world_writable_sdcard true (be careful with this one, this opens a security risk)
- the notification led can blink when the battery is fully charged - enable by setprop persist.blink_when_charged true
- F2FS support
- the notification icons are also on the lock-screen as they ware in
previous Android versions. The carrier name is moved above the clock
(this cannot be turned off)
- the dmesg buffer size is increased to 16M. I set this for debugging
and remove it in next published build.
- ramdisk LZMA compression support
- sdcardfs support - This is faster replacemnt for the FUSE filesystem. I backported this for higher kernel version. Although I`ve been using this for several months without any problem, please consider this experimental. Enable with setprop persist.sys.sdcardfs
force_on
- mount directories for sdcard are protected against writing while the sdcard is not mounted (this solves a race condition problem which allows some apps to create files in there)
- there some other small changes related to my multiboot envrionment, czech translation, carrier name, etc.
Source code
In the installation zip there is a directory code_info with following content:
roomservice.xml - roomservice.xml for the build
commits - list of git repositories and commits used for the build
patches - directory tree with structure reflecting the source and containing
patches for individual projects. The idea (not always followed) is that one patch is one feature,if possible.
code1.diff - all the patches from patches directory together
code2.diff - changes which are not in patches directory
diff-commits.txt - obsolete, I`ll remove this one in the future or maybe use
it again
The only bug I know about is occasional crash of MTP, but I didn`t notice any negative consequences. There may some problem with battery charging (the display turns on time to time without no obvious reason during charging), but it may be some hardware error (bad cable or charger).
Since this is based on official LineageOS, thanks to everyone who contributed to it.
I am using this build for over a week without any problem, except those mentioned above.
Continue here, for the latest build.
UPDATE:
I totally forget about this yesterday - here are the proprietary files I used for this build proprietary-files-ocm13-skk-ril.tgz It is a mixture from the CM 13 official build and KitKat stock files, with modified ks file (then connect symbol is replaced with xonnect, so it doesn`t crash), maybe some other files and changes. I really don`t remember, I put this together during a long period of time. If you find any of your work inside, please accept my apologies and let me know. From my point of view it just works. If you want to apply the patches, then you will most probably want to change the hardcoded full path to these files in device/samsung/i9305/extract-files.sh.
UPDATE:
If you want to use anything from my patches, feel free to do so, just follow the license of the original project.

I tested it for about 4 hours for modem stability, taking the logs. All SAHARA transfers were ok, with no errors and retries. I should have mentioned your name in some post earlier

gongrats and many thanks @p.a.n. Your rom runs very well, its awesome. :good:
Do you mind, if I take your sources or parts of it or some files from your rom.zip for my builds? If I do so, I will mention you and what I took and give you credits.

rodman01 said:
gongrats and many thanks @p.a.n. Your rom runs very well, its awesome. :good:
Do you mind, if I take your sources or parts of it or some files from your rom.zip for my builds? If I do so, I will mention you and what I took and give you credits.
Click to expand...
Click to collapse
Thanks Use whatever you want from it just follow the license of the original project (I updated OP with similar note).

Help??? How to fix gps on this Rom plzz

Great work p.a.n.
Using for 24 hours no problems yet and seems very smooth.
Used it for a few hours with the built-in kernel then switched to Boeffla to get Boeffla Sound etc.
Very nice to have the customisable LED again as it was missing from the official LineageOS.
More importantly for me, the magnetic compass seems to work properly. I couldn't get it to work on official, nor on Rodman's RR.
No issues with GPS for me.
I had to install 'The SELinux Toggler' to set permissive so I could get Viper4Android to work (as with official) but I expected that.

One other thing, the MTP crash is the 'MTP host' app. I just disable this as it's only needed if you need your phone to be an MTP host for something like a digital camera, which I don't. It doesn't affect connections to your PC.

Is there an issue with the automatic execution of init.d scripts? I'm on Boeffla so it may just be that. Luckily you can tell Boeffla app to execute them anyway.

@Glenn2, thanks for testing I am not completely sure about it, but if I remember well, the compass problem is caused by the opensource sensor library (I think that just replacing the/system/lib/hw/sensors.smdk4x12.so with the one from my build should fix that). But the problem is not actually with the compass sensor, that one is ok, but in the opensource version there are missing some "fake" sensors, which provide calculated data based other "real" sensors. One of them provides orientation information, often used in apps as compass. Try some app (e.g. Androsens2) which lists all the sensors and you`ll see the difference - the "fake" ones have iNemo in their name.
I actually don`t care about the MTP crashes. It mostly happens after uninstalling some app, which doesn`t happen too often and otherwise I haven`t noticed any negative related to that. It is just annoying popup for me.
What do you mean by the question about init.d scripts?

p.a.n said:
What do you mean by the question about init.d scripts?
Click to expand...
Click to collapse
I have a couple of scripts and they were not running on boot. I don't know if Boeffla kernel affects busybox. I remedied this by telling the Boeffla Config app to run init.d scripts when it launches.
Also, I had a power manager service wakelock that kept my phone awake for hours, only a reboot cleared it. I had this happen a couple of times on official LineageOS too. Not the famous mdm_hsic_pm0 which now seems to be cured at long last! I had a period of no signal when I was on the London Underground, maybe that was the cause.

Glenn2 said:
I have a couple of scripts and they were not running on boot. I don't know if Boeffla kernel affects busybox. I remedied this by telling the Boeffla Config app to run init.d scripts when it launches.
Click to expand...
Click to collapse
There is /system/etc/init.d/* scripts, which run OK, or at least /system/etc/init.d/00banner does. There is also /system/etc/init.d/90userinit, which executes /data/local/userinit.sh. I remember that seme previous CM version there was also a user defined init.d somewhere in /data. This may what has changed, but I am not if this is your case.
Glenn2 said:
Also, I had a power manager service wakelock that kept my phone awake for hours, only a reboot cleared it.
Click to expand...
Click to collapse
This on is also often on the top of my kernel wakelock list, but never that bad, always with reasonable times.
Glenn2 said:
Not the famous mdm_hsic_pm0 which now seems to be cured at long last!
Click to expand...
Click to collapse
Yes, the solution has been sitting in the Samsung kernel source for a long time ...

Glenn2 said:
Great work p.a.n.
Using for 24 hours no problems yet and seems very smooth.
Used it for a few hours with the built-in kernel then switched to Boeffla to get Boeffla Sound etc.
Very nice to have the customisable LED again as it was missing from the official LineageOS.
More importantly for me, the magnetic compass seems to work properly. I couldn't get it to work on official, nor on Rodman's RR.
No issues with GPS for me.
I had to install 'The SELinux Toggler' to set permissive so I could get Viper4Android to work (as with official) but I expected that.
Click to expand...
Click to collapse
Do you install the last rom ??? Or not

It is worth pointing out that after backing and restoring between roms, the SELinux attributes for efs files can become not correct. That can lead to something like this :
Code:
06-28 04:17:43.705 3799 3799 W ks : type=1400 audit(0.0:30): avc: denied { read } for name="efs1.bin" dev=mmcblk0p11 ino=8200 scontext=u:r:qcks:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
Code:
06-28 04:17:43.712 3799 3799 E kickstart: Requested ID 16, file "/tombstones/qcks/efs1.bin"
06-28 04:17:43.712 3799 3799 E kickstart: ERROR: function: open_file:80 Unable to open input file /tombstones/qcks/efs1.bin. Error 13: Permission denied
It results in not working RIL because of enforced SELinux. Running restorecon fixes the problem.

moad gastro said:
Do you install the last rom ??? Or not
Click to expand...
Click to collapse
I don't know what your question means, as there is only one ROM. I installed from the link in the OP (dated the same date as the OP).

Still using this ROM, and still very few problems.
The day before yesterday it crashed with the screen off. Had to hold power button in to restart.
And yesterday the damn wakelock. It got stuck at a time when I had no signal, and also I used the camera, so either may be relevant. It didn't seem to cause any drastic battery drain though (see images attached). I suppose when the CPU is awake but only at 200MHz and not doing much it uses little more than when it is sleeping?

Regarding init.d scripts. I added one to /system/etc/init.d that simply writes a file to /data when it runs, to test that it DID run. Script starts #!/system/bin/sh
Results:
1) rom with its own kernel - didn't run
2) rom with Boeffla kernel - didn't run
3) rom with Boeffla kernel and Boeffla Config app set to execute init.d scripts itself - did run

One more, just for fun!
Two days ago I was at the Wimbledon tennis, and the location service and/or weather widget decided I was in Boulogne-Billancourt (Paris) instead! I then opened and closed Maps, refreshed the widget and it changed to the correct location!

..

Hi,
I'm trying to install the current build using TWRP 3.0.2-1, but it gets stuck at the "Patching system image unconditionally..." step with the progressbar at around 40%. It's been sitting there for about 10 minutes. Does anyone know how that'd be fixable?`
Cheers

Latest build is ok for me. I've flashed it using TWRP 3.1.0 build from rgib
https://drive.google.com/drive/folders/0B7pwslEEF0l4Yzk2Nm1jOGRDQVU