awesome-webhid
awesome-webhid copied to clipboard
robatwilliams
My device is not visible for webHid, but works fine with node-hid
Hi, Like in title: hid.requestDevice({filters: [{ }]}) display only my mouse and keyboard in prompt for selection device, but usb.requestDevice show it well. Also node-hid detect it and works fine with my device.
My device (UPS): Bus 003 Device 007: ID 0001:0000 Fry's Electronics MEC0003
Cheers Patryk
Hi @todbot,
First of all Thank you for your response
OS: Ubuntu 20.04.2 Chrome 89.0.4389.114
/etc/udev/rules.d/50-ups.rules SUBSYSTEM=="input", GROUP="input", MODE="0666" SUBSYSTEM=="usb", ATTRS{idVendor}=="0001", SYMLINK+="ups2", ATTRS{idProduct}=="0000", MODE:="666", GROUP="plugdev" KERNEL=="hidraw*", ATTRS{idVendor}=="0001", SYMLINK+="ups2", ATTRS{idProduct}=="0000", MODE="0666", GROUP="plugdev"
Anyway everything works fine in the Electron with node-hid and without root privileges. The device is also detected via webUSB.
Best Patryk
From the Linux Hardware Database: https://linux-hardware.org/index.php?id=usb:0001-0000 it appears this device is a telephony device and has a kernel driver. So if some of these are true:
- Ubuntu 20 enables this driver in its kernel
- Ubuntu uses a class driver the HID Telephony Usage Page (0x0B)
- Chrome has an exception for HID Telephony Usage Page
Then I can imagine that's how you're getting the results you're seeing. The reason why node-hid could be working is if you're using the libusb variant of node-hid (instead of hidraw). libusb bypasses the normal OS-level HID handling.
Welcome to the joys of HID. The OS will hide or disallow access to many defined HID Usage Pages (mouse, keyboard, gamepad, etc), so if a device declares it's one of those usages, WebHID / hidapi / node-hid won't be able to access it. You can learn more about Usage Pages here: https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
Thanks for response @todbot Restart the browser did not help, but after restarting the pc my device is visible. In the meantime, I was installing libusb and add and reload rules.
Anyway I have other issue with webHid.
I got a problem with receiveFeatureReport function. For node-hid, I use getFeatureReport and it works fine there. Report id:
- 0x03 (command Q1) returns the device parameters (I think this is a slower instruction)
- 0x0c (command I) returns information about the device (it is a simple and quick instruction)
- 0x04 run tests (device makes sounds then I know the command works)
For node-hid case: 0x03 - return '(242.4 242.4 242.4 004 50.0 13.6 --.- 00001001' 0x0c- '#. ' 0x04 - 'UPS No Ack' (the device beeps)
for web-hid case: 0x03 - (with 0xE0 byte before)'Q1 or (2x 0xE0 bytes)'Q1' or 'UPS No' or function throw exception 0x0c- on 100 tests first result is 'I' and next 99 return expected response '#. ' 0x04 - 'UPS No' (the device beeps)
In the case of web-hid, For me it looks like the response is not synchronized properly and is sent before the buffer is updated.
Best Patryk
I think the device was originally blocked because Chrome's implementation of WebHID on Linux requires read-write access to the hidraw device node. Adding the udev rules (and then reloading or restarting) is likely what fixed it.
There's a known issue with receiveFeatureReport on Linux where the buffer size is off by one byte due to confusion over whether the report ID byte should be included in the returned buffer. I don't think that's what's going on here since the returned data differs by more than one byte.
Internally, Chrome uses the HIDIOCGFEATURE ioctl to read feature reports:
https://source.chromium.org/chromium/chromium/src/+/main:services/device/hid/hid_connection_linux.cc;l=86;drc=b3040fd7f4402e4658483321402dd342808361c8
Can you test that the returned data matches the node-hid case when HIDIOCGFEATURE is called from outside of Chrome?
First of all very Thank You for response!!
In sum:
- I get correct responses from electron app with node-hid library even if I choose hidraw driver.
- I have tested my script on Windows 10 with WebHid with the same issue like on linux. Below I present the results of these tests from windows:
for (var i = 0; i < 100 ; i++){ try{ console.log(await device.receiveFeatureReport(0x03)); await sleep(2000); }catch(e){ console.error(e); } }
test results:
- DataView(12) 0C 03 E0 00 E0 00 51 00 31 00 0D 00 => ......Q.1...
- 2x Failed to receive the feature report.
- DataView(16) 16 03 55 00 50 00 53 00 20 00 4E 00 6F 00 20 00 => ?.U.P.S. .N.O. .
- DataView(13) 10 03 E0 00 D4 00 CC 00 C3 00 51 00 31 => ..........Q.1
- 95x Failed to receive the feature report.
test with delay after any request:
for (var i = 0; i < 100 ; i++){ try{ console.log(await device.receiveFeatureReport(0x03)); }catch(e){ console.error(e); } await sleep(2000); }
test results:
- DataView(12) 0C 03 E0 00 E0 00 51 00 31 00 0D 00 => ......Q.1...
- Failed to receive the feature report.
- DataView(10) 0C 03 E0 00 51 00 31 00 0D 00 => ....Q.1...
- Failed to receive the feature report.
- DataView(10) 0C 03 E0 00 51 00 31 00 0D 00 => ....Q.1...
- Failed to receive the feature report.
- DataView(10) 0C 03 E0 00 51 00 31 00 0D 00 => ....Q.1...
Q1 is the name of the UPS protocol and name of command used to retrieve this data from Rj45, so it is not a random value. However, it is returned in a random form. Also under this ID I expect a different value which I get when using node-hid.
I appreciate your commitment and thank You very much for your quick replies! Cheers Patryk
I think the device was originally blocked because Chrome's implementation of WebHID on Linux requires read-write access to the hidraw device node. Adding the udev rules (and then reloading or restarting) is likely what fixed it.
There's a known issue with
receiveFeatureReporton Linux where the buffer size is off by one byte due to confusion over whether the report ID byte should be included in the returned buffer. I don't think that's what's going on here since the returned data differs by more than one byte.Internally, Chrome uses the HIDIOCGFEATURE ioctl to read feature reports:
https://source.chromium.org/chromium/chromium/src/+/main:services/device/hid/hid_connection_linux.cc;l=86;drc=b3040fd7f4402e4658483321402dd342808361c8
Can you test that the returned data matches the node-hid case when HIDIOCGFEATURE is called from outside of Chrome? ` #include <stdio.h> #include <string.h> #include <stdlib.h> #include <errno.h> #include <fcntl.h> #include <unistd.h> #include <linux/input.h> #include <linux/hidraw.h>
#define BUFFOR_SIZE 128
int main(int argc, char **argv) { int fd, i, res = 0; char buf[BUFFOR_SIZE], *device = argv[1];
memset(buf, 0, BUFFOR_SIZE);
fd = open(device, 0);
buf[0] = atoi(argv[2]);
if(!strcmp("send", argv[3])) ioctl(fd, HIDIOCSFEATURE(2), buf);
res = ioctl(fd, HIDIOCGFEATURE(BUFFOR_SIZE), buf);
printf("\n\nString representation: \n\n");
for (i=0; i < res; ++i) if(buf[i] > 0 && i >= 2) printf("%c", buf[i]);
printf("\n\ndecimal: \n\n");
for (i=0; i < res; ++i) printf("%d, ", buf[i]);
printf("\n\nhex: \n\n");
for (i=0; i < res; ++i) printf("0x%hhx, ", buf[i]);
printf("\n\n");
close(fd);
return 0;
}
`
- After plug in usb then I receive
` gcc -o test main.c && ./test /dev/hidraw5 3
String representation: Q1
decimal: 10, 3, -32, 0, 81, 0, 49, 0, 13, 0,
hex:
0xa, 0x3, 0xe0, 0x0, 0x51, 0x0, 0x31, 0x0, 0xd, 0x0,
In next use
gcc -o test main.c && ./test /dev/hidraw5 3
String representation: (242.4 242.4 242.4 003 50.0 13.8 --.- 00001001
decimal: 96, 3, 40, 0, 50, 0, 52, 0, 50, 0, 46, 0, 52, 0, 32, 0, 50, 0, 52, 0, 50, 0, 46, 0, 52, 0, 32, 0, 50, 0, 52, 0, 50, 0, 46, 0, 52, 0, 32, 0, 48, 0, 48, 0, 51, 0, 32, 0, 53, 0, 48, 0, 46, 0, 48, 0, 32, 0, 49, 0, 51, 0, 46, 0, 56, 0, 32, 0, 45, 0, 45, 0, 46, 0, 45, 0, 32, 0, 48, 0, 48, 0, 48, 0, 48, 0, 49, 0, 48, 0, 48, 0, 49, 0, 13, 0,
hex: 0x60, 0x3, 0x28, 0x0, 0x32, 0x0, 0x34, 0x0, 0x32, 0x0, 0x2e, 0x0, 0x34, 0x0, 0x20, 0x0, 0x32, 0x0, 0x34, 0x0, 0x32, 0x0, 0x2e, 0x0, 0x34, 0x0, 0x20, 0x0, 0x32, 0x0, 0x34, 0x0, 0x32, 0x0, 0x2e, 0x0, 0x34, 0x0, 0x20, 0x0, 0x30, 0x0, 0x30, 0x0, 0x33, 0x0, 0x20, 0x0, 0x35, 0x0, 0x30, 0x0, 0x2e, 0x0, 0x30, 0x0, 0x20, 0x0, 0x31, 0x0, 0x33, 0x0, 0x2e, 0x0, 0x38, 0x0, 0x20, 0x0, 0x2d, 0x0, 0x2d, 0x0, 0x2e, 0x0, 0x2d, 0x0, 0x20, 0x0, 0x30, 0x0, 0x30, 0x0, 0x30, 0x0, 0x30, 0x0, 0x31, 0x0, 0x30, 0x0, 0x30, 0x0, 0x31, 0x0, 0xd, 0x0,
2. After plug in usb with commandgcc -o test main.c && ./test /dev/hidraw5 3 send` everything is well but I next use I got error and next time working again.
- ./test /dev/hidraw5 3 send && ./test /dev/hidraw5 3 - working well
Anyway in webhid case always I get wrong data. Also in that case I got error: await device.sendFeatureReport(0x03, outputReport); console.log( await device.receiveFeatureReport(0x03) ); <- Uncaught (in promise) DOMException: Failed to receive the feature report.
In libusb case everything works exelent
Best Patryk
Can you check if any errors were logged in chrome://device-log? When you get a "Failed to receive the feature report" exception there should be a log message explaining why it failed.
On Linux, if HIDIOCGFEATURE fails then you'll see a log message "Failed to get feature report" followed by an error code.
On Windows, Chrome uses DeviceIoControl with IOCTL_HID_GET_FEATURE. If that fails you'll see "HID read failed" or "HID transfer failed" followed by an error code.
From the behavior you described I think it's the device sending bad data rather than an error in the application. It seems like the device is using HID feature reports to return the output from serial commands and changes the length of the report based on the length of the output. Normally, the length of a HID report is a fixed number of bytes and should not change. However, the platform HID API typically doesn't enforce this so "invalid" reports are still passed to applications.
My guess is the failure occurs when trying to read a feature report that's longer than the buffer allocated to receive it. Chrome allocates a buffer large enough to fit the largest report of a given type. For instance, when receiving a feature report, Chrome finds the length of the longest feature report in the device's HID report descriptor and allocates a buffer large enough to fit that report plus an optional report ID byte. If the data is longer than the maximum report length then the transfer will fail.
Can you share the contents of the device's report descriptor? On Linux you can get it through the kernel debug interface:
$ sudo ls /sys/kernel/debug/hid
0003:0001:0000.000A
$ sudo head -n 1 /sys/kernel/debug/hid/0003:0001:0000.000A/rdesc
05 01 09 02 a1 ...
chrome://device-log
For code:
try{
res = await device.receiveFeatureReport(reportId);
console.log(res);
}catch(e){
console.error(e);
}
try{
let outputReport = Int8Array.from([-1]);
await device.sendReport(reportId, outputReport);
}catch(e){
console.error(e);
}
try{
res = await device.receiveFeatureReport(reportId);
console.log(res);
}catch(e){
console.error(e);
}
output:
DataView(14)
DOMException: Failed to write the report.
DOMException: Failed to receive the feature report.
chrome://device-log/
HIDEvent[22:38:28] hid_connection_linux.cc:96 Failed to get feature report: Błąd protokołu (71) (protocol error)
HIDUser[22:38:28] hid_connection.cc:113 This device does not support output reports.
HIDUser[22:38:03] hid_service.cc:131 HID device added: vendorId=1, productId=0, name='MEC MEC0003', serial='', deviceIds=[/sys/devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.0/0003:0001:0000.0145/hidraw/hidraw1']
USBUser[22:38:03] usb_service_linux.cc:304 USB device added: path=/dev/bus/usb/003/067 vendor=1 "MEC", product=0 "MEC0003", serial="", guid=1aa3c203-8f53-40f7-9d0d-38bc032f439e
$ usbhid-dump -m 0001:0000
003:076:000:DESCRIPTOR 1627334825.314075
05 86 09 04 A1 01 05 84 09 1E A1 00 85 01 09 1F
65 00 75 04 95 01 15 00 25 0F 65 00 B1 02 75 04
95 01 B1 03 09 40 75 10 95 01 67 21 D1 F0 00 55
07 15 00 26 FA 00 B1 02 09 42 75 10 95 01 66 01
F0 55 00 15 00 25 3C B1 02 09 53 75 10 95 01 67
21 D1 F0 00 55 07 15 00 26 FA 00 B1 02 09 54 75
10 95 01 67 21 D1 F0 00 55 07 15 00 26 FA 00 B1
02 09 FD 09 FE 09 FF 75 08 95 03 26 FF 00 65 00
B1 00 C0 05 84 09 1E A1 00 85 02 09 1F 65 00 75
04 95 01 15 00 25 0F 65 00 B1 02 95 01 75 04 B1
03 09 40 75 10 95 01 67 21 D1 F0 00 55 07 15 00
26 FA 00 B1 02 09 42 75 10 95 01 66 01 F0 55 00
15 00 25 3C B1 02 09 43 75 10 95 01 66 21 D1 55
07 15 00 27 FE FF 00 00 B1 02 09 44 95 01 75 10
66 21 D1 55 07 15 00 27 FE FF 00 00 B1 02 09 56
75 18 95 01 66 01 10 55 00 15 00 27 FE FF 00 00
B1 02 09 57 75 18 95 01 66 01 10 55 00 15 00 27
FE FF 00 00 B1 02 C0 05 84 09 10 A1 00 85 03 09
11 65 00 75 04 95 01 15 00 25 0F 65 00 B1 02 75
04 95 01 B1 03 09 02 A1 02 09 6D 09 61 75 01 95
02 15 00 25 01 B1 02 75 06 95 01 B1 03 C0 09 30
75 18 95 01 67 21 D1 F0 00 55 05 27 FE FF 00 00
B1 02 09 36 75 10 95 01 67 01 00 01 00 27 FE FF
00 00 B1 02 09 58 75 01 95 06 15 00 25 01 81 02
75 02 95 01 81 03 09 58 75 01 95 04 15 00 25 01
B1 02 75 04 95 01 B1 03 C0 05 84 09 16 A1 00 85
04 09 17 75 04 95 01 15 00 25 0F 65 00 81 02 75
04 95 01 81 03 09 1A A1 00 09 1B 09 1F 75 04 95
02 15 00 25 0F 65 00 81 02 09 02 A1 02 09 61 75
01 95 01 15 00 25 01 81 02 75 07 95 01 81 03 C0
09 30 75 10 95 01 67 21 D1 F0 00 55 05 27 FE FF
00 00 81 02 09 32 75 10 95 01 66 01 F0 55 05 27
FE FF 00 00 81 02 C0 09 1C A1 00 85 05 09 1D 09
1F 75 04 95 02 15 00 25 0F 65 00 81 02 09 30 75
10 95 01 67 21 D1 F0 00 55 05 27 FE FF 00 00 81
02 09 32 75 10 95 01 66 01 F0 55 05 27 FE FF 00
00 81 02 09 35 75 10 95 01 15 00 26 FF 00 81 02
09 02 A1 02 09 65 09 6E 09 6F 75 01 95 03 15 00
25 01 65 00 81 02 75 05 95 01 81 03 C0 C0 C0 C0
$ lsusb -vd 0001:0000
Bus 003 Device 067: ID 0001:0000 Fry's Electronics MEC0003
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0001 Fry's Electronics
idProduct 0x0000
bcdDevice 1.00
iManufacturer 1 MEC
iProduct 2 MEC0003
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 624
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
Thanks for reply @nondebug, You are the best.
Is it possible that you will introduce the optional parameter to define a fixed buffer length? Or do you think there is any way to solve this problem in webhid implementation?
Cheers Patryk
Thanks for sharing the report descriptor. It looks like the device has five top-level Application Collections and six reports:
- Collection with usage Power Device / Flow (0084:001E)
- Feature report 0x01
- Collection with usage Power Device / Flow (0084:001E)
- Feature report 0x02
- Collection with usage Power Device / BatterySystem (0084:0010)
- Feature report 0x03
- Input report 0x03
- Collection with usage Power Device / PowerConverter (0084:0016)
- Input report 0x04
- Collection with usage Power Device / Output (0084:001C)
- Input report 0x05
Feature report 0x03 is 8 bytes long, or 9 bytes if the report ID byte is included, and contains information about the battery system:
- 8-bit report ID
- 4-bit value with usage Power Device / BatterySystemID (0084:0011)
- 4-bit constant value
- Logical collection with usage Power Device / PresentStatus (0084:0002)
- 1-bit value with usage Power Device / Used (0084:006D)
- 1-bit value with usage Power Device / Good (0084:0061)
- 6-bit constant value
- 24-bit value with usage Power Device / Voltage (0084:0030)
- 16-bit value with usage Power Device / Temperature (0084:0036)
- six 1-bit values with usage Power Device / Test (0084:0058)
- 2-bit constant value
HIDEvent[22:38:28] hid_connection_linux.cc:96 Failed to get feature report: Błąd protokołu (71) (protocol error)
HIDIOCGFEATURE is failing with EPROTO which suggests it's a bad device. I didn't have any luck tracking down exactly where the error comes from.
Please try modifying your test app to set the buffer size to a smaller value and verify that you get the same EPROTO error.
Is it possible that you will introduce the optional parameter to define a fixed buffer length? Or do you think there is any way to solve this problem in webhid implementation?
If we address the issue we'll do it in a way that doesn't modify the API.
In general I think WebHID shouldn't block any reports that are allowed by the platform API even if the reports are technically invalid. I think it would be good to handle this case. That said, it's probably not worth increasing the complexity of the implementation just to handle a single device, and so far there's no evidence of other devices with this issue.
There might be an opportunity for an easier fix that works for this device but may not work in the general case. For instance, a minimum buffer size of 64 bytes would be large enough for the status string returned by feature report 0x03.
Please try modifying your test app to set the buffer size to a smaller value and verify that you get the same EPROTO error.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <linux/input.h>
#include <linux/hidraw.h>
#define BUFFER_SIZE 8
int main(int argc, char **argv)
{
int fd, i, res = 0, reportId;
char buf[BUFFER_SIZE], *device = argv[1];
reportId = atoi(argv[2]);
fd = open(device, 0);
buf[0] = reportId;
if(argc > 3 && !strcmp("send", argv[3])){
res = ioctl(fd, HIDIOCSFEATURE(2), buf);
printf("test 1: %d \n\n", res);
if(0 >= res ) perror("HIDIOCSFEATURE"); else printf("sent test1 with success\n\n");
}
buf[0] = reportId;
res = ioctl(fd, HIDIOCGFEATURE(BUFFER_SIZE), buf);
printf("test 1: %d \n\n", res);
if(0 >= res ) perror("HIDIOCGFEATURE");
else{
printf("\n\nString representation: \n\n");
for (i=0; i < res; ++i) if(buf[i] > 0 && i >= 2) printf("%c", buf[i]);
printf("\n\ndecimal: \n\n");
for (i=0; i < res; ++i) printf("%d, ", buf[i]);
printf("\n\nhex: \n\n");
for (i=0; i < res; ++i) printf("0x%hhx, ", buf[i]);
printf("\n\n");
}
if(argc > 3 && !strcmp("send", argv[3])){
buf[0] = reportId;
res =ioctl(fd, HIDIOCSFEATURE(2), buf);
printf("test 3: %d \n\n", res);
if(0 >= res ) perror("HIDIOCSFEATURE"); else printf("sent test3 with success\n\n");
}
close(fd);
usleep(1000000);
return 0;
}
There might be an opportunity for an easier fix that works for this device but may not work in the general case. For instance, a > minimum buffer size of 64 bytes would be large enough for the status string returned by feature report 0x03.
Minimal buffer size to handle that report is #define BUFFER_SIZE 96 because it return response as fake unicde with an extra > zero after each byte.
So for #define BUFFER_SIZE 96: all is good like in previous test above
For #define BUFFER_SIZE 8 like You expected:
test 1: 2
sent test1 with success
test 1: -1
HIDIOCGFEATURE: Protocol error
test 3: -1
HIDIOCSFEATURE: Protocol error
For #define BUFFER_SIZE 94:
test 1: 2
sent test1 with success
test 1: -1
HIDIOCGFEATURE: Value too large for defined data type
test 3: 2
sent test3 with success
That said, it's probably not worth increasing the complexity of the implementation just to handle a single device, and so far there's no evidence of other devices with this issue.
I think 50% UPS devices use that MEC0003.
If we address the issue we'll do it in a way that doesn't modify the API.
Do you have any idea how to solve this problem?
Thanks for the really quick reply. You diagnose problems very rightly. It is enjoyable to debug problems with you :)
Best Patryk
Hi @nondebug
If we address the issue we'll do it in a way that doesn't modify the API.
Do you think we can solve this problem in any case? Can you enter a minimum and maximum buffer size in the next releases?
I would love to use this functionality from the chrome. I would like to aggregate many of our devices in it, unfortunately not all devices are produced by ourselves, we brand a lot and we have no influence on them. I think many lesser known devices may have a similar problem (or Chinese devices). For me, the best buffer size would be 128 bytes but I think a buffer of a few kilobytes would not be any problem with on-demand functionality.
I think it's solvable but I won't be confident in the fix if I can't test against a device that has the same behavior as yours.
Can you share a link to a product page that shows a picture of your device or its packaging? My guess is your device is designed for EU voltages but maybe I can track down a North American version.
I found this issue that suggests it could be a "Eurocase EA200LED 1200VA". Or maybe it's a "Logic Power UPS 2000".
I've filed a Chromium bug to document the issue: https://crbug.com/1234222