Hi Suraj, > > this looks like the total wrong approach to me. This needs to be done between mac80211 and Bluetooth subsystems in the kernel directly. Going through userspace for this is a pretty bad idea. > > > Especially if you wanna listen on D-Bus events from bluetoothd and then run another process to then execute nl80211 commands looks like total overhead at no gain. Not to talk about potential latency > effects that might be counterproductive. > > > What you really want is a way to mark A2DP channels for streaming from userspace as streaming/realtime/priority so the Bluetooth subsystem knows on what to do with it and that way can also tell > > mac80211 correctly about coex settings. > > > We are already settings flushable flags for A2DP streaming channels and there is work ongoing for SO_PRIORITY support with L2CAP sockets. > > More than the A2DP connection, it would be more useful to find out when A2DP start/stop streaming so that we can know when to reallocate resource to Bluetooth. Is it possible to tap this information out of the Bluetooth core? > Also, can you suggest a way to get A2DP streaming status, inquiry status, and SCO and ACL role without a hack in the Bluetooth subsystem? the inquiry status is tracked by the Linux kernel since ever. Same goes for ACL and SCO status. The kernel keeps track over almost everything on the HCI level and will do proper cleanup afterwards. Doing this in userspace will not work out. And it is also racy. Especially in the future bluetoothd will be tracking less and less information. The new management interface will hide almost every single state from bluetoothd where the kernel is doing the job anyway and can do a way better job in the first place. This is also leads to power consumption advantages since bluetoothd does not need to be woken up that often anyway. And in addition the kernel has not deal with the extra HCI filter handling. The only thing that you mentioned here is A2DP streaming. And by the nature of the A2DP protocol, you do establish a second L2CAP channel that is just used for streaming. That channel is also only present if you are streaming right now. If not streaming is going on, it will be disconnected. So it is pretty easy to have bluetoothd tag such a channel with proper SO_PRIORITY (once we have that code merged upstream) and then the Bluetooth subsystem knows when A2DP streaming or any high priority/realtime data is transferred over Bluetooth. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
