On Mon, Feb 25, 2008 at 3:30 PM, Dave Young <[EMAIL PROTECTED]> wrote: > Quote mail from [EMAIL PROTECTED] : > > 2007/12/17 Louis JANG <[EMAIL PROTECTED]>: > > > > Hello everybody, > > > > I attached two patches. the first one(bluez-kernel-forcesco.patch) is to > > force using HCI_OP_ADD_SCO instead of HCI_OP_SETUP_SYNC_CONN, and the > > second one is to handle SCO connection complete event but its request > > was ESCO. > > > > 1. > > I'm developing bluetooth functions in my linux phone project, and I'm > > using bluez for my job. I've tested lots of headsets, and found that I > > coudn't connect SCO channel with HCI_OP_SETUP_SYNC_CONN in some old > > headsets. I could connect SCO channel with HCI_OP_ADD_SCO in this case. > > however, there is no api to force using SCO instead of ESCO in bluez. so > > I added SCO_FORCESCO to handle this old headsets > > > > 2. > > When I tried to connect SCO channel with > > HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets responds > > with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't > > handle this situation, and patch_hci_event.c is for this. > > > > > > BRs > > Louis JANG > > > > > > Reply from [EMAIL PROTECTED]: > > On Mon, Feb 25, 2008 at 2:43 PM, Brad Midgley <[EMAIL PROTECTED]> wrote: > > Louis > > > > > > > > When I tried to connect SCO channel with > > > HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets > responds > > > with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't > > > handle this situation, and patch_hci_event.c is for this. > > > > > Marcel looked at this patch and came back with the comments below. Can > > you revisit it? I think some other people are seeing the same issues. > > The patch won't go upstream until Marcel likes it. > > > > the patch you sent me is fully broken. First of all the coding style > > is wrong. Does nobody have learned this by now? I always look for that > > first before even reading the patch. Second the case where an > > ESCO_LINK returns NULL is broken and will fall over and crash. > > > > -- > > Brad > > > > > I ever asked marcel about the coding style. please see following thread: > http://lkml.org/lkml/2008/1/22/91 > > I think the style problem marcel said is > 1. using kernel codeing style > 2. marcel's style > container_of or get_user_data calls at the top of the variable declaration > using the empty lines to seperate code blocks > > Please rework your patch and resend if you fixed them. > > BTW, please use the new bluetooth mailing list for kerne issue. > [EMAIL PROTECTED] > > (Thanks for andrew and davem)
On bugzilla, bug 9871 are same problem as yours. add davem and netdev in cc-list > > Regards > dave > > Regards > dave > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
