Re: HID Driver for CE.NET 4.2 by Steve
Steve
Tue Nov 04 13:12:23 CST 2003
Could you also turn on all debug zones for USBHID.DLL and HIDPARSE.DLL and
post the output that occurs upon device insertion? Thanks.
--
Steve Schrock
Windows CE Device Drivers
This posting is provided "AS IS" with no warranties, and confers no rights.
"Steve Schrock [MS]" <sschrock@online.microsoft.com> wrote in message
news:%23BoapVwoDHA.2424@TK2MSFTNGP10.phx.gbl...
> What is probably happening is that you are getting each 8-byte USB packet
> prepended with the report number byte. This way you are getting 337 data
> bytes plus 43 bytes that hold the report number. What is the make/model of
> the card reader that you are using?
>
> --
> Steve Schrock
> Windows CE Device Drivers
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> "Michael" <michael_jordan_15@yahoo.com> wrote in message
> news:371c3d5a.0310231755.6012312f@posting.google.com...
> > Steve,
> >
> > Please read the answers to your questions below:
> >
> > "Steve Schrock [MS]" <sschrock@online.microsoft.com> wrote in message
> news:<eg6VS0AmDHA.1488@TK2MSFTNGP12.phx.gbl>...
> > > Could you describe how your device is reporting data in more detail?
> What is
> > > the interrupt endpoint size? What is the size of
InputReportByteLength?
> > >
> > The device is reporting data in 4 different parts:
> >
> > The first part is the credit card type and the last 3 parts contain
> > data from each track of the credit card. We retreive the first part
> > simply via HidP_GetUsageValue(). The last three parts are each
> > retrieved via the following pseudo code:
> >
> > for(int i=0; i<3; i++) // Handle 3 tracks.
> > if( HidP_GetUsageValue() == HIDP_STATUS_SUCCESS ) // Get status.
> > if( HidP_GetUsageValue() == HIDP_STATUS_SUCCESS ) // Get size.
> > if( HidP_GetUsageValueArray() == HIDP_STATUS_SUCCESS ) //
> > Get data.
> >
> > I hope this answers how the device is reporting data. The size of
> > InputReportByteLength is 338 on both Windows CE and Windows 2000.
> >
> > > I think you could probably continue calling GetInterruptReport until
you
> had
> > > received the total number of bytes that you are expecting.
> > >
> > The problem is that under Windows 2000, ReadFile() always returns 338,
> > without any problems for all credit cards. GetInterruptReport() in
> > Windows CE however returns 380 for all credit cards even though
> > InputReportByteLength is 338.
> >
> > I am apprehensive about hardcoding 380 since if we decide to use a
> > different card reader, results may vary. It seems, even under Windows
> > CE, the data is in the first 338 bytes, why then is
> > GetInterruptReport() reading 380 before it declares it has no more to
> > read? I want to understand why GetInterruptReport() is behaving this
> > way and how I can predict its behavior with this and possibly future
> > HID devices.
> >
> > Thanks again,
> > Mike
> >
> > > --
> > > Steve Schrock
> > > Windows CE Device Drivers
> > >
> > > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > >
> > > "Michael" <michael_jordan_15@yahoo.com> wrote in message
> > > news:371c3d5a.0310202305.8d68a1b@posting.google.com...
> > > > Great hint, reports were being dropped due to a full queue. Since
on
> > > > Windows 2000, ReadFile() would return the entire report in one shot
I
> > > > didn't imagine that GetInterruptReport() would only give partial
data,
> > > > especially 9 bytes at a time. This leads me to a follow up question
> > > > regarding GetInterruptReport() which is that I am receiving more
data
> > > > than InputReportByteLength. How do I know when to stop asking
> > > > GetInterruptReport() so I can process a full report if
> > > > GetInterruptReport() is always returning ERROR_SUCCESS and I'm not
> > > > sure how much of the report is left since it is exceeding
> > > > InputReportByteLength?
> > > >
> > > > ReadFile() on Windows 2000 read exactly InputReportByteLength so
this
> > > > problem is not exhibited on the PC.
> > > >
> > > > Thanks in advance.
> > > > Mike
> > > >
> > > > >"Steve Schrock [MS]" <sschrock@online.microsoft.com> wrote in
message
> > > news:<#Fgb0k0lDHA.3256@tk2msftngp13.phx.gbl>...
> > > > > GetInterruptReport() is what you should call, assuming that your
> reader
> > > is
> > > > > sending its data that way. Try turning on all the USBHID.DLL debug
> zones
> > > to
> > > > > see the contents of the interrupt reports it is getting from the
> device
> > > to
> > > > > see if any reports are being dropped due to a full queue or if the
> > > report
> > > > > contents look different there.
> > > > >
> > > > > --
> > > > > Steve Schrock
> > > > > Windows CE Device Drivers
> > > > >
> > > > > This posting is provided "AS IS" with no warranties, and confers
no
> > > rights.
> > > > >
> > > > > "Michael" <michael_jordan_15@yahoo.com> wrote in message
> > > > > news:371c3d5a.0310191920.464b5ce9@posting.google.com...
> > > > > > We have written a HID driver for a USB credit card reader. When
> the
> > > > > > card reader is plugged in, our driver is successfully loaded via
> > > > > > USBHID.DLL and successfully unloaded when the card reader is
> > > > > > unplugged. We correctly initialize our driver and all
information
> > > > > > passed in to our driver via HIDDeviceAttach seems correct. A
> problem
> > > > > > I cannot figure out is when a credit card is swiped our driver
> thread
> > > > > > is correctly notified of the swipe via GetInterruptReport()
> similar to
> > > > > > the HID mouse and keyboard driver samples shipped with Platform
> > > > > > Builder 4.2 however our buffer always contains 9 bytes with no
> > > > > > relevant information for us to use. We can 100% successfully
> > > > > > communicate with the card reader on Windows 2000 via SetupDi
> functions
> > > > > > and CreateFile and ReadFile. While the initialization seems
fine
> on
> > > > > > CE.NET 4.2, we cannot seem to ever get data when a card is
swiped.
> > > > > > Not sure if we are way off base by using GetInterruptReport().
> > > > > >
> > > > > > Any direction would be appreciated.
> > > > > >
> > > > > > Thanks,
> > > > > > Mike
>
>