summaryrefslogtreecommitdiff
path: root/examples/opieui/okeyconfigwidget/keyconfig.pro
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/opieui/okeyconfigwidget/keyconfig.pro
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/opieui/okeyconfigwidget/keyconfig.pro') (more/less context) (ignore whitespace changes)
0 files changed, 0 insertions, 0 deletions