author | mickeyl <mickeyl> | 2005-07-15 19:50:35 (UTC) |
---|---|---|
committer | mickeyl <mickeyl> | 2005-07-15 19:50:35 (UTC) |
commit | 637271751ea243456c9c00319e59675f47dcc022 (patch) (side-by-side diff) | |
tree | b17c488a688da6aa004991206d1b2b0aae2f40c7 /examples/opiebluez/config.in | |
parent | 72224480ec012cf8d68608aea5a1b035f4d16895 (diff) | |
download | opie-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