Date: Thu, 06 Apr 2006 14:42:52 -0500 From: Eric Anderson <anderson@centtech.com> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: mouse battery status? Message-ID: <44356F3C.1090508@centtech.com> In-Reply-To: <44354908.9030505@savvis.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44356F3C.1090508>