What's Changed

Updates the crate version in anticipation of a v1.0 tagged release.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

• N/A

Integration Instructions

• N/A
  
  

Full Changelog: https://github.com/microsoft/mu_rust_hid/compare/v1.0.0...v1.0.1

What's Changed

Refactor the project structure to make it more idiomatic by using the built-in way of doing examples. Previously, we used workspace to separate the project library and the binary use as example, which made the project more complex.

To do so, I move the content of the hidparser workspace as the root project and the content of hidparse workspace in the examples folder. main.rs has become hidparse.rs since it is the test name.

Pros of using the examples folder:

• Simpler to understand which code part of the library and which code is part of the example.
• Easier to add other examples in the future.
• Examples dependency can be managed with [dev-dependency] and make the difference between library dependency and example dependency clearer.
• Examples are built when doing cargo test so it ensures that they always build.
• Examples can be installed with the command `cargo install --example

Now instead of doing cargo run to execute the cli, we need to do cargo run --example hidparse
Ex: cargo run --example hidparse -- --path .\examples\samples\boot_keyboard.bin

Cargo book - Examples

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

• Run the example and expect the same output as before.
• Change the hidparser dependency github link for this branch in Devices project and everything should build and test as usual with cargo make build and cargo make test. In Cargo.toml: hidparser = {git = "https://github.com/magravel/mu_rust_hid.git", branch = "review_mu_rust_hid-task-4098342"}

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Made some changes that makes the code more rutsy.

• Impact functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

I test this feature by running cargo make build and cargo make test in the devices repository with my code as dependency.

Integration Instructions

N/A

⚠️ Breaking Changes

Description

This allows handling descriptors that are not completely per HID spec; this allows partial support for devices where some reports are not valid, but some are. This gives more flexibility in supporting hardware with various degrees of adherence to spec requirements.

• Impacts functionality?
  • If an error is detected in a report descriptor, only the affected reports are not parsed. Other reports that are valid within the same descriptor are still parsed and returned. Parsing returns a list of any errors determined along with the ids (if any) of the affected reports.
• Impacts security?
• Breaking change?
  • The main parsing API (`ReportDescriptor::parse(&[u8]) -> Result<ReportDescriptor, ReportDescriptorError> does not change, but the definition of ReportDescriptor expands to include "bad descriptor" lists to report parsing failures, and error is no longer returned for the whole descriptor for all errors. Invalid item tokenization will still cause the whole descriptor parse to fail, but if an error is localized (like missing report count), then the remaining unaffected reports are returned.
• Includes tests?
  • Tests and examples updated to accommodate the change.
• Includes documentation?

How This Was Tested

Unit tests updated and passed, example parser behavior verified on good and bad descriptors.

Integration Instructions

N/A unless the application was previously relying on descriptor parse failure semantics in some way, in which case error cases may need to be revisited.

Full Changelog: https://github.com/microsoft/mu_rust_hid/compare/v0.2.2...v1.0.0

What's Changed

Use cargo tarpaulin for testing, which creates code coverage results. Upload those results to codecov.io

• Impacts functionality?
  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...
• Impacts security?
  • Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  • Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
• Breaking change?
  • Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  • Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
• Includes tests?
  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests, integration tests, robot tests, ...
• Includes documentation?
  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

<Please describe the test(s) that were run to verify the changes.>

Integration Instructions

<Describe how these changes should be integrated. Use N/A if nothing is required.>

Derives implementations of PartialEq/Eq traits for HID report descriptor structures.

• Impacts functionality?
  • Adds PartialEq/Eq implementations for report descriptor structures.
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

PR includes a unit test that parses a report descriptor twice and verifies the results are equal.

Integration Instructions

N/A

HID spec indicates that LogicalMaximum should be treated as signed (i32) when LogicalMinimum is negative, but unsigned (u32) when LogicalMinum is not negative. Prior to this modification, the field_value() routine was always treating LogicalMaximum as i32, resulting in incorrect handling of some fields. This change addresses that, and adds a test to catch it.

• Impacts functionality?
  • Fixes a bug in field_value() computation
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

Verified in QEMU, which has a USB keyboard implementation that reports LogicalMinimum(0), LogicalMaximum(0xffffffff) that triggers this issue.

This PR also incorporates unit tests to reproduce the issue, and these tests pass.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_rust_hid/compare/v0.2.1...v0.2.2

What's Changed

🚀 Features & ✨ Enhancements

Description

Add set_field_data() and set_field_values() functions on VariableFields. These routines take a report buffer and modify data for the bit positions associated with the field location.

• Impacts functionality?
  • Adds two new functions to VariableField
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

Unit tests incorporated.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_rust_hid/compare/v0.2.0...v0.2.1

What's Changed

🚀 Features & ✨ Enhancements

Initial import of hidparse and hid_report_descriptor_parser crates.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• includes unit tests for hid_report_descriptor_parser crates and hidparse command utility.
• Includes documentation?
  • Standard rustdocs

How This Was Tested

Built in unit tests, functional testing with real hardware.

Integration Instructions

Crate may be leveraged via standard rust crate usage practice.

📖 Documentation Updates

Initial import of hidparse and hid_report_descriptor_parser crates.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• includes unit tests for hid_report_descriptor_parser crates and hidparse command utility.
• Includes documentation?
  • Standard rustdocs

How This Was Tested

Built in unit tests, functional testing with real hardware.

Integration Instructions

Crate may be leveraged via standard rust crate usage practice.

Full Changelog: https://github.com/microsoft/mu_rust_hid/compare/v0.1.0...v0.2.0

What's Changed

• Run spell check against .md, .py, and .rs files in the repo

• Run markdownlint against .md files in the repo

• Impacts functionality?

  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...

• Impacts security?

  • Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  • Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...

• Breaking change?

  • Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  • Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...

• Includes tests?

  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests, integration tests, robot tests, ...

• Includes documentation?

  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

PR pipelines.

Integration Instructions

N/A

• Base readme
• Contributing, license, security, etc.
• Tool configuration
• GitHub configuration files and workflows
  
  

Full Changelog: https://github.com/microsoft/mu_rust_hid/compare/...v0.1.0