1 Topic by vondollie

  • vondollie
  • New member
  • Offline
  • Registered: 2026-03-21
  • Posts: 2

Topic: HidSharp Feature request: HID device in write-only or read-only mode

Hi James,

I have one use-case where the current API is quite painful to work around, and I think adding support for write-only or read-only opening would help a lot of people.

My scenario:
I need to send Feature Reports to a HID mouse (mostly to control RGB lighting, DPI stages, polling rate, etc. on gaming mice).

On Windows:
The mouse is opened successfully with GENERIC_WRITE access
Writing Feature Reports (via HidD_SetFeature) works perfectly
But Windows refuses to open the same device with GENERIC_READ access.
When I do device.TryOpen(out var stream) in HidSharp, it requests both read and write access and fails.

Feature request / suggestion
An OpenMode / Access option in TryOpen(OpenConfiguration)

Something like:
var config = new OpenConfiguration();
config.SetOption(OpenOption.ReadAccess, true);
config.SetOption(OpenOption.WriteAccess, true);
device.TryOpen(config, out var stream);

This would allow clean write-only usage for exactly the kind of devices that Windows protects from being read (mice, some keyboards, touchpads, etc.) while still letting us send output/feature reports.

Thanks for considering this.

2 Reply by vondollie

  • vondollie
  • New member
  • Offline
  • Registered: 2026-03-21
  • Posts: 2

Re: HidSharp Feature request: HID device in write-only or read-only mode

Just wanted to add one more practical workaround (and which I've implemented myself for now):
Instead of always forcing Read+Write access, try opening the device multiple times with falling back to reduced access modes if the full one fails. 

IntPtr handle = NativeMethods.CreateFileFromDevice(path, NativeMethods.EFileAccess.Read | NativeMethods.EFileAccess.Write, NativeMethods.EFileShare.Read | NativeMethods.EFileShare.Write);
if (handle == (IntPtr)(-1))
{
    handle = NativeMethods.CreateFileFromDevice(path, NativeMethods.EFileAccess.Read, NativeMethods.EFileShare.Read | NativeMethods.EFileShare.Write);
}

if (handle == (IntPtr)(-1))
{
    handle = NativeMethods.CreateFileFromDevice(path, NativeMethods.EFileAccess.Write, NativeMethods.EFileShare.Read | NativeMethods.EFileShare.Write);
}

if (handle == (IntPtr)(-1))
{
    throw DeviceException.CreateIOException(Device, "Unable to open HID class device (" + path + ").", Marshal.GetHRForLastWin32Error());
}

To make this even cleaner in HidSharp, it would be great if after a successful open, the HidStream (or a new DeviceStream base) exposed read-only properties like:

public bool CanRead { get; }     // true if GENERIC_READ was granted
public bool CanWrite { get; }    // true if GENERIC_WRITE was granted

This would allow user code to gracefully check capabilities at runtime (e.g. skip async read loops if !CanRead, or show a warning if !CanWrite).
Many devices (especially mice) will happily accept writes without read access, but HidSharp's current TryOpen always requests both → which fails with Access Denied (5) or Sharing Violation (32) on protected input devices.
This fallback strategy has worked reliably for me on several gaming mice where I only send RGB/DPI Feature Reports.
What do you think — would something like configurable access fallbacks or post-open CanRead/CanWrite props be feasible to add?
Thanks again!