Hi Matthieu,
with HCI_RAW, application can bypass the bluez stack and send raw
stuff
to dongle.
This seems not possible anymore with btusb because it uses
"hdev->conn_hash" to check if ACLDATA/SCODATA should be send/
received.
These checks make the HCI_RAW mode a bit useless (ie not working
for acl
and sco).
Can we make the HCI_RAW work like before with acl and sco data ?
For example we can ignore theses check in HCI_RAW mode and send a
notify
event when we turn on/off HCI_RAW mode.
we could, but that will cost a lot of CPU power. The SCO data packets
are just not an option here. Also without a full blown Bluetooth
stack,
you don't know with alternate setting to use.
But hci_usb wasn't doing that (ie always use max alternate setting +
submit sco/alc urb), and I wasn't under the impression that it costs
too
much CPU power.
there is not concept of max alternate setting. You just have to use
the right one and powertop showed the difference in power consumption.
So this is a little bit
pointless here and before just worked by pure luck. Why do you want
this
support in the first place?
This can be helpful to test userspace bluetooth stack or do some
fuzzing.
I seriously couldn't care less about any userspace Bluetooth stack.
Also why is RAW not working for ACL packets. It actually should work
if the adapter is brought up properly and switched to RUNNING state.
SCO will not be possible without magic.
What is the goal of HCI_RAW ?
With btusb it seems useless in the tx path.
It is mainly used for commands and events and for that it works
perfectly fine.
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
