Related
Hello everybody, my first post here!
I've been around this forum for a while now, searching for help to get the Widcomm BT stack onto the Magician/Jam/XDA mini/MDA compact... (I've got an XDA mini) - like so many others
The topic has been discussed in several other posts in this forum, but nowhere I could find an answer why Widcomm is working on XDA II, but not on the Magician.
So I'd like to submit my own theory here for discussion.
In short - my guess is that none of the Widcomm stacks floating around(1.4, 1.5, 1.6, etc.) actually has the right HCI transport library dll included.
The Bluetooth spec allows for the following HCI transport drivers:
UART
USB
Serial
On UART, there is the standard protocol H4, as well as the proprietary BSCP protocol, which was invented by CSR, are large manufacturer of bluetooth chipsets (the Magician has a CSR chip as well)
Now it seems that the bluetooth chip in the XDA II as well as many other devices is internally connected via a serial connection (UART), which means that the bluetooth stack is implementing a UART transport layer dll.
On the Magician, though, the bluetooth chip is connected by USB! This becomes visible when you install the ITV Bluesoleil stack. Also, when you look in the registry under HKLM\SOFTWARE\Microsoft\Bluetooth\Transports\BuiltIn\1, you'll see that the Microsoft BT stack on our Magicians load bthusb.dll, which is Microsoft's USB HCI transport layer driver. Under \Windows, you'll see that Microsoft also includes all the other dll's for other bluetooth chipset architectures: bthuart.dll, bthcsr.dll, etc.
Unfortunately, Widcomm is not so gentle, they seem just to distribute the dll for the architecture their driver bundle is licensed to. And this is why the only Widcomm transport layer driver I found so far under HKLM\SOFTWARE\Widcomm\BtConfig\General\TransportLibrary Key is "BtCeBCSPTrans.dll" So you see that the transport layer is for UART, BCSP protocol - not the one we need in our Magicians!
So my second guess is: If Widcomm/Broadcom has built a transport layer driver for USB, then using this might get the stack to work on the Magicians. Unfortunately, so far I could not find anything!
But there is some hope: Broadcom claims here (http://www.broadcom.com/collateral/pb/1000-WCE-PB03-R.pdf) that their BCM1000-WCE stack (the successor of Widcomm stack) supports USB hardware implementation.
So, to cut a long story short: If anyone manages to get hold of a Widcomm/Broadcomm USB HCI transport layer dll, then we might get the stack to work on our Magicians
i have the same problem
You're probably right. I installed the WIDCOMM stack today just to try it out. It didn't work, but it has some nice features (it actually has features, as opposed to MS's featureless stack )
Has anyone contacted Broadcomm to see whether they'll develop one and sell it as a standalone upgrade? If the features are as good and compatible as people say, then I'll pay a small fee. But if we can get a cracked one then I'm all for that too!
Since there are still a lot of people looking for a way of getting the Widcomm stack to work:
Wouldn't it be possible to write a wrapper or replacement dll that directs the UART calls to USB?
(though it seems like the BSCP-protocol is closed source?)
Can't you just use this stack (BlueSoleil?) from this thread ???
See here for A2DP compatibility, etc...
Hello,
Has anyone taken a look at the bcm4329's kernel module? I've been looking around and trying to figure out how the Sprint Hotspot application works and I've found it calls the SIOCSIWPRIV system call on the interface to bring up this mode.
Does anyone have any experience on this matter? I'm looking to get infrastructure mode working.
My current approach is to write a native C app, do the ioctl with some sort of struct (I'm tempted just to memalloc and hand-write the first one), and see what happens.
The driver throws a bunch of debug info into the kernel log when you invoke the command so its dead easy to spot.
Any suggestions?
andrew500 said:
Hello,
Has anyone taken a look at the bcm4329's kernel module? I've been looking around and trying to figure out how the Sprint Hotspot application works and I've found it calls the SIOCSIWPRIV system call on the interface to bring up this mode.
Does anyone have any experience on this matter? I'm looking to get infrastructure mode working.
My current approach is to write a native C app, do the ioctl with some sort of struct (I'm tempted just to memalloc and hand-write the first one), and see what happens.
The driver throws a bunch of debug info into the kernel log when you invoke the command so its dead easy to spot.
Any suggestions?
Click to expand...
Click to collapse
im definitely not up to speed on this but if you wanna post some links to the source files you're referencing, it might help me and anybody else who is interested to get up to speed quicker and provide suggestions.
appreciate your work on troubleshooting and experimenting with wifi tether!
joeykrim,
I'm knee deep in it right now. I'm taking the source code to iwconfig and using it as a template to implement the system calls I need, using a hybrid of the structs in wireless.h and in the bcm4329 driver source, from the bravo kernel. Basically I create a big struct in memory and pass it into the driver using a pointer to a iw_point struct, which holds my big master struct, and then the driver copies it out of user-space into kernel space and acts upon it.
I'll put together all the details once they are a little more solid.
It looks like infrastructure-mode on the EVO is a very distinct possibility, this code will also translate into the workaround for built-in tether on Froyo, from what I've seen they are exclusively using this broadcom interface so far.
It's a hardware specific hack, but many of the phones that have come out lately are using the bcm4329 (and with good reason, chip has freakin everything).
Hi
Any ideas on how to adjust the a2dp bitpool settings. I am coming from windows mobile where this was easy to do in the registry. The stock bitpool seems to be 32 as per the logcat readout below. This is coming from an Evo 4G:
W/BTLD ( 1677): ### :: codec open ::
W/BTLD ( 1677): ### mtu 512, 660 bytes/frame, bitrate 229, nbr ch 0, freq 240
W/BTLD ( 1677): ### alloc : 3, blk len 240, chmode:15, bitpool 32:2, subbands 12
the sound is ok but could be better.
Another interesting part of the logcat is:
V/A2dpAudioInterface( 136): setParameters() bt_headset_name=DRC-BT15;bt_headset_nrec=on
E/AudioHardwareQSD( 136): setParameters() bt_headset_name=DRC-BT15;bt_headset_nrec=on
I/AudioHardwareQSD( 136): Using default acoustic parameters (DRC-BT15 not in acoustic database)
(I wonder what the acoustic database is.)
Any suggestions would be welcome. I did search around and found nothing easily implemented. Also nothing on the market.
Thanks
I want to know the exact same thing and not ready to accept that WinMo is superior to Android in any way...
I just found this page here which discuss some terminal and backend files in OSX for modifying these settings. Is there any similar file or terminal command we can do on our own unix based systems?
I have spent the last couple of weeks working on this and have come up with nothing. But I am not a programmer. Hope someone knows where to make the changes.
any update on this?
I am no programmer in any way, but I would realy like to know the outcome of this thread because it's been bugging me since I bought my Desire. I realy can't stand the loss of sound quality when listening to music on a bluetooth headset with my sennheiser headphones(HD215) connected.
I was wondering about the same thing. I used to tweak my WinMo Bitpool and samplerate. Any way to do this on Android?
I have been following this too. There must be a way to edit this somehow!! The a2dp quality of the evo/desire is awful! Must find a way!!!
I'm also disappointed in the audio quality on my Desire. I use my phone to listen to music in my car or mobile speaker via bt. But there are many tracks with high frequencies (or frequencies in some range), that causes some really disturbing clicking noise! Which I don't had on my Nokia N82 and SE K800i.
This really annoys me, and I consider to change to a different phone if there will not be a solution I'm currently using the original HTC firmware/radio, because I haven't rooted my phone yet. Is it possible that flashing a different radio will help?
I'm not sure if this is caused by the bitpool setting.
I will try to capture/upload some fragment with this clicking...
Edit: The microphone isn't good enough to record the clicking, but this fragment illustrates it very well (the clicking was actually in the track itself, but it sounds almost the same):
fragment (mp3)
Has there been any kind of an update on this one? A fix or a setting that could be changed?
I'm thinking of buying a Desire Z, but I will certainly stick to my ancient Touch Pro if the A2DP quality on Android is as bad as you all say. Bitpool of 32 is unlistenable, and I can't believe that neither Google nor HTC care about it.
Now that Cyanogen has fixed this in their ROM, I don't understand why no one has released a method for people not running Cyanogen.
So it has been fixed? What bitpool does that ROM run? I can't seem to find any info :S
And will they make a ROM for Vision with that fix?
I know I've got stupid noobish questions, but I'm completely new to the whole Android story and I haven't used these forums for ages so I'm quite lost atm...
CM6 is running 53
Thanks for the info
I'm having issues with an epic I just got (luckily in the 30 day return period). The a2dp audio sounds like garbage. The a2dp audio on my touch pro stock (before tweaked) was much better.
This could be a dealbreaker for me.
naorion said:
Now that Cyanogen has fixed this in their ROM, I don't understand why no one has released a method for people not running Cyanogen.
Click to expand...
Click to collapse
This is good news, but surely Mr.Cyanogen can pass on his method to Cotulla or one of the other primary Android Devs.... Hmm!
Any news on this? I flashed to Cyanogen 6.1. A2DP sounds much better. I now have mulitple exchange accounts working. The few issues are the Expensify receipt image capture does not work, 4G and HDMI also (know issues). I hope someone can find a fix for this.
I had a look at the bluez source code posted on HTC's developer site and I believe this is where the bitpool value is being set:
Code:
supersonic_bt.zip/external/bluetooth/bluez/liba2dp.c:
static uint8_t default_bitpool(uint8_t freq, uint8_t mode)
...
case BT_SBC_SAMPLING_FREQ_44100:
switch (mode) {
case BT_A2DP_CHANNEL_MODE_MONO:
case BT_A2DP_CHANNEL_MODE_DUAL_CHANNEL:
return 31;
case BT_A2DP_CHANNEL_MODE_STEREO:
case BT_A2DP_CHANNEL_MODE_JOINT_STEREO:
return 53;
default:
ERR("Invalid channel mode %u", mode);
return 53;
}
Changing the "return 31;" to "return 53;" and recompiling -or- hex editing the binary liba2dp.so on the phone ought to do the trick.
The same code block also appears in ipctest.c, pcm_bluetooth.c, sink.c, and source.c, so one or more of those files may also need to be modified.
I just got my Evo and I don't know enough about it yet to try this myself, but if someone else is able to then I think we'd all appreciate it if you could give it a shot. (Not all of us are interested in running a custom ROM just to fix this one problem.)
Edit: Another way may be to just force your desired min and max bitpool settings in the function bluetooth_a2dp_init():
Code:
cap->min_bitpool = min_bitpool;
cap->max_bitpool = max_bitpool;
Disregard that last post of mine. I had another look at liba2dp.c as well as some D/A2DP log output. All of the log output I could find posted online contains "channel_mode: JOINT STEREO", which according to default_bitpool() means the "default" bitpool should be 53. I originally thought the problem might be the bitpool setting of 31 referenced in that function, but I could not find any log output that contained "channel_mode: DUAL CHANNEL". (It shouldn't be too hard to verify this.)
So why is a lower bitpool value used? Look at this code snippet from bluetooth_a2dp_init():
Code:
min_bitpool = MAX(MIN_BITPOOL, cap->min_bitpool);
max_bitpool = MIN(default_bitpool(cap->frequency,
cap->channel_mode),
cap->max_bitpool);
cap->min_bitpool = min_bitpool;
cap->max_bitpool = max_bitpool;
The max_bitpool value is set to the lower of 1) the "default" bitpool and 2) the max bitpool reported by the audio sink (ie. your headset). If your headset reports a max bitpool of 32, then that is what will be used since it is less than 53. My understanding of the bluetooth spec is that audio sinks are supposed to accept bitpool values higher than 32 in order to support up to 512 Kb/s audio. Lower bitpool settings are more reliable, though, so perhaps that is why many headsets are configured to report artificially low values.
The actual bitpool value used is simply max_bitpool. See bluetooth_a2dp_setup():
Code:
data->sbc.bitpool = active_capabilities.max_bitpool;
The a2dp code isn't set up to take bitpool parameters from a configuration file, so liba2dp.c will need to be modified and recompiled. Possible quick fixes would be to change the "max_bitpool = MIN(" line to "max_bitpool = MAX(" or to manually set your desired bitpool value (ie. "data->sbc.bitpool = 53").
Hi,
I just want to say that since unfortunately my programming capabilities are close to non-existent I'm afraid I'm not able to provide much actual help in solving this issue but i highly appreciate that there are people who are looking into this and trying to remedy what Android OS designers and phone manufacturers neglected. I've been using A2DP headsets for the past 3-4 years with Nokia E51 and E52 phones which provided very good sound quality virtually indistinguishable from a cable connection and now after buying a Samsung Galaxy S phone I'm terribly disappointed at its A2DP performance comparable to 112kbps MP3s with even the highest quality sources.
I own three different A2DP headsets manufactured by Sony Ericsson, Nokia and unnamed Chinese labourers respectively and a set of quality IEM earphones plugged into quite good and relatively trained ears. Since A2DP support on both Nokias and a Samsung Blackjack I owned shortly (and let go of just because of its pitiful A2DP performance) has not always been perfect I know a thing or two about how A2DP works and performs. So if there is anything I can do to help regarding testing, preparing and submitting logs etc. just let me know and I will be very happy to help if that's what is needed.
Thanks!
Petr
Hi,
I currently try to follow these instructions...
http://mobisocial.stanford.edu/news...together-by-hacking-connectivityservice-java/
Very hard for me. Don't know what to do.
The goal of COIN project is to use WiFi and 3G connections simultaneously. So it conflicts with the policy of Connectivity Service, but there is no configuration to edit the policy, and it is hard coded. You can find the clue in ConnectivityService.java:handleConnect function.
Our current solution is quite brutal, which is to mask the eyes of Connectivity Service by modifying its message handler entry like the following:
// must be stateless – things change under us.
private class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
NetworkInfo info;
//added by COIN to disable Connectivity Service
int networkState = 8; //not any following state
/*use static google dns server for wifi and 3g*/
if (msg.what == NetworkStateTracker.EVENT_STATE_CHANGED) {
SystemProperties.set(“net.dns1″, “8.8.8.8″);
SystemProperties.set(“net.dns2″, “8.8.4.4″);
bumpDns();
}
//////////////////////////////////////////////
//switch (msg.what) {
switch (networkState) {
case NetworkStateTracker.EVENT_STATE_CHANGED:
info = (NetworkInfo) msg.obj;
int type = info.getType();
…..
And then compile the modified ConnectivityService.java in the android source code tree, you can get an new services.jar file in framework directory. Replace the existing services.jar on the cell phone with the following adb commands, then reboot the phone
adb shell “mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system”
adb shell “chmod 0777 /system/framework”
adb push services.jar /system/framework
adb shell “chmod 0644 /system/framework/services.jar”
adb shell “chmod 0755 /system/framework”
Click to expand...
Click to collapse
Does he mean I have to compile the whole Android source code again?
So I would need to learn first, how to compile Android, then change this file, compile Android, copy file?
Instant of adb shell, could I also use root explorer?
How device dependant is this? Or how android version dependant?
Could someone offer the compiled file?
No answer yet.
I believe so. This is actually what compelled me to go learn to compile android by myself-- the constant switching between 3g and wifi in a semi-strong wifi zone sucks. For now I am starting with CM7 since it is so popular.
Yes you would need to compile the whole OS and it will only work on an AOSP rom. It will also be very version dependent.
Please let me know if it worked ! I probably don't think it will. Read this on the page:
Pallas Says:
April 13, 2012 at 5:58 am
are you sure the packets are going thru both interfaces?
I think it doesn’t work, simply because you would need two default gateways, leading to some hard problems:
- how does the system choose where to send the packets?
- for outgoing packets: unless the two connections have both statically assigned public IP addresses, which is very unlikely, you will end up with two differently NATed paths, and the client will refuse packets coming from two different ip addresses on the same connection.
- for incoming packets: to let the client send packets to both interfaces, you would need to send them from both interfaces with different source ip addresses: it will not work, the client will get confused. and anyway you would need support at the application level.
to solve all this, you’d need to:
- make an ad-hoc application which understands all this and can send chuncks to both interfaces, then merge all the returning chunks. you’d need support at the application level: for example you’d need http byte range support on both client and server
- divide “equally” the single specific connections thru the two gateways. this may work but it’s pretty hard if you do not have access to advanced routing and traffic shaping at the kernel level. may be possible on a phone with custom compiled aosp rom and modified kernel
gouthamsn said:
Please let me know if it worked ! I probably don't think it will. Read this on the page:
Pallas Says:
April 13, 2012 at 5:58 am
are you sure the packets are going thru both interfaces?
I think it doesn’t work, simply because you would need two default gateways, leading to some hard problems:
- how does the system choose where to send the packets?
- for outgoing packets: unless the two connections have both statically assigned public IP addresses, which is very unlikely, you will end up with two differently NATed paths, and the client will refuse packets coming from two different ip addresses on the same connection.
- for incoming packets: to let the client send packets to both interfaces, you would need to send them from both interfaces with different source ip addresses: it will not work, the client will get confused. and anyway you would need support at the application level.
to solve all this, you’d need to:
- make an ad-hoc application which understands all this and can send chuncks to both interfaces, then merge all the returning chunks. you’d need support at the application level: for example you’d need http byte range support on both client and server
- divide “equally” the single specific connections thru the two gateways. this may work but it’s pretty hard if you do not have access to advanced routing and traffic shaping at the kernel level. may be possible on a phone with custom compiled aosp rom and modified kernel
Click to expand...
Click to collapse
(Probably for your Interest
This project works on a MultiPath-TCP Implementation (follow link to mptcp.info.ucl.ac.be). The hard times you get is compiling the Kernel with the additional files. This Protocol can only work effectively for download Purposes if the Server also has a MPTCP Kernel running. But on the other Hand you can shut down a single connection without loosing the active Connection (Downloads are not interrupted and improved Bandwidth Capacity if your Server is MPTCP-Ready)
Until now this Protocol is only working for Homeservers or similar Projects, where you have full access to the Server and the working Kernel of the system.
I am currently working on implementation of the Protocol for my Bachelor Thesis. I already compiled a working Kernel (Glados Nexus S) and now i'm working on keeping both Interfaces active. I hope this Tut can help me...
Has anybody tried other approaches to this topic? I tried manually loading the wifi-module and configuring it, but i only managed to ping via one Interface.
You managed to make it work?
bagers said:
No answer yet.
Click to expand...
Click to collapse
You managed to make it work? i want to make it also for my master thesis
Hello everybody,
I created this thread because I noticed a lot of people are busy with it, but not a lot of knowledge is shared about it.
Unfortunatly this board doesn't use the common way of implementing bluetooth, so bluetooth loading is giving problems with hciattach.
Already a lot of developers notices in the sources of the Samsung Galaxy Y Sources which can be downloaded from Samsungs contains a folder in hardware/broadcom which is called bt.
Also I noticed another bluetooth folder in the external packages in which broadcom also changed some code to the standard bluez stack.
I was able to find almost the exact source base at Code Aurora Forum so I was able to extract the commits which broadcom has added to the bluez stack.
The patch I extracted can be found here:
http://pastebin.com/Biv570y0
It still contains some Code Aurora stuff, because it's almost imposible to find the exact source base Samsung used.
But if you search for broadcom inside the patch you can find the additions broadcom made.
Also I'm searching for the glib source base they used, because in there broadcom also applied some changes, but haven't found the correct base yet.
Hopefully this forum will become one big pool of knowledge which everybody has so we can crack this problem very soon.
Because I saw a lot of people doing the same thing over and over because there isn't much shared about whats already tried.
So hopefully we can combine our forces on this one.
Greetings PsychoGame
nice idea
but what do we actually need to work upon? the bluetooth library files?
i heard broadcom had released test binaries ....will final their release be fixing bluetooth?
Regards
aNubhav
anubhavrev said:
nice idea
but what do we actually need to work upon? the bluetooth library files?
i heard broadcom had released test binaries ....will final their release be fixing bluetooth?
Regards
aNubhav
Click to expand...
Click to collapse
We need to work on reviewing the Bluetooth files in the source code and reverse engineer them to get the Bluetooth working. Broadcomm released test binaries for the chipset, not for the Bluetooth. Hope that helps you. They have not even released their first stable binary, much less their "final release". I think they have forgotten all about it for now and released the test binaries to ease pressure off their backs.
Whats the exact reason that bt is not working? Im a bit disconnected from this forum...
I guess its not detectable cuz unlike wifi this wont even show error :/
BTW nice sig
Indeed the test binaries which have been released by Broadcom are only applicable to the graphics chipset.
For bluetooth the only things we have available is the BCM4330 .hcd binary located in the /system/bin which is in someway loaded by btld.
Also in the kernel broadcom implemented their own form of rfkill which is called bcm-rfkill if I remember correct, but is found on the system in the folder /sys/class/rfkill/rfkill0.
And appart from that only the kernel sources which are provided in the GT-S5360 Opensource package is the only source we have at this time.
From those sources I extracted the patch I added in my first post.
Btld I think should create a hci socket on /dev/ttyS1 which it does in the stock firmware but doesn' t work on the ported versions.
In the logcat it shows an error when loading bluetooth which says something like failed to create hci socket.
I will post a logcat later for exact errors shown in my logcat.
Greetings PsychoGame
Code:
E/bluedroid( 1518): Failed to create bluetooth hci socket: Address family not supported by protocol (97)
Is any kind of documentation available? Maybe you could then change the protocol to a supported one.
PsychoGame said:
Hello everybody,
I created this thread because I noticed a lot of people are busy with it, but not a lot of knowledge is shared about it.
Unfortunatly this board doesn't use the common way of implementing bluetooth, so bluetooth loading is giving problems with hciattach.
Already a lot of developers notices in the sources of the Samsung Galaxy Y Sources which can be downloaded from Samsungs contains a folder in hardware/broadcom which is called bt.
Also I noticed another bluetooth folder in the external packages in which broadcom also changed some code to the standard bluez stack.
I was able to find almost the exact source base at Code Aurora Forum so I was able to extract the commits which broadcom has added to the bluez stack.
The patch I extracted can be found here:
http://pastebin.com/Biv570y0
It still contains some Code Aurora stuff, because it's almost imposible to find the exact source base Samsung used.
But if you search for broadcom inside the patch you can find the additions broadcom made.
Also I'm searching for the glib source base they used, because in there broadcom also applied some changes, but haven't found the correct base yet.
Hopefully this forum will become one big pool of knowledge which everybody has so we can crack this problem very soon.
Because I saw a lot of people doing the same thing over and over because there isn't much shared about whats already tried.
So hopefully we can combine our forces on this one.
Greetings PsychoGame
Click to expand...
Click to collapse
i said for u alls my tentatives about this !
Hello Whitexp,
I never meant to insult you in any way, and I'm sorry if I did that in any way.
I know you shared you're knowledge on this with me, because I have received a PM from you with what you already did.
But after our conversation about that I found out that some other people also tried out what you did with the same results.
That is why I started this topic so we have a central point where all the information is shared.
Also tomorrow I will create a post for you in which I explain what you already tried, so other people know this.
Greetings PsychoGame
whitexp said:
i said for u alls my tentatives about this !
Click to expand...
Click to collapse
PsychoGame said:
Hello Whitexp,
I never meant to insult you in any way, and I'm sorry if I did that in any way.
I know you shared you're knowledge on this with me, because I have received a PM from you with what you already did.
But after our conversation about that I found out that some other people also tried out what you did with the same results.
That is why I started this topic so we have a central point where all the information is shared.
Also tomorrow I will create a post for you in which I explain what you already tried, so other people know this.
Greetings PsychoGame
Click to expand...
Click to collapse
lol
nops
just said for u , i explain my tentaives
Thank you Whitexp,
I misread a little bit what you said, so I interpreted it a little bit wrong.
Then we'll just wait and see what everybody is trying to do.
I know what you already tried was:
- You replaced the bluetooth folder in /external with the folder which was supplied in the GT-S5360 Opensource 2 package from the Samsung opensource website and compiled it with the options given in the Readme. This was no succes, which I can confirm because I also tried it, but took the bluetooth folder from GT-S5360 Opensource update 3 with the same result.
Also the result in android logcat was no different from without the bluetooth folder applied so this error came up:
E/bluedroid( 1518): Failed to create bluetooth hci socket: Address family not supported by protocol (97)
- The second try you made was to use brcm_patchram_plus in combination with btld. Also this lead to a dead end. I haven't tried this myself, so I don't know what errors may have come up in the logcat.
- Third try was to use brcm_patchram_plus without the use of btld, so the way you find it on many of the other CM ports without succes. I can also confirm this and I believe it led to the same error in the logcat as with the first try.
As an addition I found out that the bluedroid error above is found in the android sourcecode in the file <androidsource>/system/bluetooth/bluedroid/bluetooth.c which compiles to the file libbluedroid.so. Also I found in the Android.mk the option BOARD_CUSTOM_BLUEDROID which makes android building possible with a customized bluetooth.c so a libbluedroid.so. An example of this can be found for example on the samsung cooper device: https://github.com/CyanogenMod/android_device_samsung_cooper . I think we may have to do something with this also, because I found that the android port also has strange behavior when copying over the libbluedroid.so from the stock firmware. With the compiled version CM boots without a problem, but with the libbluedroid.so from stock the boot process hangs early on in the bootproces which you can see if you pull a logcat from the device. It doesn't even make it to alsa initialization. To be honest I only tested this with clean compiled CM, so without the external/bluetooth folder replaced with the one from source. Today will test to see if the same happens if I replaced the external/bluetooth folder with the one from the Samsung Opensource package.
Greetings PsychoGame
GermainZ said:
Code:
E/bluedroid( 1518): Failed to create bluetooth hci socket: Address family not supported by protocol (97)
Is any kind of documentation available? Maybe you could then change the protocol to a supported one.
Click to expand...
Click to collapse
Unfortunately as far as I know theres currently no real developer documentation available on the board or bluetooth chip.
The only information which google comes up with is this small bit of information on the bluetooth chip and board:
- BCM21553:
http://www.broadcom.com/products/Cellular/3G-Baseband-Processors/BCM21553
http://pdadb.net/index.php?m=cpu&id=a21553&c=broadcom_bcm21553
- BCM4330
https://www.bluetooth.org/tpg/RefNotes/4330-PB10X-R1.pdf
http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM4330
Still no luck in getting bluetooth to work.
Even compiling the Android source with the Bluetooth package from the GT-S5360 Opensource in combination with libbluedroid.so from stock didn't do the job.
Still rendered the system unbootable:S.
My developing will be on a low speed in the weekend, so will try new things next week.
Also people who have suggestions are welcome to post over here, but don't spam the thread.
I hope to keep this thread as informational as possible for other porters as well so we have as much information as possible in a central place:good:
Greetings PsychoGame
Hello ppl ....
jst placing a small request here
could you please run - "rfkill list" in terminal and post your results....
results from both stock and cm7 builds are welcome....
if you get "rfkill" not found on terminal try install busybox ..
i just googled the
Failed to create bluetooth hci socket: Address family not supported by protocol (97)
error and came up with this ....
TIA
anubhav
Not the Combine from Half-Life
</joke>
Hello anubhavrev,
I'll add the output of the rfkill list here in a minute.
Today I'm going to work on the bluetooth problem again.
I've found some new clues, when executing a logcat on the btld and bluetoothd in the stock rom.
I thought lets return to the point it was still working, and put the bluetooth system through the logwrapper.
Currently I'm building CM7 again with the bluetooth line in the init scripts exactly the same.
When finished building and flashing I will pull a logcat again and try to see if the logwrapper on the bluetooth system spits out something different.
Greetings PsychoGame
anubhavrev said:
Hello ppl ....
jst placing a small request here
could you please run - "rfkill list" in terminal and post your results....
results from both stock and cm7 builds are welcome....
if you get "rfkill" not found on terminal try install busybox ..
i just googled the
Failed to create bluetooth hci socket: Address family not supported by protocol (97)
error and came up with this ....
TIA
anubhav
Click to expand...
Click to collapse
Hello everybody,
I thought I'll update on what I tried with bluetooth today.
It looks promising, but it might just be a dead end as well, I'll investigate this further later on.
What I did was study the code in brcm_patchram_plus.c, and found out that it uses the UART H4 interface for bluetooth.
I knew from kernel developing this was a kernel feature, so I thought lets take a look what a search in the default config comes up with.
And bingo the bluetooth UART H4 was disabled in the kernel, so what I did was enable it and compile the kernel again.
To initialize the bluetooth with brcm_patchram_plus I added the next line to the init script in place of the btld daemon:
service hciattach /system/bin/logwrapper /system/bin/brcm_patchram_plus --enable_hci --baudrate 3000000 \
--patchram /system/bin/BCM4330B1_002.001.003.0634.0652.hcd /dev/ttyS1
user bluetooth
group bluetooth net_bt_admin
disabled
Click to expand...
Click to collapse
This time bluetooth started initializing, but the logcat shows that it fails with the following error:
D/DTUN_CLNT( 2055): BTLIF_MAKE_LOCAL_SERVER_NAME return name: brcm.bt.btlif.9000
I/DTUN_CLNT( 2055): connect_srv ret:-1 server name:brcm.bt.btlif.9000
I/bluetoothd( 2054): connect: Connection refused
E/BluetoothEventLoop.cpp( 1538): get_adapter_path: D-Bus error: org.freedesktop.DBus.Error.ServiceUnknown (The name org.bluez was not provided by any .service files)
I just wanted to let everybody know what I'm up to.
Greetings PsychoGame
I have very good news for the GT-S5360 community and other devices with bcm21553 board.
It looks like bluetooth is partially working in my device.
I can scan and find other bluetooth devices in my surrounding, and are able to find the GT-S5360 on other devices as well.
At the moment this is as far as I got, so pairing with the device is still not possible and sending files to the device is also still not possible.
But the first step has been set.
I think I also know what the problem might be with the bluetooth unable to pair, but I don't have time to fix this over the weekend.
As I have said in another thread I'm already investing a great deal of free time into this project, so this weekend I'm gonna take a break again.
Monday I'll start getting all the other problems out so hopefully somewhere next week I'll get bluetooth fully functioning.
In my CM7 thread I'll be releasing a new build where the bluetooth is partially working, so if you want to check it out for yourself then I'll advice you to take a look in the build.
Greetings PsychoGame
PsychoGame said:
I have very good news for the GT-S5360 community and other devices with bcm21553 board.
It looks like bluetooth is partially working in my device.
I can scan and find other bluetooth devices in my surrounding, and are able to find the GT-S5360 on other devices as well.
At the moment this is as far as I got, so pairing with the device is still not possible and sending files to the device is also still not possible.
But the first step has been set.
I think I also know what the problem might be with the bluetooth unable to pair, but I don't have time to fix this over the weekend.
As I have said in another thread I'm already investing a great deal of free time into this project, so this weekend I'm gonna take a break again.
Monday I'll start getting all the other problems out so hopefully somewhere next week I'll get bluetooth fully functioning.
In my CM7 thread I'll be releasing a new build where the bluetooth is partially working, so if you want to check it out for yourself then I'll advice you to take a look in the build.
Greetings PsychoGame
Click to expand...
Click to collapse
Ohh..thats great bro :thumbup: sorry i dnt knw anythng abut build cm7 or related to cm stuff..
Bt one thing i knw U r best in devloping forum for sgy :thumbup:
Keep it Up :thumbup: N all d best bro
I knw one day we will get bugless cm. :thumbup: due to ur awsme work :thumbup:
Sent from my GT-S5360 using xda app-developers app
If anyone wants to help me in my bluetooth development hereby I write what I did to get it working up to the point I'm at, at the moment.
In the kernel the following options have been set to Y and the kernel has been recompiled:
CONFIG_BT=y
CONFIG_BT_L2CAP=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_HIDP=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
About the these I'm not sure if I should include them in the kernel or not. Officially our kernel already had rfkill, which is a bcm-rfkill.
The problem is that the bluetoothd daemon is not able to correctly communicate with this bcm-rfkill. When the options below are not included bluetooth starts but a few bluetooth crashes occur. When I include them I'm able to start bluetooth, but am not able anymore to find any devices, and also my device isn't detected by other bluetooth devices anymore. So I think we will need to do some modifications to make the bluetoothd compatible with bcm-rfkill. Also it it not possible to work without the bcm-rfkill and use the kernels rfkill because then bluetooth isn't able to start anymore at all.
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
In the init scripts I have set the following things to work with brcm_patchram_plus:
# Set the correct bluetooth MAC Address
setprop ro.bt.bdaddr_path "/data/misc/bluetooth/.nvmac_bt.info"\
# permissions for bluetooth.
chown bluetooth bluetooth /data/misc/bluetooth
chown bluetooth bluetooth ro.bt.bdaddr_path
chown bluetooth bluetooth /dev/ttyS1
chmod 0600 /dev/ttyS1
chmod 0660 /sys/class/rfkill/rfkill0/state
chown bluetooth bluetooth /sys/class/rfkill/rfkill0/state
chown bluetooth bluetooth /sys/class/rfkill/rfkill0/type
service hciattach /system/bin/logwrapper /system/bin/brcm_patchram_plus --enable_hci \
--baudrate 3000000 --patchram /system/bin/BCM4330B1_002.001.003.0634.0652.hcd /dev/ttyS1
user bluetooth
group bluetooth net_bt_admin
disabled
oneshot
The bluetoothd line in the init.rc isn't changed, so you can just leave it untouched in the init scripts.
Hopefully we are all able to crack it.
Greetings PsychoGame