Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Jun 2011 10:56:40 -0500
From:      Brandon Gooch <jamesbrandongooch@gmail.com>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, freebsd-usb@freebsd.org
Subject:   Re: Broadcom BCM2046B1 in HCI mode?
Message-ID:  <BANLkTiki_awVOrjV1L3VjcriAHizf6JNag@mail.gmail.com>
In-Reply-To: <201106260651.17090.hselasky@c2i.net>
References:  <BANLkTikUpA-1NxFrrgXACzPoeocjjZXT=A@mail.gmail.com> <BANLkTikbiJtr6E7-G86tEX-PpTZn2R8u7A@mail.gmail.com> <BANLkTi=SqvgOHRpvQSAc%2BQ60wUHJFi7nDg@mail.gmail.com> <201106260651.17090.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 25, 2011 at 11:51 PM, Hans Petter Selasky <hselasky@c2i.net> wr=
ote:
> On Sunday 26 June 2011 05:46:35 Brandon Gooch wrote:
>> On Wed, Jun 22, 2011 at 11:17 AM, Maksim Yevmenkin
>>
>> <maksim.yevmenkin@gmail.com> wrote:
>> > On Tuesday, June 21, 2011, Brandon Gooch <jamesbrandongooch@gmail.com>
> wrote:
>> >> I have one of these in my notebook:
>> >>
>> >> uhub4: <Broadcom BCM2046B1, class 9/0, rev 2.00/1.00, addr 5> on usbu=
s0
>> >>
>> >> This is a bluetooth device in HID mode, but I'd like to switch it to
>> >> HCI mode. I found the following in rc.conf(5):
>> >>
>> >> =A0 =A0 =A0ubthidhci_enable
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(bool) If set to ``YES'', change t=
he USB Bluetooth
>> >> controller from HID mode to HCI mode. =A0You also need to specify the
>> >> location of USB Bluetooth controller with the
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ubthidhci_busnum and ubthidhci_add=
r variables.
>> >>
>> >> =A0 =A0 =A0ubthidhci_busnum
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Bus number where the USB Bluetooth=
 controller is
>> >> located. Check the output of usbconfig(8) on your system to find this
>> >> information.
>> >>
>> >> =A0 =A0 =A0ubthidhci_addr
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Bus address of the USB Bluetooth c=
ontroller. =A0Check the
>> >> out- put of usbconfig(8) on your system to find this information.
>> >>
>> >> So I added the appropriate directives to /etc/rc.conf, to no avail:
>> >>
>> >> ubthidhci_enable=3D"YES"
>> >> ubthidhci_busnum=3D"0"
>> >> ubthidhci_addr=3D"5"
>> >>
>> >> This basically calls usbconfig(8) at system start-up in the following
>> >> way:
>> >>
>> >> /usr/sbin/usbconfig -u 0 -a 5 do_request 0x40 0 0 0 0 > /dev/null 2>&=
1
>> >>
>> >> Running this command manually, I see this output:
>> >>
>> >> REQUEST =3D <ERROR>
>> >>
>> >> ...which I've read as potentially being OK, as the operation still ma=
y
>> >> have successfully completed -- it hasn't :(
>> >>
>> >> So, has anyone had any luck using this rc.conf(5) directive, or does
>> >> anyone on this list have a modified usbconfig(8) command that may hel=
p
>> >> me coax HCI from this device?
>> >
>> > Switching device between hid and hci modes is s something that is
>> > device / manufacturer specific. It could be that this particular
>> > device need different request or something like that. I would suggest
>> > to look at linux tool called hid2hci. It has support for different
>> > devices from different manufacturers.
>> >
>> > Thanks,
>> > Max
>>
>> That was an excellent suggestion, so I went and checked it out. In
>> fact, I verified that it indeed does the trick in a couple of recent
>> Linux distros.
>>
>> So can someone help me decipher the byte sequence I need to provide to
>> usbconfig(8)?
>>
>> The hid2hci utility has this function defined for dealing with the
>> device in question:
>>
>> http://git.kernel.org/?p=3Dbluetooth/bluez.git;a=3Dblob;f=3Dtools/hid2hc=
i.c;h=3D45a
>> 3a3db8b29411ee193e480f5ce8a82a40103d1;hb=3D7822123d08b176ef8b3e8aaecbc3c=
8ff25
>> a33483#l122
>>
>> static int usb_switch_dell(struct usb_dev_handle *dev, enum mode mode)
>> ...
>> =A0 =A0 =A0 =A0 char report[] =3D { 0x7f, 0x00, 0x00, 0x00 };
>> ...
>> =A0 =A0 =A0 =A0 report[1] =3D 0x13;
>> ....
>> =A0 =A0 =A0 =A0 err =3D usb_control_msg(dev,
>> =A0 =A0 =A0 =A0 =A0 =A0 USB_ENDPOINT_OUT | USB_TYPE_CLASS | USB_RECIP_IN=
TERFACE,
>> =A0 =A0 =A0 =A0 =A0 =A0 USB_REQ_SET_CONFIGURATION, 0x7f | (0x03 << 8), 0=
,
>> =A0 =A0 =A0 =A0 =A0 =A0 report, sizeof(report), 5000);
>> ...
>>
>> And according to:
>>
>> http://lxr.linux.no/#linux+v2.6.39/include/linux/usb.h#L1400
>>
>> usb_control_msg() is prototyped:
>>
>> extern int usb_control_msg(struct usb_device *dev, unsigned int pipe,
>> =A0 =A0 =A0 =A0 =A0__u8 request, __u8 requesttype, __u16 value, __u16 in=
dex,
>> =A0 =A0 =A0 =A0 =A0void *data, __u16 size, int timeout);
>>
>> ...and I'd like to know what this means in terms of the following
>> (from src/usr.sbin/usbconfig/usbconfig.c):
>>
>> libusb20_dev_request_sync(pdev, &opt->setup,
>> =A0 =A0 opt->buffer, &actlen, 5000 /* 5 seconds */ , 0))
>>
>> which is prototyped as:
>>
>> libusb20_dev_request_sync(struct libusb20_device *pdev,
>> =A0 =A0 =A0 =A0 =A0struct LIBUSB20_CONTROL_SETUP_DECODED *setup, void *d=
ata,
>> =A0 =A0 =A0 =A0 =A0uint16_t *pactlen, uint32_t timeout, uint8_t flags);
>>
>> I'm looking for something like the following:
>>
>> # usbconfig -u 0 -a 5 do_request 0x37f 0x13 0 0 0
>>
>> However, this isn't correct I know, but I could use some help sorting
>> it out -- any takers?
>>
>
> Hi,
>
> Try this:
>
> usbconfig -d X.Y do_request 0x21 0x09 0x037f 0x0000 0x04 0x7f 0x13 0x00 0=
x00
>
> --HPS

It worked, albeit after addressing the correct ugen(4) device:

dmesg(8):
...
ugen0.7: <vendor 0x413c> at usbus0
...

Then:
# usbconfig -d ugen0.7 do_request 0x21 0x09 0x037f 0x0000 0x04 0x7f
0x13 0x00 0x00

dmesg(8):
...
ugen0.8: <Dell Computer Corp> at usbus0
...

And after:

# kldload ng_ubt

dmesg(8):

ubt0: <Dell Computer Corp Dell Wireless 365 Bluetooth Module, class
224/1, rev 2.00/1.73, addr 8> on usbus0

For now, can we add another (optional) parameter for rc.conf, to allow
an override of the do_request parameters?

So, in /etc/rc.d/ubthidhci, we could pass a value in $ubthidhci_req
(or whatever) that could be worked into:

command_args=3D"-u ${ubthidhci_busnum} -a ${ubthidhci_addr} do_request
${ubthidhci_req} > /dev/null 2>&1"

Further, we could document known devices somewhere, allowing users to
select the appropriate values themselves -- maybe even in the form of:

ubthidhci_enable=3D"YES"
ubthidhci_busnum=3D"0"
ubthidhci_addr=3D"7"
ubthidhci_devtype=3D"BCM2046B1"

Hans, I don't see an easy way to automate any of this for now,
although you're working on an auto-configuration system for USB
devices (possibly to be generalized for other devices later). Can this
be a facet of that system?

Thanks for the help everyone!

-Brandon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTiki_awVOrjV1L3VjcriAHizf6JNag>