From owner-freebsd-bluetooth@FreeBSD.ORG Wed Dec 30 19:57:08 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 65F641065672 for ; Wed, 30 Dec 2009 19:57:08 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-px0-f190.google.com (mail-px0-f190.google.com [209.85.216.190]) by mx1.freebsd.org (Postfix) with ESMTP id 390808FC18 for ; Wed, 30 Dec 2009 19:57:08 +0000 (UTC) Received: by pxi28 with SMTP id 28so8307429pxi.7 for ; Wed, 30 Dec 2009 11:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6xRNWHaloVxnf+/UK+Imsxdm2wn3gR+FReLg7AW5Kvw=; b=OPxWKv/p3rcPjlDLVKmClfvEMjOWqt2H9CEQPSzvC3nlrJe8C9jN8WnZ4bBHQLIeRk HFammD9cx2x80+kAjglODFbRVMGMdbVsWg1Oh9fW04aUwOOtOFeCn++8IoFy5QLSy8P3 lPEIutV8HsKWXI9pkhY32OTrDM6ViDvp7OvVI= 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; b=HpbK/Gp5ZhLbt1VxT6OQmilSbL9VRrzJTvVdGPdb5G2SX8caRM4VZBa3sBobMc8AY2 w0585/Nw/qKn44NEO7ogd+r6VqsceCYSvCemRRiXiMtaAlqQzQQOXEVGvb6O+INcWjFG ghfkG9gkrOfPyWM9qzWZRp6fDZQ9mNWu5FNSU= MIME-Version: 1.0 Received: by 10.115.133.2 with SMTP id k2mr12800969wan.113.1262203027908; Wed, 30 Dec 2009 11:57:07 -0800 (PST) In-Reply-To: <1262169549.695652.1010.nullmailer@galant.ukfsn.org> References: <20091227.111711.287595822663154592.imp@bsdimp.com> <1261940371.044739.879.nullmailer@galant.ukfsn.org> <20091229.162535.190753344529111277.imp@bsdimp.com> <1262169549.695652.1010.nullmailer@galant.ukfsn.org> Date: Wed, 30 Dec 2009 11:57:07 -0800 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-bluetooth@freebsd.org, "M. Warner Losh" 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 19:57:08 -0000 On Wed, Dec 30, 2009 at 2:39 AM, Iain Hibbert wrote: > 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? sure, let me dig those out first :) > 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. ok, i guess, i can see the value of having dynamic pin/key configuration, i.e. replace static /etc/bluetooht/hcsecd.conf with one built dynamically based on client's request. i could even see how generated link keys are stored in user's home directory together with user's pins etc. having said all that, i do not see why executing external pin program from hcsecd(8) is a bad idea. bluetooth is essentially single user. there is no good way, imo, to basically share multiple devices between multiple users on the same computer. what you have in netbsd is a little bit more flexible, but, i bet, in 99.9% cases it probably ends up the same way, i.e. only one user, uses only only handful or remote devices connected to the same local device (or computer). >> 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. it probably never goes to sleep :) freebsd will try to become 'master' on link, and, we are not actively enforce any link policy, so, i'm guessing link is always running with the default policy. 'sniff' mode definitely helps to reduce power consumption, and, i'm guessing, progressively (in|de)creasing 'sniff' interval based on keyboard's (in)activity is the right thing to do. >> 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) yep, usually device has some sort of hid report. i think, but not 100% sure, there also might be something that comes over hid control channel. need to re-check the specs again. > 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. oh, neat-o! i did not know about this! i will try this today. thanks! thanks max