Jump to content

Recommended Posts

Guest Dazzozo
Posted

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. :(

Guest tilal6991
Posted

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.

Guest Dazzozo
Posted

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.

Guest Dazzozo
Posted (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 by Dazzozo
Guest Dazzozo
Posted (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 by Dazzozo
Guest Dazzozo
Posted (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 by Dazzozo
Guest Dazzozo
Posted (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 by Dazzozo
Guest tilal6991
Posted

So have you just set rfkill1 to 1 in init.blade2.rc?

Guest Dazzozo
Posted (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 by Dazzozo
Guest windy_miller
Posted

@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?

Guest Dazzozo
Posted

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.

Guest tilal6991
Posted

See the change coming up soon on the skate GitHub to fix the kernel wake lock.

Guest Dazzozo
Posted

I'm still worried about the Bluetooth being permanently powered. If that's not the case it should be very simple to implement.

Guest tilal6991
Posted

I have an idea but I need to have a look at the file.

Guest Dazzozo
Posted
I have an idea but I need to have a look at the file.

Which file?

Guest Dazzozo
Posted
See my pull request on GitHub.

Will do, on my phone for about half hour.

Guest Dazzozo
Posted

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?

Guest tilal6991
Posted

That might work. I've never really figured out the precise order so it might work. I've committed another possibility.

Guest Dazzozo
Posted

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!

Guest tilal6991
Posted

It'll be because there are no su permissions from the .sh file.

Great job!

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.