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 <marcel@xxxxxxxxxxxx> 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 > > -- 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
