This project has moved and is read-only. For the latest updates, please go here.

Win7 Driver

Apr 12, 2009 at 7:44 AM

Can you share the source code of your win7 software hid driver?

Apr 13, 2009 at 10:43 AM
It is 80% vhidmini sample from DDK. Are you interested in something special?
Apr 13, 2009 at 8:24 PM

I am learning about writing a virtual software-based HID multitouch driver for Win7, exactly similar to your UniSoftHid. So far what I understand is that it should be similar to vhidmini, but also should be kmdf-based. My goal is to experiement with a software emulation of multitouch support for win7. The virtual software HID driver talks to my user-mode application, exchange touch point info (I am thinking to use TUIO as message layer).

Since you already have this working in your app, you must at least already solved several technical details, for example,
1) the translation of coordinates from one system to another, for example, from tuio bundle to win7 touch coordinates.
2) talk to user-level application (i guess you must use the vhidmini suggested approach, and not use UDP).

Anyway, it seems that you are way ahead, I want to see if you can share your code to me. If you don't feel comfortable sharing publicly, do you think you can send to my personal email (

Apr 14, 2009 at 11:59 AM
UniSoftHid is really only a "tunnel". It gets packets from user-mode application and forwards them to Win7 without any changes. All job is done by user-mode application.
Why do you want to make your own driver? You can use TUIO with my driver if this is your concern.
Apr 14, 2009 at 4:35 PM

I want to write my own driver so that I can change certain detail according to my specific need, can experiment with different approach (non-tuio), and can learn more about writing driver. I am not a programmer, I was hoping that a working source code can be my starting point.

Anyway, thanks
Apr 14, 2009 at 8:16 PM
Everything that you can change is located in user-mode application (Multitouch.Driver.Logic).
Apr 15, 2009 at 11:45 PM

I am starting to see your point now. All the necessary "formatting" is done at .NET level, and the virtual driver is simple "tunnel" to inject the coordinates to win7.

Some detail questions if you don't mind:
1) I will use your "InputProvider" concept, but I want to remove your "Service" concept/layer, since I am pretty confused on the code.
   a) Can I just change the Driver.Console code to listen to the "NewFrame" event from the InputProvider directly? Any care about?
   b) In the ApplicationInterfaceService.cs file, DispatchFrame() method, can you explain why the code has to group by handle and session, etc? What are those handle, session concepts?

2) I can use your UnisoftHid as it is, I still have one question to confirm on the driver level:
   a) I saw that you use the HIDLibrary.dll's WriteReport() function to inject the data, by the time the UniSoftHid receives the IRP, did you use the IOCTL_HID_WRITE_REPORT to handle it?

Apr 16, 2009 at 7:34 PM
Hi Martin,

1a. Yes, it is possible.
1b. Application has one session and multiple window handles. DispatchFrame method gets input for whole desktop and then sends this data only to application that is under contacts. That means application becomes only contacts that "belong" to it. If you wish, you can get ALL contacts if you create ContactHandler with IntPtr.Zero as parameter in constructor.

2a. Yes.
Apr 17, 2009 at 9:13 AM


The more I looked deeper, the more I realized how powerful and feature-rich is your framework. So far I have only looked into the InputProvider, Multitouch.Service.*, Multitouch.Driver, I am sure if continue to study Framework layer, I will find more things to learn. I have more detail questions so far:

1) Multitouch.Service namespace:
   a) why do you need to launch cmd prompt process and recall itself again with "-embedding" stuff? Why not call InvisibleForm (or MultitouchInput) directly? What is the significance of doing that?
   b) What is the "ProjectInstaller" concept? What is its fuctionality?

2) Multitouch.Service.AddIns namespace:
  a) Do you have any plan to upgrade those code in ApplicationSelector, PostSingleInput, DWMaxx?


Apr 20, 2009 at 12:34 PM
1a - In Vista all Windows Services are running in Session 0 all other applications are running in users session. If application wants to interact with user (ex. mouse input) it must run in users session. That is why when MultitouchService is started by Windows Service manager without parameters it tries to start itself as "-embedded" in users session.
1b - ProjectInstaller is used to install MultitouchService as a Windows Service.

2a - No.
        ApplicationSelector is not needed anymore. Already done inside ApplicationInterfaceService.cs.
        PostSingleInput is obsolet with HID driver for Windows 7.
        DWMaxx runs only with Vista SP1 and not very stable.
Jul 29, 2009 at 7:52 AM

Hi Nesher,

The vhidmini sample I found in the DDK is a WDM driver. However, your UniSoftHid seems to be a KMDF driver. I am just wondering did you port the vhidmini to KMDF before you modify it to your UniSoftHid? or is there a KMDF version of vhidmini that you based on?


Aug 4, 2009 at 3:23 PM

I have used KMDF version of vhidmini.

Mar 2, 2010 at 6:47 PM

Hi Nesher,

I have a question about your UniSoftHid driver. I have seen that the user-mode application send packets with the position, the ID and the timestamp to the driver. Is it possible to send other extra data to the driver and to receive it by the Windows 7 Multitouch structure?  In WM_TOUCH structure is a pointer dwExtraInfo. If it is not possible with your driver, how could I do it. Could I have your source code of the driver? Could you send it to me