All of lore.kernel.org
 help / color / mirror / Atom feed
* ACL/SCO packets not transferred to slave device with new btusb/BlueZ driver
@ 2011-07-28  8:33 Eponymous -
  2011-07-28 14:00 ` Peter Hurley
  0 siblings, 1 reply; 4+ messages in thread
From: Eponymous - @ 2011-07-28  8:33 UTC (permalink / raw)
  To: linux-bluetooth

Thanks for your reply Peter.

The problem I've got is that I work for a company testing Bluetooth so
I have my hands tied as to how much information I can give - this is
obviously a nightmare for both you who is trying to help me and for me
who is trying to get the issue fixed :)

It could be very well that the program I'm using (that used to work
with BlueZ just fine when the hci_usb driver was around) is no longer
compatible.

I need to speak to the developers of the program I'm using to work out
how they communicate with BlueZ/the chip.

Cheers.


On Fri, Jul 15, 2011 at 9:41 PM, Eponymous - <the.epon@gmail.com> wrote:
>
> I'm not sure I follow you.
>
> What is wrong with the subject line?
>
> Cheers.
>
> On Thu, Jul 14, 2011 at 3:40 PM, Markus Burvall <markus.burvall@swedenconnectivity.com> wrote:
>>
>> Hi,
>>
>> I don't think they read this mail due to the subject line.
>>
>> Best of luck!
>>
>> On 2011-07-12 11:07, Eponymous - wrote:
>>
>> I'm now thinking that it's going to be a waste of time unless I can
>> get SCO support as well.
>>
>> To re-iterate my prev question: is this a bug and if so, will it be fixed?
>>
>> On Fri, Jul 1, 2011 at 8:06 AM, Eponymous - <the.epon@gmail.com> wrote:
>>
>> Hmm, is this patch included/due to be included in later releases of
>> btusb? It sounds like a bug if you can't send ACL/SCO packets over a
>> RAW socket.... Am I wrong?
>>
>> How exactly is everything packaged up? Is btusb part of the bluez
>> suite or is it a separate packaged?
>>
>> Cheers.
>>
>>
>> On Fri, Jul 1, 2011 at 7:59 AM, Markus Burvall <
>> markus.burvall@swedenconnectivity.com> wrote:
>>
>> **
>> Hello,
>>
>> For non SCO packets the fix from Kim works.
>>
>> Recompile btusb.c and use RAW mode.
>>
>> However it didn't work work SCO over RAW.
>>
>> http://lkml.org/lkml/2010/4/7/146
>>
>> Best Regards, Markus
>>
>>
>> On 2011-07-01 08:46, Eponymous - wrote:
>>
>> Thanks for the information.
>>
>> Hmm, I'm not sure what you mean about a "raw hci" socket. Could you
>> tell me how I can check this?
>>
>> I'm using a custom program that can communicate directly to the chip
>> over hci using bluez as a go-between. Does this help?
>>
>> Cheers.
>>
>> On Thu, Jun 30, 2011 at 4:47 PM, Peter Hurley <peter@hurleysoftware.com> <peter@hurleysoftware.com> wrote:
>>
>>  On Wed, 2011-06-29 at 06:22 -0400, Eponymous - wrote:
>>
>>  Thanks for your reply Peter.
>>
>> Sorry if I came across a bit rude there, it is just very frustrating
>> sometimes :)
>>
>>  I get it. BT can be <arggghhh>...
>>
>>
>>  You mentioned enabling debug messages for btusb and bluetooth. Do you
>> by any chance know how to do this?
>>
>>  I always run a debug kernel. My relevant build settings in the "Kernel
>> hacking" submenu are:
>>  Kernel Debugging => DEBUG_KERNEL=y
>>  Debug Filesystem => DEBUG_FS=y
>>  Compile the kernel with debug info => DEBUG_INFO=y
>> and most importantly,
>>  Enable dynamic printk() support DYNAMIC_DEBUG=y
>>
>> Then read the short dynamic debug howto in the kernel documentation:
>> Documentation/dynamic-debug-howto.txt (there are some copies online as
>> well if that's easier).
>>
>> Then when I want to see debug messages, I just enable those source
>> files. Eg.,
>> # echo -n 'file hci_core.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>>
>> M.Sc Markus Burvall
>> Senior Consultant
>>
>> Adress:
>> Torshamnsgatan 30B / 28A
>> 164 40 Kista
>> Sweden
>> Mobile: +46 70 650 11 44
>> Mail: Markus.Burvall@SwedenConnectivity.com
>> Web: http://swedenconnectivity.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ACL/SCO packets not transferred to slave device with new btusb/BlueZ driver
  2011-07-28  8:33 ACL/SCO packets not transferred to slave device with new btusb/BlueZ driver Eponymous -
@ 2011-07-28 14:00 ` Peter Hurley
  2011-07-28 14:02   ` Eponymous -
  0 siblings, 1 reply; 4+ messages in thread
From: Peter Hurley @ 2011-07-28 14:00 UTC (permalink / raw)
  To: Eponymous -; +Cc: linux-bluetooth

T24gVGh1LCAyMDExLTA3LTI4IGF0IDA0OjMzIC0wNDAwLCBFcG9ueW1vdXMgLSB3cm90ZToNCj4g
VGhhbmtzIGZvciB5b3VyIHJlcGx5IFBldGVyLg0KPiANCj4gVGhlIHByb2JsZW0gSSd2ZSBnb3Qg
aXMgdGhhdCBJIHdvcmsgZm9yIGEgY29tcGFueSB0ZXN0aW5nIEJsdWV0b290aCBzbw0KPiBJIGhh
dmUgbXkgaGFuZHMgdGllZCBhcyB0byBob3cgbXVjaCBpbmZvcm1hdGlvbiBJIGNhbiBnaXZlIC0g
dGhpcyBpcw0KPiBvYnZpb3VzbHkgYSBuaWdodG1hcmUgZm9yIGJvdGggeW91IHdobyBpcyB0cnlp
bmcgdG8gaGVscCBtZSBhbmQgZm9yIG1lDQo+IHdobyBpcyB0cnlpbmcgdG8gZ2V0IHRoZSBpc3N1
ZSBmaXhlZCA6KQ0KPiANCj4gSXQgY291bGQgYmUgdmVyeSB3ZWxsIHRoYXQgdGhlIHByb2dyYW0g
SSdtIHVzaW5nICh0aGF0IHVzZWQgdG8gd29yaw0KPiB3aXRoIEJsdWVaIGp1c3QgZmluZSB3aGVu
IHRoZSBoY2lfdXNiIGRyaXZlciB3YXMgYXJvdW5kKSBpcyBubyBsb25nZXINCj4gY29tcGF0aWJs
ZS4NCj4gDQo+IEkgbmVlZCB0byBzcGVhayB0byB0aGUgZGV2ZWxvcGVycyBvZiB0aGUgcHJvZ3Jh
bSBJJ20gdXNpbmcgdG8gd29yayBvdXQNCj4gaG93IHRoZXkgY29tbXVuaWNhdGUgd2l0aCBCbHVl
Wi90aGUgY2hpcC4NCj4gDQo+IENoZWVycy4NCg0KSGksDQoNClRoZSBwYXRjaCB0byB0aGUgYnR1
c2IgZHJpdmVyICh3aGljaCBtYXkgb3IgbWF5IG5vdCBmaXggdGhlIGlzc3VlIHlvdSdyZQ0KaGF2
aW5nKSBpcyBvbiB0aGUgYmx1ZXRvb3RoLW5leHQgZGV2ZWxvcG1lbnQgdHJlZSBhbmQgaXMgc2xh
dGVkIGZvcg0KaW5jbHVzaW9uIGluIHRoZSBuZXh0IGtlcm5lbCByZWxlYXNlIChwcm9iYWJseSBz
b21ldGltZSBpbiBTZXB0ZW1iZXIsDQpiYXNlZCBvbiBjdXJyZW50IHJlbGVhc2UgY3ljbGUgdGlt
ZXMpLg0KDQpJZiB5b3VyIGZhbWlsaWFyIHdpdGggaG93IHRvIGJ1aWxkIGEga2VybmVsIG1vZHVs
ZSwgeW91IGNvdWxkIGdyYWIgdGhlDQpwYXRjaCBmcm9tIHRoaXMgbGlzdCBoZXJlOg0KaHR0cDov
L3Blcm1hbGluay5nbWFuZS5vcmcvZ21hbmUubGludXguYmx1ZXoua2VybmVsLzE0NzU4DQpUaGVu
IHJlYnVpbGQgJ2RyaXZlcnMvYmx1ZXRvb3RoL2J0dXNiJy4NCg0KTGV0IHVzIGtub3cgd2hldGhl
ciBvciBub3QgdGhhdCByZXNvbHZlcyB0aGUgcHJvYmxlbS4NCg0KUmVnYXJkcywNClBldGVyDQo=

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ACL/SCO packets not transferred to slave device with new btusb/BlueZ driver
  2011-07-28 14:00 ` Peter Hurley
@ 2011-07-28 14:02   ` Eponymous -
  2011-07-29  8:54     ` Eponymous -
  0 siblings, 1 reply; 4+ messages in thread
From: Eponymous - @ 2011-07-28 14:02 UTC (permalink / raw)
  To: Peter Hurley; +Cc: linux-bluetooth

Thanks. I'll give it a try.

On Thu, Jul 28, 2011 at 3:00 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On Thu, 2011-07-28 at 04:33 -0400, Eponymous - wrote:
>> Thanks for your reply Peter.
>>
>> The problem I've got is that I work for a company testing Bluetooth so
>> I have my hands tied as to how much information I can give - this is
>> obviously a nightmare for both you who is trying to help me and for me
>> who is trying to get the issue fixed :)
>>
>> It could be very well that the program I'm using (that used to work
>> with BlueZ just fine when the hci_usb driver was around) is no longer
>> compatible.
>>
>> I need to speak to the developers of the program I'm using to work out
>> how they communicate with BlueZ/the chip.
>>
>> Cheers.
>
> Hi,
>
> The patch to the btusb driver (which may or may not fix the issue you're
> having) is on the bluetooth-next development tree and is slated for
> inclusion in the next kernel release (probably sometime in September,
> based on current release cycle times).
>
> If your familiar with how to build a kernel module, you could grab the
> patch from this list here:
> http://permalink.gmane.org/gmane.linux.bluez.kernel/14758
> Then rebuild 'drivers/bluetooth/btusb'.
>
> Let us know whether or not that resolves the problem.
>
> Regards,
> Peter
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ACL/SCO packets not transferred to slave device with new btusb/BlueZ driver
  2011-07-28 14:02   ` Eponymous -
@ 2011-07-29  8:54     ` Eponymous -
  0 siblings, 0 replies; 4+ messages in thread
From: Eponymous - @ 2011-07-29  8:54 UTC (permalink / raw)
  To: linux-bluetooth

Yey!

It works perfectly with this change :)

Thanks a lot!

On Thu, Jul 28, 2011 at 3:02 PM, Eponymous - <the.epon@gmail.com> wrote:
> Thanks. I'll give it a try.
>
> On Thu, Jul 28, 2011 at 3:00 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>> On Thu, 2011-07-28 at 04:33 -0400, Eponymous - wrote:
>>> Thanks for your reply Peter.
>>>
>>> The problem I've got is that I work for a company testing Bluetooth so
>>> I have my hands tied as to how much information I can give - this is
>>> obviously a nightmare for both you who is trying to help me and for me
>>> who is trying to get the issue fixed :)
>>>
>>> It could be very well that the program I'm using (that used to work
>>> with BlueZ just fine when the hci_usb driver was around) is no longer
>>> compatible.
>>>
>>> I need to speak to the developers of the program I'm using to work out
>>> how they communicate with BlueZ/the chip.
>>>
>>> Cheers.
>>
>> Hi,
>>
>> The patch to the btusb driver (which may or may not fix the issue you're
>> having) is on the bluetooth-next development tree and is slated for
>> inclusion in the next kernel release (probably sometime in September,
>> based on current release cycle times).
>>
>> If your familiar with how to build a kernel module, you could grab the
>> patch from this list here:
>> http://permalink.gmane.org/gmane.linux.bluez.kernel/14758
>> Then rebuild 'drivers/bluetooth/btusb'.
>>
>> Let us know whether or not that resolves the problem.
>>
>> Regards,
>> Peter
>>
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-07-29  8:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-28  8:33 ACL/SCO packets not transferred to slave device with new btusb/BlueZ driver Eponymous -
2011-07-28 14:00 ` Peter Hurley
2011-07-28 14:02   ` Eponymous -
2011-07-29  8:54     ` Eponymous -

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.