Comment 22 for bug 268877

I'm wondering if your device needs a reset quirk and that's why HCI mode
isn't working with it.

Try creating a file /etc/modprobe.d/btusb with the following contents:

options btusb reset=1

Unplug the dongle, rmmod btusb plug it in again, and then get the device
back into HCI mode using hid2hci again. See if you are able to pair in the
UI now. If so, that requires an extra kernel quirk.

On Sun, Nov 16, 2008 at 07:40, Martin G Miller <email address hidden>wrote:

> Chow Loong Jin wrote:
> "1. Set HID2HCI_ENABLED=0 in /etc/default/bluetooth, and then manually
> run
> PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions
> /usr/lib/pm-utils/sleep.d/48hid2hci
>
> This results in no error message."
>
> This would not give an error message as it has just switched the device
> from HID to HCI mode.
>
> Then, if you do:
> "2. Set HID2HCI_ENABLED=1 in /etc/default/bluetooth, and the manually run
> PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions
> /usr/lib/pm-utils/sleep.d/48hid2hci
>
> This results in the error message "No devices in HID mode found"."
>
> This confirms that the HCI mode is still enabled from the previous
> command, which should not be the case.
>
>
> Is there any way to determine the status of the device before and after
> issuing the commands? That way you could boot with HID2HCI_ENABLED=0 set
> and test to see that it is in fact in HID mode. Then run the command:
> "PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions
> /usr/lib/pm-utils/sleep.d/48hid2hci"
> and again test to see what mode the device is in. I believe it is changing
> to HCI even though it shouldn't be.
>
> --
> bluetooth service does not restart after a suspend to ram
> https://bugs.launchpad.net/bugs/268877
> You received this bug notification because you are a bug assignee.
>

--
Mario Limonciello
<email address hidden>