It's impossible to read data from vmulti

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open any HID device that supports reading with CreateFile
2. Try to read from it with ReadFile without overlapped IO

What is the expected output? What do you see instead?

The expected output is a nonblocking read. Instead, ReadFile hangs.

HID_GetInputReport kind of works, but the input buffer size is always zero. 

When I use ReadFile, it just blocks and debug output from the driver doesn't 
show any indication of that call. It's like the call wasn't forwarded to the 
driver at all.

Do I understand correctly that call to ReadFile should result in 
IOCTL_HID_READ_REPORT being sent to VMultiEvtInternalDeviceControl?

HID_GetInputReport results in IOCTL_HID_GET_INPUT_REPORT being send. 

I verified above results with HClient from WDK.

Original issue reported on code.google.com by paw...@gmail.com on 30 Jun 2011 at 7:21

[GoogleCodeExporter]

I am starting to take a look at this on the readfile branch 
(http://code.google.com/p/vmulti/source/browse/?name=readfile)

Original comment by djpnew...@gmail.com on 5 Jul 2011 at 5:33

[GoogleCodeExporter]

I tried changing DevicesArePolled in hidmapper to TRUE. This makes hidclass 
deliver read requests, but ReadFile still just blocks, perhaps my ReadReport 
function was somehow wrong.

Also, this thread might be of interest: 
http://www.osronline.com/cf.cfm?PageURL=showlists.cfm?list=NTDEV

Try the overlapped handle?

Original comment by paw...@gmail.com on 5 Jul 2011 at 6:28

[GoogleCodeExporter]

Ok so here is what i have so far:

>The expected output is a nonblocking read. Instead, ReadFile hangs.

You are using non-overlapped IO so by definition ReadFile should block until 
the request is completed or cancelled.

>When I use ReadFile, it just blocks and debug output from the driver doesn't 
show any indication of that call. It's like the call wasn't forwarded to the 
driver at all.

The issue here (i think) is that hidclass.sys is the gatekeeper between our 
hid-minidriver (vmulti) and the actual top level collection PDOs. So hidclass 
has its own queues and buffers etc that is manages and it communicates to 
vmulti via the hid-minidriver ioctl interface. Hidclass pends a maximum of 2 
hid read requests to the minidriver at one time so I assume your ReadFile 
request is waiting in a hidclass queue.

If you build the latest code from the readfile branch it is possible to get 
readfile comms working.

execute 'testvmulti /read_message' in one console window and then execute 
'testvmulti /write_message' in another.

Original comment by djpnew...@gmail.com on 6 Jul 2011 at 10:14

[GoogleCodeExporter]

The problem was the hidclass ring buffer was too small so the data sent via 
WriteFile would be dumped and then the ReadFile call would hang...

I have pushed some new changes to the branch which increase the hidclass buffer 
size.

execute 'testvmulti /message' with code built from the 'readfile' branch to 
test and confirm

Original comment by djpnew...@gmail.com on 11 Jul 2011 at 12:12

• Changed state: Started
• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

merged to trunk

Original comment by djpnew...@gmail.com on 31 Jul 2011 at 6:28

• Changed state: Fixed