Hi,
In the last couple of months I have been developing an HID device.
To communicate with my device I use hid_api which is a cross plataform wrapper, which by it’s turn uses HID user API of Windows.
Today, after updating to Windows 8.1, I can’t perform GetFeature calls. They result in error.
Does anybody here suffered of the same problem?
Does anyone know what might be happening?
Regards,
Nuno Santos
www.displax.com
xxxxx@imaginando.net wrote:
In the last couple of months I have been developing an HID device.
To communicate with my device I use hid_api which is a cross plataform wrapper, which by it’s turn uses HID user API of Windows.
Today, after updating to Windows 8.1, I can’t perform GetFeature calls. They result in error.
Does anybody here suffered of the same problem?
There is no such thing as a “Get Feature” request. There is “Set
Feature” and “Clear Feature”, but there is no standard request to
determine the current state of a feature.
Do you mean you are doing a HID Get_Report on a feature report? Exactly
what USB request are you making?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
And what permissions are you requesting when opening the file handle?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, December 11, 2013 12:09 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Can’t perform HID Get Feature after updating to Windows 8.1
xxxxx@imaginando.net wrote:
In the last couple of months I have been developing an HID device.
To communicate with my device I use hid_api which is a cross plataform wrapper, which by it’s turn uses HID user API of Windows.
Today, after updating to Windows 8.1, I can’t perform GetFeature calls. They result in error.
Does anybody here suffered of the same problem?
There is no such thing as a “Get Feature” request. There is “Set Feature” and “Clear Feature”, but there is no standard request to determine the current state of a feature.
Do you mean you are doing a HID Get_Report on a feature report? Exactly what USB request are you making?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Hi Tim, Doron,
Sorry for the typo, I mean GetFeatureReport.
After desperating a little bit I have found that the problem was due to file handle permissions. However this, can become quite critic. Let me explain.
hid_api, originally defines the open_device the way below. Depending on if it is called during a simple enumerate or a explict open, a boolean flag enumerate is specified, which will condition the desired access and share mode. On my first experience with this lib on Windows 8 (didn’t test it on Windows 7 yet), I had to modify desired_access to (GENERIC_WRITE | GENERIC_READ) and share_mode to (FILE_SHARE_READ|FILE_SHARE_WRITE), otherwise I couldn’t make any request to the device, only list them.
Since my upgrade do Windows 8.1 yesterday, I had to change the desired_access and share mode to (GENERIC_WRITE | GENERIC_READ) and FILE_SHARE_READ respectively.
As you might agree, this effectively concerns me. First of all, why isn’t this coehrent across Windows versions? How can I guarantee that my control panel will work across several Windows versions?
I hope your expertise can help me understand the differences and what should I do in order to keep my “sanity intact”! 
I’m using hid_api because it saves me the hassle of writing custom code for Windows, Linux and Mac OSX. Beside this question of the open device desired access and share mode, I hadn’t any other problem with the lib so far. Below is the code for open_device and the link for hid_api github project.
static HANDLE open_device(const char *path, BOOL enumerate)
{
HANDLE handle;
DWORD desired_access = (enumerate)? 0: (GENERIC_WRITE | GENERIC_READ);
DWORD share_mode = (enumerate)?
FILE_SHARE_READ|FILE_SHARE_WRITE:
FILE_SHARE_READ;
handle = CreateFileA(path,
desired_access,
share_mode,
NULL,
OPEN_EXISTING,
FILE_FLAG_OVERLAPPED,/*FILE_ATTRIBUTE_NORMAL,*/
0);
return handle;
}
https://github.com/signal11/hidapi/blob/master/windows/hid.c
With my best regards,
Nuno Santos
xxxxx@imaginando.net wrote:
hid_api, originally defines the open_device the way below. Depending on if it is called during a simple enumerate or a explict open, a boolean flag enumerate is specified, which will condition the desired access and share mode. On my first experience with this lib on Windows 8 (didn’t test it on Windows 7 yet), I had to modify desired_access to (GENERIC_WRITE | GENERIC_READ) and share_mode to (FILE_SHARE_READ|FILE_SHARE_WRITE), otherwise I couldn’t make any request to the device, only list them.
Since my upgrade do Windows 8.1 yesterday, I had to change the desired_access and share mode to (GENERIC_WRITE | GENERIC_READ) and FILE_SHARE_READ respectively.
Is your device also being claimed by the operating system? If your
device is operating as a normal HID device, then it may be the operating
system itself has a handle that is conflicting with yours.
However, there are no circumstances in which adding FILE_SHARE_WRITE
should restrict your success. FILE_SHARE_READ|FILE_SHARE_WRITE should
be giving you the maximum possible exposure. Exactly what error were
you getting when this failed?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.