summaryrefslogtreecommitdiff
path: root/examples/opiebluez/config.in
authormickeyl <mickeyl>2005-07-15 19:50:35 (UTC)
committer mickeyl <mickeyl>2005-07-15 19:50:35 (UTC)
commit637271751ea243456c9c00319e59675f47dcc022 (patch) (side-by-side diff)
treeb17c488a688da6aa004991206d1b2b0aae2f40c7 /examples/opiebluez/config.in
parent72224480ec012cf8d68608aea5a1b035f4d16895 (diff)
downloadopie-637271751ea243456c9c00319e59675f47dcc022.zip
opie-637271751ea243456c9c00319e59675f47dcc022.tar.gz
opie-637271751ea243456c9c00319e59675f47dcc022.tar.bz2
opiebluez: add scanning.
Ok, guys, everything until now was easy. It gets very ugly to go from here - even to just get the name of a remote device, you have to setup some filters on the bluez socket, fill in some random flags to generate a PDU that calls 'get name' and then afterwards poll until the result comes in. Nasty :/ The BlueZ kernel interface seems to be very badly (if at all) documented. All people are assuming that you use libbluetooth to talk to that stack. However since libbluetooth is GPL, we can't do that :/ Guess, we are stuck here until someone finds time and/or motivation to look into that and create some easy-to-understand examples for how to talk directly to the BlueZ kernel interface.
Diffstat (limited to 'examples/opiebluez/config.in') (more/less context) (ignore whitespace changes)
0 files changed, 0 insertions, 0 deletions