Hi Marcel, On Thu, Jan 17, 2013 at 7:02 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hello, > > so I have been looking into how we handle LE scanning in central role a > little bit. And I am not really happy with what we do right now. Instead > of just adding new profiles, we need to take one step back and get the > basics right. > > The one thing that I stumbled about is that we are trying to use the > Start Discovery management command to scan for connectable device that > we are paired with. And it is all triggered by bluetoothd. It tries to > get this done right, but fails badly at it. Trying to do this ends up in > a convoluted solution that will just break down eventually. > > So Start Discovery and Stop Discovery management commands are for > finding new devices. They are for finding devices that we want to pair > with. They are not for checking if a paired device is in range or > signals connection requests to us. It is called discovery for a reason. > > It might have looked like a good idea to just re-use these two commands, > but what I am seeing when working with multiple paired LE devices is > just a big mess. The amount of code that is needed to keep track of > states between running D-Bus commands for discovery, discovery triggered > management commands, scanning triggered management commands etc. is not > a good idea. > > I am failing to understand why we tried to solve this inside bluetoothd > and not just let the kernel take full control here. We are loading the > list of paired LE devices at controller power on anyway. So the kernel > does know about our paired devices. It can control sensible scan > intervals and also sync a device discovery with scanning for connection > triggers from know remote devices. It also can sensible disconnect on > idle and scan for other devices that requests connections. We are working on moving this connection management into kernel space and we should start sending RFCs soon. > What I think we should have is a management command that allows us to > load device specific scan parameter configuration into the kernel. And > then the kernel will execute this on our behalf. We need to decouple the > commands for device discovery from the commands that scan for known > devices. Once we have the connection management working properly we can working on this new management command to setup the scan parameters. Regards, Andre -- 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
