November 2005 - Bluetooth-dev

Re: Questions about Run Loops
by Joseph Kelly 17 Nov '05

17 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Questions about Run Loops
by Geoffrey Schmit 17 Nov '05

17 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com On 16/11/2005 at 3:14 PM -0800, Joseph Kelly <joeman(a)mac.com> wrote: > It is absolutely not advisable to use a dedicated worker thread to > call the Bluetooth api's. It's unreliable, and you won't even be able > to use IOBluetoothUI.framework. I've ensured that my framework functions that end up calling into the IOBluetoothUI framework are always called on the application's UI thread. If I ensure this, what problems would I encounter if I create a thread that is responsible for calling into the IOBluetooth framework and have my other framework functions pass messages to this thread? If I create a thread using pthreads, will that thread have an associated run loop or do I have to create one explicitly? The documentation I've read was not clear on this point. Thanks for any insight! geoff _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Questions about Run Loops
by Joseph Kelly 16 Nov '05

16 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com But here are some hints: joe On Nov 16, 2005, at 2:48 PM, Geoffrey Schmit wrote: CFRunLoopRunInMode( kCFRunLoopDefaultMode, timeout, false ); CFRunLoopRef runLoopRef = CFRunLoopGetCurrent(); CFRunLoopStop( runLoopRef ); which returns control to the read method which then returns the data. Is this a reasonable approach? Any advice would be appreciated. Thanks! geoff -- Geoffrey Schmit Senior Software Engineer National Instruments geoffrey.schmit(a)ni.com www.ni.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/joeman%40mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… Oh would that Apple have developed a Bluetooth framework that was thread-safe! It is absolutely not advisable to use a dedicated worker thread to call the Bluetooth api's. It's unreliable, and you won't even be able to use IOBluetoothUI.framework. I've developed a program model in which the main thread performs Bluetooth operations at the behest of other threads which post requests in a queue which the main thread reads. The api I present to the client thread specifies that the operation be synchronous, thus my request object contains a conditional mutex which blocks until the main thread is done with the operation. Instead of having the main thread busy poll the queue (the queue itself is protected by a mutex), I set up a run loop source on the main thread which is triggered by the client thread when it adds the request object. The main thread wakes up, takes a request off the queue, and performs the indicated operation using the async Bluetooth apis whenever possible -- this lets the main thread handle multiple requests at a given timeframe. It got tricky when I tried to implement the requirement that the main thread could also call the api and expect to block. The workaround is to "pretend" to block, but not actually use the conditional mutex in the request object. Instead, add the command to the queue which triggers the source, and call CFRunLoopRun(), and in the completion routine, which would normally set the "completed" condition on the mutex, call CFRunLoopStop(CFRunLoopGetCurrent()). Hopefully you won't have to support CFM applications, but if that's the case, I've got more hints. I'm creating a framework that handles interactions with a Bluetooth device. While not too familiar with CFRunLoops, I've learned that they are integral to Bluetooth on Mac OS X. For example, in order for my RFCOMM event listener callback to be invoked, I need to ensure that the run loop is running. My framework presents a synchronous read method, so I handle this by invoking: in the read method. In my RFCOMM event listener callback, I exit the run loop with: I've also read that all interactions with the Bluetooth frameworks must be on the same thread. However, my framework is designed to be multi-thread safe and to be called by the application with a variety of threads. As expected, if the application invokes my framework with a variety of threads, the above approach doesn't work; the RFCOMM event listener callback is not invoked and the CFRunLoopRunInMode function returns immediately and reports that the run loop has no source or timers. If I restrict the application such that it only calls my framework on the applications UI thread, everything appears to work. However, this has some undesirable side effects. If I restrict the application to always calling my framework with the same thread, but have that thread not be the same thread that the application uses for UI, is this sufficient? Alternatively, if I want to continue to allow the application to invoke my framework with a variety of threads, can I create a single thread in my framework that manages all Bluetooth communication and then dispatch messages between this dedicated thread and the application's threads? Can this dedicated thread be a normal "naked" pthread? This email sent to joeman(a)mac.com This email sent to site_archiver(a)lists.apple.com

1 0

Questions about Run Loops
by Geoffrey Schmit 16 Nov '05

16 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com I'm creating a framework that handles interactions with a Bluetooth device. While not too familiar with CFRunLoops, I've learned that they are integral to Bluetooth on Mac OS X. For example, in order for my RFCOMM event listener callback to be invoked, I need to ensure that the run loop is running. My framework presents a synchronous read method, so I handle this by invoking: CFRunLoopRunInMode( kCFRunLoopDefaultMode, timeout, false ); in the read method. In my RFCOMM event listener callback, I exit the run loop with: CFRunLoopRef runLoopRef = CFRunLoopGetCurrent(); CFRunLoopStop( runLoopRef ); which returns control to the read method which then returns the data. Is this a reasonable approach? I've also read that all interactions with the Bluetooth frameworks must be on the same thread. However, my framework is designed to be multi-thread safe and to be called by the application with a variety of threads. As expected, if the application invokes my framework with a variety of threads, the above approach doesn't work; the RFCOMM event listener callback is not invoked and the CFRunLoopRunInMode function returns immediately and reports that the run loop has no source or timers. If I restrict the application such that it only calls my framework on the applications UI thread, everything appears to work. However, this has some undesirable side effects. If I restrict the application to always calling my framework with the same thread, but have that thread not be the same thread that the application uses for UI, is this sufficient? Alternatively, if I want to continue to allow the application to invoke my framework with a variety of threads, can I create a single thread in my framework that manages all Bluetooth communication and then dispatch messages between this dedicated thread and the application's threads? Can this dedicated thread be a normal "naked" pthread? Any advice would be appreciated. Thanks! geoff -- Geoffrey Schmit Senior Software Engineer National Instruments geoffrey.schmit(a)ni.com www.ni.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Bluetooth-dev Digest, Vol 2, Issue 85
by Esa Karjalainen 14 Nov '05

14 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com User-agent: Mutt/1.4.1i Ouch. Thanks for the reply, but that's no good for me. I need to be able to send and receive RFCOMM packets hand-built over L2CAP. The ability to see the bytes directly is sort of the point, here. Is there any way to circumvent this issue? Thanks, - Esa > > Message: 2 > Date: Fri, 11 Nov 2005 08:45:59 -0800 > From: Marco Pontil <mpontil(a)apple.com> > Subject: Re: Help! Sending RFCOMM packet over L2CAP fails. > To: Esa Karjalainen <ekarjala(a)codenomicon.com> > Cc: bluetooth-dev(a)lists.apple.com > Message-ID: <2DA6944C-B72B-470B-B39E-A60B54FA3524(a)apple.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > This happens because the Apple RFCOMM implementation matches > on the L2CAP channel with PSM 3 much before yours, and then makes > that L2CAP channel unavailable to anybody else (there can be only one > client). > > I would recommend you to use the Apple OBEX implementation, aside > of the fact that it would workaround this specific issue it will save > you a > lot of work, it has really easy to use apis, and has been extensively > tested. > > Should you decide to use your own obex, just build the connection over > the RFCOMM APIs instead than building your own RFCOMM stack. > > ... Marco > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Help! Sending RFCOMM packet over L2CAP fails.
by Marco Pontil 11 Nov '05

11 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Should you decide to use your own obex, just build the connection over the RFCOMM APIs instead than building your own RFCOMM stack. ... Marco On Nov 11, 2005, at 3:54 AM, Esa Karjalainen wrote: Greetings. I've been working on an application, which builds an RFCOMM (OBEX) packet directly on top of L2Cap. The initialization of the connection seems to go okay. Interestingly enough, SDP works fine built over L2Cap. Another question: The class IOBluetoothHCIController. Does any documentation exist of that class? I'd very much like being able to access the HCI layer. Thanks, - Esa Here's the relevant parts of the code: [super connectionAttempt:true]; [localPool release]; return true; } --------------- Send: --------------- - (bool)send:(char*)data len:(int)len { IOReturn ioret; ioret = [l2capChannel writeSync:data length:len]; if (ioret != kIOReturnSuccess) { if (debug){ printf("RAWDEBUG: Write failed, ioret: 0x%x\n", ioret); } return false; } return true; } _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This happens because the Apple RFCOMM implementation matches on the L2CAP channel with PSM 3 much before yours, and then makes that L2CAP channel unavailable to anybody else (there can be only one client). I would recommend you to use the Apple OBEX implementation, aside of the fact that it would workaround this specific issue it will save you a lot of work, it has really easy to use apis, and has been extensively tested. However, Writing, i.e. writeSync always fails. it returns kIOReturnNotPrivileged. (0xe00002c1). Is L2Cap access somehow restricted, to disallow direct creation of RFCOMM connections? I ran the program as root. ( I sudo'ed the application, I sudo su'd, _then_ ran it - didn't help. ) Creating the connection: --------------- NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init]; IOBluetoothDevice* blue_device = [super getDevice:target]; if (blue_device == NULL) { if (debug) { printf("Unable to get the Bluetooth device\n"); } [super connectionAttempt:false]; [localPool release]; return false; } if ([blue_device openConnection] != kIOReturnSuccess) { if (debug) { printf("Failed to open a connection to the bluetooth device. \n"); } [super connectionAttempt:false]; [localPool release]; return false; } IOReturn ioret = [blue_device openL2CAPChannelSync:&l2capChannel withPSM:psm delegate:self]; [l2capChannel retain]; if (ioret != kIOReturnSuccess) { if (debug) { printf("Failed to open a L2CAP channel. \n"); } [super connectionAttempt:false]; [localPool release]; return false; } _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/mpontil% 40apple.com This email sent to mpontil(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Help! Sending RFCOMM packet over L2CAP fails.
by Esa Karjalainen 11 Nov '05

11 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com User-agent: Mutt/1.4.1i Greetings. I've been working on an application, which builds an RFCOMM (OBEX) packet directly on top of L2Cap. The initialization of the connection seems to go okay. However, Writing, i.e. writeSync always fails. it returns kIOReturnNotPrivileged. (0xe00002c1). Is L2Cap access somehow restricted, to disallow direct creation of RFCOMM connections? I ran the program as root. ( I sudo'ed the application, I sudo su'd, _then_ ran it - didn't help. ) Interestingly enough, SDP works fine built over L2Cap. Another question: The class IOBluetoothHCIController. Does any documentation exist of that class? I'd very much like being able to access the HCI layer. Thanks, - Esa Here's the relevant parts of the code: Creating the connection: --------------- NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init]; IOBluetoothDevice* blue_device = [super getDevice:target]; if (blue_device == NULL) { if (debug) { printf("Unable to get the Bluetooth device\n"); } [super connectionAttempt:false]; [localPool release]; return false; } if ([blue_device openConnection] != kIOReturnSuccess) { if (debug) { printf("Failed to open a connection to the bluetooth device.\n"); } [super connectionAttempt:false]; [localPool release]; return false; } IOReturn ioret = [blue_device openL2CAPChannelSync:&l2capChannel withPSM:psm delegate:self]; [l2capChannel retain]; if (ioret != kIOReturnSuccess) { if (debug) { printf("Failed to open a L2CAP channel. \n"); } [super connectionAttempt:false]; [localPool release]; return false; } [super connectionAttempt:true]; [localPool release]; return true; } --------------- Send: --------------- - (bool)send:(char*)data len:(int)len { IOReturn ioret; ioret = [l2capChannel writeSync:data length:len]; if (ioret != kIOReturnSuccess) { if (debug){ printf("RAWDEBUG: Write failed, ioret: 0x%x\n", ioret); } return false; } return true; } _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

JSR-82 on intel
by Moritz Gmelin 09 Nov '05

09 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Hi, Thanks Moritz _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… I have just compiled avetanaBluetooth (a jsr-82 implementation to use Bluetooth with java) to work with both PPC and Intel. Is there anybody on that list who could try this for me on an Intel- Mac and give me feedback ? Please send me an eMail or download an evaluation version from www.avetanabluetooth.com This email sent to site_archiver(a)lists.apple.com

1 0

Browse Device never worked with Nokia 6600
by Robert Nicholson 09 Nov '05

09 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com It never shows me anything in the table that shows the files. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… So, why is it that Browse Device never has work with the Nokia 6600 in Bluetooth File Exchange? This email sent to site_archiver(a)lists.apple.com

1 0

A2DP
by Lars Engel 08 Nov '05

08 Nov '05

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=OFEhmg+c0WDv4ONX5+gkiDP+HtrcgqPGWwy4JKmBYC/xTtbbqj49oCKCGQz0GLrC2WXJzazfpFsJOvm15/WGpTLAHxG3gUpZHpJLa92IRqBSOdsVh0tQEARQd0sbDG8BrLTXWKdLPfD31PhFoYhBcVDUDIk+Y7uy8OXoduCFNAk= Hi, /Lars _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… due to the more and more growing market and interest of bluetooth enabled stereo headsets I'd like to know if someone can tell about Apple's ambitions to support A2DP shortly?! Anyone who likes to discuss? This email sent to site_archiver(a)lists.apple.com

1 0