Win 7 Sensor Driver

[WindowsNT]

I am trying to create the UMDF sensor driver for Windows 7.

While the driver correctly reports device = 6 when using ISimpleDevice::GetType(), when running under the context of the user-mode driver framework it returns a 0.

Are there issues I must consider before trying to load the driver under the Wu Host ? I 've tried with COINIT_APARTMENTTHREADED and COINIT_MULTITHREADED, same error. It reports that no device is attached.

At the same time, normal applications work with it.

Best Regards.

[jwick]

Hi WindowsNT,

From the deviceType 0, it appears that the initialization isn't working.

We've never tried, or imagined that someone would try, to use this API in a UDMF driver. We suggest Raw Input.

If you want to continue to proceed with 3DxInput, please create a log file showing your connection attempt, and post it here (do try to keep it short). You can turn on the log file in the GUI. It gets written to your %appdata%\3dconnexion\3dxware dir.

[WindowsNT]

I don't see any log file. It is running under wudfhost.exe which is a local service - perhaps you could save the data into another folder.

Also, does your implementation create a hidden window for WM_INPUT ? If so, that could be a reason of failure. For the same reason I don't believe I can use raw input.

I am trying to create a sensor driver and I would be done already If could get through this.

[jwick]

Oh, you are running as a service. I don't think you can create windows as a service. This is the same reason our new driver isn't a service. 3DxInput uses a hidden window to communicate with the driver.

You might have to use HID. It doesn't require a window. See our sample HID code.

[WindowsNT]

I 'll try. I 've never used HID but it shouldn't be that tough.

[WindowsNT]

Failure ;(

Although HidD* functions are supposed to be available to all user mode applications, not all of them apparantely are available to UMDF , including the Preparsed Data crucial calls.

[jwick]

Then I'm at a loss. There are kernel versions of some of those HID calls. Perhaps you should ask on the UMDF forums. These are all MS products we are trying to work with here. I'm sure they have a vision of how they work together. Please post any info you get from them.

[WindowsNT]

The problem is that a sensor driver must be an UMDF and not a KMDF. But I asked the sensor msdn forum (although I doubt if anyone will know something at there - it seems that the sensor technology is too new), and I am waiting for a response.

[WindowsNT]

I 've managed to open the driver with CreateFile().

I am trying to understand the format returned - a quick explanation would help.

[WindowsNT]

And by the way, is the driver always "\\?\HID#VID_046D&PID_C626#6&10bdce10&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" ?

[WindowsNT]

I got the raw input sample with WM_INPUT, presumably its the same format.

[jwick]

That name is for the device not the driver. You are connecting directly to the device and bypassing the driver. You don't even need to install the driver.

You'll notice the HID Vendor ID (VID) in there (0x046D for all Logitech devices), then the Product ID (PID) for the device you have attached (0xC626 in this case). The PID and everything after it will vary.

[WindowsNT]

Does this mean that {4d1e55b2-f16f-11cf-88cb-001111000030} is not fixed ?
How would you suggest for me to detect the device accurately?

[jwick]

I actually don't know if that UUID is fixed. The first thing I'd try is to check it on another USB port and/or hub layout.

The driver enumerates all the HID devices looking at the VID and then PID (to distinguish 3D mouse devices from other Logitech devices (2D mouse, keyboard, cameras, etc.)).

[WindowsNT]

Okay I am uploading the driver in a minute.