Guest Dazzozo Posted June 14, 2012 Report Share Posted June 14, 2012 Quick update: merging smali was a bit of a failure, couldn't even get it to compile. It seems the broadcom stuff has its own BluetoothHidService and it's... not fun replacing all that, and I'm not even sure it's the solution. I had a look at the stock ROM earlier but I couldn't get much information out of that. Just seems like we've hit a second dead end. :( Link to comment Share on other sites More sharing options...
Guest tilal6991 Posted June 14, 2012 Report Share Posted June 14, 2012 TBH I don't think the problem is in the framework - even when I had bad issues with BT not enabling at all on early CM7 on the Skate the framework itself was never the issue. Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 14, 2012 Report Share Posted June 14, 2012 TBH I don't think the problem is in the framework - even when I had bad issues with BT not enabling at all on early CM7 on the Skate the framework itself was never the issue. I'll revert back to the unmodified framework.jar and keep all the btld stuff in place, and see what happens when I setprop ctl.start hciattach. Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 14, 2012 Report Share Posted June 14, 2012 (edited) Well I never. You are indeed right. My input: echo 1 > /sys/class/rfkill/rfkill1/state setprop ctl.start hciattach bt_testmode.sh [/CODE] logcat: [CODE] E/bluez_hciattach( 633): Call init_uart E/bluez_hciattach( 633): ->bcm2035 E/bluez_hciattach( 633): read HCD file ok, size=38135 E/bluez_hciattach( 633): download hcd file success E/bluez_hciattach( 633): bt-addr:0x0ebeccb21a68 E/bluez_hciattach( 633): Set PCM ok E/bluez_hciattach( 633): Set sleep mode ok E/bluez_hciattach( 633): BT chip change BaudRate to: 3000000 E/bluez_hciattach( 633): <-bcm2035 E/bluez_hciattach( 633): Device setup complete Output: # bt_testmode.sh bt_testmode.sh BCM-DUT start < HCI Command: ogf 0x03, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 18 0C 00 < HCI Command: ogf 0x03, ocf 0x0005, plen 3 02 00 02 > HCI Event: 0x0e plen 4 01 03 0C 00 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 03 > HCI Event: 0x0e plen 4 01 1A 0C 00 < HCI Command: ogf 0x06, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 18 00 BCM-DUT ok # hciconfig hci0 hciconfig hci0 hci0: Type: BR/EDR Bus: UART BD Address: 0E:BE:CC:B2:1A:68 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN ISCAN RX bytes:380 acl:0 sco:0 events:14 errors:0 TX bytes:65 acl:0 sco:0 commands:14 errors:0 # hcitool dev hcitool dev Devices: hci0 0E:BE:CC:B2:1A:68 # [/code] Okay, now I'm really confused. What's stopping Android using it? Edit: I reverted every framework file that I edited (services.jar and framework.jar) Edited June 14, 2012 by Dazzozo Link to comment Share on other sites More sharing options...
Guest tilal6991 Posted June 14, 2012 Report Share Posted June 14, 2012 I'm honestly lost now. No idea. Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 14, 2012 Report Share Posted June 14, 2012 (edited) Going to see if I can figure out how to scan with hcitool and get it to list devices (I think you can do that with it?), just waiting for a dead BlackBerry to power up. See you in about 25 years. Edit: Yep, it's definitely working. # hcitool scan hcitool scan Scanning ... 33:33:CE:30:7C:30 Retired Old BlackBerry # hcitool info 33:33:CE:30:7C:30 hcitool info 33:33:CE:30:7C:30 Requesting information ... BD Address: 33:33:CE:30:7C:30 Device Name: Retired Old BlackBerry LMP Version: 2.1 (0x4) LMP Subversion: 0x12e9 Manufacturer: Cambridge Silicon Radio (10) ... [/CODE] Edited June 14, 2012 by Dazzozo Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 14, 2012 Report Share Posted June 14, 2012 (edited) Fixed! Android's Bluetooth is working without Wi-Fi being on on CM7. Oh my... Incredibly simple. Leave everything as it is (including hciattach) and run "echo 1 > /sys/class/rfkill/rfkill1/state" before starting Bluetooth. Works fine. The problem is how to do this properly. Where to run this automatically, etc. Edit: Actually, on second thoughts, isn't bluedroid meant to do this? Edit 2: Tried putting it in the init.qcom.bt.sh script but it doesn't seem to be actually setting the state. I don't think this is the "proper" way to fix it, either. I still think bluedroid is meant to do this and I'm puzzled as to why it doesn't. Edited June 15, 2012 by Dazzozo Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 15, 2012 Report Share Posted June 15, 2012 (edited) Right, /sys/class/rfkill/rfkill1/state only has to be set to 1 when we want Bluetooth on with Wi-Fi off. Its value is seemingly ignored when we have Wi-Fi on. rfkill0 is controlled automatically (I assume by bluedroid), is set to 1 when it is (trying) to turn Bluetooth on, and set to 0 when it isn't. It currently has no way of knowing that rfkill1 must be set to 1 when Wi-Fi is off, though I guess we could just be safe to set it to 1 whenever we want Bluetooth on. Edit: Going to test if the fix works on ICS (no reason why not). Edit 2: Does indeed. Edited June 15, 2012 by Dazzozo Link to comment Share on other sites More sharing options...
Guest fr0do Posted June 15, 2012 Report Share Posted June 15, 2012 Congrats on that dazz ;) Link to comment Share on other sites More sharing options...
Guest tilal6991 Posted June 15, 2012 Report Share Posted June 15, 2012 So have you just set rfkill1 to 1 in init.blade2.rc? Link to comment Share on other sites More sharing options...
Guest b4da55 Posted June 15, 2012 Report Share Posted June 15, 2012 Good work that man! Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 15, 2012 Report Share Posted June 15, 2012 (edited) So have you just set rfkill1 to 1 in init.blade2.rc? Won't that do strange things like permanently power it? Edit: knew the fix would be simple :P Edited June 15, 2012 by Dazzozo Link to comment Share on other sites More sharing options...
Guest windy_miller Posted June 15, 2012 Report Share Posted June 15, 2012 @Daz The problem is Bluetooth is not being enabled but the system thinks it is so starts the framework service which realizes that Bluetooth is actually enabled and so crashes the system thread. Could this explain the kernel wakelock that was eating all my battery in CM9, even though I had bluetooth disabled? Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 15, 2012 Report Share Posted June 15, 2012 Could this explain the kernel wakelock that was eating all my battery in CM9, even though I had bluetooth disabled? No, this issue was in my internal test build. Link to comment Share on other sites More sharing options...
Guest tilal6991 Posted June 15, 2012 Report Share Posted June 15, 2012 See the change coming up soon on the skate GitHub to fix the kernel wake lock. Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 15, 2012 Report Share Posted June 15, 2012 I'm still worried about the Bluetooth being permanently powered. If that's not the case it should be very simple to implement. Link to comment Share on other sites More sharing options...
Guest tilal6991 Posted June 15, 2012 Report Share Posted June 15, 2012 I have an idea but I need to have a look at the file. Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 15, 2012 Report Share Posted June 15, 2012 I have an idea but I need to have a look at the file. Which file? Link to comment Share on other sites More sharing options...
Guest tilal6991 Posted June 15, 2012 Report Share Posted June 15, 2012 See my pull request on GitHub. Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 15, 2012 Report Share Posted June 15, 2012 See my pull request on GitHub. Will do, on my phone for about half hour. Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 15, 2012 Report Share Posted June 15, 2012 Right, back, going to test. Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 15, 2012 Report Share Posted June 15, 2012 That patch doesn't work, rfkill1's state needs to be set before hciattach, and not before bluetoothd which happens after hciattach. Could I create an on property for hciattach and do it there? Something like on property:init.svc.hciattach=running, or would that be too late too? Link to comment Share on other sites More sharing options...
Guest tilal6991 Posted June 15, 2012 Report Share Posted June 15, 2012 That might work. I've never really figured out the precise order so it might work. I've committed another possibility. Link to comment Share on other sites More sharing options...
Guest Dazzozo Posted June 15, 2012 Report Share Posted June 15, 2012 That might work. I've never really figured out the precise order so it might work. I've committed another possibility. I tried that last night, and for some reason it just won't set it from init.qcom.bt.sh. However... It's fixed! on property:init.svc.hciattach=running did the trick! Link to comment Share on other sites More sharing options...
Guest tilal6991 Posted June 15, 2012 Report Share Posted June 15, 2012 It'll be because there are no su permissions from the .sh file. Great job! Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now