Charles Lepple
2009-Sep-03 03:42 UTC
[Nut-upsdev] ups_set_altinterface() breaks tripplite_usb on Mac OS X
Is there a particular reason why we are setting the alternate interface to 0 in drivers/libusb.c? I have seen some documentation which indicates that this should already done by the OS when the device is enumerated. If that is the case, then there is no reason why we should hardcode the alternate interface to 0. If I remove the following code, tripplite_usb seems to work*: /* set default interface */ usb_set_altinterface(udev, 0); Any objections to removing this? Can I get some volunteers to try this out on their non-OS X systems? I am using libusb-0.1.12 on Mac OS X 10.5.8. * I did have to monkey with a codeless kext in order to allow libusb to claim the device. However, it doesn't seem like OS X allows you to bypass the claim operation anymore. -- - Charles Lepple
Arnaud Quette
2009-Sep-03 09:05 UTC
[Nut-upsdev] ups_set_altinterface() breaks tripplite_usb on Mac OS X
2009/9/3 Charles Lepple <clepple at gmail.com>> Is there a particular reason why we are setting the alternate > interface to 0 in drivers/libusb.c? > > I have seen some documentation which indicates that this should > already done by the OS when the device is enumerated. If that is the > case, then there is no reason why we should hardcode the alternate > interface to 0. >iirc, this is indeed done automatically on Linux (and possibly OSX) when there's only one interface (the same goes for the config). but it's not the case on windows.> If I remove the following code, tripplite_usb seems to work*: > > /* set default interface */ > usb_set_altinterface(udev, 0); >prefer to flag it for windows (#ifdef WIN32...) so that we don't face a problem when porting to windows.> Any objections to removing this? Can I get some volunteers to try this > out on their non-OS X systems? > > I am using libusb-0.1.12 on Mac OS X 10.5.8. > > * I did have to monkey with a codeless kext in order to allow libusb > to claim the device. However, it doesn't seem like OS X allows you to > bypass the claim operation anymore. >I'll be interested in the result since usbhid-ups, bcmxcp_usb and richcomm are in the same case. I'll try to make an OS X test on usbhid-ups with an Eaton... cheers, Arnaud -- Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090903/41cad77c/attachment.htm>
Apparently Analagous Threads
- Apple iMac OS X 10.13.5 | Powershield Defender 1200 UPS
- Apple iMac OS X 10.13.5 | Powershield Defender 1200 UPS
- Apple iMac OS X 10.13.5 | Powershield Defender 1200 UPS
- Unable to use nut-2.7.4 with Eaton 5E1500I USB
- BBEdit Ruby & Rails Syntax Module available