• Announcements

    • Reminder - MoDaCo position on illegal content   07/30/15

      ILLEGAL CONTENT I'd like to just reaffirm MoDaCo's position regarding piracy and illegal content in the light of some recent questions / postings. Posts will be censored by myself or my moderation team if the contain or link to: Illegal / pirated / cracked software or sites that host such softwareNintendo emulators / ROMs or sites hosting them (in light of Nintendo's legal stance)CUSTOM ROMS You may discuss and post links to custom device ROMs on MoDaCo, provided the following rules are adhered to: ROMs must not contain any illegal 3rd party software (this includes trial versions included without permission)ROMs must give full credit to the original authorISSUES If you have any issues with this policy, please contact PaulOBrien directly via PM.
    • Reminder: Selling items on the forum directly is not allowed   07/30/15

      Please note that selling items on the forum directly is not allowed by the forum rules. There is a forum for eBay auctions whereby you can list the items on eBay and link to them there. This is the ONLY forum for this type of activity. You may also advertise links to the eBay forum in your signature. Please note that selling directly in contravention of these rules will result in a warning / suspension / ban.

[ROM]<<<Mokee SF2>>>Link up

89 posts in this topic

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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.

0

Share this post


Link to post
Share on other sites

Posted · Report post

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.

0

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

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
0

Share this post


Link to post
Share on other sites

Posted · Report post

I'm honestly lost now. No idea.

0

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

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
1

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

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
2

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

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
1

Share this post


Link to post
Share on other sites

Posted · Report post

Congrats on that dazz ;)

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

Good work that man!

0

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

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
0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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.

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

Which file?

0

Share this post


Link to post
Share on other sites

Posted · Report post

See my pull request on GitHub.

0

Share this post


Link to post
Share on other sites

Posted · Report post

See my pull request on GitHub.

Will do, on my phone for about half hour.

0

Share this post


Link to post
Share on other sites

Posted · Report post

Right, back, going to test.

0

Share this post


Link to post
Share on other sites

Posted · Report post

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?

0

Share this post


Link to post
Share on other sites

Posted · Report post

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

0

Share this post


Link to post
Share on other sites

Posted · Report post

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!

1

Share this post


Link to post
Share on other sites

Posted · Report post

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

Great job!

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2015. MoDaCo uses IntelliTxt technology.