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. 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. Seems also we should actually implement the scan parameters service as a core feature of bluetoothd and not just a plugin. For me it looks like it essential that we allow different behavior for different devices. 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
