Database Develop

dev help! how did u fix wifi and sync on eclair??

cud anyone share with me how to get sync fixed and wifi fixed on eclair??
Im compiling an elair sapphire rom, ive got it booting, and it runs ok. just no wifi or sync.
please help!

bump!
cmon guys... i need help with this, im a noob to developing....
think i dun ok gettin it to compile and boot!
please help me out... and share ur fixes... it'll only mean more choice of roms!

I dont know a lot but I imagine its two seperate things.
the WiFi I imagine is a driver issue, and the sync is because you are missing the google apps.
I am guessing, but after compiling my own 1.6 rom and overcoming some of the strange things I found in doing that its a somewhat educated guess.

you re right! it is two seperate issues..
i have compiled the rom with the google apps from the milestone included. however i am experiencing the same issues with the sync that other devs did when they started working on eclair.
i am wondering how the other devs fixed the issues as this is the only thing preventing me releasing the rom
can anyone shed any light on these issues for me??? will credit u appropriatley on release.

bump again! sorry
can a dev help me out then??
thought this community was about sharing knowledge??

i think this would be a question that actually does belong in development. try there.

this thread already got moved from the development section!
just need pointin in the right direction, will figure the rest out myself!

bump, bump, bump!
can no one help me with this??!!
im guna try and pull sum stuff from the nexus one dump.. see if that works...
feels like im bangin my head against a brick wall tho..
ive downloaded loadsa roms off this site... and now im tryin to put something back, no one will help me out!
cmon devs, pm me, help me out with a fix for sync and wifi.
thanks!

ok, first of all, you're making a sapphire build but is it for the sapphire or the magic? They both use different kernels. If you're building for the sapphire (32b) then the stock kernel and wlan modules work fine. You might have a bluetooth problem, so, if bluetooth won't start, in your /vendor/htc/sapphire-open look for init.sapphire.rc and at line 59 change where it says "texas" to "texasalt". If you don't have bluetooth problems then don't change it.
Did you change your kernel by any chance? This could happen if you're using somebody else's boot.img or if you knowingly used another kernel and packed it to the default boot.img, or further, if you built your own kernel.
If you used somebody else's kernel, then you need to replace the wlan.ko module, again, in /vendor/htc/sapphire-open with the wlan.ko module from the kernel you took.
If, instead, you built your own kernel, then you need to rebuild the wlan.ko module doing the following (taken mostly in part from Johan de Koning's blog), ~/mydroid reffers to your working android path (mine's ~/Desktop/android/master):
Code:
export PATH=$PATH:~/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.X.X/bin
(replace X.X with the toolchain version numbers you used to build your kernel)
Code:
cd ~/mydroid/system/wlan/ti/sta_dk_4_0_4_32
export KERNEL_DIR=~/mydroid/kernel/
make
and then copy the just-created module to sapphire-open
Code:
cp wlan.ko ~/mydroid/vendor/htc/sapphire-open
And about the sync problem? I'm wondering myself too. My last AOSP master build had gapps on it, but sync was still broken (you had to disable it), and so is still everybody else's based on AOSP, except for JAC/Cyanogen's.
The only other eclair build out there with working sync is Manup's, but his is based on the 2.0.1 sdk system image and he didn't fix sync, it just works on 2.0.1, so whatever was preventing sync from working on the 2.0 aosp build was fixed on 2.0.1, he just tossed the gapps in there and they worked.
I'm interested too in learning how Cyanogen worked out the sync problem on AOSP, he tweeted something like "I think I know how to solve the sync problem" a few days ago, but he didn't elaborate. We have to find someway to lure him to this thread and let us know how to fix it on our repos rather than copy his own.

If you do find out about fixing the sync problem (programatically), let me know please, I'm also interested.

Actually, looking through cyanongen's github, I think I found the answer. I'll make a quick eclair build and test.
http://github.com/cyanogen/android_...mmit/eea38a1ad7a61b4426612222a654da610e02855a
---edit---
nope, not it.

Here's the sync fix:
http://github.com/cyanogen/android_frameworks_base/commit/9fb8bb8a9542dfcaf9f546d9cee545517a03bed1
I think this would be pretty easy to patch into a non-AOSP build using smali/baksmali too since it's so simple.
Not sure what kind of wifi problem you have.. I've had no problems with it.

thanks 10chars
---edit---
nevermind

thanks guys.. i will start my own build as soon as i get home!

Also.. You should be able to build using my sources and get a system.img that actually works 100% and can be fastbooted.

Kovsky Kernel Development [2.6.27]

Guys,
Seems like there are lots of threads popping up with new 'packages'. I thought we should create a thread solely for the discussion of kernel hacks/patches so that we can separate the two:
For those of you who dont know, http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm-xdadev is the repo were are working on.
Just to clarify, this topic is ONLY for discussion regarding Kernel patches. Thanks to vdelf's headset patch it seems sensible to focus on:
1. Backlight always on problem FIXED 01/05/10 (vdelf)
2. Battery Issue FIXED 11/05/10 (drlucky)
3. Camera
4. USB
5. GPS

Makes sense. Lets add USB to the list. While charging works, data transfer does not. Also USB might allow us to debug kernel/android on the x1 and that is what dev's always dream of

:suggestion: why not add the latest kernel as download in the 1st post if there is progress. So everyone know where to download the latest updates u ppl do

dexteral said:
:suggestion: why not add the latest kernel as download in the 1st post if there is progress. So everyone know where to download the latest updates u ppl do
Click to expand...
Click to collapse
It will be great to do this, and stick it

@dexteral,
Anyone can checkout the kernel from the above repo I posted. To do what you require we would need to upload the Kernel everytime someone adds a patch...

vdelf said:
Makes sense. Lets add USB to the list. While charging works, data transfer does not. Also USB might allow us to debug kernel/android on the x1 and that is what dev's always dream of
Click to expand...
Click to collapse
Is data transfer even possible in haret? I mean how would system unmount sdcard if it's running from sdcard itself?

not fast data but normal will work

love it
vietdoan20062006

Hi, Lets add fm-radio to the list

Great idea ... otherwise we are creating such a mess with lots of different kernel versions in different threads.
If anyone is interested in compiling the kernel as well as the wifi modules, I have setup a VMWare debian appliance containing all necessary tools and scripts to compile everything. Since this is a few hundes MB, I haven't got a place to upload ... need to check this first. If you are interested, let me know.

@drlucky
Have you had a chance to look at the backlight issue? I am almost out of ideas

Can you post your modifications on the microp-module and what you found out until now?

_Sensible said:
Guys,
Seems like there are lots of threads popping up with new 'packages'. I thought we should create a thread solely for the discussion of kernel hacks/patches so that we can separate the two:
For those of you who dont know, http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm-xdadev is the repo were are working on.
Just to clarify, this topic is ONLY for discussion regarding Kernel patches. Thanks to vdelf's headset patch it seems sensible to focus on:
1. Backlight always on problem
2. Battery Issue
3. Camera
4. USB
5. GPS
Click to expand...
Click to collapse
hey could you post the steps involved for compiling the kernel i am able to comile the kernel but it is not running

Wich toolchain do you use? arm-2008q1 or arm-2009q3?

X1iser said:
Wich toolchain do you use? arm-2008q1 or arm-2009q3?
Click to expand...
Click to collapse
arm-2010q1
could u write all the commands used by you
the way i have written

Personally I'll start to see how to compile the kernel. Can you share the link to download arm-2010q1?
Have you read this post ?

X1iser said:
Personally I'll start to see how to compile the kernel. Can you share the link to download arm-2010q1?
Have you read this post ?
Click to expand...
Click to collapse
http://www.codesourcery.com/downloa...-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
but may be it is not the right one it has got 202 in it insted of 67
ya i read that post only
i was able to compile the kernel but it is giving some errors

_Sensible said:
@drlucky
Have you had a chance to look at the backlight issue? I am almost out of ideas
Click to expand...
Click to collapse
Sorry, haven't had the time. Could you push your changes to the git repo, I will try to have a look at it this week ...

okay i tried to make the kernel bt following the guide above by fatsal...
but i got stuck at
make htckovsky_defconfig ARCH=arm
htckovsky_defconfig doesn't exist (in the new repo anyway, i believe)
any help? which defconfig to use? :S

drlucky said:
Sorry, haven't had the time. Could you push your changes to the git repo, I will try to have a look at it this week ...
Click to expand...
Click to collapse
Just played with the klt-driver a bit. I always get version 0x0000, which on a hero means "bootloader mode". I have tried to migrate the hero code, but with no luck. It seems that the microp-klt needs a "reset", which shoudl be done by using a magical GPIO (on hero: 76), but this doesn't currently work at all. Kernel boots up, but still gets no valuable version number.

[development]-kernel 3.4-freexperia

hy all
this is an project starter for android 3.4 kernel development for all msm7x30 mogami devices
sources are hosted on
https://github.com/freexperia/android_kernel_semc_msm7x30
br
J

Project Status
- we got initial branch after diffing lost of branches
M7630AABBQMLZA203029A
https://www.codeaurora.org/gitweb/q...it;h=4b2b84c6a0b6d29864e982a7aecc223acfd2eaa1
forked to our git and with mogami patches aplied
https://github.com/freexperia/android_kernel_semc_msm7x30/tree/M7630AABBQMLZA203029A
latest CAF tag for 7630 not usefull for now
https://www.codeaurora.org/xwiki/bin/QAEP/release
"November 16, 2012 M7630AABBQMLZA40701070 - msm7630 - M7630AABBQMLZA40701070.xml - 04.01.02" android 4.1

ETA
depending on problems and developers that will join
from 6 months to NEVER

This is a bold task. Perhaps you could look at the developments of irii-soft (and some others), they have replaced some crap Sony-specific code with generic wrappers. Main obstacle if I remember is memory maps now, there was an issue with partition maps but ATAG can be easily over-ridden via kernel command-line.
Getting it to boot should be trivial, sound and video will be difficult, and RIL may be never working due to lack of sources. Regardless, all the best. When I have more time I plan to help irii with his work on a "generic" 2.x kernel newer than what we have (because 3.x seems outrageous at this point).

Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)

Boudin said:
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Click to expand...
Click to collapse
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.

To FXP team,
I don't know if you know or not or even got this far in the development stage but I just wanted to point out a couple of things which may or may not help you...
So with the 3.4 kernel brings newer WiFi drivers which will give a better connection signal on wpa2 security but you might find that devices won't be able to connect to open security networks and WiFi hotspot will probably be broken. I'm posting this as on my gnex using custom kernel (FrancoFransico) he incorporated the 3.4 WiFi drivers a few times and broken hotspot and not being able to use open security WiFi networks were repeatedly reported problems.
I think it may be something hardware specific which allows these features to work on the 3.4 WiFi drivers specific to the nexus 4? You may have more luck trying the 3.0.xx WiFi drivers and getting those to work fully.
Best of luck to you guys!
Sent from my Galaxy Nexus

I'm pretty sure wifi is way down on the priority list, not to be rude but really - who cares about that now. Priority list would be like this:
(1) Get it to boot
(2) Fix primary/critical hardware-specific code for msm7k and qcom platform (display, audio)
(3) Fix RIL
(4) Fix secondary hardware (sensors, bluetooth, wifi)
One step at a time. Getting wifi will probably be trivial because bcm sources are part of the mainline kernel.
With that said, I'm unsubscribing from this thread now. There is massive work to be done and I can see this thread is just going to be filled with posts that have nothing to do with actual development.

All non-dev related posts, and especially "Thank You" posts, will be deleted without further notice. If I have to delete 5 pages of useless posts again, this thread will be locked.
Thank you!​

We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.

adridu59 said:
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
Click to expand...
Click to collapse
Whats the progress so far on this? Bootable already?

CosmicDan said:
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
Click to expand...
Click to collapse
I was asked by some user of this forum to give some kernel porting guidelines in this thread, so let me introduce myself first. I'm the developer of 3.0.x kernel for Samsung Galaxy Spica (also several other projects for Spica and Galaxy Apollo/Galaxy 3) and currently also Linux kernel developer at Samsung Poland R&D Center. Porting the kernel for Spica was a difficult task, because of poor quality of original kernel code, which required rewriting from scratch most of it, but it was very educational.
It's not easy to give advice, but I'd say that taking all the differences from clean kernel and applying all of that on top of newer version is what should be avoided. Of course those differences should be collected to see what was changed by the manufacturer, but this should be only used for further analysis, not as a ready code.
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree. This will elminate Google's changes (that would be already available in your new base - android-3.4 branch of kernel/common) from the diff.
For getting the diff, I would personally also use Git. If you create a branch in your working tree which contains Android kernel in the version corresponding to your device kernel (using the way I described in previous paragraph), then copying your device kernel sources onto your working tree (remember to make distclean both trees to remove any compiled/generated files) will allow you to see the differences using git status and git diff. (See http://gitimmersion.com/ if you want to learn more about Git.)
Now it's important to split the changes into logically separate parts, for example core changes in arch/arm/mach-whatever_suitable_for_your_device, adding of particular drivers in drivers/, sound/ and include/, modifications to core kernel code in any other directories. It's essential to check whether all the changes are really required or not and why, because minimalizing the set of changes required to be replayed on top of your new base kernel sources will simplify your work.
After collecting all the changes, it's the time to apply them on top of your new kernel sources. All the changes should be applied one by one, checking how much the component that is being touched has changed since your old kernel and adjusting the changes properly. After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Some links that might be useful:
- Linux cross reference, for comfortable reading of kernel code - http://lxr.linux.no/+trees
- Linux Device Drivers, a book about kernel programming - http://lwn.net/Kernel/LDD3/
- Git Immersion, a great Git tutorial - http://gitimmersion.com/
- Android kernel/common repository with full archive - https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary
- Linux stable repository, with all version tags - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Hopefully what I wrote will be helpful in your project. Good luck and best regards.

Hey tom3q,
thanks a lot for leaving some useful statements here!
tom3q said:
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree.
Click to expand...
Click to collapse
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
tom3q said:
After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Click to expand...
Click to collapse
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert

hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
scholbert said:
Hey tom3q,
thanks a lot for leaving some useful statements here!
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
Click to expand...
Click to collapse

FXP said:
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
Click to expand...
Click to collapse
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7

voyteckst said:
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
Click to expand...
Click to collapse
ok
nice explanation
look on first page

diff is 5mb on proper tag
pushed on github

nice to see so many developers trying to help

FXP said:
diff is 5mb on proper tag
pushed on github
Click to expand...
Click to collapse
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.

tom3q said:
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
Click to expand...
Click to collapse
sony added too many changes to be usefull
since there are several api changes on 32->3.x diff is no good
we have to start from clean board-7x30 and populate devices porting drivers 1 by 1
we have to try an device bringup based on sony changes

[ROM] Cyanogenmod 10.1 with App Permission Control (unofficial)

OpenPDroid is an awesome mod developed and maintained by CollegeDev, FFU5y, Mateor, Pastime1971, Syvat and Wbedard that allows you to configure for each app separately exactly which permissions it should have and block or spoof everything else. Unfortunately, it can only be used if the core platform is integrated directly into the ROM. (For more details, see http://forum.xda-developers.com/showthread.php?t=2098156)
Since I have completed the integration anyway during my attempts to fix the HDMI rotation bug (without success so far, I'm afraid) and the current version of CM does not seem to contain any more critical bugs, I thought others might like to make use of my ROM as well.
I therefore hereby present: CM 10.1 with OpenPDroid integration. Besides the platform integration I made the following changes:
PDroid Manager app integration.
Standard CM Updates are disabled by default.
CM anonymous stats collection is disabled by default.
Google Analytics integration has been removed from the CM stats collection module.
Updates and anonymous stats collection can simply be enabled again using the menu. (Warning! Applying a normal CM update purges the OpenPDroid integration!)
I will try to at least provide updates to newer versions at critical update moments and will perhaps provide some more in between.
You'll need to have ClockworkMOD installed in order to flash this ROM.
Downloads:
11/07/13: Version based on CM 10.1.1 stable. Steps:
1. Flash the stable version of CM 10.1.1 (10/07/13) for our device.
2. Flash this OpenPDroid patch.
3. Install PDroid Manager either from the Play Store or using the APK attached to this post.
10/07/13: (based on source code 09/07)
10/07/13: https://mega.co.nz/#!uswGGQ6K!Wt9JAFDBElZQ2i74yNxMrkz3y7kO4U8-LWK2dLx_L8s
10/07/13: MD5: 99fc3769c9b2354a844ac1ac92504650
16/05/13: (build with standard CM kernel)
16/05/13: https://mega.co.nz/#!StIyQbzD!GfgNa3Seha74UnSahokwIzvcZ9UVqKaa2P38_LlxuMY
16/05/13: MD5: ad036e4035291bba901ad90826ab0abf
13/05/13: (general source code cleanup)
13/05/13: https://mega.co.nz/#!KoxixajK!Wn91VGj5ooOFYXs-Vt8QJDkU8Bo7VuR40_939hd3YMg
13/05/13: MD5: dffad528804bf830c4b225b0bfff5a76
09/05/13: (WerewolfJB kernel v003 new)
09/05/13: https://mega.co.nz/#!2txwmS4S!aR4bHG6BHMkoTPabi8Z0K0r4hPsUICmKO9ROaaIYOg0
09/05/13: MD5: 4a75829296a167a563ad78ffe26991de
05/05/13: (vibration,memory management)
05/05/13: https://mega.co.nz/#!bsQERDaS!RHB4rHhQsDf9XauyOpeMySAiDt1gtc8Y7gnsckdWOlo
05/05/13: MD5: e05017acf9e50affcba7379050514d63
01/05/13: (merged in the WerewolfJB kernel, fixed headphone button actions)
01/05/13: https://mega.co.nz/#!ig5hCJYY!eHM5vwER9zEEZJRk9_C6vCvclH14rDcKa9CyBcU9kTc
01/05/13: MD5: 3ababb1c0cda47874ed7d688de032638
28/04/13 (adjusted some device references for improved custom recovery compatibility)
28/04/13: https://mega.co.nz/#!71BgVLBY!PEcEHAYxpDZVZcQycpgGJ2QeJZZ0HbgVdjaBkiD72bg
28/04/13: MD5: 7f2616736dd78940e37d1e14ea47084f
24/04/13: (storage, power profiles)
24/04/13: https://mega.co.nz/#!j44XWBDb!UrmGEhCUcjbj8Q3WTj1EkDrImXJXwcNGvEMIHFm-TvE
24/04/13: MD5: 491a500c5bef958d7575a6ce62fae1aa
23/04/13: https://mega.co.nz/#!75IDhCAA!EpwDqHm6W6fG3mk0lNaC0XPWvlsJxi2TjEpjJPEuj6Q
23/04/13: MD5: 609c76958796f19fb04aee217c44ba98
PS. If anyone ever discovers the correct procedure for calling the proprietary nvidia tegra driver api, please let me know.

is the baseband wakelock solved in this rom?

Who can change the other network disk ，thx

xtribas said:
is the baseband wakelock solved in this rom?
Click to expand...
Click to collapse
The main additional problem that this ROM currently fixes compared to standard CM is that of blatant privacy violation.
Since the wakelock issue seems to be related to mobile data use, and I don't have a data subscription, experimentation with this would quickly rack up my phone bill. If someone comes up with a solution I'd be happy to patch it out though.

Hansey said:
Who can change the other network disk ，thx
Click to expand...
Click to collapse
I assume you're referring here to the swapping of disk names when using MTP. I actually only noticed this bug last night and it should be easy to fix. I plan to have it patched out in the next version.

Update 24/04/13 uploaded, involving official CM patches for MTP storage & power profile settings.

Is there a guide how to compile it my self?

DavidXanatos said:
Is there a guide how to compile it my self?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1994860

DavidXanatos said:
Is there a guide how to compile it my self?
Click to expand...
Click to collapse
At the Cyanogenmod website there are instructions for compiling yourself. You can apply the OpenDroid patches using the link I included in the post. Make sure to synchronize the proprietary files with those provided by Cyanogenmod or some aspects will fail to work.

@Wenque - As the original CM on which you based this has the incorrectly labelled hardware platform which means it can only be flashed with the one particular version of CWM, could you possibly modify your version so the coding is for X3, not for P880 - then it could be flashed with any recovery.

SimonTS said:
@Wenque - As the original CM on which you based this has the incorrectly labelled hardware platform which means it can only be flashed with the one particular version of CWM, could you possibly modify your version so the coding is for X3, not for P880 - then it could be flashed with any recovery.
Click to expand...
Click to collapse
Thanks for pointing this out, as I wasn't aware that my ROMs still suffered from this problem. I'll look into it.

Wenque said:
Thanks for pointing this out, as I wasn't aware that my ROMs still suffered from this problem. I'll look into it.
Click to expand...
Click to collapse
No problem. I got the 'Status 7' message when I tried to flash it, due to the P880.
This problem goes away with the latest (v6.0.3.1) version of CWM, so it's not massively important I guess. It would be better if CM modified their builds to reflect the correct hardware identifier.
May be worth you expanding your OP slightly to contain a link to the correct CWM - just to make it easier for people to find.

SimonTS said:
No problem. I got the 'Status 7' message when I tried to flash it, due to the P880.
This problem goes away with the latest (v6.0.3.1) version of CWM, so it's not massively important I guess. It would be better if CM modified their builds to reflect the correct hardware identifier.
May be worth you expanding your OP slightly to contain a link to the correct CWM - just to make it easier for people to find.
Click to expand...
Click to collapse
Good idea. I'll probably just expand the model check in the update script for future uploads so it accepts both references.

Update 28/04/13 uploaded, for some improved custom recovery compatibility. As every update, it also contains all official CM patches.
All patches between this version and the last one are minor, so for people who have installed the previous version of the ROM there is no need to update to this one.

Is anyone else having problems with GPS on this ROM? I am going to try going back to all the old methods I used on my HTC DesireS, but thought I'd ask here as well.
For those who wonder what the old methods were, have a look at derekgordon.com

SimonTS said:
Is anyone else having problems with GPS on this ROM? I am going to try going back to all the old methods I used on my HTC DesireS, but thought I'd ask here as well.
For those who wonder what the old methods were, have a look at derekgordon.com
Click to expand...
Click to collapse
No-body?
I have tried ths both with Derek Gordon's gps.conf modification, and with my own one using just the UK NTP servers and no fancy settings.
If I reboot the phone and run GPS Status & Toolbox it takes between 3 and 5 minutes to get the first lock. This happens whether I do it immediately on reboot or leave the phone alone for an hour first. Once it has established a first good lock, GPS seems to be very good - relocks quickly and stays in the background happily.
The problem is the first lock - it's almost as if the hardware is actually starting off disabled and takes time to warm up or something.
Can someone else using this ROM please test to confirm? I will try this with the standard CM 10.1 build and also with the Stock ROM again, but can't do so for a couple of days.

Update 01/05/13 uploaded. I swapped the default CM kernel with the WerewolfJB kernel (thanks laufersteppenwolf!) and I fixed the headphone button actions (key 248 HEADSETHOOK).
SimonTS said:
Is anyone else having problems with GPS on this ROM? I am going to try going back to all the old methods I used on my HTC DesireS, but thought I'd ask here as well.
For those who wonder what the old methods were, have a look at derekgordon.com
Click to expand...
Click to collapse
Sorry SimonTS, but I don't know whether this version fixes your GPS problems. Perhaps I'll have time to look into it later.

Wenque said:
Update 01/05/13 uploaded. I swapped the default CM kernel with the WerewolfJB kernel (thanks laufersteppenwolf!) and I fixed the headphone button actions (key 248 HEADSETHOOK).
Sorry SimonTS, but I don't know whether this version fixes your GPS problems. Perhaps I'll have time to look into it later.
Click to expand...
Click to collapse
No need to apologise mate. I have tried the WerewolfJB kernel, but it doesn't seem to make any difference. I'm going to look at running the WerewolfJB ROM for a while as GPS seems to work perfectly in that, but hopefully you will get time to build a new version as I really want a ROM with pDroid in it.

SimonTS said:
No need to apologise mate. I have tried the WerewolfJB kernel, but it doesn't seem to make any difference. I'm going to look at running the WerewolfJB ROM for a while as GPS seems to work perfectly in that, but hopefully you will get time to build a new version as I really want a ROM with pDroid in it.
Click to expand...
Click to collapse
All you really need to do is copy the good /system/etc/gps.conf file to the PDroid ROM and make sure that you do not block too many permissions. You are probably using Google's SUPL server to help you obtain an initial location estimation and you don't want to block that if you rely on fast GPS locks.
You can do this by first copying the gps.conf file to a safe location (root of sdcard for instance in /mnt/shell/emulated/) and then performing the following steps:
- Use the terminal emulator with the following commands:
= su
= mount -o remount,rw /system
- Now copy the good gps.config file over the current one (for instance using root-permission File Manager or 'su', 'cp /mnt/shell/emulated/gps.conf /system/etc/' )
- Either reboot now or use the terminal emulator with the following commands:
= su
= mount -o remount,ro /system

Wenque said:
All you really need to do is copy the good /system/etc/gps.conf file to the PDroid ROM and make sure that you do not block too many permissions. You are probably using Google's SUPL server to help you obtain an initial location estimation and you don't want to block that if you rely on fast GPS locks.
You can do this by first copying the gps.conf file to a safe location (root of sdcard for instance in /mnt/shell/emulated/) and then performing the following steps:
- Use the terminal emulator with the following commands:
= su
= mount -o remount,rw /system
- Now copy the good gps.config file over the current one (for instance using root-permission File Manager or 'su', 'cp /mnt/shell/emulated/gps.conf /system/etc/' )
- Either reboot now or use the terminal emulator with the following commands:
= su
= mount -o remount,ro /system
Click to expand...
Click to collapse
It's not that simple mate, but thanks for the reply. I know all about the gps.conf file as we used to have real problems with GPS on my old Desire S. The problem I see with this build and the standard CM is almost as if it doesn't know how to talk to the GPS hardware properly.
With the WerewolfJB build and my own gps.conf file I can get a lock in under 10 seconds sometimes, and always under 20.

Question for Kernel Devs, Re: Hotspot, DUN, "Carrier does not allow type 'dun'."

Question for Kernel Devs, Re: Hotspot, DUN, "Carrier does not allow type 'dun'."
Devs of kernels, ever since Android O, attempting to add dun to APN, results in error "Carrier does not allow type 'dun.'", ever since Google baked it in for the benefit of carriers (in this particular case, T-mobile) to prevent hotspot tethering.
That's very nice of them, but not helpful for me, who must stay on Android N for my hotspot to work properly.
Can one of you kernel devs modify this so that hotspot will once again work properly, or tell me of a kernel or ROM on which it already works the way it used to?
You can let me know via DM if you don't want to reply here.

pbergonzi said:
Devs of kernels, ever since Android O, attempting to add dun to APN, results in error "Carrier does not allow type 'dun.'", ever since Google baked it in for the benefit of carriers (in this particular case, T-mobile) to prevent hotspot tethering.
That's very nice of them, but not helpful for me, who must stay on Android N for my hotspot to work properly.
Can one of you kernel devs modify this so that hotspot will once again work properly, or tell me of a kernel or ROM on which it already works the way it used to?
You can let me know via DM if you don't want to reply here.
Click to expand...
Click to collapse
There has been work on this in LOS. Particularly @nvertigo67 has got a good understanding of the issue and has been endeavoring to enable the functionality on a case by case basis. I'd begin there if i were you.

Dirk said:
There has been work on this in LOS. Particularly @nvertigo67 has got a good understanding of the issue and has been endeavoring to enable the functionality on a case by case basis. I'd begin there if i were you.
Click to expand...
Click to collapse
Thank you.
 @nvertigo67 made a custom confs file that we tested on LOS 16--while it did indeed install dun parameter, the result was still non-functional.
He is still researching, however we both believe google baked in the functionality, and it needs a kernel dev to find it. There were articles a while back (the advent of Oreo?) that refer to google having done so.

pbergonzi said:
Thank you.
@nvertigo67 made a custom confs file that we tested on LOS 16--while it did indeed install dun parameter, the result was still non-functional.
He is still researching, however we both believe google baked in the functionality, and it needs a kernel dev to find it. There were articles a while back (the advent of Oreo?) that refer to google having done so.
Click to expand...
Click to collapse
I've stated it's "more complecated" then adding dun - I've never stated it's kernel related, and I don't think it's kernel related!
I've stoped dealing with this, because I'm tired of begging for information. When we tried the modified apns-conf.xml, you told me it's not not working, but it's working unusable slowly ("like before without the modified apns-conf.xml")...
Again: this is NOT related to the kernel.

nvertigo67 said:
I've stated it's "more complecated" then adding dun - I've never stated it's kernel related, and I don't think it's kernel related!
I've stoped dealing with this, because I'm tired of begging for information. When we tried the modified apns-conf.xml, you told me it's not not working, but it's working unusable slowly ("like before without the modified apns-conf.xml")...
Again: this is NOT related to the kernel.
Click to expand...
Click to collapse
I apologize for misunderstanding.
Thank you for the clarification and your efforts.

nvertigo67 said:
I've stated it's "more complecated"
Click to expand...
Click to collapse
Found another solution--sold OP3T and got OP6T. Surprisingly, it connects properly with pie, using stock or modded ROMs.
Phew.

pbergonzi said:
Found another solution--sold OP3T and got OP6T. Surprisingly, it connects properly with pie, using stock or modded ROMs.
Phew.
Click to expand...
Click to collapse
Which proofes, you were wrong with the dun change you've ask me to do - on los op6t and op3/t use the very same apns-conf.xml file... Perhaps because it's more complecated... *lol*

nvertigo67 said:
Which proofes, you were wrong with the dun change you've ask me to do - on los op6t and op3/t use the very same apns-conf.xml file... Perhaps because it's more complecated... *lol*
Click to expand...
Click to collapse
Yes, thank you.