Re: [PATCH BlueZ v3 3/4] doc/hci-protocol: Add BT_RECV_VENDOR_PKT socket option for HCI_CHANNEL_USER

[Zijun Hu <zijun.hu@oss.qualcomm.com>]

On 9/3/2026 11:16 PM, Luiz Augusto von Dentz wrote:
>> +BT_RECV_VENDOR_PKT (since Linux 7.3)
>> +------------------------------------
>> +
>> +Control receiving vendor packets, requires hci_channel to be set to
>> +HCI_CHANNEL_USER.
>> +
>> +Default is disabled.
>> +
>> +Example:
>> +
>> +.. code-block::
>> +
>> +    uint32_t enable = 1;
>> +    int err;
>> +
>> +    err = setsockopt(fd, SOL_BLUETOOTH, BT_RECV_VENDOR_PKT, &enable,
>> +                     sizeof(enable));
> I don't think we ever applied this socket option to the kernel,
> though. Anyway, I think we are better off adding another channel,

Hi Luiz,

Good catch — that socket option is introduced by the below kernel patch, which is still under review:
https://lore.kernel.org/all/20260830-btusb_qcc2072-v2-2-5c0e0c9dd98b@oss.qualcomm.com
I'll drop this userspace patch in v4 temporarily to avoid confusion.

> e.g., HCI_CHANNEL_VENDOR which can then allow packet type rather than
> just the known ones.

For this new proposal:

1) Is my below understanding correct?
- H/W wire: BT and vendor packets are serialized together.
- Kernel: splits BT and vendor packets to their own channels.
- Userspace: merges both channels on RX, sends to the corresponding channel on TX.

2) How would a HCI_CHANNEL_USER user, e.g. Chromebook, send and receive vendor packets?