On Aug 27, 2011, at 6:46 AM, Arnaud Quette wrote:
this is very similar to the HAL / UPower (using the system provided
PM integration)!
but you have a converse approach: consume data from this source.
does this means that using this source is better (in terms of data
and features provided)?
Fewer features, but easier to implement. It's really more of a
monitoring interface, since the OS GUI provides a number of different
shutdown thresholds.
and / or that NUT drivers can't replace (as with UPower) OS X' one(s)?
This is what got me looking at HIDAPI: the HID driver in OS X makes it
hard to grab a HID device/interface with libhid.
Then again, since HIDAPI doesn't deal with HID usage paths, I might be
able to code up some alternate HID stuff for NUT that uses the native
OS X HID interface now that I'm a bit more familiar with that code. I
need a sabbatical :-)
is this still limited to USB HID?
I think the OS only supports USB HID, but it would be possible to
write a bridge that goes the other way to let the OS see UPS status
for a serial or network UPS. I think it would be best implemented as
an upsd client.
my last idea on UPower (and similar needs) was to change the driver
dstate layer (which is used for communication with upsd) to a plugin
system style. the default would still be to load the classic dstate.
but alternative would be provided for DBus / UPower and any other
kind of useful protocols.
Personal preference: I don't like plugin interfaces where only one
interface is used at a time. The HAL drivers just linked in a
different dstate layer at compile time - wouldn't that work?
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
