summaryrefslogtreecommitdiff
path: root/libopie2/opiebluez
AgeCommit message (Collapse)AuthorFilesLines
2007-04-20removed unused member functionerik2-17/+0
2005-07-15opiebluez: add scanning.mickeyl2-11/+146
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.
2005-07-14- add device classmickeyl2-1/+96
- first bits at inquiry
2005-07-14- add bool OBluetoothInterface::setUp( bool )mickeyl2-7/+46
- add void OBluetoothInterface::isUp() const
2005-07-11gather HCI mac address directlymickeyl1-5/+12
2005-07-11stupid typomickeyl1-2/+2
2005-07-11don't link to libbluez since this would taint LGPLmickeyl3-15/+6
2005-07-10yank infrared stuffmickeyl1-3/+1
2005-07-10s/opieshower/opiebluez/, infrared better goes through opienetmickeyl5-0/+344
there's the need of a connection abstraction library which bases on opienet and opiebluez in the future. It's for discussion if it makes sense in Opie 1.x