Help getting started: Driver for a USB Mouse like device

NTDEV
1

I’m working with a USB device, which is to be used as a mouse. This device
cannot report co-ordinates and cannot be made into a HID Class device (in
the firmware) because the embedded micro is slow. The raw-sensor data needs
considerable post-processing … before co-ordinates can be generated.

I figure there are two ways I can do this : (I am new to driver
development…)

* Write a MouClass port driver which communicates with the USB Bus driver
directly.

– This should be easy’ish?
– Sample MouClass port driver source code is available in the DDK.
(sermouse for instance)

* Write a HID Class Mini-Driver (which emulates all the HID stuff, reports,
usages, descriptors etc). This driver would also communicate with the USB
Bus driver eventually.

– This would mean DirectX support for the mouse?
– It’s lower down the stack (kind of) and thus better?
– Sample HIDFake is available as part of Walter Oney’s book.

Which do you folks think is the better path?

Also, the algorithm that converts raw-sensor data into mouse like
co-ordinates is complex, needs a lot of look up tables (a megabyte or so)
and will probably need to do quite a lot of floating point math.

Could I execute this algorithm somewhere in user-space? and call it from
within the port (mini) drivers? Would this means excessive context switching
etc?

Any suggestions on where to start, what to look for? I’m reading the Walter
Oney book now. And Inside Windows 2000 is next on the queue.

Vishal.
PS: could you reply to xxxxx@ntlworld.com, if you’re not also copying
the group?)

2

Vishal Doshi wrote:

I’m working with a USB device, which is to be used as a mouse. This device
cannot report co-ordinates and cannot be made into a HID Class device (in
the firmware) because the embedded micro is slow. The raw-sensor data needs
considerable post-processing … before co-ordinates can be generated.

I had a similar problem to solve for a client, and I did it by writing a
HID minidriver. HIDFAKE would be a good model to start with.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

3

Walter Oney wrote:

Vishal Doshi wrote:
> I’m working with a USB device, which is to be used as a mouse. This
> device cannot report co-ordinates and cannot be made into a HID
> Class device (in the firmware) because the embedded micro is slow.
> The raw-sensor data needs considerable post-processing … before
> co-ordinates can be generated.

I had a similar problem to solve for a client, and I did it by
writing a HID minidriver. HIDFAKE would be a good model to start with.

Thanx for the tip;

I still have a lot of questions though:

  1. Where did you put the algorithms (for converting raw sensor readings to
    co-ordinates) ? Is the best solution to bundle them into the HID
    minidriver? (there might be a lot of floating point math involved)

  2. Isn’t there extra overhead in creating and parsing HID class reports that
    can be avoided altogether by using a MouseClass minidriver instead? Why did
    you choose to go the HID minidriver route?

  3. Any gotchas I should be aware of?

TIA,
Vishal.

4

You may also consider a
usermode service that uses ‘SendInput’. The minimal USB-client driver then
would simply forward your pipe-data to this service.
No hassles with floating-point, but I guess also no DirectX.
Norbert.

“Diplomacy is the art of telling someone to go to hell and have them
look forward to the trip.”
---- snip ----

5

Norbert Kawulski wrote:

You may also consider a
usermode service that uses ‘SendInput’. The minimal USB-client driver then
would simply forward your pipe-data to this service.
No hassles with floating-point, but I guess also no DirectX.

Actually, the project where I did the HID minidriver was for a mouse. It
was a rescue job – the previous contractor had tried to do what you’re
suggesting, and it was simply not working.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

6

Vishal Doshi wrote:

  1. Where did you put the algorithms (for converting raw sensor readings to
    co-ordinates) ? Is the best solution to bundle them into the HID
    minidriver? (there might be a lot of floating point math involved)

In the minidriver. Floating point is not a particular problem on
2K/XP/2K3 – just follow the rules as outlined in the FPUTEST sample in
my book.

  1. Isn’t there extra overhead in creating and parsing HID class reports that
    can be avoided altogether by using a MouseClass minidriver instead? Why did
    you choose to go the HID minidriver route?

So what? It’s how regular mice work anyway?

  1. Any gotchas I should be aware of?

Many hundreds of them. I expect you’ll enjoy the experience of finding
them…

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

7

Note that all mice in Windows are joined to 1 mouse, and you will not
be able to distinguish your mouse’s events from usual mouse events. To
distinguish, you will need to develop a custom HID device which is not
a mouse.

– Sample MouClass port driver source code is available in the DDK.
(sermouse for instance)

Why not?

* Write a HID Class Mini-Driver (which emulates all the HID stuff,
reports,

Why bother with HID if you need only the standard mouse functionality
without any additional sensors or controls?

– This would mean DirectX support for the mouse?

IIRC DirectInput is always supported for all mice, regardless of them
being HID or not.

Could I execute this algorithm somewhere in user-space? and call it

For what? Why bother with extra ring transitions?

Max