buffer[offset + 1] = reportID;
int bytes = NativeMethods.ioctl(_handle, NativeMethods.HIDIOCGFEATURE(count - 1), (IntPtr)(ptr + offset + 1));
if (bytes < 0) { throw new IOException("GetFeature failed."); }
Array.Clear(buffer, 1 + bytes, count - (1 + bytes));

to

int bytes = NativeMethods.ioctl(_handle, NativeMethods.HIDIOCGFEATURE(count), (IntPtr)(ptr + offset));
if (bytes < 0) { throw new IOException("GetFeature failed."); }
if(buffer.Length < offset + bytes)
    Array.Clear(buffer, offset + bytes, buffer.Length - offset - bytes);

I am not sure why the whole operation was shifted by one in the first place, but reading over the original buffer, without an offset of 1, seems to work for my use case.

SetFeature works great, but I seem to be running into an issue with GetFeature, which I believe to be with the library.

Whenever I try to read data from the device, all bytes after the report id appears to be shifted by one.

eg, reading the color back from the device, I expect back the following sequence:

ReportId, 'r', R, G, B, 0, 0, 0

But instead I get

ReportId, 0, 'r', R, G, B, 0, 0

Other reads are similarly suffering from an added zero byte after the report id.

Looking at the source for the LinuxHidStream class, in the GetFeature method, the call to ioctl passes numPtr + offset + 1 as the value argument. While I admit to not fully understand that low level call, I was wondering if perhaps that value should not have one added to it, as this amendment might already be taken into account by the system call.

Is anyone else experiencing a similar issue? Or is it just me?

My next step is to remove the NuGet reference, clone the source, make the change, and see if it solves the problem. I'll report back with my findings.