View Single Post
Posts: 77 | Thanked: 63 times | Joined on Sep 2009
#150
Originally Posted by Ulysses View Post
No, nobody seems to know where the problem lies. The only people who succeeded in using their bluetooth keyboard with firmware PR1.1 have upgraded their firmware OTA and not by reflashing via USB. It looks like this is the only scenario to get the bluetooth keyboards working in firmware PR1.1.

What difference in terms of the bluetooth stack and configuration files occur with a firmware upgrade OTA vs USB?
If we can pin this down, maybe we can find and fix the problem.
Yes, but there are people who have done OTA updates but who are not able to get bluetooth keyboards to connect. One might think that it requires having previously connected prior to upgrade. But there are people who have who are not able to get bluetooth keyboards to connect and people who haven't who are.

Here is my table. It is not updated with the latest posts over the past few days.
| keyboard works OTA prior spp
-------------------------------------------------
filogen | SU-8W yes yes yes no
olighak | palm no yes/no no ?
woody14619 | 3245WW no yes no ?
JoHnY | freepro no ? no ?
jtkim | iGoStow no ? no ?
cardiff-blues | iGoStow no ? no false
dnastase | iGoStow yes yes yes ?
rabilancia | iGoStow no yes no false
poser | iGoStow yes yes yes ?
beel | iGoStow no yes yes ?
qobi | iGoStow yes 44 yes no
lwalker | SU-8W yes yes no false

(Sorry, it displays nicer in a fixed width font.)
spp means that gconftool lists strong_pin_pairing.

I can't find any simple correlation that explains what is going on. I also don't see any simple correlation in the output of gconftool on /system/bluetooth. And I also don't see any simple correlation in the files in /var/lib/bluetooth.

I think we need to find out which process is issuing the HCI disconnect command.
 

The Following User Says Thank You to qobi For This Useful Post: