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

[Luiz Augusto von Dentz]

Hi Zijun,

On Fri, Sep 4, 2026 at 10:12 AM Zijun Hu <zijun.hu@xxxxxxxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxxxx
> 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.

I guess that is up to us to define, HCI_CHANNEL_VENDOR could just
serialize everything, so it supersed HCI_CHANNEL_USER which only took
care of known packet types. That said I don't think it would be an API
break if we decide HCI_CHANNEL_USER carry everything, but since you
are trying to introduce BT_RECV_VENDOR_PKT there maybe a reason not to
enable everything to be send over HCI_CHANNEL_USER.

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

Would have to switch to use HCI_CHANNEL_VENDOR, just as it would have
to use BT_RECV_VENDOR_PKT, but then again Id rather do it on
HCI_CHANNEL_USER if we don't consider it an API breakage.

-- 
Luiz Augusto von Dentz