Hi all,
After the patch was added to btusb.c to allow ACL packets to be
sent/received in HCI_RAW mode I was wondering what would be involved
in allowing raw SCO packets to be sent/received?
This would be a useful feature for someone like me who works with
Bluetooth firmware at this level on a daily basis.
However, I can understand there may be some limitations.
Is this something that can be realistically done?
Thanks.
Thanks for getting back to me so quickly Marcel.
Yes that sounds logical. I think it sounds like we are wanting connect
using USB another way in this case rather than trying to re-engineer
BlueZ to work in a way which it wasn't intended.
Cheers.
On Sat, Jan 26, 2013 at 3:23 AM, Marcel Holtmann <[email protected]> wrote:
> Hi,
>
>> After the patch was added to btusb.c to allow ACL packets to be
>> sent/received in HCI_RAW mode I was wondering what would be involved
>> in allowing raw SCO packets to be sent/received?
>>
>> This would be a useful feature for someone like me who works with
>> Bluetooth firmware at this level on a daily basis.
>>
>> However, I can understand there may be some limitations.
>>
>> Is this something that can be realistically done?
>
> I do not see a way to do this properly. The main problem here is the USB
> transport. It requires special settings and active URBs.
>
> Once you switch it to HCI_RAW mode, the Bluetooth host stack does no
> command/event tracking and with that no connection tracking anymore.
> This means it can not inform the driver about any changes. And for USB
> it is required to change its alternate setting based on the number of
> connections and start ISOC URBs. Having ISOC URBs submitted all the time
> is not feasible either since that consumes way too much power.
>
> For other transports like UART, the SCO packets in HCI_RAW mode should
> still work.
>
> Regards
>
> Marcel
>
>
Hi,
> After the patch was added to btusb.c to allow ACL packets to be
> sent/received in HCI_RAW mode I was wondering what would be involved
> in allowing raw SCO packets to be sent/received?
>
> This would be a useful feature for someone like me who works with
> Bluetooth firmware at this level on a daily basis.
>
> However, I can understand there may be some limitations.
>
> Is this something that can be realistically done?
I do not see a way to do this properly. The main problem here is the USB
transport. It requires special settings and active URBs.
Once you switch it to HCI_RAW mode, the Bluetooth host stack does no
command/event tracking and with that no connection tracking anymore.
This means it can not inform the driver about any changes. And for USB
it is required to change its alternate setting based on the number of
connections and start ISOC URBs. Having ISOC URBs submitted all the time
is not feasible either since that consumes way too much power.
For other transports like UART, the SCO packets in HCI_RAW mode should
still work.
Regards
Marcel