So, it turns out that in order for any external usb bluetooth adapters
to re-connect to paired input devices on reboot, you need to issue an
'hciconfig hci0 reset' command after rebooting in order to reconnect.
More info can be found in bug #133690 on Launchpad
(https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
I'm posting here.
Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
source would solve this bug. Is this a reasonable solution?
What is required in order to get a fix implemented?
Thanks,
Alex (Jackflap/OdyTheDog)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Peter,
>> So, if I'm reading this correctly, you should issue the reset for all
>> CSR-based dongles with build id > 118.
>>
>> Am I on the right track here? Does this information look accurate
>> to you
>> guys?
>
> This is basically correct in that the fix appeared in firmware
> around then
> (the internal log says 117, but possibly that was never released---
> I've
> confined my search to the development side).
>
> However, it's not that simple in that releases of earlier firmware
> branches
> were still being made for some time. Our ID numbers increase
> monotonically
> so these would have later numbers. I haven't done an exhaustive
> search;
> mostly these releases had L2CAP + RFCOMM on chip for embedded
> applications,
> so you wouldn't care about them. I don't see any evidence of a
> later HCI
> release based on the old code, offhand (but don't take this as
> gospel).
this is what Steven told me. We don't have to worry about the RFCOMM
builds since they don't include a HCI interface.
> If you want to be quite sure not to pick up a build which didn't
> have the
> fix for reset, you could restrict the change to BlueCore 2 and later
> chips
> using the "bcget chipver" call. The early branches without the fix
> only ever ran on BlueCore 1: the fix was made in major release 12 and
> BlueCore 2 first ran on major release 14.
No vendor specific setup/init quirks that would have to call vendor
commands :)
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Thu, 20 Mar 2008 17:19:22 +0000
"Odysseus Flappington" <[email protected]> wrote:
>...
> So, if I'm reading this correctly, you should issue the reset for all
> CSR-based dongles with build id > 118.
>
> Am I on the right track here? Does this information look accurate to you
> guys?
This is basically correct in that the fix appeared in firmware around then
(the internal log says 117, but possibly that was never released---I've
confined my search to the development side).
However, it's not that simple in that releases of earlier firmware branches
were still being made for some time. Our ID numbers increase monotonically
so these would have later numbers. I haven't done an exhaustive search;
mostly these releases had L2CAP + RFCOMM on chip for embedded applications,
so you wouldn't care about them. I don't see any evidence of a later HCI
release based on the old code, offhand (but don't take this as gospel).
If you want to be quite sure not to pick up a build which didn't have the
fix for reset, you could restrict the change to BlueCore 2 and later chips
using the "bcget chipver" call. The early branches without the fix
only ever ran on BlueCore 1: the fix was made in major release 12 and
BlueCore 2 first ran on major release 14.
--
Peter Stephenson <[email protected]> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Marcel, Dave,
I've been looking around to see if I could figure out the build id where the
dongles started shipping with the correct HCI_Reset. I think I may have
found something.
http://www.csr.com/ contains the docs regarding the release of the CSR
firmware and the specs that each adhere's to. Looking at the following HCI
overall Implementation doc, I think we can find the relevant build id:
https://www.csrsupport.com/document.php?did=141
Firstly, i found confirmation that the problem has been solved in
HCIStack1.1v12.x:
"In builds before HCIStack1.1v12.x, the HCI Reset command rebooted the
BlueCore device. This implied the host
transport was reset. This was a consequence of the way the firmware team
understood an early version of the
Bluetooth specification (probably 0.7).
Rebooting the BlueCore device is incorrect behaviour. Version 1.1 [BT] now
makes it clear that the Reset
command must reinitialise radio, LC, LM and HCI state, but leave the host
transport in place. Builds since
HCIStack1.1v12.x obey [BT]."
So this should be fixed in HCIStack1.1v12.x, the doc outlines the build ids
for each version of of the stack, here is the build id for HCIStack1.1v12.1:
BuildID (hex) BuildID (decimal) Build Name
0x0077 119 HCIStack1.1v12.1
So, if I'm reading this correctly, you should issue the reset for all
CSR-based dongles with build id > 118.
Am I on the right track here? Does this information look accurate to you
guys?
If there's anything else I can to do re this issue, please let feel free to
ask me.
Many thanks,
Alex (Jackflap)
On 18/03/2008, Dave Young <[email protected]> wrote:
>
> On Mon, Mar 17, 2008 at 8:28 PM, Odysseus Flappington
>
> <[email protected]> wrote:
> > Hi Dave,
> >
>
> > So I got around to recompiling my kernel this weekend, and ran off a
> test on
> > the patch attached and it worked like a charm.
> >
> > I have to wonder though why the line was commented out in the first
> place.
> > Could it be because internal adapters don't need the line?
> >
> > Anyway, I'd love to see this fixed in future kernels. If there's
> anything
> > else I can do to help test, let me know. Now that I've got my head
> around
> > recompiling kernels again, I can probably turn around tests a lot
> faster.
>
>
> Hi thanks
>
> About the reset issue, I get some response from marcel about reset csr
> dongles
> -------- Marcel said :
> this is a clear NAK since you gonna break all old CSR based dongles.
> Within the Bluetooth 1.0b and 1.1 specification there was an issues
> with if HCI_Reset should only reset the Bluetooth internals or also
> the transport. So issuing HCI_Reset on an old dongle will cause an USB
> reset.
>
> The solution is to find the build id when CSR produced correct
> firmware and set the HCI_RESET quirk based on that. I meant to do this
> for a long time, but so far never got around to inquiry the correct
> build id where this got fixed.
> --------
>
> But I think it's hard to find that build id, so ...
>
> Regards
>
> dave
>
>
> >
> > Many thanks,
> >
> >
> > Alex
> >
> > On 03/03/2008, Odysseus Flappington <[email protected]> wrote:
> > > Ok,
> > >
> > > I passed reset=1 to hci_usb by adding the following line to
> > > /etc/modprobe.d/options:
> > >
> > > options hci_usb reset=1
> > >
> > > and that's fixed the problem!
> > >
> > > Wasn't sure about my lsusb output, didn't seem to show very much, so
> > > here's my lsusb -v output for my bluetooth device:
> > >
> > > Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> > > Bluetooth Dongle (HCI mode)
> > > Device Descriptor:
> > > bLength 18
> > > bDescriptorType 1
> > > bcdUSB 2.00
> > > bDeviceClass 224 Wireless
> > > bDeviceSubClass 1 Radio Frequency
> > > bDeviceProtocol 1 Bluetooth
> > > bMaxPacketSize0 64
> > > idVendor 0x0a12 Cambridge Silicon Radio, Ltd
> > > idProduct 0x0001 Bluetooth Dongle (HCI mode)
> > > bcdDevice 31.64
> > > iManufacturer 0
> > > iProduct 0
> > > iSerial 0
> > > bNumConfigurations 1
> > > Configuration Descriptor:
> > > bLength 9
> > > bDescriptorType 2
> > > wTotalLength 177
> > > bNumInterfaces 2
> > > bConfigurationValue 1
> > > iConfiguration 0
> > > bmAttributes 0xc0
> > > Self Powered
> > > MaxPower 0mA
> > > Interface Descriptor:
> > > bLength 9
> > > bDescriptorType 4
> > > bInterfaceNumber 0
> > > bAlternateSetting 0
> > > bNumEndpoints 3
> > > bInterfaceClass 224 Wireless
> > > bInterfaceSubClass 1 Radio Frequency
> > > bInterfaceProtocol 1 Bluetooth
> > > iInterface 0
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x81 EP 1 IN
> > > bmAttributes 3
> > > Transfer Type Interrupt
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0010 1x 16 bytes
> > > bInterval 1
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x02 EP 2 OUT
> > > bmAttributes 2
> > > Transfer Type Bulk
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0040 1x 64 bytes
> > > bInterval 1
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x82 EP 2 IN
> > > bmAttributes 2
> > > Transfer Type Bulk
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0040 1x 64 bytes
> > > bInterval 1
> > > Interface Descriptor:
> > > bLength 9
> > > bDescriptorType 4
> > > bInterfaceNumber 1
> > > bAlternateSetting 0
> > > bNumEndpoints 2
> > > bInterfaceClass 224 Wireless
> > > bInterfaceSubClass 1 Radio Frequency
> > > bInterfaceProtocol 1 Bluetooth
> > > iInterface 0
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x03 EP 3 OUT
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0000 1x 0 bytes
> > > bInterval 1
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x83 EP 3 IN
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0000 1x 0 bytes
> > > bInterval 1
> > > Interface Descriptor:
> > > bLength 9
> > > bDescriptorType 4
> > > bInterfaceNumber 1
> > > bAlternateSetting 1
> > > bNumEndpoints 2
> > > bInterfaceClass 224 Wireless
> > > bInterfaceSubClass 1 Radio Frequency
> > > bInterfaceProtocol 1 Bluetooth
> > > iInterface 0
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x03 EP 3 OUT
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0009 1x 9 bytes
> > > bInterval 1
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x83 EP 3 IN
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0009 1x 9 bytes
> > > bInterval 1
> > > Interface Descriptor:
> > > bLength 9
> > > bDescriptorType 4
> > > bInterfaceNumber 1
> > > bAlternateSetting 2
> > > bNumEndpoints 2
> > > bInterfaceClass 224 Wireless
> > > bInterfaceSubClass 1 Radio Frequency
> > > bInterfaceProtocol 1 Bluetooth
> > > iInterface 0
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x03 EP 3 OUT
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0011 1x 17 bytes
> > > bInterval 1
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x83 EP 3 IN
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0011 1x 17 bytes
> > > bInterval 1
> > > Interface Descriptor:
> > > bLength 9
> > > bDescriptorType 4
> > > bInterfaceNumber 1
> > > bAlternateSetting 3
> > > bNumEndpoints 2
> > > bInterfaceClass 224 Wireless
> > > bInterfaceSubClass 1 Radio Frequency
> > > bInterfaceProtocol 1 Bluetooth
> > > iInterface 0
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x03 EP 3 OUT
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0019 1x 25 bytes
> > > bInterval 1
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x83 EP 3 IN
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0019 1x 25 bytes
> > > bInterval 1
> > > Interface Descriptor:
> > > bLength 9
> > > bDescriptorType 4
> > > bInterfaceNumber 1
> > > bAlternateSetting 4
> > > bNumEndpoints 2
> > > bInterfaceClass 224 Wireless
> > > bInterfaceSubClass 1 Radio Frequency
> > > bInterfaceProtocol 1 Bluetooth
> > > iInterface 0
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x03 EP 3 OUT
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0021 1x 33 bytes
> > > bInterval 1
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x83 EP 3 IN
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0021 1x 33 bytes
> > > bInterval 1
> > > Interface Descriptor:
> > > bLength 9
> > > bDescriptorType 4
> > > bInterfaceNumber 1
> > > bAlternateSetting 5
> > > bNumEndpoints 2
> > > bInterfaceClass 224 Wireless
> > > bInterfaceSubClass 1 Radio Frequency
> > > bInterfaceProtocol 1 Bluetooth
> > > iInterface 0
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x03 EP 3 OUT
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0031 1x 49 bytes
> > > bInterval 1
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x83 EP 3 IN
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0031 1x 49 bytes
> > > bInterval 1
> > > Device Status: 0x0001
> > > Self Powered
> > >
> > > Thanks,
> > > Alex
> > >
> > >
> > >
> > >
> > > On 03/03/2008, Odysseus Flappington <[email protected]> wrote:
> > > > Hi Dave,
> > > >
> > > > Thanks for the help. I can probably get a recompile of my kernel
> done
> > > > by the end of the weekend, maybe end of week, if it'll help.
> > > >
> > > > In the meantime, I'll try loading the bluetooth module with reset=1
> > > > and get the lsusb output to you tonight when I get home from work.
> > > >
> > > > Thanks,
> > > > Alex (Jackflap)
> > > >
> > > >
> > > > On 03/03/2008, Dave Young <[email protected]> wrote:
> > > > > On Mon, Mar 3, 2008 at 9:21 AM, Dave Young
> > <[email protected]> wrote:
> > > > > > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > > > > > <[email protected]> wrote:
> > > > > >
> > > > > >
> > > > > > > So, it turns out that in order for any external usb
> bluetooth
> > adapters
> > > > > > > to re-connect to paired input devices on reboot, you need
> to
> > issue an
> > > > > > > 'hciconfig hci0 reset' command after rebooting in order to
> > reconnect.
> > > > > > >
> > > > > > > More info can be found in bug #133690 on Launchpad
> > > > > > >
> > (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > > > > > >
> > > > > > > This bug isn't Ubuntu-specific since I have reproduced in
> > Fedora 8, so
> > > > > > > I'm posting here.
> > > > > > >
> > > > > > > Simply adding 'hciconfig hci0 reset' in
> /etc/default/bluetooth
> > in
> > > > > > > source would solve this bug. Is this a reasonable
> solution?
> > > > > > >
> > > > > > > What is required in order to get a fix implemented?
> > > > >
> > > > >
> > > > > Sorry for previous blank reply.
> > > > >
> > > > > For your problem, if you don't want to patch kernel you can also
> try
> > > > > load the bluetooth module with parameter "reset=1"
> > > > >
> > > > > Could you send the lsusb output?
> > > > >
> > > > > Regards
> > > > >
> > > > > dave
> > > > >
> > > > >
> > > > >
> >
> -------------------------------------------------------------------------
> > > > > This SF.net email is sponsored by: Microsoft
> > > > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > > _______________________________________________
> > > > > Bluez-users mailing list
> > > > > [email protected]
> > > > > https://lists.sourceforge.net/lists/listinfo/bluez-users
> > > > >
> > > >
> > >
> >
> >
>
On Mon, Mar 17, 2008 at 8:28 PM, Odysseus Flappington
<[email protected]> wrote:
> Hi Dave,
>
> So I got around to recompiling my kernel this weekend, and ran off a test on
> the patch attached and it worked like a charm.
>
> I have to wonder though why the line was commented out in the first place.
> Could it be because internal adapters don't need the line?
>
> Anyway, I'd love to see this fixed in future kernels. If there's anything
> else I can do to help test, let me know. Now that I've got my head around
> recompiling kernels again, I can probably turn around tests a lot faster.
Hi thanks
About the reset issue, I get some response from marcel about reset csr dongles
-------- Marcel said :
this is a clear NAK since you gonna break all old CSR based dongles.
Within the Bluetooth 1.0b and 1.1 specification there was an issues
with if HCI_Reset should only reset the Bluetooth internals or also
the transport. So issuing HCI_Reset on an old dongle will cause an USB
reset.
The solution is to find the build id when CSR produced correct
firmware and set the HCI_RESET quirk based on that. I meant to do this
for a long time, but so far never got around to inquiry the correct
build id where this got fixed.
--------
But I think it's hard to find that build id, so ...
Regards
dave
>
> Many thanks,
>
>
> Alex
>
> On 03/03/2008, Odysseus Flappington <[email protected]> wrote:
> > Ok,
> >
> > I passed reset=1 to hci_usb by adding the following line to
> > /etc/modprobe.d/options:
> >
> > options hci_usb reset=1
> >
> > and that's fixed the problem!
> >
> > Wasn't sure about my lsusb output, didn't seem to show very much, so
> > here's my lsusb -v output for my bluetooth device:
> >
> > Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> > Bluetooth Dongle (HCI mode)
> > Device Descriptor:
> > bLength 18
> > bDescriptorType 1
> > bcdUSB 2.00
> > bDeviceClass 224 Wireless
> > bDeviceSubClass 1 Radio Frequency
> > bDeviceProtocol 1 Bluetooth
> > bMaxPacketSize0 64
> > idVendor 0x0a12 Cambridge Silicon Radio, Ltd
> > idProduct 0x0001 Bluetooth Dongle (HCI mode)
> > bcdDevice 31.64
> > iManufacturer 0
> > iProduct 0
> > iSerial 0
> > bNumConfigurations 1
> > Configuration Descriptor:
> > bLength 9
> > bDescriptorType 2
> > wTotalLength 177
> > bNumInterfaces 2
> > bConfigurationValue 1
> > iConfiguration 0
> > bmAttributes 0xc0
> > Self Powered
> > MaxPower 0mA
> > Interface Descriptor:
> > bLength 9
> > bDescriptorType 4
> > bInterfaceNumber 0
> > bAlternateSetting 0
> > bNumEndpoints 3
> > bInterfaceClass 224 Wireless
> > bInterfaceSubClass 1 Radio Frequency
> > bInterfaceProtocol 1 Bluetooth
> > iInterface 0
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x81 EP 1 IN
> > bmAttributes 3
> > Transfer Type Interrupt
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0010 1x 16 bytes
> > bInterval 1
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x02 EP 2 OUT
> > bmAttributes 2
> > Transfer Type Bulk
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0040 1x 64 bytes
> > bInterval 1
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x82 EP 2 IN
> > bmAttributes 2
> > Transfer Type Bulk
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0040 1x 64 bytes
> > bInterval 1
> > Interface Descriptor:
> > bLength 9
> > bDescriptorType 4
> > bInterfaceNumber 1
> > bAlternateSetting 0
> > bNumEndpoints 2
> > bInterfaceClass 224 Wireless
> > bInterfaceSubClass 1 Radio Frequency
> > bInterfaceProtocol 1 Bluetooth
> > iInterface 0
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x03 EP 3 OUT
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0000 1x 0 bytes
> > bInterval 1
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x83 EP 3 IN
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0000 1x 0 bytes
> > bInterval 1
> > Interface Descriptor:
> > bLength 9
> > bDescriptorType 4
> > bInterfaceNumber 1
> > bAlternateSetting 1
> > bNumEndpoints 2
> > bInterfaceClass 224 Wireless
> > bInterfaceSubClass 1 Radio Frequency
> > bInterfaceProtocol 1 Bluetooth
> > iInterface 0
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x03 EP 3 OUT
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0009 1x 9 bytes
> > bInterval 1
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x83 EP 3 IN
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0009 1x 9 bytes
> > bInterval 1
> > Interface Descriptor:
> > bLength 9
> > bDescriptorType 4
> > bInterfaceNumber 1
> > bAlternateSetting 2
> > bNumEndpoints 2
> > bInterfaceClass 224 Wireless
> > bInterfaceSubClass 1 Radio Frequency
> > bInterfaceProtocol 1 Bluetooth
> > iInterface 0
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x03 EP 3 OUT
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0011 1x 17 bytes
> > bInterval 1
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x83 EP 3 IN
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0011 1x 17 bytes
> > bInterval 1
> > Interface Descriptor:
> > bLength 9
> > bDescriptorType 4
> > bInterfaceNumber 1
> > bAlternateSetting 3
> > bNumEndpoints 2
> > bInterfaceClass 224 Wireless
> > bInterfaceSubClass 1 Radio Frequency
> > bInterfaceProtocol 1 Bluetooth
> > iInterface 0
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x03 EP 3 OUT
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0019 1x 25 bytes
> > bInterval 1
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x83 EP 3 IN
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0019 1x 25 bytes
> > bInterval 1
> > Interface Descriptor:
> > bLength 9
> > bDescriptorType 4
> > bInterfaceNumber 1
> > bAlternateSetting 4
> > bNumEndpoints 2
> > bInterfaceClass 224 Wireless
> > bInterfaceSubClass 1 Radio Frequency
> > bInterfaceProtocol 1 Bluetooth
> > iInterface 0
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x03 EP 3 OUT
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0021 1x 33 bytes
> > bInterval 1
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x83 EP 3 IN
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0021 1x 33 bytes
> > bInterval 1
> > Interface Descriptor:
> > bLength 9
> > bDescriptorType 4
> > bInterfaceNumber 1
> > bAlternateSetting 5
> > bNumEndpoints 2
> > bInterfaceClass 224 Wireless
> > bInterfaceSubClass 1 Radio Frequency
> > bInterfaceProtocol 1 Bluetooth
> > iInterface 0
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x03 EP 3 OUT
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0031 1x 49 bytes
> > bInterval 1
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x83 EP 3 IN
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0031 1x 49 bytes
> > bInterval 1
> > Device Status: 0x0001
> > Self Powered
> >
> > Thanks,
> > Alex
> >
> >
> >
> >
> > On 03/03/2008, Odysseus Flappington <[email protected]> wrote:
> > > Hi Dave,
> > >
> > > Thanks for the help. I can probably get a recompile of my kernel done
> > > by the end of the weekend, maybe end of week, if it'll help.
> > >
> > > In the meantime, I'll try loading the bluetooth module with reset=1
> > > and get the lsusb output to you tonight when I get home from work.
> > >
> > > Thanks,
> > > Alex (Jackflap)
> > >
> > >
> > > On 03/03/2008, Dave Young <[email protected]> wrote:
> > > > On Mon, Mar 3, 2008 at 9:21 AM, Dave Young
> <[email protected]> wrote:
> > > > > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > > > > <[email protected]> wrote:
> > > > >
> > > > >
> > > > > > So, it turns out that in order for any external usb bluetooth
> adapters
> > > > > > to re-connect to paired input devices on reboot, you need to
> issue an
> > > > > > 'hciconfig hci0 reset' command after rebooting in order to
> reconnect.
> > > > > >
> > > > > > More info can be found in bug #133690 on Launchpad
> > > > > >
> (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > > > > >
> > > > > > This bug isn't Ubuntu-specific since I have reproduced in
> Fedora 8, so
> > > > > > I'm posting here.
> > > > > >
> > > > > > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth
> in
> > > > > > source would solve this bug. Is this a reasonable solution?
> > > > > >
> > > > > > What is required in order to get a fix implemented?
> > > >
> > > >
> > > > Sorry for previous blank reply.
> > > >
> > > > For your problem, if you don't want to patch kernel you can also try
> > > > load the bluetooth module with parameter "reset=1"
> > > >
> > > > Could you send the lsusb output?
> > > >
> > > > Regards
> > > >
> > > > dave
> > > >
> > > >
> > > >
> -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by: Microsoft
> > > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > _______________________________________________
> > > > Bluez-users mailing list
> > > > [email protected]
> > > > https://lists.sourceforge.net/lists/listinfo/bluez-users
> > > >
> > >
> >
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Dave,
So I got around to recompiling my kernel this weekend, and ran off a test on
the patch attached and it worked like a charm.
I have to wonder though why the line was commented out in the first place.
Could it be because internal adapters don't need the line?
Anyway, I'd love to see this fixed in future kernels. If there's anything
else I can do to help test, let me know. Now that I've got my head around
recompiling kernels again, I can probably turn around tests a lot faster.
Many thanks,
Alex
On 03/03/2008, Odysseus Flappington <[email protected]> wrote:
>
> Ok,
>
> I passed reset=1 to hci_usb by adding the following line to
> /etc/modprobe.d/options:
>
> options hci_usb reset=1
>
> and that's fixed the problem!
>
> Wasn't sure about my lsusb output, didn't seem to show very much, so
> here's my lsusb -v output for my bluetooth device:
>
> Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 224 Wireless
> bDeviceSubClass 1 Radio Frequency
> bDeviceProtocol 1 Bluetooth
> bMaxPacketSize0 64
> idVendor 0x0a12 Cambridge Silicon Radio, Ltd
> idProduct 0x0001 Bluetooth Dongle (HCI mode)
> bcdDevice 31.64
> iManufacturer 0
> iProduct 0
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 177
> bNumInterfaces 2
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xc0
> Self Powered
> MaxPower 0mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0010 1x 16 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 1
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0009 1x 9 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0009 1x 9 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 2
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0011 1x 17 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0011 1x 17 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 3
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0019 1x 25 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0019 1x 25 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 4
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0021 1x 33 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0021 1x 33 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 5
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0031 1x 49 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0031 1x 49 bytes
> bInterval 1
> Device Status: 0x0001
> Self Powered
>
> Thanks,
> Alex
>
>
>
>
> On 03/03/2008, Odysseus Flappington <[email protected]> wrote:
> > Hi Dave,
> >
> > Thanks for the help. I can probably get a recompile of my kernel done
> > by the end of the weekend, maybe end of week, if it'll help.
> >
> > In the meantime, I'll try loading the bluetooth module with reset=1
> > and get the lsusb output to you tonight when I get home from work.
> >
> > Thanks,
> > Alex (Jackflap)
> >
> >
> > On 03/03/2008, Dave Young <[email protected]> wrote:
> > > On Mon, Mar 3, 2008 at 9:21 AM, Dave Young <[email protected]>
> wrote:
> > > > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > > > <[email protected]> wrote:
> > > >
> > > >
> > > > > So, it turns out that in order for any external usb bluetooth
> adapters
> > > > > to re-connect to paired input devices on reboot, you need to
> issue an
> > > > > 'hciconfig hci0 reset' command after rebooting in order to
> reconnect.
> > > > >
> > > > > More info can be found in bug #133690 on Launchpad
> > > > > (
> https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > > > >
> > > > > This bug isn't Ubuntu-specific since I have reproduced in
> Fedora 8, so
> > > > > I'm posting here.
> > > > >
> > > > > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth
> in
> > > > > source would solve this bug. Is this a reasonable solution?
> > > > >
> > > > > What is required in order to get a fix implemented?
> > >
> > >
> > > Sorry for previous blank reply.
> > >
> > > For your problem, if you don't want to patch kernel you can also try
> > > load the bluetooth module with parameter "reset=1"
> > >
> > > Could you send the lsusb output?
> > >
> > > Regards
> > >
> > > dave
> > >
> > >
>
> > > -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > _______________________________________________
> > > Bluez-users mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/bluez-users
> > >
> >
>
Ok,
I passed reset=1 to hci_usb by adding the following line to
/etc/modprobe.d/options:
options hci_usb reset=1
and that's fixed the problem!
Wasn't sure about my lsusb output, didn't seem to show very much, so
here's my lsusb -v output for my bluetooth device:
Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a12 Cambridge Silicon Radio, Ltd
idProduct 0x0001 Bluetooth Dongle (HCI mode)
bcdDevice 31.64
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 177
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Device Status: 0x0001
Self Powered
Thanks,
Alex
On 03/03/2008, Odysseus Flappington <[email protected]> wrote:
> Hi Dave,
>
> Thanks for the help. I can probably get a recompile of my kernel done
> by the end of the weekend, maybe end of week, if it'll help.
>
> In the meantime, I'll try loading the bluetooth module with reset=1
> and get the lsusb output to you tonight when I get home from work.
>
> Thanks,
> Alex (Jackflap)
>
>
> On 03/03/2008, Dave Young <[email protected]> wrote:
> > On Mon, Mar 3, 2008 at 9:21 AM, Dave Young <[email protected]> wrote:
> > > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > > <[email protected]> wrote:
> > >
> > >
> > > > So, it turns out that in order for any external usb bluetooth adapters
> > > > to re-connect to paired input devices on reboot, you need to issue an
> > > > 'hciconfig hci0 reset' command after rebooting in order to reconnect.
> > > >
> > > > More info can be found in bug #133690 on Launchpad
> > > > (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > > >
> > > > This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
> > > > I'm posting here.
> > > >
> > > > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
> > > > source would solve this bug. Is this a reasonable solution?
> > > >
> > > > What is required in order to get a fix implemented?
> >
> >
> > Sorry for previous blank reply.
> >
> > For your problem, if you don't want to patch kernel you can also try
> > load the bluetooth module with parameter "reset=1"
> >
> > Could you send the lsusb output?
> >
> > Regards
> >
> > dave
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Bluez-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-users
> >
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Dave,
Thanks for the help. I can probably get a recompile of my kernel done
by the end of the weekend, maybe end of week, if it'll help.
In the meantime, I'll try loading the bluetooth module with reset=1
and get the lsusb output to you tonight when I get home from work.
Thanks,
Alex (Jackflap)
On 03/03/2008, Dave Young <[email protected]> wrote:
> On Mon, Mar 3, 2008 at 9:21 AM, Dave Young <[email protected]> wrote:
> > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > <[email protected]> wrote:
> >
> >
> > > So, it turns out that in order for any external usb bluetooth adapters
> > > to re-connect to paired input devices on reboot, you need to issue an
> > > 'hciconfig hci0 reset' command after rebooting in order to reconnect.
> > >
> > > More info can be found in bug #133690 on Launchpad
> > > (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > >
> > > This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
> > > I'm posting here.
> > >
> > > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
> > > source would solve this bug. Is this a reasonable solution?
> > >
> > > What is required in order to get a fix implemented?
>
>
> Sorry for previous blank reply.
>
> For your problem, if you don't want to patch kernel you can also try
> load the bluetooth module with parameter "reset=1"
>
> Could you send the lsusb output?
>
> Regards
>
> dave
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
<[email protected]> wrote:
> So, it turns out that in order for any external usb bluetooth adapters
> to re-connect to paired input devices on reboot, you need to issue an
> 'hciconfig hci0 reset' command after rebooting in order to reconnect.
>
> More info can be found in bug #133690 on Launchpad
> (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
>
> This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
> I'm posting here.
>
> Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
> source would solve this bug. Is this a reasonable solution?
>
> What is required in order to get a fix implemented?
>
> Thanks,
> Alex (Jackflap/OdyTheDog)
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Mon, Mar 3, 2008 at 9:21 AM, Dave Young <[email protected]> wrote:
> On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> <[email protected]> wrote:
>
>
> > So, it turns out that in order for any external usb bluetooth adapters
> > to re-connect to paired input devices on reboot, you need to issue an
> > 'hciconfig hci0 reset' command after rebooting in order to reconnect.
> >
> > More info can be found in bug #133690 on Launchpad
> > (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> >
> > This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
> > I'm posting here.
> >
> > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
> > source would solve this bug. Is this a reasonable solution?
> >
> > What is required in order to get a fix implemented?
Sorry for previous blank reply.
For your problem, if you don't want to patch kernel you can also try
load the bluetooth module with parameter "reset=1"
Could you send the lsusb output?
Regards
dave
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Tue, Jul 22, 2008 at 4:53 AM, Odysseus Flappington
<[email protected]> wrote:
> Hi Marcel,
>
> I keep reading kernel developers saying that we should be persistent, so I'm
> following up on this, has any progress been made regarding the following
> issue?
Hi, I ever tried to implement it, but I'm occupied by other projects.
The key problem is that bluetooth drivers can only set the flags
during the probe now, but we need to send bluetooth commands to get
the revision.
>
> This one's a bit of an old one, regarding bluetooth adapters after a certain
> build number to require a reset command every boot before they'll work
> properly, I've attached a previous discussion as a reminder to the issue.
>
> If there's anything I can do (non-code writing though), please let me know,
> I'll be glad to help get this sorted.
>
> Alexander Deriziotis
>
> On 26/03/2008, Marcel Holtmann <[email protected]> wrote:
>>
>> Hi Dave,
>>
>>>> I've been looking around to see if I could figure out the build id where
>>>> the
>>>> dongles started shipping with the correct HCI_Reset. I think I may have
>>>> found something.
>>>
>>> Thanks a lot.
>>>
>>> Marcel, I think it's what you want. I would like to file a patch.
>>
>> yes, but I already got it via CSR internals. They have always been helpful
>> when it comes to BlueZ. CSR is an open source friendly company. I didn't
>> have time to actually produce that patch since we have to turn the whole
>> logic around.
>>
>> Regards
>>
>> Marcel
>>
>
>
--
Regards
dave
Hi Marcel,
I keep reading kernel developers saying that we should be persistent, so I'm
following up on this, has any progress been made regarding the following
issue?
This one's a bit of an old one, regarding bluetooth adapters after a certain
build number to require a reset command every boot before they'll work
properly, I've attached a previous discussion as a reminder to the issue.
If there's anything I can do (non-code writing though), please let me know,
I'll be glad to help get this sorted.
Alexander Deriziotis
On 26/03/2008, Marcel Holtmann <[email protected]> wrote:
>
> Hi Dave,
>
> I've been looking around to see if I could figure out the build id where
>>> the
>>> dongles started shipping with the correct HCI_Reset. I think I may have
>>> found something.
>>>
>>
>> Thanks a lot.
>>
>> Marcel, I think it's what you want. I would like to file a patch.
>>
>
> yes, but I already got it via CSR internals. They have always been helpful
> when it comes to BlueZ. CSR is an open source friendly company. I didn't
> have time to actually produce that patch since we have to turn the whole
> logic around.
>
> Regards
>
> Marcel
>
>