On Wed, Jun 22, 2011 at 11:17 AM, Maksim Yevmenkin
<maksim.yevmen...@gmail.com> wrote:
> On Tuesday, June 21, 2011, Brandon Gooch <jamesbrandongo...@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 usbus0
>> 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):
>>      ubthidhci_enable
>>                  (bool) If set to ``YES'', change the USB Bluetooth 
>> controller
>>                  from HID mode to HCI mode.  You also need to specify the
>>                  location of USB Bluetooth controller with the
>>                  ubthidhci_busnum and ubthidhci_addr variables.
>>      ubthidhci_busnum
>>                  Bus number where the USB Bluetooth controller is located.
>>                  Check the output of usbconfig(8) on your system to find this
>>                  information.
>>      ubthidhci_addr
>>                  Bus address of the USB Bluetooth controller.  Check 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="YES"
>> ubthidhci_busnum="0"
>> ubthidhci_addr="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:
>> ...which I've read as potentially being OK, as the operation still may
>> 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 help
>> 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

The hid2hci utility has this function defined for dealing with the
device in question:


static int usb_switch_dell(struct usb_dev_handle *dev, enum mode mode)
        char report[] = { 0x7f, 0x00, 0x00, 0x00 };
        report[1] = 0x13;
        err = usb_control_msg(dev,
            USB_REQ_SET_CONFIGURATION, 0x7f | (0x03 << 8), 0,
            report, sizeof(report), 5000);

And according to:


usb_control_msg() is prototyped:

extern int usb_control_msg(struct usb_device *dev, unsigned int pipe,
         __u8 request, __u8 requesttype, __u16 value, __u16 index,
         void *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,
    opt->buffer, &actlen, 5000 /* 5 seconds */ , 0))

which is prototyped as:

libusb20_dev_request_sync(struct libusb20_device *pdev,
         struct LIBUSB20_CONTROL_SETUP_DECODED *setup, void *data,
         uint16_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?


(Bad form: I'm cross-posting)
freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to