Hello List,
i have several years of experience in application and uc programming and would like to use this imho “simple” problem to get into device driver development, so please bear with my lack of knowledge.
I have an Apple keyboard with two nonstandard keys: fn and eject.
Both do not generate scancodes under windows xp x64 using the stock ms drivers, and therefore are not usable. The problem is, that the fn key replaces the insert key which is commonly used in serveral apllications.
Using SnoopyUSB i can see the keycodes produced:
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 for fn
- 0x08 for eject
I am guessing that the fn-code is invalid / not processed because 0x01 should be in third position, or at least not preceeded by zeroes
and the eject code is only 1 byte, but needs to be 8 bytes long to be hid compliant.
I would like to replace the (invalid) keycodes sent from the keyboard before they are parsed and mapped to scancodes.
Having read Ms’s basic documents on driver development i understand that a filter driver is capable of these customizations.
But looking at the sources of kbfiltr from the wlh-examples and other googled snippets, it seems to me that you can only use these filters to work on the produced scancodes.
Is this the way to go and i am just misled in my assumptions? Or do i need to write a full-fledged driver?
From:
> I would like to replace the (invalid) keycodes sent from the keyboard
> before they are parsed and mapped to scancodes.
How about a lower filter for HIDUSB? You would filter the read URBs that are
sent down via INTERNAL_CONTROL operations on the back end – i.e., in a
completion routine. For robustness, you need to correctly handle either a
buffer pointer or an MDL in the URB. For the MDL case, you would want to
call MmGetSystemAddressForMdlSafe on the way down so that you can be sure
the mapping has already happened by the time your completion routine gets
called.
Walter Oney
Consulting and Training
www.oneysoft.com
You could also place yourself as a device lower filter to kbdhid (vs kbdfiltr’s usual location as a device upper filter). As a lower filter you can intercept reads, set a completion routine and the muck with the results. OR just install apple’s magic keys driver and be done with it 
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@wiedenroth.org
Sent: Monday, May 18, 2009 2:57 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] fixing hid keyboard quirks
Hello List,
i have several years of experience in application and uc programming and would like to use this imho “simple” problem to get into device driver development, so please bear with my lack of knowledge.
I have an Apple keyboard with two nonstandard keys: fn and eject.
Both do not generate scancodes under windows xp x64 using the stock ms drivers, and therefore are not usable. The problem is, that the fn key replaces the insert key which is commonly used in serveral apllications.
Using SnoopyUSB i can see the keycodes produced:
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 for fn
- 0x08 for eject
I am guessing that the fn-code is invalid / not processed because 0x01 should be in third position, or at least not preceeded by zeroes
and the eject code is only 1 byte, but needs to be 8 bytes long to be hid compliant.
I would like to replace the (invalid) keycodes sent from the keyboard before they are parsed and mapped to scancodes.
Having read Ms’s basic documents on driver development i understand that a filter driver is capable of these customizations.
But looking at the sources of kbfiltr from the wlh-examples and other googled snippets, it seems to me that you can only use these filters to work on the produced scancodes.
Is this the way to go and i am just misled in my assumptions? Or do i need to write a full-fledged driver?
—
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
From: “Doron Holan”
> You could also place yourself as a device lower filter to kbdhid (vs
> kbdfiltr’s usual location as a device upper filter). As a lower filter you
> can
> intercept reads, set a completion routine and the muck with the results.
> OR just install apple’s magic keys driver and be done with it
In my previous post, I meant to say be a filter below HIDUSB.
IME, it’s very difficult to put yourself below KBDHID unless you are a class
filter, because the name of your devnode is dynamically constructed by
HIDCLASS. Also, I think the OP’s problem is to intervene before the HID
report gets parsed and turned into something else.
Also, isn’t there a barely documented direct call interface in the keyboard
stack someplace?
Walter Oney
Consulting and Training
www.oneysoft.com
The callback interface is documented, that is what kbdfiltr uses as an upper filter. As for install, match on a hid hwid and it will remain constant and specific enough across machines. The parsing occurrs in kbdhid, all hidclass does is split the TLCs apart when it receives data from the device
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Walter Oney
Sent: Monday, May 18, 2009 8:06 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] fixing hid keyboard quirks
From: “Doron Holan”
> You could also place yourself as a device lower filter to kbdhid (vs
> kbdfiltr’s usual location as a device upper filter). As a lower filter you
> can
> intercept reads, set a completion routine and the muck with the results.
> OR just install apple’s magic keys driver and be done with it
In my previous post, I meant to say be a filter below HIDUSB.
IME, it’s very difficult to put yourself below KBDHID unless you are a class
filter, because the name of your devnode is dynamically constructed by
HIDCLASS. Also, I think the OP’s problem is to intervene before the HID
report gets parsed and turned into something else.
Also, isn’t there a barely documented direct call interface in the keyboard
stack someplace?
Walter Oney
Consulting and Training
www.oneysoft.com
—
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
Thank you for your input.
The callback interface is documented, that is what kbdfiltr uses as an upper filter.
So kbdfiltr is a valid starting point, the basic workings are the same for upper and lower filters?
OR just install apple’s magic keys driver and be done with it
afaik there are no drivers for xp x64, only xp x86 and all flavours of vista.
Let’s assume the kmdf version of kbdfiltr which eliminates all of the pnp/power burden. That leaves you two pieces of functionality in the driver
-
code to enumerate a raw pdo. You don’t need this since you are not talking to a um app, you are just morphing data such that will report up the stack
-
code to hook into the callback chain (the service callback) that lets you morph keyboard input packets. This is upper filter only
So, you could easily start with the kmdf toaster filter sample and just add an ioqueue to handle the reads and be good to go.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@wiedenroth.org
Sent: Monday, May 18, 2009 3:58 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] fixing hid keyboard quirks
Thank you for your input.
The callback interface is documented, that is what kbdfiltr uses as an upper filter.
So kbdfiltr is a valid starting point, the basic workings are the same for upper and lower filters?
OR just install apple’s magic keys driver and be done with it
afaik there are no drivers for xp x64, only xp x86 and all flavours of vista.
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
> afaik there are no drivers for xp x64, only xp x86 and all flavours of vista.
What about 2003 x64? the drivers for it are suitable for XP x64.
Also the Vista drivers are usually OK for 2008.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Citing from Apple FAQ (http://support.apple.com/kb/HT1656)
“64 bit versions of Microsoft XP are not supported […]”
And System Requirements (System requirements for Microsoft Windows):
" * An authentic, 32-bit Microsoft Windows XP Home Edition or Professional with Service Pack 2 or Service Pack 3 disc
or
* An authentic, 32-bit Microsoft Windows Vista Home Basic, Home Premium, Business, or Ultimate disc
or
* With some Mac Pro or MacBook Pro computers, an authentic, 64-bit Microsoft Windows Vista Home Basic, Home Premium, Business, or Ultimate disc
[…]"