<br><br><div class="gmail_quote">2011/8/28 Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Aug 27, 2011, at 6:46 AM, Arnaud Quette wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
this is very similar to the HAL / UPower (using the system provided PM integration)!<br>
but you have a converse approach: consume data from this source.<br>
does this means that using this source is better (in terms of data and features provided)?<br>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and / or that NUT drivers can't replace (as with UPower) OS X' one(s)?<br>
</blockquote>
<br></div>
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.<br>
<br>
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 :-)</blockquote>
<div><br>that would probably be better (both the use of the native OS X HID interface and the sabbatical ;-)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
is this still limited to USB HID?<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br>not sure, see below. <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</blockquote>
<br></div>
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?<br>
</blockquote></div><br>you got me wrong: conversely to the hal drivers, which used a kind of static plugin system at compile time, here, we would be able to use multiple plugins.<br>so that you could, at the same time, both report to upsd and other things like upowerd, OS X power daemon, ... this could be a better way in the long run, don't you think?<br clear="all">
<br>so if your idea is quick and easy to implement, let's go ahead.<br>in the meantime, let's continue to talk on this plugins backend, and see if it fits the needs.<br><br>cheers,<br>Arnaud<br><br>