search for: usb_communication_subdriver_t

...errupts I/O as this UPS doesn't recognizes Control IO, so libusb_get_report() and libusb_set_report() will not work. Looking at libusb.c I realized there's a libusb_get_interrupt() which can be used to read from the endpoint, however there's no counterpart libusb_set_interrupt() API and usb_communication_subdriver_t structure doesn't contain a *set_interrupt element as well: libusb.h .... typedef struct usb_communication_subdriver_s { char *name; /* name of this subdriver */ char *version; /* version of this subdriver...

...e why that is commented out). I don't know enough about USB to know how NUT would know which config to choose if there were several, just that it appears to me that configurations own interfaces, not the other way around. It looks like the most flexible thing would be to create a new member in usb_communication_subdriver_t, maybe called usb_config_index (I don't know if config descriptors are HID specific?) This member would be a lot like hid_desc_index. It would default to zero but be available for those USB subdrivers that needed something other than the default. Please let me know if I'm on the right trac...

...            curDevice->Serial = strdup(string); diff --git a/drivers/libusb.h b/drivers/libusb.h index 66d26335..46414da1 100644 --- a/drivers/libusb.h +++ b/drivers/libusb.h @@ -60,6 +60,8 @@ typedef struct usb_communication_subdriver_s {      unsigned char *buf, int bufsize, int timeout);  } usb_communication_subdriver_t; +int nut_usb_get_string(usb_dev_handle *dev, int index, char *buf, size_t buflen); +  extern usb_communication_subdriver_t    usb_subdriver;  #endif /* LIBUSB_H */ diff --git a/drivers/main.c b/drivers/main.c index 0b6759dd..f05de30e 100644 --- a/drivers/main.c +++ b/drivers/main.c @@ -673,6...

...out). I don't know enough about USB to know how NUT would know which config > to choose if there were several, just that it appears to me that > configurations own interfaces, not the other way around. > > It looks like the most flexible thing would be to create a new member in > usb_communication_subdriver_t, maybe called usb_config_index (I don't know > if config descriptors are HID specific?) This member would be a lot > like hid_desc_index. It would default to zero but be available for those > USB subdrivers that needed something other than the default. > > Please let me know if I...

...ow enough about USB to know how NUT would know which config >> to choose if there were several, just that it appears to me that >> configurations own interfaces, not the other way around. >> >> It looks like the most flexible thing would be to create a new member in >> usb_communication_subdriver_t, maybe called usb_config_index (I don't know >> if config descriptors are HID specific?) This member would be a lot >> like hid_desc_index. It would default to zero but be available for those >> USB subdrivers that needed something other than the default. >> >> Ple...

...to know how NUT would know which config >>> to choose if there were several, just that it appears to me that >>> configurations own interfaces, not the other way around. >>> >>> It looks like the most flexible thing would be to create a new member in >>> usb_communication_subdriver_t, maybe called usb_config_index (I don't know >>> if config descriptors are HID specific?) This member would be a lot >>> like hid_desc_index. It would default to zero but be available for those >>> USB subdrivers that needed something other than the default. >>&...