Hi,
Are there any examples of a serial touch screen driver available? Doesn’t
seem to be anything that quite fits the bill in the DDK/WDK… having
trouble understanding what type of driver I need to write.
TIA
Regards,
Mark
Mark McDougall wrote:
Are there any examples of a serial touch screen driver available? Doesn’t
seem to be anything that quite fits the bill in the DDK/WDK… having
trouble understanding what type of driver I need to write.
I’ve read some posts suggesting a mouse class miniport driver. Others
suggest I need a filter driver of some sorts.
I always find the biggest problem with writing windows drivers is working
out where to start… 
There seems to be no documentation on this stuff
- it’s all “reference” documentation that assumes you already know what to
look for…
Regards,
Mark
> Are there any examples of a serial touch screen driver
available? Doesn’t seem to be anything that quite fits the
bill in the DDK/WDK… having trouble understanding what type
of driver I need to write.
This might sound like a crazy idea: how about only writing a user mode
driver?
In the 90’s I worked on a touchscreen ticket machine, and we decided to
not allow the public to interact with the OS (NT4 at the time) via the
touchscreen. Instead the full screen UI application talked directly to
the touchscreen over RS232 (very simple protocol) and injected touch
coordinates into its own onMouse handler (allowed testing with touch
screen and with mouse).
Good luck,
Tim Green
Development Engineer
DisplayLink (UK) Limited
Registered in England No. 04811048
Tim Green wrote:
This might sound like a crazy idea: how about only writing a user mode
driver?
The platform in question will have on-going development so the
touch-screen support should be completely transparent to the app(s). But
thanks for the suggestion.
I’m actually now leaning towards emulating a serial port and using an
existing serial touchscreen driver. The reasons why this is attractive in
this particular case is complex and I can’t really go into it here…
Regards,
Mark
Hi Mark,
Do you want this to be HID touch that will be understood by Vista as touch? Try looking at the wacompen sample. It’s a serial HID pen driver. Another route would be to start with the vhidmini sample. Make a virtual touch collection. Then write a service that reads the data from the device and injects it via the vhid driver.
Even if you just want mouse data this would work, just make the driver (either wacompen or vhidmini) create a mouse collection.
If all you want is an absolute pointing device w/out the ability to calibrate/send out of band data to the driver, look at the mouser example (src\input\mouser) as well. otherwise, if you need to be able to send/receive calibration data or some other out of band data, a hid miniport makes more sense because you can expose a 2ndary top level collection which you can then use to communicate with the miniport. Since the mouser example lives under mouclass, communication with a user mode app is not possible.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@wacom.com
Sent: Monday, November 10, 2008 11:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Serial Touch Screen Driver
Hi Mark,
Do you want this to be HID touch that will be understood by Vista as touch? Try looking at the wacompen sample. It’s a serial HID pen driver. Another route would be to start with the vhidmini sample. Make a virtual touch collection. Then write a service that reads the data from the device and injects it via the vhid driver.
Even if you just want mouse data this would work, just make the driver (either wacompen or vhidmini) create a mouse collection.
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
You should develop a serial mouse driver, you can reference ELO or the other
driver for more information(I used this method).
Another way is that you can develop a virtual mouse driver(include PS2/USB). Get
and process data from serial port.
Doron Holan wrote:
otherwise, if you need to be able
to send/receive calibration data or some other out of band data, a hid
miniport makes more sense because you can expose a 2ndary top level
collection which you can then use to communicate with the miniport.
Hmmm, I think this is most suitable for my application. I was attempting
to write a device-specific function driver but couldn’t get it to install
as a “mouse” class device.
I’ll persue your recommendation!
Thanks as always Doron,
Regards,
Mark
Dear Mark,
Yes, You can write a application.
It’s a good ideal to write a device-specific function driver.
Allen
Mark McDougall wrote:
Hmmm, I think this is most suitable for my application. I was attempting
to write a device-specific function driver but couldn’t get it to install
as a “mouse” class device.
I’ve sucessfully implemented a proof-of-concept “HID Mouse” driver that
communicates with my hardware. I effectively merged the portio and
vhidmini samples. Something weird with the device grabbing both memory and
port-mapped io space (had to comment-out the memory mapping code) but
there’s enough there to show that it all works.
Re-reading xxxxx@wacom.com’s suggestion and Doron’s I see that the
Touch/Digi HID would be more appropriate. I also need out-of-band data for
calibration so this is definitely the way to go!
Thanks again to both of you,
Regards,
Mark
I strongly suggest that you look at the kmdf hid mini port sample. Gives you a full blown kmdf driver where you can surface you own raw pdo where you get the io directly instead of getting hid data. This will give you a calibration conduit without hidclass getting in the way. The kmdf kbfiltr example shows how to enumerate a raw pdo.
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Mark McDougall
Sent: Monday, November 17, 2008 9:17 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Serial Touch Screen Driver
Mark McDougall wrote:
> Hmmm, I think this is most suitable for my application. I was attempting
> to write a device-specific function driver but couldn’t get it to install
> as a “mouse” class device.
I’ve sucessfully implemented a proof-of-concept “HID Mouse” driver that
communicates with my hardware. I effectively merged the portio and
vhidmini samples. Something weird with the device grabbing both memory and
port-mapped io space (had to comment-out the memory mapping code) but
there’s enough there to show that it all works.
Re-reading xxxxx@wacom.com’s suggestion and Doron’s I see that the
Touch/Digi HID would be more appropriate. I also need out-of-band data for
calibration so this is definitely the way to go!
Thanks again to both of you,
Regards,
Mark
—
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
Doron Holan wrote:
I strongly suggest that you look at the kmdf hid mini port sample.
Gives you a full blown kmdf driver where you can surface you own raw
pdo where you get the io directly instead of getting hid data. This
will give you a calibration conduit without hidclass getting in the
way. The kmdf kbfiltr example shows how to enumerate a raw pdo.
Sorry Doron, I’m not clear on which sample you mean?!? I’m using
WINDDK/6000 and can’t see a KMDF HID miniport sample there?!?
Regards,
Mark
THE KMDF HID miniport requires a stub HID miniport driver and a lower
class KMDF filter driver, just to clarify. I’ve been through all of this
lately for a multi-touch device and there are a bunch of issues with
this model but it does basically work. The Windows 7 release is suppose
to have the stub HID miniport as an in-box driver but to get things to
work correctly within the KMDF lower filter driver you need to write
your own;i.e. it can’t be a simple pass through.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Doron Holan wrote:
I strongly suggest that you look at the kmdf hid mini port sample. Gives you a full blown kmdf driver where you can surface you own raw pdo where you get the io directly instead of getting hid data. This will give you a calibration conduit without hidclass getting in the way. The kmdf kbfiltr example shows how to enumerate a raw pdo.
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Mark McDougall
> Sent: Monday, November 17, 2008 9:17 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Serial Touch Screen Driver
>
>
> Mark McDougall wrote:
>
>> Hmmm, I think this is most suitable for my application. I was attempting
>> to write a device-specific function driver but couldn’t get it to install
>> as a “mouse” class device.
>
> I’ve sucessfully implemented a proof-of-concept “HID Mouse” driver that
> communicates with my hardware. I effectively merged the portio and
> vhidmini samples. Something weird with the device grabbing both memory and
> port-mapped io space (had to comment-out the memory mapping code) but
> there’s enough there to show that it all works.
>
> Re-reading xxxxx@wacom.com’s suggestion and Doron’s I see that the
> Touch/Digi HID would be more appropriate. I also need out-of-band data for
> calibration so this is definitely the way to go!
>
> Thanks again to both of you,
> Regards,
> Mark
>
> —
> 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
Mark, the sample you want is in the 6001 wdk, 6001.18000\src\kmdf\hidusbfx2.
Peter, you do not need to write your own hid pass through miniport, the sample contains one (hidmapper) that can be used as is w/out modification. I am curious as to the “bunch of issues” you refer to are. Perhaps if you can list them out, we can address them in a future release.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Monday, November 17, 2008 9:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Serial Touch Screen Driver
THE KMDF HID miniport requires a stub HID miniport driver and a lower
class KMDF filter driver, just to clarify. I’ve been through all of this
lately for a multi-touch device and there are a bunch of issues with
this model but it does basically work. The Windows 7 release is suppose
to have the stub HID miniport as an in-box driver but to get things to
work correctly within the KMDF lower filter driver you need to write
your own;i.e. it can’t be a simple pass through.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Doron Holan wrote:
I strongly suggest that you look at the kmdf hid mini port sample. Gives you a full blown kmdf driver where you can surface you own raw pdo where you get the io directly instead of getting hid data. This will give you a calibration conduit without hidclass getting in the way. The kmdf kbfiltr example shows how to enumerate a raw pdo.
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Mark McDougall
> Sent: Monday, November 17, 2008 9:17 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Serial Touch Screen Driver
>
>
> Mark McDougall wrote:
>
>> Hmmm, I think this is most suitable for my application. I was attempting
>> to write a device-specific function driver but couldn’t get it to install
>> as a “mouse” class device.
>
> I’ve sucessfully implemented a proof-of-concept “HID Mouse” driver that
> communicates with my hardware. I effectively merged the portio and
> vhidmini samples. Something weird with the device grabbing both memory and
> port-mapped io space (had to comment-out the memory mapping code) but
> there’s enough there to show that it all works.
>
> Re-reading xxxxx@wacom.com’s suggestion and Doron’s I see that the
> Touch/Digi HID would be more appropriate. I also need out-of-band data for
> calibration so this is definitely the way to go!
>
> Thanks again to both of you,
> Regards,
> Mark
>
> —
> 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
—
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
Doron,
One of the main issues I had was simply that trying to match a request
file object coming through an IOCTL_HID_xxx handler would not be
propagated to the cleanup callback. I am guessing since the
IRP_MJ_CREATE was not handled by KMDF because the HID pass through
driver does not receive the IRP_MJ_CREATE requests, the HID class driver
deals with these itself.
Other issues were the non-stop error messages from KMDF indicating that
the filter was doing something wrong when handling one of the IOCTl
requests or IRP_MJ_CLEANUP requests, sent via a custom top level
collection. Again I believe this is due to the IRP_MJ_CREATE request not
being passed into KMDF by the HID class driver.
In order to work around these issues I needed to create my own callback
which was invoked by the HID pass through driver that would actually
send the IRP_MJ_CLEANUP request to the KMDF filter so I could match up
the FileObject in order to perform correct cleanup on requests opened by
the user mode application.
Granted these things may be edge cases but for the multi-touch interface
my client required, they were pretty standard.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Doron Holan wrote:
Mark, the sample you want is in the 6001 wdk, 6001.18000\src\kmdf\hidusbfx2.
Peter, you do not need to write your own hid pass through miniport, the sample contains one (hidmapper) that can be used as is w/out modification. I am curious as to the “bunch of issues” you refer to are. Perhaps if you can list them out, we can address them in a future release.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Monday, November 17, 2008 9:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Serial Touch Screen DriverTHE KMDF HID miniport requires a stub HID miniport driver and a lower
class KMDF filter driver, just to clarify. I’ve been through all of this
lately for a multi-touch device and there are a bunch of issues with
this model but it does basically work. The Windows 7 release is suppose
to have the stub HID miniport as an in-box driver but to get things to
work correctly within the KMDF lower filter driver you need to write
your own;i.e. it can’t be a simple pass through.Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295Doron Holan wrote:
> I strongly suggest that you look at the kmdf hid mini port sample. Gives you a full blown kmdf driver where you can surface you own raw pdo where you get the io directly instead of getting hid data. This will give you a calibration conduit without hidclass getting in the way. The kmdf kbfiltr example shows how to enumerate a raw pdo.
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not intentional.
>
> -----Original Message-----
> From: Mark McDougall
>> Sent: Monday, November 17, 2008 9:17 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Serial Touch Screen Driver
>>
>>
>> Mark McDougall wrote:
>>
>>> Hmmm, I think this is most suitable for my application. I was attempting
>>> to write a device-specific function driver but couldn’t get it to install
>>> as a “mouse” class device.
>> I’ve sucessfully implemented a proof-of-concept “HID Mouse” driver that
>> communicates with my hardware. I effectively merged the portio and
>> vhidmini samples. Something weird with the device grabbing both memory and
>> port-mapped io space (had to comment-out the memory mapping code) but
>> there’s enough there to show that it all works.
>>
>> Re-reading xxxxx@wacom.com’s suggestion and Doron’s I see that the
>> Touch/Digi HID would be more appropriate. I also need out-of-band data for
>> calibration so this is definitely the way to go!
>>
>> Thanks again to both of you,
>> Regards,
>> Mark
>>
>> —
>> 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
>
> —
> 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
The hid miniport is not supposed to see file objects or process their state, so yes, what you are describing is an edge case. Hidclass is acting by design here, it owns the create/cleanup/close paths for each collection. Each TLC is supposed to be stateless wrt to open file handles from a hw POV.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Monday, November 17, 2008 10:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Serial Touch Screen Driver
Doron,
One of the main issues I had was simply that trying to match a request
file object coming through an IOCTL_HID_xxx handler would not be
propagated to the cleanup callback. I am guessing since the
IRP_MJ_CREATE was not handled by KMDF because the HID pass through
driver does not receive the IRP_MJ_CREATE requests, the HID class driver
deals with these itself.
Other issues were the non-stop error messages from KMDF indicating that
the filter was doing something wrong when handling one of the IOCTl
requests or IRP_MJ_CLEANUP requests, sent via a custom top level
collection. Again I believe this is due to the IRP_MJ_CREATE request not
being passed into KMDF by the HID class driver.
In order to work around these issues I needed to create my own callback
which was invoked by the HID pass through driver that would actually
send the IRP_MJ_CLEANUP request to the KMDF filter so I could match up
the FileObject in order to perform correct cleanup on requests opened by
the user mode application.
Granted these things may be edge cases but for the multi-touch interface
my client required, they were pretty standard.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Doron Holan wrote:
Mark, the sample you want is in the 6001 wdk, 6001.18000\src\kmdf\hidusbfx2.
Peter, you do not need to write your own hid pass through miniport, the sample contains one (hidmapper) that can be used as is w/out modification. I am curious as to the “bunch of issues” you refer to are. Perhaps if you can list them out, we can address them in a future release.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Monday, November 17, 2008 9:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Serial Touch Screen DriverTHE KMDF HID miniport requires a stub HID miniport driver and a lower
class KMDF filter driver, just to clarify. I’ve been through all of this
lately for a multi-touch device and there are a bunch of issues with
this model but it does basically work. The Windows 7 release is suppose
to have the stub HID miniport as an in-box driver but to get things to
work correctly within the KMDF lower filter driver you need to write
your own;i.e. it can’t be a simple pass through.Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295Doron Holan wrote:
> I strongly suggest that you look at the kmdf hid mini port sample. Gives you a full blown kmdf driver where you can surface you own raw pdo where you get the io directly instead of getting hid data. This will give you a calibration conduit without hidclass getting in the way. The kmdf kbfiltr example shows how to enumerate a raw pdo.
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not intentional.
>
> -----Original Message-----
> From: Mark McDougall
>> Sent: Monday, November 17, 2008 9:17 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Serial Touch Screen Driver
>>
>>
>> Mark McDougall wrote:
>>
>>> Hmmm, I think this is most suitable for my application. I was attempting
>>> to write a device-specific function driver but couldn’t get it to install
>>> as a “mouse” class device.
>> I’ve sucessfully implemented a proof-of-concept “HID Mouse” driver that
>> communicates with my hardware. I effectively merged the portio and
>> vhidmini samples. Something weird with the device grabbing both memory and
>> port-mapped io space (had to comment-out the memory mapping code) but
>> there’s enough there to show that it all works.
>>
>> Re-reading xxxxx@wacom.com’s suggestion and Doron’s I see that the
>> Touch/Digi HID would be more appropriate. I also need out-of-band data for
>> calibration so this is definitely the way to go!
>>
>> Thanks again to both of you,
>> Regards,
>> Mark
>>
>> —
>> 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
>
> —
> 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
—
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
Doron,
Sure this is understandable. But if I have an application which is
performing some configuration via a top level collection, say
configuring a buffer queue to process requests from the device, then I
need to be sure to clean this up when the application closes the handle;
it may crash and not be able to call some tear down IOCtl. Thus I need
to be able to associate the file object used to configure the driver
passed into the IOCTL_HID_xxx handler with the IRP_MJ_CLEANUP handler.
In the HID pass through driver I do see the IOCTL request and the
IRP_MJ_CLEANUP request. As well in the KMDF filter I am able to get the
IOCTL_HID_xxx file object. But in my Cleanup callback the passed in
parameter is always NULL, again probably because the IRP_MJ_CREATE entry
was not called for the request since the HID Class driver handled it
internally.
Right now I have had to implement a mechanism within the HID miniport
driver to call into the KMDF driver for the IRP_MJ_CLEANUP processing to
allow me to correctly recognize the handle being closed and perform
cleanup of resources prior to the application going away.
It would seem that if you need to establish any sort of communication
channel to a user mode application in this model; i.e. using a custom
top level collection and the HID miniport pass through, that would
require resource cleanup before the application ends, you are going to
be in this same predicament.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Doron Holan wrote:
The hid miniport is not supposed to see file objects or process their state, so yes, what you are describing is an edge case. Hidclass is acting by design here, it owns the create/cleanup/close paths for each collection. Each TLC is supposed to be stateless wrt to open file handles from a hw POV.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Monday, November 17, 2008 10:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Serial Touch Screen DriverDoron,
One of the main issues I had was simply that trying to match a request
file object coming through an IOCTL_HID_xxx handler would not be
propagated to the cleanup callback. I am guessing since the
IRP_MJ_CREATE was not handled by KMDF because the HID pass through
driver does not receive the IRP_MJ_CREATE requests, the HID class driver
deals with these itself.Other issues were the non-stop error messages from KMDF indicating that
the filter was doing something wrong when handling one of the IOCTl
requests or IRP_MJ_CLEANUP requests, sent via a custom top level
collection. Again I believe this is due to the IRP_MJ_CREATE request not
being passed into KMDF by the HID class driver.In order to work around these issues I needed to create my own callback
which was invoked by the HID pass through driver that would actually
send the IRP_MJ_CLEANUP request to the KMDF filter so I could match up
the FileObject in order to perform correct cleanup on requests opened by
the user mode application.Granted these things may be edge cases but for the multi-touch interface
my client required, they were pretty standard.Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295Doron Holan wrote:
> Mark, the sample you want is in the 6001 wdk, 6001.18000\src\kmdf\hidusbfx2.
>
> Peter, you do not need to write your own hid pass through miniport, the sample contains one (hidmapper) that can be used as is w/out modification. I am curious as to the “bunch of issues” you refer to are. Perhaps if you can list them out, we can address them in a future release.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
> Sent: Monday, November 17, 2008 9:53 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Serial Touch Screen Driver
>
>
> THE KMDF HID miniport requires a stub HID miniport driver and a lower
> class KMDF filter driver, just to clarify. I’ve been through all of this
> lately for a multi-touch device and there are a bunch of issues with
> this model but it does basically work. The Windows 7 release is suppose
> to have the stub HID miniport as an in-box driver but to get things to
> work correctly within the KMDF lower filter driver you need to write
> your own;i.e. it can’t be a simple pass through.
>
> Pete
>
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295
>
> Doron Holan wrote:
>> I strongly suggest that you look at the kmdf hid mini port sample. Gives you a full blown kmdf driver where you can surface you own raw pdo where you get the io directly instead of getting hid data. This will give you a calibration conduit without hidclass getting in the way. The kmdf kbfiltr example shows how to enumerate a raw pdo.
>>
>> d
>>
>> Sent from my phone with no t9, all spilling mistakes are not intentional.
>>
>> -----Original Message-----
>> From: Mark McDougall
>>> Sent: Monday, November 17, 2008 9:17 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: Re:[ntdev] Serial Touch Screen Driver
>>>
>>>
>>> Mark McDougall wrote:
>>>
>>>> Hmmm, I think this is most suitable for my application. I was attempting
>>>> to write a device-specific function driver but couldn’t get it to install
>>>> as a “mouse” class device.
>>> I’ve sucessfully implemented a proof-of-concept “HID Mouse” driver that
>>> communicates with my hardware. I effectively merged the portio and
>>> vhidmini samples. Something weird with the device grabbing both memory and
>>> port-mapped io space (had to comment-out the memory mapping code) but
>>> there’s enough there to show that it all works.
>>>
>>> Re-reading xxxxx@wacom.com’s suggestion and Doron’s I see that the
>>> Touch/Digi HID would be more appropriate. I also need out-of-band data for
>>> calibration so this is definitely the way to go!
>>>
>>> Thanks again to both of you,
>>> Regards,
>>> Mark
>>>
>>> —
>>> 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
>> —
>> 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
>
> —
> 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