Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

usbhid-ups generally: apply disable_fix_report_desc…; cps-hid: fix mismatched LogMax between input/output voltages (bad encoding) #2718

Merged
merged 12 commits into from
Dec 18, 2024

Conversation

jimklimov
Copy link
Member

@jimklimov jimklimov commented Dec 12, 2024

…interruptsize and interruptonly before comm_driver->open_dev() [#1512, #1575]

Follows up from PR #1245 that addressed #439 and a ton of related issues.

@jimklimov jimklimov added bug USB service/daemon start/stop General subject for starting and stopping NUT daemons (drivers, server, monitor); also BG/FG/Debug USB-HID encoding/LogMin/LogMax Issues and solutions (PRs) specifically about incorrect values in bitstream impacts-release-2.8.1 Issues reported against NUT release 2.8.1 (maybe vanilla or with minor packaging tweaks) impacts-release-2.8.2 Issues reported against NUT release 2.8.2 (maybe vanilla or with minor packaging tweaks) labels Dec 12, 2024
@jimklimov jimklimov added this to the 2.8.3 milestone Dec 12, 2024
@jimklimov jimklimov added need testing Code looks reasonable, but the feature would better be tested against hardware or OSes CyberPower (CPS) labels Dec 13, 2024
@jimklimov
Copy link
Member Author

jimklimov commented Dec 13, 2024

Awaiting end-user testing with a custom build of NUT from this PR branch, as detailed in #1512 (comment) - namely, to test for voltage fix-ups, you can install the prerequisites for your platform as listed in links from the wiki article https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests e.g. at https://networkupstools.org/docs/user-manual.chunked/_build_prerequisites_to_make_nut_from_scratch_on_various_operating_systems.html, and build the PR source branch:

:; git clone https://github.com/jimklimov/nut -b issue-1575 nut-issue-1575
:; cd nut-issue-1575
:; BUILD_TYPE=inplace ./ci_build.sh

and then stop your current NUT driver service, and run sudo ./drivers/usbhid-ups -DDDDDD -d1 -a YourUpsName for a single (-d1) data-collection pass and dump, and post the results.

Remember you would need to comment away disable_fix_report_desc from ups.conf if it is there :)

CC @AlexJakeGreen @Timi7007

Also CC @nbriggs @flashydave : does the change make sense?

Adding pings for other related issues, to see if they can get closed by this (or earlier e.g. #1040, #1245) development, primarily on CPS Vendor ID 0x0764 devices with Product IDs 0x0501 and 0x0601. There seems to be quiet a list of CPS users bit by this, even though maybe I've missed some:

...and that there is no new regression for closed cases at (note the voltage data in some of the DDL dumps there seemed wrong, may be better now):

@jimklimov jimklimov changed the title drivers/usbhid-ups.c, NEWS.adoc: apply disable_fix_report_desc… usbhid-ups generally: apply disable_fix_report_desc…; cps-hid: fix mismatched LogMax between input/output voltages (bad encoding) Dec 13, 2024
@jimklimov jimklimov added the Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) label Dec 16, 2024
@AlexJakeGreen
Copy link

AlexJakeGreen commented Dec 16, 2024

I guess I collected observations properly ↓↓↓↓

Built from

git checkout issue-1575
   repository:               https://github.com/jimklimov/nut.git
   at the commit:            68bbe9cec2ae66c1c4d625d7429381013d46ce0f

Result of /lib64/nut/usbhid-ups -DDDDDD -d1 -a ups:
usbhid-ups_DDDDDD_d1_a_ups.txt.gz

Both input and output are wrong (expected somewhere between 230...232):

$ zgrep -E '(input|output).voltage:' usbhid-ups_DDDDDD_d1_a_ups.txt.gz 
input.voltage: 0.7
output.voltage: 0.7

Result of /lib64/nut/usbhid-ups -DDDDDD -d1 -x disable_fix_report_desc -a ups:
usbhid-ups_DDDDDD_d1_a_ups_x_disable_fix_report_desc.txt.gz
input is correct, output is wrong:

$ zgrep -E '(input|output).voltage:' usbhid-ups_DDDDDD_d1_a_ups_x_disable_fix_report_desc.txt.gz 
input.voltage: 225.4
output.voltage: 20.6

Real values for input and output are the same, but measurement difference is 2254 - 206 = 2048

ups.conf:
ups.conf.gz

@jimklimov
Copy link
Member Author

Thanks @AlexJakeGreen! This couple of data-dumps (and their comparison) looks most helpful. Reports differ in one byte (note 0xc7 vs. 0xce) and resulting "Value", reviewing if the byte-difference is due to our fixup.

Note that we see readings and conversions twice - in initial discovery and attempt to parse the HID report there, and (after Detected a UPS line) the "subsequent update" just before the driver's first data processing loop.

  • on one side I see the logic firing, even if not too correct-looking:
   0.011435	Using subdriver: CyberPower HID 0.82
   0.011454	[D3] Attempting Report Descriptor fix for UPS: Vendor: 0764, Product: 0601
   0.011468	[D4] Original Report Descriptor: output LogMin: 0 LogMax: 255 (assumed: yes)
   0.011479	[D4] Original Report Descriptor: input LogMin: 0 LogMax: 65535 (assumed: yes)
   0.011489	[D3] Fixing Report Descriptor: set Input Voltage LogMax = 12
   0.011499	[D3] Fixing Report Descriptor: set Output Voltage LogMax = 12
   0.011508	[D2] Report Descriptor Fixed
   0.011519	[D1] 73 HID objects found
...
### Initial data walk, Report 0x0f with fixup
   0.019406	[D4] Entering libusb_get_report
   0.019580	[D3] Report[get]: (3 bytes) => 0f c7 08
   0.019602	[D5] PhyMax = 0, PhyMin = 0, LogMax = 12, LogMin = 0
   0.019614	[D5] Unit = 00f0d121, UnitExp = 6
   0.019624	[D5] Exponent = -1
   0.019635	[D5] hid_lookup_path: 00840004 -> UPS
   0.019647	[D5] hid_lookup_path: 0084001a -> Input
   0.019658	[D5] hid_lookup_path: 00840030 -> Voltage
   0.019672	[D1] Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 0.7
...
### Initial data walk, Report 0x12 with fixup
   0.020846	[D4] Entering libusb_get_report
   0.021078	[D3] Report[get]: (3 bytes) => 12 c7 08
   0.021100	[D5] PhyMax = 0, PhyMin = 0, LogMax = 12, LogMin = 0
   0.021113	[D5] Unit = 00f0d121, UnitExp = 6
   0.021123	[D5] Exponent = -1
   0.021134	[D5] hid_lookup_path: 00840004 -> UPS
   0.021146	[D5] hid_lookup_path: 0084001c -> Output
   0.021157	[D5] hid_lookup_path: 00840030 -> Voltage
   0.021171	[D1] Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 0.7
...
### Subsequent (first) update, Report 0x0f with fixup
   0.242479	[D5] hid_lookup_usage: UPS -> 00840004
   0.242494	[D5] hid_lookup_usage: Input -> 0084001a
   0.242515	[D5] hid_lookup_usage: Voltage -> 00840030
   0.242527	[D4] string_to_path: depth = 3
   0.242545	[D3] Report[buf]: (3 bytes) => 0f c7 08
   0.242557	[D5] PhyMax = 0, PhyMin = 0, LogMax = 12, LogMin = 0
   0.242568	[D5] Unit = 00f0d121, UnitExp = 6
   0.242578	[D5] Exponent = -1
   0.242592	[D2] Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 0.7
   0.242611	[D5] send_to_all: SETINFO input.voltage "0.7"
...
### Subsequent (first) update, Report 0x12 with fixup
   0.243298	[D5] hid_lookup_usage: UPS -> 00840004
   0.243313	[D5] hid_lookup_usage: Output -> 0084001c
   0.243327	[D5] hid_lookup_usage: Voltage -> 00840030
   0.243339	[D4] string_to_path: depth = 3
   0.243355	[D3] Report[buf]: (3 bytes) => 12 c7 08
   0.243368	[D5] PhyMax = 0, PhyMin = 0, LogMax = 12, LogMin = 0
   0.243378	[D5] Unit = 00f0d121, UnitExp = 6
   0.243388	[D5] Exponent = -1
   0.243402	[D2] Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 0.7
   0.243420	[D5] send_to_all: SETINFO output.voltage "0.7"
...
  • for the other contender, the flag is now honoured (at least that fix works):
   0.000282	[D3] main_arg: var='disable_fix_report_desc' val='<null>'
   0.000303	[D5] send_to_all: SETINFO driver.flag.disable_fix_report_desc "enabled"
...
   0.010850	Using subdriver: CyberPower HID 0.82
   0.010864	[D3] NOT Attempting Report Descriptor fix for UPS: Vendor: 0764, Product: 0601 (got disable_fix_report_desc in config)
   0.010878	[D1] 73 HID objects found
...
### Initial data walk, Report 0x0f without fixup
   0.020566	[D4] Entering libusb_get_report
   0.020728	[D3] Report[get]: (3 bytes) => 0f ce 08
   0.020745	[D5] PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0
   0.020757	[D5] Unit = 00f0d121, UnitExp = 6
   0.020768	[D5] Exponent = -1
   0.020778	[D5] hid_lookup_path: 00840004 -> UPS
   0.020789	[D5] hid_lookup_path: 0084001a -> Input
   0.020801	[D5] hid_lookup_path: 00840030 -> Voltage
   0.020817	[D1] Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 225.4
...
### Initial data walk, Report 0x12 without fixup
   0.021614	[D4] Entering libusb_get_report
   0.021805	[D3] Report[get]: (3 bytes) => 12 ce 08
   0.021823	[D5] PhyMax = 0, PhyMin = 0, LogMax = 255, LogMin = 0
   0.021835	[D5] Unit = 00f0d121, UnitExp = 6
   0.021845	[D5] Exponent = -1
   0.021856	[D5] hid_lookup_path: 00840004 -> UPS
   0.021867	[D5] hid_lookup_path: 0084001c -> Output
   0.021879	[D5] hid_lookup_path: 00840030 -> Voltage
   0.021894	[D1] Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 20.6
...
### Subsequent (first) update, Report 0x0f without fixup
   0.241426	[D5] hid_lookup_usage: UPS -> 00840004
   0.241440	[D5] hid_lookup_usage: Input -> 0084001a
   0.241454	[D5] hid_lookup_usage: Voltage -> 00840030
   0.241465	[D4] string_to_path: depth = 3
   0.241481	[D3] Report[buf]: (3 bytes) => 0f ce 08
   0.241493	[D5] PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0
   0.241504	[D5] Unit = 00f0d121, UnitExp = 6
   0.241514	[D5] Exponent = -1
   0.241529	[D2] Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 225.4
   0.241567	[D5] send_to_all: SETINFO input.voltage "225.4"
...
### Subsequent (first) update, Report 0x12 without fixup
   0.242283	[D5] hid_lookup_usage: UPS -> 00840004
   0.242298	[D5] hid_lookup_usage: Output -> 0084001c
   0.242313	[D5] hid_lookup_usage: Voltage -> 00840030
   0.242324	[D4] string_to_path: depth = 3
   0.242340	[D3] Report[buf]: (3 bytes) => 12 ce 08
   0.242353	[D5] PhyMax = 0, PhyMin = 0, LogMax = 255, LogMin = 0
   0.242363	[D5] Unit = 00f0d121, UnitExp = 6
   0.242373	[D5] Exponent = -1
   0.242388	[D2] Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 20.6
   0.242406	[D5] send_to_all: SETINFO output.voltage "20.6"
...

I am not sure if the fixup is related to issues occasionally seen after upsdrv_updateinfo line (happened in both cases at different times), or if it is the firmware acting up:

  • first couple:
### with fixup
   0.254606	[D1] upsdrv_updateinfo...
   1.005307	[D2] nut_libusb_get_interrupt: Connection timed out
   1.005338	[D1] Got 0 HID objects (1 times in a row, tolerance is -1)...
   1.005354	[D1] Quick update...
...

### without fixup:
   0.246060	[D1] upsdrv_updateinfo...
   0.357154	[D3] Report[int]: (6 bytes) => 08 64 60 09 2c 01
   0.357187	[D1] Got 3 HID objects...
...
  • second couple:
### with fixup
   1.005866	[D1] upsdrv_updateinfo...
   1.756564	[D2] nut_libusb_get_interrupt: Connection timed out
   1.756596	[D1] Got 0 HID objects (2 times in a row, tolerance is -1)...
   1.756612	[D1] Quick update...
   1.756625	[D4] Entering libusb_get_report
   1.757708	[D2] nut_libusb_get_report: Overflow
   1.757745	[D1] Can't retrieve Report 16: Success
   1.757760	[D4] Entering libusb_get_report
   1.758624	[D2] nut_libusb_get_report: Overflow
   1.758644	[D1] Can't retrieve Report 15: Success
   1.758658	[D4] Entering libusb_get_report
   1.759170	[D2] nut_libusb_get_report: Overflow
   1.759195	[D1] Can't retrieve Report 0b: Success
   1.759209	[D4] Entering libusb_get_report
   1.759596	[D2] nut_libusb_get_report: Overflow
   1.759616	[D1] Can't retrieve Report 0b: Success
   1.759628	[D4] Entering libusb_get_report
   1.760082	[D2] nut_libusb_get_report: Overflow
   1.760102	[D1] Can't retrieve Report 0b: Success
   1.760114	[D4] Entering libusb_get_report
   1.760563	[D2] nut_libusb_get_report: Overflow
   1.760591	[D1] Can't retrieve Report 0b: Success
   1.760620	[D5] send_to_all: SETINFO driver.state "quiet"
   1.760641	[D5] send_to_all: SETINFO driver.state "dumping"
...

### without fixup:
   0.358019	[D1] upsdrv_updateinfo...
   1.108485	[D2] nut_libusb_get_interrupt: Connection timed out
   1.108516	[D1] Got 0 HID objects (1 times in a row, tolerance is -1)...
   1.108532	[D1] Quick update...
   1.108548	[D3] Report[buf]: (3 bytes) => 16 ff ff
   1.108561	[D5] PhyMax = 1966020, PhyMin = -60, LogMax = 32767, LogMin = -1
   1.108572	[D5] Unit = 00001001, UnitExp = 0
   1.108582	[D5] Exponent = 0
   1.108598	[D2] Path: UPS.Output.DelayBeforeStartup, Type: Feature, ReportID: 0x16, Offset: 0, Size: 16, Value: -60
   1.108618	[D3] Report[buf]: (3 bytes) => 15 ff ff
   1.108630	[D5] PhyMax = 1966020, PhyMin = -60, LogMax = 32767, LogMin = -1
   1.108641	[D5] Unit = 00001001, UnitExp = 0
   1.108651	[D5] Exponent = 0
   1.108664	[D2] Path: UPS.Output.DelayBeforeShutdown, Type: Feature, ReportID: 0x15, Offset: 0, Size: 16, Value: -60
   1.108682	[D3] Report[buf]: (2 bytes) => 0b 13
   1.108694	[D5] PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
   1.108705	[D5] Unit = 00000000, UnitExp = 0
   1.108714	[D5] Exponent = 0
   1.108728	[D2] Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x0b, Offset: 0, Size: 1, Value: 1
   1.108738	[D5] hu_find_infoval: found online (value: 1)
   1.108749	[D5] process_boolean_info: online
   1.108761	[D3] Report[buf]: (2 bytes) => 0b 13
   1.108773	[D5] PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
   1.108784	[D5] Unit = 00000000, UnitExp = 0
   1.108793	[D5] Exponent = 0
   1.108806	[D2] Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, ReportID: 0x0b, Offset: 1, Size: 1, Value: 1
   1.108816	[D5] hu_find_infoval: found chrg (value: 1)
   1.108826	[D5] process_boolean_info: chrg
   1.108839	[D3] Report[buf]: (2 bytes) => 0b 13
   1.108851	[D5] PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
   1.108861	[D5] Unit = 00000000, UnitExp = 0
   1.108871	[D5] Exponent = 0
   1.108884	[D2] Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature, ReportID: 0x0b, Offset: 2, Size: 1, Value: 0
   1.108894	[D5] hu_find_infoval: found !dischrg (value: 0)
   1.108904	[D5] process_boolean_info: !dischrg
   1.108917	[D3] Report[buf]: (2 bytes) => 0b 13
   1.108928	[D5] PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
   1.108939	[D5] Unit = 00000000, UnitExp = 0
   1.108949	[D5] Exponent = 0
   1.108961	[D2] Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: Feature, ReportID: 0x0b, Offset: 3, Size: 1, Value: 0
   1.108975	[D5] hu_find_infoval: found !lowbatt (value: 0)
   1.108985	[D5] process_boolean_info: !lowbatt
   1.109009	[D5] send_to_all: SETINFO driver.state "quiet"
   1.109024	[D5] send_to_all: SETINFO driver.state "dumping"
...

Seemingly more offtopic right now: there are also quite a few entries (for different Reports) like:

   0.030167	[D4] Entering libusb_get_report
   0.030435	[D2] nut_libusb_get_report: Overflow
   0.030456	[D1] Can't retrieve Report 2d: Success
   0.030469	[D5] hid_lookup_path: 00840004 -> UPS
   0.030482	[D5] hid_lookup_path: ff01001d -> not found in lookup table
   0.030494	[D5] hid_lookup_path: ff01001b -> not found in lookup table
   0.030506	[D5] hid_lookup_path: ff01001f -> not found in lookup table
   0.030518	[D1] Path: UPS.ff01001d.ff01001b.ff01001f, Type: Feature, ReportID: 0x2d, Offset: 2, Size: 1

...where on one hand, we do not even know the mapping of numeric HID path components to their logical roles/names, and on another - something overflows. I did not investigate what happens, but we might expect a number by default and get a string (too large for a buffer) or something else - just guessing based on it being an unknown report, and that we SETINFO strings (mfr, model, etc.) just after those.

Also more specifically about string fetches (which I think #2604 should have solved, unless this dialog is broken in some other way):

   0.032835	[D2] Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, ReportID: 0x04, Offset: 0, Size: 8, Value: 4
   0.033137	[D1] nut_usb_get_string_descriptor: string descriptor 0 request failed, retrying...
   0.084018	[D1] nut_usb_get_string_descriptor: string descriptor 0 request failed, retrying...
   0.134874	[D2] nut_libusb_get_string: Overflow
   0.134914	[D5] send_to_all: SETINFO battery.type ""
...

   0.135121	[D2] Path: UPS.PowerSummary.iOEMInformation, Type: Feature, ReportID: 0x03, Offset: 0, Size: 8, Value: 3
   0.136103	[D1] nut_usb_get_string_descriptor: string descriptor 0 request failed, retrying...
   0.187014	[D1] nut_usb_get_string_descriptor: string descriptor 0 request failed, retrying...
   0.237877	[D2] nut_libusb_get_string: Overflow
   0.237918	[D5] send_to_all: SETINFO battery.mfr.date ""

jimklimov added a commit to jimklimov/nut that referenced this pull request Dec 16, 2024
jimklimov added a commit to jimklimov/nut that referenced this pull request Dec 16, 2024
@jimklimov
Copy link
Member Author

jimklimov commented Dec 16, 2024

@AlexJakeGreen: thanks again for the logs, I caught the bug I think (got distracted and mixed up the languages, mindlessly used ^ as power-of operator when it was not). Now the code should limit LogMax=32767 for the 16-bit signed value (CC @nbriggs - I hope this is the most correct guess when we imagine things in lieu of a good statement in device reports, e.g. 65535 would be wrong, right?)

Can you please re-check with the descriptor fix-up?

Please note that I had to force-push the changes after an update from master branch, so you'd likely need to remove and recreate the build workspace, fetching the new state of the PR source branch.

Or if you're comfortable with git, try something like this to change the workspace files "in place":

:; git fetch --all && git reset origin/issue-1575 && git checkout -f

@jimklimov
Copy link
Member Author

Sounds plausible. I think I'll pick this up for a comment in LogMax fixup.

As for 327V... maybe 3-phase devices can claim 420V. I guess we'd see if there are any practical bug reports against 32767 (or their makers get specs right).

@Timi7007
Copy link

As for 327V... maybe 3-phase devices can claim 420V. I guess we'd see if there are any practical bug reports against 32767 (or their makers get specs right).

In the 60Hz part of the world it's a different story and I'm not an expert, but in our European 50Hz grid single phase is 230 V ± 10%/23 V so between 207V and 253V. Three-phase used to be 380V and 415V, they now met in the middle at 400V ± 10% setting the maximum to 440V.
Since the UPS should kick in even if the grid values are violated (e.g. overloaded generator) everything lower than these should also be functional. This coincidentally includes the 120V single-phase three-leg 60Hz US-power and it's three-phase potentials of 208V and 415V. Even the lowest international grid voltage of Japan's 100V.

That's just power theory though and I don't have a clue about USB drivers.

@jimklimov
Copy link
Member Author

Ok, so to err on the safe side, I'll assume 65535 for the 16-bit maximum (=>655V)?

Or... wait... with Exponent = -1 we count in 0.1V not 0.01V - so a 32767 value is 3276,7V anyway? Did someone up in the thread try to confuse me? ;p

@Timi7007
Copy link

Timi7007 commented Dec 17, 2024

I know of industrial setups with 690V three-phase power with 400V on each phase but haven't heard of UPSes for those and would assume anything that high would be over-voltage for everything used in IT.
I also don't know how NUT handles three-phase UPSes. Realistically measuring each phase and calculating total voltage from that would work just fine and may be somewhat more useful for diagnostics. So again no idea if 65535 would be required, I was just trying to say that 420V might not be unrealistic.

@Timi7007
Copy link

My test was successful: #1512 (comment)

@jimklimov jimklimov merged commit 38b7051 into networkupstools:master Dec 18, 2024
30 checks passed
@jimklimov jimklimov deleted the issue-1575 branch December 18, 2024 11:44
jimklimov added a commit that referenced this pull request Dec 18, 2024
…p for input_logmin/input_logmax vs. high voltage transfer [#1245, #2718]

Signed-off-by: Jim Klimov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug CyberPower (CPS) impacts-release-2.8.1 Issues reported against NUT release 2.8.1 (maybe vanilla or with minor packaging tweaks) impacts-release-2.8.2 Issues reported against NUT release 2.8.2 (maybe vanilla or with minor packaging tweaks) Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) need testing Code looks reasonable, but the feature would better be tested against hardware or OSes service/daemon start/stop General subject for starting and stopping NUT daemons (drivers, server, monitor); also BG/FG/Debug USB USB-HID encoding/LogMin/LogMax Issues and solutions (PRs) specifically about incorrect values in bitstream
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants