From owner-freebsd-bluetooth@FreeBSD.ORG Sun Jun 26 15:56:42 2011 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A78F106566B; Sun, 26 Jun 2011 15:56:42 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 977468FC0A; Sun, 26 Jun 2011 15:56:41 +0000 (UTC) Received: by wwe6 with SMTP id 6so3845597wwe.31 for ; Sun, 26 Jun 2011 08:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AFyfer/Nic1qKYZ++KZ2s+6sjaSMzCLqPUVf6W2vmQc=; b=mHsVL1gCM+RXf5J5VpKhZhQ5VBjnA5Ebge0duUImBpJjCrGG/xJYffPXyeqxbyzYac +V5skn1EJhrKZwkiLGgbOKCSErh2TdY0iyABVTabwUBExqzp1qKViu+HIexuQibLbYGI vmxlyuKYhF2rIFfy2sSdZfIFMeamFZnex2rkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q82axNc18Up3QRoPnRE4IB1O4jWSzE3wwxNdNFOptqQGSYy6jrUEyrdmX1G40U2mgT edRec59p+Qoac7gGOfPajQ2F/r6L4tO32mAGuNjPwTQVc5cMKYszxT3BLrOtN216xrM3 4de8iWjHvmwGTiznNG4FCmXW4GQzgCS0H+5BQ= MIME-Version: 1.0 Received: by 10.216.232.13 with SMTP id m13mr1459805weq.110.1309103800294; Sun, 26 Jun 2011 08:56:40 -0700 (PDT) Received: by 10.216.65.203 with HTTP; Sun, 26 Jun 2011 08:56:40 -0700 (PDT) In-Reply-To: <201106260651.17090.hselasky@c2i.net> References: <201106260651.17090.hselasky@c2i.net> Date: Sun, 26 Jun 2011 10:56:40 -0500 Message-ID: From: Brandon Gooch To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-bluetooth@freebsd.org" , freebsd-usb@freebsd.org Subject: Re: Broadcom BCM2046B1 in HCI mode? X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 15:56:42 -0000 On Sat, Jun 25, 2011 at 11:51 PM, Hans Petter Selasky wr= ote: > On Sunday 26 June 2011 05:46:35 Brandon Gooch wrote: >> On Wed, Jun 22, 2011 at 11:17 AM, Maksim Yevmenkin >> >> wrote: >> > On Tuesday, June 21, 2011, Brandon Gooch > wrote: >> >> I have one of these in my notebook: >> >> >> >> uhub4: 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 >> >> >> >> ...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: at usbus0 ... Then: # usbconfig -d ugen0.7 do_request 0x21 0x09 0x037f 0x0000 0x04 0x7f 0x13 0x00 0x00 dmesg(8): ... ugen0.8: at usbus0 ... And after: # kldload ng_ubt dmesg(8): ubt0: 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