<br><br><div><span class="gmail_quote">2005/9/13, Peter Selinger <<a href="mailto:selinger@mathstat.dal.ca">selinger@mathstat.dal.ca</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have checked in a cleaned-up version of patch #302111 (Belkin<br>support) into CVS. See</blockquote><div><br>
seen on the -commits list ;-)<br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Please let me know if there's anything you don't like.</blockquote><div><br>
few things<br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Notes:<br><br>* I documented the new variables and instant commands in<br> new-names.txt
. Some of them already existed in other drivers, but<br> had not yet been documented.</blockquote><div><br>
please discuss (seen Charles ;-) before adding any entry to the naming.<br>
if you find some undocumented vars in drivers, announce these on the -dev ml.<br>
<br>
- ups.devicechemistry => that would more fit to "battery.type" (opaque string?!)<br>
- other vars are ok<br>
</div><br>
Also, don't forget to bump newhidups drv release, as we can attach a release to the added mfr support...<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">* One exception is the variable ups.serial.internal, which should not<br> really exist. The information contained in that variable should
<br> normally be in ups.serial. The problem is that the Belkin UPS does<br> not announce its serial number in the device descriptor (like a good<br> HID device should), but in a report. So this info is not available<br>
at initialization time. So either one needs a specialized function<br> for retrieving the Belkin serial number at initialization time, or<br> one needs to set the variable ups.serial "after the fact". I could
<br> not figure out how to do that, so I left the variable<br> ups.serial.internal, and a "FIXME" comment, for the time being.</blockquote><div><br>
you can stick at ups.serial. If it already exists, it will be updated by dstat_setinfo(). Otherwise, it will be created. <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> - why did you remove the restriction on Belkin ProductID<br>><br>> (dev->
descriptor.idProduct == 0x0551)<br>><br>> It's not useful for UPS only mfrs, but belkin also sells other devices...<br><br>My Belkin UPS has product ID 0x0980. It seems silly to start making a<br>long list of Belkin UPS products, because every user would have to
<br>email us their product ID before their device could be supported. A<br>better strategy seems to support all Belkin devices. They do make<br>non-UPS devices, but I think it's mostly passive devices like power<br>strips. I don't know if they make any other USB HID devices. I can see
<br>no harm in trying to connect to the first Belkin device we find; if a<br>user wants to specify a specific device, they can e.g. use my new<br>regex mechanism.</blockquote><div><br>
don't they sells mice, keyboard and others USB/HID alike devs? <br>
for sure, it doesn't hurt, but it can make a longer probing time...<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I am planning to work on modularizing the code for newhidups a bit, so<br>that there can be specialized policies for different manufacturers. A
<br>better permanent solution might be to look at the product string (for<br>Belkin devices only) to determine whether it's a UPS.</blockquote><div><br>
that would result in the same thing as with Vid... Keep in mind that it should work with the libhid callback system, ie:<br>
<a href="http://svn.ailab.ch/cgi-bin/viewcvs.cgi/libhid/trunk/test/test_libhid.c?rev=207&view=markup">http://svn.ailab.ch/cgi-bin/viewcvs.cgi/libhid/trunk/test/test_libhid.c?rev=207&view=markup</a><br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> - about your comment in newhidups.h (specifically "there is not file<br>
> libusb.h"):<br>><br>> +/* there is not file libusb.h, so we have to declare this "by hand":<br>> */+int libusb_get_string(int StringIdx, char *string);<br>><br>> => if you mean the nut file that should go with
libusb.c, then it's<br>> hid-usb.h<br>> (the reason is linked to the old libHID, and it's various backends...)<br>> => if you mean the header from the libusb project, then it's named usb.h<br>> and is included in
hid-usb.h.<br><br>Thanks, I fixed that.</blockquote><div><br>
ok, seen.<br>
<br>
btw, you can remove "John Stamp" reference as he only added things in apc-hid.h...<br>
<br>
Arnaud <br>
</div><br></div>