From owner-freebsd-bluetooth@FreeBSD.ORG Wed Dec 30 10:39:13 2009 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 75EA61065692 for ; Wed, 30 Dec 2009 10:39:13 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp6.freeserve.com (smtp5.freeserve.com [193.252.22.151]) by mx1.freebsd.org (Postfix) with ESMTP id 147528FC12 for ; Wed, 30 Dec 2009 10:39:12 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3513.me.freeserve.com (SMTP Server) with ESMTP id 57AA47000084; Wed, 30 Dec 2009 11:39:11 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3513.me.freeserve.com (SMTP Server) with ESMTP id 48C03700008B; Wed, 30 Dec 2009 11:39:11 +0100 (CET) Received: from rya-online.net (unknown [89.194.128.19]) by mwinf3513.me.freeserve.com (SMTP Server) with SMTP id 22B607000084; Wed, 30 Dec 2009 11:39:10 +0100 (CET) X-ME-UUID: 20091230103910142.22B607000084@mwinf3513.me.freeserve.com Received: (nullmailer pid 944 invoked by uid 1000); Wed, 30 Dec 2009 10:39:09 -0000 Date: Wed, 30 Dec 2009 10:39:09 +0000 (GMT) To: "M\. Warner Losh" In-Reply-To: <20091229.162535.190753344529111277.imp@bsdimp.com> References: <20091227.111711.287595822663154592.imp@bsdimp.com> <1261940371.044739.879.nullmailer@galant.ukfsn.org> <20091229.162535.190753344529111277.imp@bsdimp.com> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1262169549.695652.1010.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: Keyboard - how? 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: Wed, 30 Dec 2009 10:39:13 -0000 On Tue, 29 Dec 2009, M. Warner Losh wrote: > : yep, the whole thing is "ugly" because pairing basically requires some > : form of (graphical) user interface. its an interactive process. i have > : a patch somewhere that teaches hcsecd(8) how to execute external > : program and pass requester and pin info back and forth. with this, one > : can use something like xdialog and get prompted when pairing is > : happening. > > Exactly... That would be cool. Wanna pass them over to me? If you are working on something, please look at the NetBSD implementation as I think having a system daemon execute an external program to request input from the user is wrong. What I did is to have the daemon[1] open a socket and accept client connections. When it sees a PIN request it offers it out to the clients to see if any of them can provide a PIN. When users log in, they can run a PIN application[2] that registers on the socket and will put up a requester when required. Alternatively, I can use the base application[3] to set a PIN before trying to pair. [1] http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/bthcid [2] http://homepages.rya-online.net/plunky/btpin-qt-1.4.tar.gz [3] http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/btpin As said, I don't think its ideal (and Qt4 takes way too long to build!) but it does work ok for my purposes. > BTW, after the big hammers, the newer apple keyboard and mouse (2008) > are working just fine[*] with my FreeBSD box and it they seem to wake > up better than OS X does (or maybe they just never go to sleep). I'm not sure if having things like 'Sniff', 'Park' and 'Hold' modes enabled will make a difference to this. Certainly enabling sniff mode keeps the batteries going for longer (many weeks vs some days) but I think hold and park require active OS support to be effective. > Is there some way to find out what the battery level in these devices > is? I investigated this somewhat. The HID descriptor (of the Mighty Mouse, not my older keyboard or mouse) shows a feature report: Feature id=71 size=8 count=1 page=Device_Controls usage=Battery_Strength Variable NoPref Volatile logical range 0..100 and I think this means that the host can poll the device by sending the feature report and getting a return value with battery strength. I never tried it though.. (the keyboard descriptor you posted earlier also shows this, except the logical range is 0..255) Also, my mouse (and keyboard) both send an undocumented input report with id#42 containing a single byte (0x01 or 0x02) just before the batteries finally shut down. No idea what this should be interpreted as, but I use NiMH batteries and the voltage remains constant until they run out of power, so perhaps the 'strength' would not be a very useful value anyway. If you have OSX there is a way to capture bluetooth packets and you could investigate more there. I think something like hold down 'option' key while opening the bluetooth menu and you should see it listed. Not sure if it shows a live stream but hcidump can interpret the packet capture files. regards, iain