xxxxx@gmail.com 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, xxxxx@probo.com
Providenza & Boekelheide, Inc.