I have updated the the IHO binary, my build comes with a newly compiled kernel that I believe has the fixes for the zv9 radio. This kernel like mrg666 is going to be only for OM-IHO.
[ROM+Kernel] Inferior Human Organs unofficial CM7.1
- Thread starter blarf
- Start date
If you've flashed the new kernel, it should read:
Kernel version
2.6.32.9-v4
bobzhome@ubuntu #1
Mms stoppex working for me on bobzhome a while ago. I havent tried his builds for a while, but mirage works for me
So I flashed the new bobz v4 kernel. I noticed things were a little faster, but i wrote it off as a reboot and a clearing of the cash. Then i was doing some web browsing and noticed it was loading and redrawing way faster then usual. Then, after reading about higher over clocks I tried in mine and was able to go up 20MHz. Am I imagining this speed increase and stability, or is there something different about this kernel, that explains it? No complaints, of course, just curious.
I am going to bring up a bug that was first raised a few months ago: The hardcoded Bluetooth address: Instead of using the phone's unique MAC address, all IHO ROMs use the same fixed address of 43:25: D1:00:00:00.
That makes it impossible for two IHO phones to talk to each other through Bluetooth. For me, the more annoying consequence is that my wife and I cannot pair both our phones to our car and swicth between them: Paring one phone wipes out the other, because the car sees the same address. So switching phones in the car involves full pairing procedure every time (entering security codes and all).
(I actually tried naming the phones the same, hoping the car wouldn't know the difference and just connect to the first available phone, but unfortunately that didn't work either).
The issue was previously mentioned in this thread. Also, it was brought up in the IHO thread a couple months ago, but didn't elicit any response (except from me
).
The problem isn't limited to IHO, I believe it is all CM7 phones. Even quattrimus ICS seemed to have the same problem when I last tried it (alpha 9). Still, I am posting it here since IHO is where I have the problem. Of course stock ROM reads the actual, unique MAC address and works fine.
I've searched all over recently. Many users mention the issue and ask for help, but nobody seems to have answers, except "that's just Cyanogen".
Have any of you (devs or others) investigated this issue -- or possibly even have a solution, whether permanent or temporary?
What I tried so far:
1) Deleting folder(s) in /data/misc/bluetoothd. When the BT address is first set, a folder is created here named by the address, containing a config file with device name and class. Someone suggested to delete it and let the folder be re-created next time BT is enabled (presumeably with the correct address). But it always ends up being 43:25: D1:00:00:00 no matter what.
2) Setting the BT address manually with:
Both commands execute fine and claim to do as told, but the BT address doesn't change -- not right away, nor after BT disable/enable, nor after reboot. I would be happy if these commands worked, even if lost on reboot or BT disable, as they could be scripted. Unfortunately they don't work -- or I am missing a step to make them work.
3) bdaddr does create a new folder in /data/misc/bluetoothd with the specified name/address (I used my phone's actual MAC address as shown by stock ROM) and creates a config in it (same class as the original one, but no device name.) I tried copying the original config to the new folder, deleting the old folder, and hciconfig reset again (AND BT disable/enable AND reboot), but it always ends up creating a 43:25: D1:00:00:00 folder and using that address.
4) I dug a tiny bit into the source on github. bdaddr_read was the only file I could find that's unique to IHO. It reads the MAC address from service.brcm.bt.mac and saves it to /data/bdaddr (which doesn't exist on my phone, but maybe it's just a temporary file). I presume bdaddr and the service are plain Gingerbread or CM, but since this issue exists on other CM phones I guess the problem could lie there.
Seriously guys, I've never coded for Linux, let alone Android. I have to just admit that it would be a gargantuan task for me to try and debug this myself. Or even just figure out the repository
If I can persuade anyone to look into this, I would be most grateful. I am very happy to contribute in any way I can. I was a systems coder 25-30 years ago (and a fairly sought after bug hunting consultant), but without knowing the environment or libraries I don't know how much I could realistically do. Won't stop me from trying though.
Thank you in advance.
On a completely different note: I just have to say what an absolute PLEASURE it is to have my rock solid IHO/MiRaGe phone back after the ZV9 debacle. While it was going on I told myself that it wasn't all that bad. But now, what a difference: It's faster and more solid than ever. Thanks again for that, guys and girls!
That makes it impossible for two IHO phones to talk to each other through Bluetooth. For me, the more annoying consequence is that my wife and I cannot pair both our phones to our car and swicth between them: Paring one phone wipes out the other, because the car sees the same address. So switching phones in the car involves full pairing procedure every time (entering security codes and all).
(I actually tried naming the phones the same, hoping the car wouldn't know the difference and just connect to the first available phone, but unfortunately that didn't work either).
The issue was previously mentioned in this thread. Also, it was brought up in the IHO thread a couple months ago, but didn't elicit any response (except from me
).The problem isn't limited to IHO, I believe it is all CM7 phones. Even quattrimus ICS seemed to have the same problem when I last tried it (alpha 9). Still, I am posting it here since IHO is where I have the problem. Of course stock ROM reads the actual, unique MAC address and works fine.
I've searched all over recently. Many users mention the issue and ask for help, but nobody seems to have answers, except "that's just Cyanogen".
Have any of you (devs or others) investigated this issue -- or possibly even have a solution, whether permanent or temporary?
What I tried so far:
1) Deleting folder(s) in /data/misc/bluetoothd. When the BT address is first set, a folder is created here named by the address, containing a config file with device name and class. Someone suggested to delete it and let the folder be re-created next time BT is enabled (presumeably with the correct address). But it always ends up being 43:25: D1:00:00:00 no matter what.
2) Setting the BT address manually with:
Code:
[B]su[/B]
[B]bdaddr [new bluetooth address][/B]
[B]hciconfig hci0 reset[/B]Both commands execute fine and claim to do as told, but the BT address doesn't change -- not right away, nor after BT disable/enable, nor after reboot. I would be happy if these commands worked, even if lost on reboot or BT disable, as they could be scripted. Unfortunately they don't work -- or I am missing a step to make them work.
3) bdaddr does create a new folder in /data/misc/bluetoothd with the specified name/address (I used my phone's actual MAC address as shown by stock ROM) and creates a config in it (same class as the original one, but no device name.) I tried copying the original config to the new folder, deleting the old folder, and hciconfig reset again (AND BT disable/enable AND reboot), but it always ends up creating a 43:25: D1:00:00:00 folder and using that address.
4) I dug a tiny bit into the source on github. bdaddr_read was the only file I could find that's unique to IHO. It reads the MAC address from service.brcm.bt.mac and saves it to /data/bdaddr (which doesn't exist on my phone, but maybe it's just a temporary file). I presume bdaddr and the service are plain Gingerbread or CM, but since this issue exists on other CM phones I guess the problem could lie there.
Seriously guys, I've never coded for Linux, let alone Android. I have to just admit that it would be a gargantuan task for me to try and debug this myself. Or even just figure out the repository
If I can persuade anyone to look into this, I would be most grateful. I am very happy to contribute in any way I can. I was a systems coder 25-30 years ago (and a fairly sought after bug hunting consultant), but without knowing the environment or libraries I don't know how much I could realistically do. Won't stop me from trying though.
Thank you in advance.
On a completely different note: I just have to say what an absolute PLEASURE it is to have my rock solid IHO/MiRaGe phone back after the ZV9 debacle. While it was going on I told myself that it wasn't all that bad. But now, what a difference: It's faster and more solid than ever. Thanks again for that, guys and girls!
Last edited:
Set your browsers user agent to desktop and try downloading from media fire again, it works
I would love to see this fixed. The thread you reference from a couple months back where several others also reported this issue was mine.
If others are experiencing diffuculties due to duplicate bluetooth addresses among their OVs, please chime in to encourage the devs to amend this.
Is the problem baked in by Cyanogen?
I don't know how far up or down the dev tree to climb to leave a note. (I don't even entirely understand the dev hierarchy)
@Schlidel: Since this problem exists in multiple ROMs for different phones, I would speculate there is a module in CM that needs to be adapted for each phone in order to properly pick up the Bluetooth MAC address. In that case it would be a common CM issue, but one that can only be fixed in a hardware specific implementation. Since CM doesn't officially support our phones, they may not consider it their problem.
That bdaddr_read module I mention in the IHO repository, gets the address from a Broadcom service (which I think is generic). Maybe that service returns the wrong address - or maybe bdaddr_read doesn't save the address properly for the Bluetooth daemon to pick up.
I honestly shouldn't post these speculations here. I am sure the devs are laughing or rolling their eyes over my ignorance
That bdaddr_read module I mention in the IHO repository, gets the address from a Broadcom service (which I think is generic). Maybe that service returns the wrong address - or maybe bdaddr_read doesn't save the address properly for the Bluetooth daemon to pick up.
I honestly shouldn't post these speculations here. I am sure the devs are laughing or rolling their eyes over my ignorance
@Schlidel: Since this problem exists in multiple ROMs for different phones, I would speculate there is a module in CM that needs to be adapted for each phone in order to properly pick up the Bluetooth MAC address. In that case it would be a common CM issue, but one that can only be fixed in a hardware specific implementation. Since CM doesn't officially support our phones, they may not consider it their problem.
That bdaddr_read module I mention in the IHO repository, gets the address from a Broadcom service (which I think is generic). Maybe that service returns the wrong address - or maybe bdaddr_read doesn't save the address properly for the Bluetooth daemon to pick up.
I honestly shouldn't post these speculations here. I am sure the devs are laughing or rolling their eyes over my ignorance
I am definitely not rolling my eyes. I will look into this bluetooth address issue. Let me see what can I do.
MiRaGe 05152012
I have uploaded the 05152012 build of MiRaGe to the IHO Wiki.
Followings are the main changes from CM repo sync. You can find details of the changes in CM repo at this link.
- Remove misleading "default" indication in CMParts
- Make compcache script fail-safe
- Make absolutely sure the theme change receivers are only unregistered if
they were registered before.
- Optimize T9Search performance / memory consumption
- Busybox 1.20.0 squashed commit for gingerbread and fixes after that
- RC2
I have also updated the data indicators in the status bar (made myself). The bluetooth indicator icon was plain ugly and 3G/1X indicators had always the arrows in wrong directions. Nobody noticed since the up/down arrows were so tiny that the direction they point was not easy to see.
The same ROM modified for Verizon Network is also available here. MD5sum: 9a697d6bfdba8547e48b655aa792eefc
As always thanks to Blarf, Bob, Jerry, LeslieAnn, tdm, thekraven, gannon5197, tvall, bigsupersquid, Whyzor, Earthnfire78, and all of the CM team.
I have uploaded the 05152012 build of MiRaGe to the IHO Wiki.
Followings are the main changes from CM repo sync. You can find details of the changes in CM repo at this link.
- Remove misleading "default" indication in CMParts
- Make compcache script fail-safe
- Make absolutely sure the theme change receivers are only unregistered if
they were registered before.
- Optimize T9Search performance / memory consumption
- Busybox 1.20.0 squashed commit for gingerbread and fixes after that
- RC2
I have also updated the data indicators in the status bar (made myself). The bluetooth indicator icon was plain ugly and 3G/1X indicators had always the arrows in wrong directions. Nobody noticed since the up/down arrows were so tiny that the direction they point was not easy to see.
The same ROM modified for Verizon Network is also available here. MD5sum: 9a697d6bfdba8547e48b655aa792eefc
As always thanks to Blarf, Bob, Jerry, LeslieAnn, tdm, thekraven, gannon5197, tvall, bigsupersquid, Whyzor, Earthnfire78, and all of the CM team.
Oh heaven's yes.
Sent from my VM670 using Android Central Forums
I have tried the Hdyro kernel first to check the 2.6.35 GB kernel. It gives the same bluetooth MAC address as IHO kernel. So LG's 2.6.35 official GB kernel cannot help us. On the other hand, this is certainly not a CM7 problem since the other device that I also build CM7, Nook Color, does not have this problem. The two devices have different BT chips and I think OV's problem lies within the Broadcom driver. I think so because the BCM4325 driver in Hydrokernel is the same version with IHO kernel (there are slight changes in the driver code due to different header files in two kernels). I will try to find an updated BCM4325 driver. If not we will need to fix the BCM4325 driver. Please comment if I am missing something.
@mrg666: You're awesome, thanks a lot. Both for your work and for being so nice about it. Seriously!
One question: Were you able to determine that it actually is the Broadcom service returning the wrong address - and not just bdaddr_read (which I believe WAS localized for IHO) that saves it incorrectly (or in a way so that dependent processes never pick it up right)?
Is there a way to call that Broadcom service straight and display (or log) the address it returns?
Just a thought, so you don't spend time replacing or fixing the Broadcom driver, only to find that it was a simple mistake in bdaddr_read.
Again, sorry if I am confusing things...
One question: Were you able to determine that it actually is the Broadcom service returning the wrong address - and not just bdaddr_read (which I believe WAS localized for IHO) that saves it incorrectly (or in a way so that dependent processes never pick it up right)?
Is there a way to call that Broadcom service straight and display (or log) the address it returns?
Just a thought, so you don't spend time replacing or fixing the Broadcom driver, only to find that it was a simple mistake in bdaddr_read.
Again, sorry if I am confusing things...
CM7/IHO seems to read the bluetooth address from /sys/devices/virtual/bluetooth/hci0/address. Guess what is inside that file? 43:25
1:00:00:00. So Android has no problem reading it. The bcm4325 driver in the Linux kernel writes the wrong information in sysfs. We need to fix the driver. Let's see how can we do that.Edit: the sys file is there only when the bluetooth is on. From dmesg, the function that turns on the blueooth is thunderc_bluetooth_power which is in arch/arm/mach-msm/lge/board-thunderc-bt.c in the kernel source. Now we need to trace back from here which function assigns the MAC address and writes that file.
Last edited:
@mrg: isn't that a completely virtual file? As in, generated on the fly whenever opened. I thought that was how much of the stuff in sysfs is exposed. If so, it may not be written by anybody.
Yeah, I noticed too when trying to mess with it that the entire /sys/devices/virtual/bluetooth folder only comes into existence when BT is enabled.
One question: Since this problem is nonexistent in stock ROM, clearly the LG Broadcom driver in the stock kernel must be working. Either we're not using that driver in IHO kernel OR parts of the ROM (CM7 or IHO) is not calling it correctly. Yes, no?
Yeah, I noticed too when trying to mess with it that the entire /sys/devices/virtual/bluetooth folder only comes into existence when BT is enabled.
One question: Since this problem is nonexistent in stock ROM, clearly the LG Broadcom driver in the stock kernel must be working. Either we're not using that driver in IHO kernel OR parts of the ROM (CM7 or IHO) is not calling it correctly. Yes, no?
Drives work by reading hardware type and generates files as to what the drivers_read_head kicks back, if there is a problem with the driver or a simple typo then the wrong data will be output.
Gamers would remember how the drivers ATI used for their video cards had typos because Microsoft did not release the source code for Windows Vista to ATI, and caused a great videos card to not functions right.
Gamers would remember how the drivers ATI used for their video cards had typos because Microsoft did not release the source code for Windows Vista to ATI, and caused a great videos card to not functions right.
Dane I pm'ed mgr this, I googled the problem and the epic 4g has a bug report up about it. I also seen several other results for various phones. I think that is why he is making the connection. Nothing has been posted as a fix that I seen. But it also could have been forgotten about like it was here.
The only port of CM7 for my new phone is a pain in the ass to flash plus it reminds me of asopbots build of cm7. To many broken things.
The only port of CM7 for my new phone is a pain in the ass to flash plus it reminds me of asopbots build of cm7. To many broken things.
Similar threads
Trending Posts
-
[Chatter] "Where everybody knows your name ..."
- Started by zero neck
- Replies: 53K
-
-
-
-
Question Redmi 12 (5g) disable black screen during calls
- Started by unirockers
- Replies: 0
Facebook
Twitter
Instagram