<br><div class="gmail_quote">2009/9/3 Arjen de Korte<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Citeren Arnaud Quette<br><div class="im">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
strange indeed. the data is there, and now know.<br>
<br>
I've made a minor fix (r1955).<br>
please test it and tell me back if input.transfer.reason appears now.<br>
</blockquote>
<br></div>
No, it won't. The 'input.transfer.reason' value is set through the VRANGE and FRANGE status bits. In the absence of either, it will be cleared. Therefor, you can't treat this as an ordinary variable. There are HID PDC fields that use these, so we'll have to be careful to change this in order not to break other subdrivers in the process.<br>
</blockquote></div><br>ooch, right! I completely missed that. thanks for pointing it Arjen ;-)<br><br>I just commited a fix (r1956): it only reports voltage or frequency out of range, and not over/under voltage / ripple / force / selftest as it was in the previous version.<br>
Is it fine like that Markus?<br><br>cheers,<br>Arnaud<br>-- <br>Linux / Unix Expert R&D - Eaton - <a href="http://www.eaton.com/mgeops">http://www.eaton.com/mgeops</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/">http://www.networkupstools.org/</a><br>
Debian Developer - <a href="http://www.debian.org">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.free.fr/">http://arnaud.quette.free.fr/</a><br><br>