WinUsb to communicate with a mouse

Hello,
As I said in the lastest message I wrote in this forum, I finally decided to use the WinUsb driver to communicate with the mouse instead of having to write my own filter driver for obvious sake of convenience.

The app I’ve written so far is working good, capable of sending virtual keystrokes to the foreground application used based on the mouse button pressed. For that purpose, I’m using the WinUsb_ReadPipe function in synchronous mode and the function is running in its own thread. The mouse communicates over the pipe using a 8bytes data report protocol. The first byte contains information about the button states (I hold this information from the vendor’s datasheet).

Therefore, when I click on a button, the read operation returns with the buffer whose bit corresponding to that button is set up to 1. It’s consequently super easy afterwards to determine which button was pressed and what actions to perform. (Pipe policy is default and power policy is set to SUSPEND_DELAY with a delay = ULONG_MAX).

However, I’m facing two problems :

  1. Sometimes (to me, it seems to happen completely randomly), the data in the buffer is shifted by 4 bytes (byte four contains the button state and not byte one?). Of course, when this occurs, my app doesn’t recognize that a button has been pressed and doesn’t do the corresponding actions? Very annoying. Any idea where this shift could come from and how to solve this issue ?

  2. The read operation returns only when the mouse button was RELEASED (the bit corresponding to the button is set to 1 on button release). However, I would like to determine for how long the button was pressed so I can perform two differents action based on short or long presses. Therefore, I need to know when the button was pressed and not released ! I know it’s possible (at least with a conventionnal mouse driver) because Windows provide a WM message for that purpose : WM_LBUTTONDOWN for the left button for instance. Is there a way to do the same with the WinUsb driver ? If so, how ? I’m a lost for now as the WinUsb_readPipe function returns only when a button was released I can’t see anyway to resolve this issue.

Thanks in advance for your help,

Guillaume.

Just to append some clarification to my previous message (can’t find a way to edit it ?) :
the WinUsb driver for that particular mouse is installed as a functional one, not on as a filter on top of a mouse driver.

xxxxx@gmail.com xxxxx@lists.osr.com wrote:

  1. Sometimes (to me, it seems to happen completely randomly), the data in the buffer is shifted by 4 bytes (byte four contains the button state and not byte one?). Of course, when this occurs, my app doesn’t recognize that a button has been pressed and doesn’t do the corresponding actions? Very annoying. Any idea where this shift could come from and how to solve this issue ?

You should be able to tell from the report descriptor exactly what’s
being sent in each report, including the bit positions. Are you just
reverse engineering the reports from the data? Is it possible that the
mouse status is ALWAYS in byte 4, but you’ve been fooled into thinking
it’s in byte 1?

Is it possible this is a different report? Some HID devices have
multiple reports, with multiple formats. Could you be seeing motion
reports here?

  1. The read operation returns only when the mouse button was RELEASED (the bit corresponding to the button is set to 1 on button release). However, I would like to determine for how long the button was pressed so I can perform two differents action based on short or long presses. Therefore, I need to know when the button was pressed and not released ! I know it’s possible (at least with a conventionnal mouse driver) because Windows provide a WM message for that purpose : WM_LBUTTONDOWN for the left button for instance. Is there a way to do the same with the WinUsb driver ? If so, how ? I’m a lost for now as the WinUsb_readPipe function returns only when a button was released I can’t see anyway to resolve this issue.

All standard mice send a HID report every time the state changes, either
up or down. What mouse are you using?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Excuse me for the late reply, I was out home.

You are exact, it’s because the mouse is indeed using a different report format.

I’m using the “PAW3515DB” USB optical mouse single chip.