In https://github.com/networkupstools/nut/issues/3040 I bought a new 'Vida Armour' UPS and sniffed USB communication of the Windows drivers. If I understand correctly, the 'protocol' in nutdev_qx describes how we parse the strings we get back from the UPS, while the 'subdriver' describes what we do in order to *elicit* those strings. This UPS looks very close to the megatec protocol and fabula subdriver. I get these strings from the following string descriptors: ? 0x03: (242.0 000.0 243.0 000 50.0 54.0 28.0 00001001\r ? 0x0d: #230.0 10 48.00 50.0\r ? 0xf3: BL100\r ? 0x0c: # V4.20 \r Supporting this variant probably shouldn't be hard, but I'm failing at the first hurdle. The driver fails to start up because the UPS doesn't return any valid langids from descriptor zero, and the explicit noscanlangid and langid= options to the driver don't seem to make any difference. I run: LIBUSB_DEBUG=9 nutdrv_qx -a armour -DDDD -x vendorid=0001 -xproductid=0000 -x subdriver=fabula -x protocol=megatec -x noscanlangid -x langid_fix=0x409 -x novendor -x norating It says it's going to try to read string descriptor 0x03 and failing... 0.043142 [D3] send: Q1 0.043144 [D4] command index: 0x03 [ 0.040293] [0028990f] libusb: debug [libusb_submit_transfer] transfer 0x557487783d20 [ 0.040294] [0028990f] libusb: debug [add_to_flying_list] arm timer for timeout in 1000ms (first in line) [ 0.040304] [0028990f] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 0.040306] [0028990f] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms [ 0.044198] [0028990f] libusb: debug [usbi_wait_for_events] poll() returned 1 [ 0.044205] [0028990f] libusb: debug [reap_for_handle] urb type=2 status=0 transferred=0 [ 0.044208] [0028990f] libusb: debug [handle_control_completion] handling completion status 0 [ 0.044212] [0028990f] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer [ 0.044215] [0028990f] libusb: debug [usbi_handle_transfer_completion] transfer 0x557487783d20 has callback 0x7fd2f6818c20 [ 0.044217] [0028990f] libusb: debug [sync_transfer_cb] actual_length=0 [ 0.044221] [0028990f] libusb: debug [libusb_free_transfer] transfer 0x557487783d20 0.047081 [D3] read: Input/Output Error (-1) [ 0.044230] [0028990f] libusb: debug [libusb_close] But wireshark/usbmon says it actually tried to read descriptor #0: Setup Data bmRequestType: 0x80 1... .... = Direction: Device-to-host .00. .... = Type: Standard (0x0) ...0 0000 = Recipient: Device (0x00) bRequest: GET DESCRIPTOR (6) Descriptor Index: 0x00 bDescriptorType: STRING (0x03) Language Id: no language specified (0x0000) wLength: 4 .. and got a zero-length reply? USB URB [Source: 3.12.0] [Destination: host] URB id: 0xffff8eb71392ac00 URB type: URB_COMPLETE ('C') URB transfer type: URB_CONTROL (0x02) Endpoint: 0x80, Direction: IN 1... .... = Direction: IN (1) .... 0000 = Endpoint number: 0 Device: 12 URB bus id: 3 Device setup request: not relevant ('-') Data: present ('\0') URB sec: 1754559469 URB usec: 970070 URB status: Success (0) URB length [bytes]: 0 Data length [bytes]: 0 Why did it do that? I asked it not to! And even if I hadn't explicitly asked it not to... couldn't it have proceeded with en_US anyway rather than completely aborting? This is nut-2.8.3 (on Fedora 41) with libusb 1.0.28. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5069 bytes Desc: not available URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250807/e687c50a/attachment.p7s>