Marcel, Firstly, my intention has not been to be rude etc - I really dont know what top posting is. But, if I have posted something that has offended anyone - please excuse that and as it was not intentional - only trying to figure out the best approach to our issue. But, from your comments below I do see that this connection hookup needs to happen in the kernel. And I shall explore the RAW mode - if it can work for us. But thanks, Shreesh --- On Mon, 7/19/10, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > From: Marcel Holtmann <marcel@xxxxxxxxxxxx> > Subject: Re: [HCI Events] Connection Event Processing > To: "Shreesh Holla" <hshreesh@xxxxxxxxx> > Cc: "Johan Hedberg" <johan.hedberg@xxxxxxxxx>, linux-bluetooth@xxxxxxxxxxxxxxx > Date: Monday, July 19, 2010, 11:10 AM > Hi Shressh, > > first of all, stop top posting. This is rude and we will > ignore further > emails from you if you keep doing this. > > > ugh! I see the issues now. As you said - neither of > those approaches would work for me since we need to > conditionally handle the incoming connection really. > > > > Wonder if there is some design reason this was done > i.e. hardcoding it in hci_event.c? Or is it for performance > reasons? Any plans on supporting this in > the future? > > > > What I'm considering is plugging in our own handler > inside hci_event.c. > > > > We can do this inside some custom hardware - but we > are trying to avoid this since we already have other custom > hardware we need to do in our device which is a wireless > access control system. > > I really don't know what you are trying to achieve here, > but you might > better not use BlueZ if you wanna do something like this. > The connection > handling needs to be done in the kernel and it does this > the right way. > > Use your own Bluetooth stack or switch the device into RAW > mode and > program it as you like. As Johan mentioned RAW devices are > left alone by > the kernel. > > Regards > > Marcel > > > -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
