Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Re: Help request for starting the development of a HID?driver

Tim_RobertsTim_Roberts Member - All Emails Posts: 13,004 wrote:
> I'm currently developing a trackball device that's using a regular CMOS sensor (the PAW3515DB from Pixart company for the curious out there). What's amazing with this sensor is that it communicates directly with the computer over USB.

Well, that's really not very amazing. Essentially every HID device in
the world today (mouse, keyboard, trackpad, trackball) does this.

> ...However, I don't want to use it as a mouse? Or anyway not all the time. Indeed, I would like to perform some different actions based on the user's preferences (those will be changed through a user interface communicating with the driver). For instance, it must be possible to zoom in or out by deplacing the trackball back and forth instead of moving the cursor vertically,

Zoom in or out of what? Are you talking about simulating the zoom wheel
on a regular mouse? You might want to take a step back here. Much of
what you're talking about can be done through a user-mode macro tool
like AutoHotKey, which can customize your mouse actions on an
application-by-application basis. As a general rule, don't ever do work
in the kernel that can adequately be done in user mode.

> or by clicking on the main button (technically the left mouse button), it must be possible that a character ("A", "B", "CTRL+B" or whatever) is sent to the kernel instead of a left mouse button event).

Again, tools like AutoHotKey can do this , and that's a much better
solution than kernel hackery.

> However, and I'm sure it's very important for the driver development, the trackball must be able to be used in parallel with a regular mouse.

That comes by default.

> - How to detect that my trackball is plugged and not another conventional mouse ? (even though they could very well use the same CMOS sensor and therefore share the same device ID (HID) and manufacturer ID) ? Is it even possible without changing those ID?? (because one driver should control the conventional mouse while my own should be used for the trackball).

No. If you are producing a custom device with different
characteristics, then it absolutely needs to have its own VID and PID.
Do you have the opportunity to program your own descriptors with this chip?

> - What kind of driver should I develop for that purpose ? I wanted first to develop a filter based driver to modify the messages sent by the function driver controlling the mouse (as my trackball acts in every point like a common mouse) but I don't know if it's possible to filter specifically some messages (only the ones generated because of an action on the trackball and not on the mouse).

It would be POSSIBLE to do what you ask in a lower filter. You would
have to intercept and rewrite the descriptors, to advertise your
additional functionality (like a scroll wheel and a keyboard function).
You would then have to rewrite the reports coming back to change them
into your new functions. You would have to have a very good
understanding of the USB HID spec to do this.

> - Should it be UMDF or KMDF ? I would say intuitively KMDF because I think it has to deal with interrupt but I'm absolutely unsure.

You absolutely do NOT have to deal with interrupts. In the USB world,
interrupts are only handled by the host controller driver. Everything
else is just software communication between drivers.

Tim Roberts,
Providenza & Boekelheide, Inc.

Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.


  • Guillaume_MeurisseGuillaume_Meurisse Member Posts: 11
    Thanks for your reply.

    As far as I had seen, it was far from being the case, with most of the CMOS sensors (at least the ones provided by Pixart) not supporting a direct USB communication. But you certainly know this stuff a lot better than I do.

    I did know about AutoHotKey but I didn't realise beforehand how advanced features it's actually supporting. Damn, this tool is truly super powerful.

    I spent the whole day yesterday learning about it and I think I can do everything I want with it. What a relief ! It's going to be a lot easier to develop than if I had to deal with driver related concepts.

    Once again, big thanks for your eyes-opening response.

    Have a nice day,

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA