From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 6 19:46:36 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95B2416A40A for ; Thu, 6 Apr 2006 19:46:36 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 083AD43E08 for ; Thu, 6 Apr 2006 19:43:10 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k36Jh8kE098423; Thu, 6 Apr 2006 14:43:08 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44356F3C.1090508@centtech.com> Date: Thu, 06 Apr 2006 14:42:52 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Maksim Yevmenkin References: <43F34314.7030606@centtech.com> <43F3688B.8060700@savvis.net> <43F4B7AA.5030000@centtech.com> <43F5229C.8050106@savvis.net> <43F5D186.7060302@centtech.com> <43F60A7B.2090206@savvis.net> <43F62314.1070101@centtech.com> <43F645BB.4070008@savvis.net> <4434980E.8050202@centtech.com> <1144309790.220711.1109.nullmailer@galant.ukfsn.org> <44351C26.1060509@centtech.com> <44354908.9030505@savvis.net> In-Reply-To: <44354908.9030505@savvis.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1377/Thu Apr 6 01:17:48 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-bluetooth@freebsd.org Subject: Re: mouse battery status? 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: Thu, 06 Apr 2006 19:46:37 -0000 Maksim Yevmenkin wrote: > Eric, > >>>> What about a simple tiny kernel module that can maintain these and >>>> other >>>> tweaks related to bluetooth? Like a btmon.ko? >>> >>> This seems overly complex. Can you not just add an entry in your >>> syslog.conf to filter messages from bthidd? I have not tried this, but >>> syslog.conf(5) on appears to show that it is possible, eg: >>> >>> !bthidd >>> *.* |/usr/bin/batmon >>> >>> though I'm not so sure what the 'batmon' program would do - it can >>> extract >>> the battery reports at least, but can't really do anything with them. >>> Probably better to just feed bthidd output to a logfile and get a user >>> program to parse it. You could add a commandline option to bthidd to >>> make >>> it do special logging of the battery information, eg add >>> >>> if (battery_log) >>> syslog(LOG_LOCAL7, "%s %d", bt_ntoa(&s->bdaddr, NULL), val); >>> >>> to the battery report section which might make parsing easier, and use >>> something like >>> >>> !bthidd >>> user.local7 /var/log/bthidd.batlog >>> >>> so you dont have to worry about all the other stuff. Then, your user >>> program will just have to open battery.log and sit in a read() loop >>> to get >> >> I suppose logging it, and having a monitoring daemon read the log is >> ok, but for tools that want to just probe every X minutes and report >> the level, it isn't as slick. > > well, you could use kqueue(2) and get notification when log file is > changed. this way you do not have to poll the file. > >> The idea of a module would be more generic, so it could monitor all >> kinds of bluetooth related things, and allow a simple control >> interface to flip knobs if needed, very much like ACPI battery status >> is. I was thinking of a sysctl tree like: >> >> bluetooth.mouse.battery_level >> bluetooth.keyboard.battery_level >> etc.. > > perhaps i'm missing something here, but wouldn't the sysctl's have to be > polled as well? Yea, I suppose I was thinking it would be easier for a small binary program (or several different kinds) to be able to snag the latest information from the sysctl, rather than having them dig through log files and such. I guess in the end, I don't care how it's done, but digging through logs seems a little like a kludge and less robust.. Since nobody else seems to care too much, I guess I'll cobble up a perl script to just munge together what I want... :) Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------