On Mon, Feb 16, 2009 at 6:37 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hi Nick, > >> We have come across a headset (HTC M200) that does not send out a >> sniff mode request when in idle. Our Bluez based stack also does not >> send a sniff mode request, so we sit in a higher power state that >> necessary. (20mA instead of 1mA). >> >> Some quick research suggests that we would need to send HCI Sniff Mode >> Command (OCF 0x03) to initiate sniff mode, and that this is not yet >> done in the Bluez code base. We do send the HCI Write Default Link >> Policy Settings Command but, as I understand, this is only applied to >> incoming sniff mode requests by the link manager and will not initiate >> an LMP sniff request. >> >> We compared to two non-bluez mobile stacks and found the other phones >> did automatically initiate an LMP sniff mode request. >> >> Is there a reason for Bluez not automatically sending HCI Sniff Mode >> Command, or is it just a case of no-one getting around to hitting the >> problem / implementing a fix? Or have I missed something simple? > > actually BlueZ has automatically sniff mode since a long-long time ago. > It also would do sniff-subrate in case of Bluetooth 2.1 modules. However > you have to enable it since by default it is off. > > Check /sys/class/bluetooth/hci0 for idle_timeout, sniff_max_interval and > sniff_min_interval. Use idle_timeout and the others to control the > interval values. > Ah, thank you! I was looking on the userspace side. Nick -- 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
