hidmini driver and application communication

NTDEV
1

Hi,
I wrote a hidmini driver based on vhidmini sample in the DDK.
My driver reports as a HID keyboard. So that my application can’t
communicate with my driver through
ioctl(MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] ). Since It isn’t
possible to open a handle to a mouse or
keyboard collection which
my driver reports because the system input thread has opened these
devices exclusively.

I think there must be some other way to do the communication.
Then I will create a system thread in the driver to do the communication.

Any suggestions? Thanks a lot

Cheers.
Long

–
Things don’ happen. Things are made to happen.

2

There are well known ways to do this with vhidmini

  1. create a new top level collection in your hid descriptor and use this 2ndary collection to communicate with the miniport
  2. use wmi (fill out a IRP_MJ_SYSTEM_CONTROL function in your dispatch table when registering with HID)

Now with that said, there is a new HID sample starting in 6001.18000 (src\kmdf\hidusbfx2) which allows you to write a hid miniport as a full fledged KMDF driver. As such, you can do 2 new things that you could not do in a HID miniport like vhidmini
a) create a control device and talk to the driver through it
b) enumerate your own raw (non HID) PDO and talk to the driver through it

personally, I would choose b) since you can support multiple instances of the hid miniport this way and you get the notifications of arrival with a pnp raw pdo.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Long Pu
Sent: Wednesday, May 20, 2009 7:29 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] hidmini driver and application communication

Hi,
I wrote a hidmini driver based on vhidmini sample in the DDK.
My driver reports as a HID keyboard. So that my application can’t
communicate with my driver through
ioctl(MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] ). Since It isn’t
possible to open a handle to a mouse or
keyboard collection which
my driver reports because the system input thread has opened these
devices exclusively.

I think there must be some other way to do the communication.
Then I will create a system thread in the driver to do the communication.

Any suggestions? Thanks a lot

Cheers.
Long

–
Things don’ happen. Things are made to happen.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

This is my Uniq Custom HID Descriptor. you can’t find follow
descriptor other sites.

/* 1024x768 Absolute Coordinates Mouse */
/* Format: Total 6 Bytes Format */
/* 1 Bytes(ReportID) + 1 Bytes(Button-Bits + Padding) + 2
Bytes(X-Coord) + 2 Bytes(Y-Coord) */
/* Careful - if you don’t use LOGICAL-PHYSICAL MIN-MAXIMUM pair,
coordinates not recognized… */
HID_REPORT_DESCRIPTOR DefaultReportDescriptor = {
// Keyboard ReportDescriptor
0x05, 0x01, // usage page (generic desktop)
Choose the usage page “keyboard” is on
0x09, 0x06, // usage (keyboard)
Device is a keyboard
0xA1, 0x01, // collection (applicaton)
This collection comprises all the data words
0x85, 0x03, // REPORT_ID (3)
0x05, 0x07, // usage page (key codes)
Choose the key code usage page
0x19, 0xE0, // usage minimun (224)
Choose key codes 224 to 231 which are modifier keys
0x29, 0xE7, // usage maximum (231)
(left and right alt, shift, ctrl, and win)
0x15, 0x00, // logical mininum (0)
Each of these eight key codes will report ranging in
0x25, 0x01, // logical maximum (1)
value from zero to one
0x75, 0x01, // report size (1)
Assign each of these keys a 1-bit report
0x95, 0x08, // report count (8)
Report eight times
0x81, 0x02, // input (data, variable, absolute)
The defined byte above is an IN transaction
0x95, 0x01, // report count (1)
0x75, 0x08, // report size (8)
Report eight bits one time
0x81, 0x01, // input (constant)
Input the byte just described as a constant
0x95, 0x05, // report count (5)
0x75, 0x01, // report size (1)
0x05, 0x08, // usage page (page# for LEDs)
Choose LED usage page
0x19, 0x01, // usage minimum (1)
0x29, 0x05, // usage maximum (5)
Define five LEDs
0x91, 0x02, // output (data, variable, absolute)
The defined bits above are an OUT transaction
0x95, 0x01, // report count (1)
0x75, 0x03, // report size (3)
0x91, 0x01, // output (constant)
Three bit padding for the OUT transaction
0x95, 0x06, // report count (6)
0x75, 0x08, // report size (8)
Report six bytes
0x15, 0x00, // logical minimum (0)
0x25, 0x65, // logical maximum (101)
The byte values can range from 0 to 101
0x05, 0x07, // usage page (key codes)
Change usage page to key codes
0x19, 0x00, // usage minimum (0)
0x29, 0x65, // usage maximum (101)
Select key code range of 0 to 101
0x81, 0x00, // input (data, array)
Input the above six bytes
0xC0, // End collection
End application collection

0x05, 0x01, // Usage Page (Generic Desktop),
0x09, 0x02, // Usage (Mouse),
0xA1, 0x01, // Collection (Application),
0x85, 0x02, // REPORT_ID (2)
0x09, 0x01, // Usage (Pointer),
0xA1, 0x00, // Collection (Physical),
0x05, 0x09, // Usage Page (Buttons),
0x19, 0x01, // Usage Minimum (01),
0x29, 0x03, // Usage Maximun (03),
0x15, 0x00, // Logical Minimum (0),
0x25, 0x01, // Logical Maximum (1),
0x95, 0x03, // Report Count (3),
0x75, 0x01, // Report Size (1),
0x81, 0x02, // Input (Data, Variable, Absolute),
;3 button bits
0x95, 0x01, // Report Count (1),
0x75, 0x05, // Report Size (5),
0x81, 0x01, // Input (Constant), ;5 bit padding
0x05, 0x01, // Usage Page (Generic Desktop),
0x09, 0x30, // Usage (X),
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0xFF, 0x03, // LOGICAL_MAXIMUM (1023)
0x35, 0x00, // PHYSICAL_MINIMUM (0)
0x46, 0xFF, 0x03, // PHYSICAL_MINIMUM (1023)
0x75, 0x10, // REPORT_SIZE (16)
0x95, 0x01, // REPORT_COUNT (1)
0x81, 0x02, // INPUT (Data,Var,Abs)
0x09, 0x31, // Usage (Y),
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0xFF, 0x02, // LOGICAL_MAXIMUM (767)
0x35, 0x00, // PHYSICAL_MINIMUM (0)
0x46, 0xFF, 0x02, // PHYSICAL_MINIMUM (767)
0x75, 0x10, // REPORT_SIZE (16)
0x95, 0x01, // REPORT_COUNT (1)
0x81, 0x02, // INPUT (Data,Var,Abs)
0xC0, // End Collection,
0xC0, // End Collection,

0x06,0x00, 0xFF, // USAGE_PAGE (Vender Defined Usage Page)
0x09,0x01, // USAGE (Vendor Usage 0x01)
0xA1,0x01, // COLLECTION (Application)
0x85,0x01, // REPORT_ID (1)
0x09,0x01, // USAGE (Vendor Usage 0x01)
0x15,0x00, // LOGICAL_MINIMUM(0)
0x26,0xff, 0x00, // LOGICAL_MAXIMUM(255)
0x75,0x08, // REPORT_SIZE (0x08)
0x95,0x01, // REPORT_COUNT (0x01)
0xB1,0x00, // FEATURE (Data,Ary,Abs)
0xC0 // END_COLLECTION
};

I can communicate vendor top level collection.

You must side communicate to custom collection and re-layout REPORT_ID above.

because hidmini drivers can’t find Vendor Usage Page.

Thank you.

ps: sorry my poor english. I’m korean. My language is not english. :slight_smile:

2009/5/21 Long Pu :
> Hi,
> ? I wrote a hidmini driver based on vhidmini sample in the DDK.
> My driver reports as a HID keyboard. So that my application can’t
> communicate with my driver through
> ioctl(MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] ). Since It isn’t
> possible to open a handle to a mouse or
> keyboard collection which
> my driver reports because the system input thread has opened these
> devices exclusively.
>
> I think there must be some other way to do the communication.
> Then I will create a system thread in the driver to do the communication.
>
> Any suggestions? Thanks a lot
>
> Cheers.
> Long
>
>
> –
> Things don’ happen. Things are made to happen.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

4

On Thu, May 21, 2009 at 1:42 PM, Doron Holan wrote:
> There are well known ways to do this with vhidmini
> 1) create a new top level collection in your hid descriptor and use this 2ndary collection to communicate with the miniport
> 2) use wmi (fill out a IRP_MJ_SYSTEM_CONTROL function in your dispatch table when registering with HID)
Yes, I did that successfully.
Now I have 3 top level collection. One for keyboard, one for mouse,
and the other one for
side-band communication.
>
> Now with that said, there is a new HID sample starting in 6001.18000 (src\kmdf\hidusbfx2) which allows you to write a hid miniport as a full fledged KMDF driver. As such, you can do 2 new things that you could not do in a HID miniport like vhidmini
> a) create a control device and talk to the driver through it
> b) enumerate your own raw (non HID) PDO and talk to the driver through it
>
> personally, I would choose b) since you can support multiple instances of the hid miniport this way and you get the notifications of arrival with a pnp raw pdo.
What do you mean by “multiple instances”? I think I can add new top
level collection
to add new instance.

Thank you very much for your advices.

Cheers.
Long
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Long Pu
> Sent: Wednesday, May 20, 2009 7:29 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] hidmini driver and application communication
>
> Hi,
> ? I wrote a hidmini driver based on vhidmini sample in the DDK.
> My driver reports as a HID keyboard. So that my application can’t
> communicate with my driver through
> ioctl(MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] ). Since It isn’t
> possible to open a handle to a mouse or
> keyboard collection which
> my driver reports because the system input thread has opened these
> devices exclusively.
>
> I think there must be some other way to do the communication.
> Then I will create a system thread in the driver to do the communication.
>
> Any suggestions? Thanks a lot
>
> Cheers.
> Long
>
>
> –
> Things don’ happen. Things are made to happen.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
Things don’ happen. Things are made to happen.

5

Multiple instances = you install your virtual hid miniport more than once

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Long Pu
Sent: Thursday, May 21, 2009 9:54 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] hidmini driver and application communication

On Thu, May 21, 2009 at 1:42 PM, Doron Holan wrote:
> There are well known ways to do this with vhidmini
> 1) create a new top level collection in your hid descriptor and use this 2ndary collection to communicate with the miniport
> 2) use wmi (fill out a IRP_MJ_SYSTEM_CONTROL function in your dispatch table when registering with HID)
Yes, I did that successfully.
Now I have 3 top level collection. One for keyboard, one for mouse,
and the other one for
side-band communication.
>
> Now with that said, there is a new HID sample starting in 6001.18000 (src\kmdf\hidusbfx2) which allows you to write a hid miniport as a full fledged KMDF driver. As such, you can do 2 new things that you could not do in a HID miniport like vhidmini
> a) create a control device and talk to the driver through it
> b) enumerate your own raw (non HID) PDO and talk to the driver through it
>
> personally, I would choose b) since you can support multiple instances of the hid miniport this way and you get the notifications of arrival with a pnp raw pdo.
What do you mean by “multiple instances”? I think I can add new top
level collection
to add new instance.

Thank you very much for your advices.

Cheers.
Long
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Long Pu
> Sent: Wednesday, May 20, 2009 7:29 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] hidmini driver and application communication
>
> Hi,
> ? I wrote a hidmini driver based on vhidmini sample in the DDK.
> My driver reports as a HID keyboard. So that my application can’t
> communicate with my driver through
> ioctl(MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] ). Since It isn’t
> possible to open a handle to a mouse or
> keyboard collection which
> my driver reports because the system input thread has opened these
> devices exclusively.
>
> I think there must be some other way to do the communication.
> Then I will create a system thread in the driver to do the communication.
>
> Any suggestions? Thanks a lot
>
> Cheers.
> Long
>
>
> –
> Things don’ happen. Things are made to happen.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
Things don’ happen. Things are made to happen.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

yeah. Agree.

One off-topic question, Can the non-kmdf HID mini driver be used in win7?
I am targeting winxp and vista, but may migrate to win7. so I ask this

Thanks

Cheers.
Long

On Fri, May 22, 2009 at 1:25 PM, Doron Holan wrote:
> Multiple instances = you install your virtual hid miniport more than once
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Long Pu
> Sent: Thursday, May 21, 2009 9:54 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] hidmini driver and application communication
>
> On Thu, May 21, 2009 at 1:42 PM, Doron Holan wrote:
>> There are well known ways to do this with vhidmini
>> 1) create a new top level collection in your hid descriptor and use this 2ndary collection to communicate with the miniport
>> 2) use wmi (fill out a IRP_MJ_SYSTEM_CONTROL function in your dispatch table when registering with HID)
> Yes, I did ?that successfully.
> Now I have 3 top level collection. One for keyboard, one for mouse,
> and the other one for
> side-band communication.
>>
>> Now with that said, there is a new HID sample starting in 6001.18000 (src\kmdf\hidusbfx2) which allows you to write a hid miniport as a full fledged KMDF driver. As such, you can do 2 new things that you could not do in a HID miniport like vhidmini
>> a) create a control device and talk to the driver through it
>> b) enumerate your own raw (non HID) PDO and talk to the driver through it
>>
>> personally, I would choose b) since you can support multiple instances of the hid miniport this way and you get the notifications of arrival with a pnp raw pdo.
> What do you mean by “multiple instances”? I think I can add new top
> level collection
> to add new instance.
>
> Thank you very much for your advices.
>
> Cheers.
> Long
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Long Pu
>> Sent: Wednesday, May 20, 2009 7:29 PM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] hidmini driver and application communication
>>
>> Hi,
>> ? I wrote a hidmini driver based on vhidmini sample in the DDK.
>> My driver reports as a HID keyboard. So that my application can’t
>> communicate with my driver through
>> ioctl(MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] ). Since It isn’t
>> possible to open a handle to a mouse or
>> keyboard collection which
>> my driver reports because the system input thread has opened these
>> devices exclusively.
>>
>> I think there must be some other way to do the communication.
>> Then I will create a system thread in the driver to do the communication.
>>
>> Any suggestions? Thanks a lot
>>
>> Cheers.
>> Long
>>
>>
>> –
>> Things don’ happen. Things are made to happen.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
> Things don’ happen. Things are made to happen.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
Things don’ happen. Things are made to happen.

7

yes, you can install Win7 without kmdf HID minidriver.

2009/5/22 Long Pu

> yeah. Agree.
>
> One off-topic question, Can the non-kmdf HID mini driver be used in win7?
> I am targeting winxp and vista, but may migrate to win7. so I ask this
>
> Thanks
>
> Cheers.
> Long
>
> On Fri, May 22, 2009 at 1:25 PM, Doron Holan
> wrote:
> > Multiple instances = you install your virtual hid miniport more than once
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Long Pu
> > Sent: Thursday, May 21, 2009 9:54 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] hidmini driver and application communication
> >
> > On Thu, May 21, 2009 at 1:42 PM, Doron Holan
> wrote:
> >> There are well known ways to do this with vhidmini
> >> 1) create a new top level collection in your hid descriptor and use this
> 2ndary collection to communicate with the miniport
> >> 2) use wmi (fill out a IRP_MJ_SYSTEM_CONTROL function in your dispatch
> table when registering with HID)
> > Yes, I did that successfully.
> > Now I have 3 top level collection. One for keyboard, one for mouse,
> > and the other one for
> > side-band communication.
> >>
> >> Now with that said, there is a new HID sample starting in 6001.18000
> (src\kmdf\hidusbfx2) which allows you to write a hid miniport as a full
> fledged KMDF driver. As such, you can do 2 new things that you could not do
> in a HID miniport like vhidmini
> >> a) create a control device and talk to the driver through it
> >> b) enumerate your own raw (non HID) PDO and talk to the driver through
> it
> >>
> >> personally, I would choose b) since you can support multiple instances
> of the hid miniport this way and you get the notifications of arrival with a
> pnp raw pdo.
> > What do you mean by “multiple instances”? I think I can add new top
> > level collection
> > to add new instance.
> >
> > Thank you very much for your advices.
> >
> > Cheers.
> > Long
> >>
> >> d
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Long Pu
> >> Sent: Wednesday, May 20, 2009 7:29 PM
> >> To: Windows System Software Devs Interest List
> >> Subject: [ntdev] hidmini driver and application communication
> >>
> >> Hi,
> >> I wrote a hidmini driver based on vhidmini sample in the DDK.
> >> My driver reports as a HID keyboard. So that my application can’t
> >> communicate with my driver through
> >> ioctl(MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] ). Since It isn’t
> >> possible to open a handle to a mouse or
> >> keyboard collection which
> >> my driver reports because the system input thread has opened these
> >> devices exclusively.
> >>
> >> I think there must be some other way to do the communication.
> >> Then I will create a system thread in the driver to do the
> communication.
> >>
> >> Any suggestions? Thanks a lot
> >>
> >> Cheers.
> >> Long
> >>
> >>
> >> –
> >> Things don’ happen. Things are made to happen.
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> >>
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> >>
> >
> >
> >
> > –
> > Things don’ happen. Things are made to happen.
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> >
>
>
>
> –
> Things don’ happen. Things are made to happen.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>