Load order problems with a legacy keyboard driver

NTDEV
1

A client recently asked me to write a device driver for W2K/WXP for an
application-specific keyboard which has the particularity of being
uni-directional, as a consequence of which it doesn’t get seen by the PnP
enumerator, and i8042prt doesn’t get loaded to drive it.

As this was to be a quick-and-dirty job, I wrote a legacy driver which is
installed as a keyboard port driver, as follows:

\Registry\Machine\System\CurrentControlSet\Services\CONSOLE
Type = REG_DWORD 0x00000001
Start = REG_DWORD 0x00000001
ErrorControl = REG_DWORD 0x00000001
Group = Keyboard Port
ImagePath=SYSTEM32\DRIVERS\CONSOLE.SYS

In its DriverEntry routine it creates an entry under

HKLM/HARDWARE/DEVICEMAP/KeyboardPort/KeyboardPort0

to let the keyboard class driver, KbdClass, know that there’s a legacy
keyboard driver to handle, after which it creates a device object and
registers a reinitialisation routine with .

In the reinitialisation routine, which in theory is run after all other
drivers in the system load group have been loaded, I just try to register
an interrupt handler for IRQ1 (the I8042 interrupt): if this succeeds then
I know that i8042prt has not loaded - because the uni-directional keyboard
is connected - and I manage the keyboard and send data off to KbdClass. If
it doesn’t succeed then i8042prt IS loaded so the device autodestructs.

So far so good, and it works on some installations on W2K. Following
traces in the system log, I find that i8042prt gets loaded, then KbdClass,
then - eventually - my driver. Then the reinitialisation routine in
KbdClass gets called, it scans HKLM/HARDWARE/DEVICEMAP looking for any
legacy devices, finds mine, and passes an IOCTL_INTERNAL_KEYBOARD_CONNECT
IRP, from which point on all goes well.

Unfortunately, on other installations, the above is NOT what happens. What
does happen is that the reinitialisation routine in KbdClass gets called
before my driver is loaded, and so of course it never sees my driver.
Which is a great shame.

Does anyone have any ideas on this? I don’t really want to install my
driver as a boot-load driver.

Thanks in advance
Trevor Bimler
Upstart Ingenierie

2

On win2k and forward, you can’t rely on load order between a legacy port
driver and kbdclass seeing it after it loads. You must either make your
driver a boot driver or convert it into a pnp driver.

It sounds like your device is a ps2 device though; have you looked at
the kbdfiltr example in the ddk? That demonstrates how to create a
device upper filter which would allow you to filter that particular
device and not race with i8042prt as to who controls the registers and
the communication with the device.

D

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Trevor Bimler
Sent: Monday, September 22, 2003 5:27 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Load order problems with a legacy keyboard driver

A client recently asked me to write a device driver for W2K/WXP for an
application-specific keyboard which has the particularity of being
uni-directional, as a consequence of which it doesn’t get seen by the
PnP
enumerator, and i8042prt doesn’t get loaded to drive it.

As this was to be a quick-and-dirty job, I wrote a legacy driver which
is
installed as a keyboard port driver, as follows:

\Registry\Machine\System\CurrentControlSet\Services\CONSOLE
Type = REG_DWORD 0x00000001
Start = REG_DWORD 0x00000001
ErrorControl = REG_DWORD 0x00000001
Group = Keyboard Port
ImagePath=SYSTEM32\DRIVERS\CONSOLE.SYS

In its DriverEntry routine it creates an entry under

HKLM/HARDWARE/DEVICEMAP/KeyboardPort/KeyboardPort0

to let the keyboard class driver, KbdClass, know that there’s a legacy
keyboard driver to handle, after which it creates a device object and
registers a reinitialisation routine with .

In the reinitialisation routine, which in theory is run after all other
drivers in the system load group have been loaded, I just try to
register
an interrupt handler for IRQ1 (the I8042 interrupt): if this succeeds
then
I know that i8042prt has not loaded - because the uni-directional
keyboard
is connected - and I manage the keyboard and send data off to KbdClass.
If
it doesn’t succeed then i8042prt IS loaded so the device autodestructs.

So far so good, and it works on some installations on W2K. Following
traces in the system log, I find that i8042prt gets loaded, then
KbdClass,
then - eventually - my driver. Then the reinitialisation routine in
KbdClass gets called, it scans HKLM/HARDWARE/DEVICEMAP looking for any
legacy devices, finds mine, and passes an
IOCTL_INTERNAL_KEYBOARD_CONNECT
IRP, from which point on all goes well.

Unfortunately, on other installations, the above is NOT what happens.
What
does happen is that the reinitialisation routine in KbdClass gets called
before my driver is loaded, and so of course it never sees my driver.
Which is a great shame.

Does anyone have any ideas on this? I don’t really want to install my
driver as a boot-load driver.

Thanks in advance
Trevor Bimler
Upstart Ingenierie

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

I could be wrong, but it sounds like he’s saying that this keyboard
doesn’t get enumerated (strange, that). And that, therefore, i8042
doesn’t ever get an AddDevice for the keyboard.

It would be interesting to hear if there’s a way to cause i8042 to
pretend there’s a keyboard even when there “isn’t”, but on the other
hand, it’s also slightly terrifying to contemplate…

Doron Holan wrote:

On win2k and forward, you can’t rely on load order between a legacy port
driver and kbdclass seeing it after it loads. You must either make your
driver a boot driver or convert it into a pnp driver.

It sounds like your device is a ps2 device though; have you looked at
the kbdfiltr example in the ddk? That demonstrates how to create a
device upper filter which would allow you to filter that particular
device and not race with i8042prt as to who controls the registers and
the communication with the device.

D

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Trevor Bimler
Sent: Monday, September 22, 2003 5:27 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Load order problems with a legacy keyboard driver

A client recently asked me to write a device driver for W2K/WXP for an
application-specific keyboard which has the particularity of being
uni-directional, as a consequence of which it doesn’t get seen by the
PnP
enumerator, and i8042prt doesn’t get loaded to drive it.

As this was to be a quick-and-dirty job, I wrote a legacy driver which
is
installed as a keyboard port driver, as follows:

\Registry\Machine\System\CurrentControlSet\Services\CONSOLE
Type = REG_DWORD 0x00000001
Start = REG_DWORD 0x00000001
ErrorControl = REG_DWORD 0x00000001
Group = Keyboard Port
ImagePath=SYSTEM32\DRIVERS\CONSOLE.SYS

In its DriverEntry routine it creates an entry under

HKLM/HARDWARE/DEVICEMAP/KeyboardPort/KeyboardPort0

to let the keyboard class driver, KbdClass, know that there’s a legacy
keyboard driver to handle, after which it creates a device object and
registers a reinitialisation routine with .
>
> In the reinitialisation routine, which in theory is run after all other
> drivers in the system load group have been loaded, I just try to
> register
> an interrupt handler for IRQ1 (the I8042 interrupt): if this succeeds
> then
> I know that i8042prt has not loaded - because the uni-directional
> keyboard
> is connected - and I manage the keyboard and send data off to KbdClass.
> If
> it doesn’t succeed then i8042prt IS loaded so the device autodestructs.
>
> So far so good, and it works on some installations on W2K. Following
> traces in the system log, I find that i8042prt gets loaded, then
> KbdClass,
> then - eventually - my driver. Then the reinitialisation routine in
> KbdClass gets called, it scans HKLM/HARDWARE/DEVICEMAP looking for any
> legacy devices, finds mine, and passes an
> IOCTL_INTERNAL_KEYBOARD_CONNECT
> IRP, from which point on all goes well.
>
> Unfortunately, on other installations, the above is NOT what happens.
> What
> does happen is that the reinitialisation routine in KbdClass gets called
> before my driver is loaded, and so of course it never sees my driver.
> Which is a great shame.
>
> Does anyone have any ideas on this? I don’t really want to install my
> driver as a boot-load driver.
>
> Thanks in advance
> Trevor Bimler
> Upstart Ingenierie
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

–
…/ray..

4

There is a reg setting to tell i8042pr to ignore all device errors and
succeed a start, this allows you to do ps2 hotplug headless support for
servers etc. Note that this must be tested out ahead of time and can’t
be used for all hardware, the hardware must support it. Don’t ask me
why the d*mn server doesn’t have USB to fix this, that’s another story
:).

Anyways, if it can’t be detected as ps2 device (which is only a problem
on legacy non ACPI machines b/c ACPI machines pretty much hardcode the
devices into existence), it has no business being a ps2 device to begin
with.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Monday, September 22, 2003 5:35 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Load order problems with a legacy keyboard driver

I could be wrong, but it sounds like he’s saying that this keyboard
doesn’t get enumerated (strange, that). And that, therefore, i8042
doesn’t ever get an AddDevice for the keyboard.

It would be interesting to hear if there’s a way to cause i8042 to
pretend there’s a keyboard even when there “isn’t”, but on the other
hand, it’s also slightly terrifying to contemplate…

Doron Holan wrote:

On win2k and forward, you can’t rely on load order between a legacy
port
driver and kbdclass seeing it after it loads. You must either make
your
driver a boot driver or convert it into a pnp driver.

It sounds like your device is a ps2 device though; have you looked at
the kbdfiltr example in the ddk? That demonstrates how to create a
device upper filter which would allow you to filter that particular
device and not race with i8042prt as to who controls the registers and
the communication with the device.

D

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Trevor Bimler
Sent: Monday, September 22, 2003 5:27 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Load order problems with a legacy keyboard driver

A client recently asked me to write a device driver for W2K/WXP for an
application-specific keyboard which has the particularity of being
uni-directional, as a consequence of which it doesn’t get seen by the
PnP
enumerator, and i8042prt doesn’t get loaded to drive it.

As this was to be a quick-and-dirty job, I wrote a legacy driver which
is
installed as a keyboard port driver, as follows:

\Registry\Machine\System\CurrentControlSet\Services\CONSOLE
Type = REG_DWORD 0x00000001
Start = REG_DWORD 0x00000001
ErrorControl = REG_DWORD 0x00000001
Group = Keyboard Port
ImagePath=SYSTEM32\DRIVERS\CONSOLE.SYS

In its DriverEntry routine it creates an entry under

HKLM/HARDWARE/DEVICEMAP/KeyboardPort/KeyboardPort0

to let the keyboard class driver, KbdClass, know that there’s a legacy
keyboard driver to handle, after which it creates a device object and
registers a reinitialisation routine with .
>
> In the reinitialisation routine, which in theory is run after all
other
> drivers in the system load group have been loaded, I just try to
> register
> an interrupt handler for IRQ1 (the I8042 interrupt): if this succeeds
> then
> I know that i8042prt has not loaded - because the uni-directional
> keyboard
> is connected - and I manage the keyboard and send data off to
KbdClass.
> If
> it doesn’t succeed then i8042prt IS loaded so the device
autodestructs.
>
> So far so good, and it works on some installations on W2K. Following
> traces in the system log, I find that i8042prt gets loaded, then
> KbdClass,
> then - eventually - my driver. Then the reinitialisation routine in
> KbdClass gets called, it scans HKLM/HARDWARE/DEVICEMAP looking for any
> legacy devices, finds mine, and passes an
> IOCTL_INTERNAL_KEYBOARD_CONNECT
> IRP, from which point on all goes well.
>
> Unfortunately, on other installations, the above is NOT what happens.
> What
> does happen is that the reinitialisation routine in KbdClass gets
called
> before my driver is loaded, and so of course it never sees my driver.
> Which is a great shame.
>
> Does anyone have any ideas on this? I don’t really want to install my
> driver as a boot-load driver.
>
> Thanks in advance
> Trevor Bimler
> Upstart Ingenierie
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

–
…/ray..

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Thanks for the information. I’m puzzled as to why the KbdClass driver
reinitialisation routine doesn’t get called at the time Microsoft says it
should - ie after all other drivers in the group are loaded - but I
suppose I can live with it. I still think its a bug. As I don’t really
want to spend much time on the affair I think I’ll just make the driver a
boot-load driver and do something ghastly like waiting 5 seconds after
loading before trying to claim IRQ1, so as to leave time for i8042prt to
do so.

FYI, the keyboard is ps/2 style but only has a data-out line: it cannot
receive data from the controller and so can’t respond to any
interrogation/identification sequences. The result is that i8042prt
doesn’t see it and bows out early on. I had thought of doing a filter
driver but that’s impossible as there’s nothing to attach a filter to in
this case. I’d also thought of modifying i8042prt itself to force it to
load even if no keyboard was found, but I ruled that one out on the
grounds that applying any service packs would be likely to wipe out my
hacked version.

On the other hand, I didn’t think to check the source for i8042prt to see
if there were any “hidden” registry settings. If there is one to tell it
to force a load that might be simpler than the driver approach.

6

Maybe it is better to write a PnP WDM driver for w2k/XP? Using a legacy driver
which touches the hardware will disable power management.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Trevor Bimler”
To: “Windows System Software Devs Interest List”
Sent: Monday, September 22, 2003 4:26 PM
Subject: [ntdev] Load order problems with a legacy keyboard driver

> A client recently asked me to write a device driver for W2K/WXP for an
> application-specific keyboard which has the particularity of being
> uni-directional, as a consequence of which it doesn’t get seen by the PnP
> enumerator, and i8042prt doesn’t get loaded to drive it.
>
> As this was to be a quick-and-dirty job, I wrote a legacy driver which is
> installed as a keyboard port driver, as follows:
>
> \Registry\Machine\System\CurrentControlSet\Services\CONSOLE
> Type = REG_DWORD 0x00000001
> Start = REG_DWORD 0x00000001
> ErrorControl = REG_DWORD 0x00000001
> Group = Keyboard Port
> ImagePath=SYSTEM32\DRIVERS\CONSOLE.SYS
>
> In its DriverEntry routine it creates an entry under
>
> HKLM/HARDWARE/DEVICEMAP/KeyboardPort/KeyboardPort0
>
> to let the keyboard class driver, KbdClass, know that there’s a legacy
> keyboard driver to handle, after which it creates a device object and
> registers a reinitialisation routine with .
>
> In the reinitialisation routine, which in theory is run after all other
> drivers in the system load group have been loaded, I just try to register
> an interrupt handler for IRQ1 (the I8042 interrupt): if this succeeds then
> I know that i8042prt has not loaded - because the uni-directional keyboard
> is connected - and I manage the keyboard and send data off to KbdClass. If
> it doesn’t succeed then i8042prt IS loaded so the device autodestructs.
>
> So far so good, and it works on some installations on W2K. Following
> traces in the system log, I find that i8042prt gets loaded, then KbdClass,
> then - eventually - my driver. Then the reinitialisation routine in
> KbdClass gets called, it scans HKLM/HARDWARE/DEVICEMAP looking for any
> legacy devices, finds mine, and passes an IOCTL_INTERNAL_KEYBOARD_CONNECT
> IRP, from which point on all goes well.
>
> Unfortunately, on other installations, the above is NOT what happens. What
> does happen is that the reinitialisation routine in KbdClass gets called
> before my driver is loaded, and so of course it never sees my driver.
> Which is a great shame.
>
> Does anyone have any ideas on this? I don’t really want to install my
> driver as a boot-load driver.
>
> Thanks in advance
> Trevor Bimler
> Upstart Ingenierie
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Hklm\system\currentcontrolset\services\i8042prt\parameters

“Headless” : REG_DWORD : 0x01

And reboot. This will tell i8042prt to ignore device reset errors when
initializing. I think this is in win2k gold, if not, it is definitely
in win2k SP1. It is doc’ed in the res kit.

One easy way to see if the win2k gold version of i8042prt handles this
key is to dump i8042prt’s globals in the debugger,

dt i8042prt!Globals

if there is a Headless field, you’re golden. As for hacking over
i8042prt, you can always install your own service. Use
UpdateDriverForPlugAndPlayDevices to install your own service (should be
pnp, power cabable) and then you don’t have to fight with i8042prt.

As for load order, the reinit routine gets called at the end of the IO
phase (phase 2 I think) of boot. Your driver is obviously being loaded
after this phase is complete. Load order dependencies between legacy
and pnp device drivers is not guaranteed on win2k and forward.

D

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Trevor Bimler
Sent: Tuesday, September 23, 2003 1:03 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Load order problems with a legacy keyboard driver

Thanks for the information. I’m puzzled as to why the KbdClass driver
reinitialisation routine doesn’t get called at the time Microsoft says
it
should - ie after all other drivers in the group are loaded - but I
suppose I can live with it. I still think its a bug. As I don’t really
want to spend much time on the affair I think I’ll just make the driver
a
boot-load driver and do something ghastly like waiting 5 seconds after
loading before trying to claim IRQ1, so as to leave time for i8042prt to
do so.

FYI, the keyboard is ps/2 style but only has a data-out line: it cannot
receive data from the controller and so can’t respond to any
interrogation/identification sequences. The result is that i8042prt
doesn’t see it and bows out early on. I had thought of doing a filter
driver but that’s impossible as there’s nothing to attach a filter to in
this case. I’d also thought of modifying i8042prt itself to force it to
load even if no keyboard was found, but I ruled that one out on the
grounds that applying any service packs would be likely to wipe out my
hacked version.

On the other hand, I didn’t think to check the source for i8042prt to
see
if there were any “hidden” registry settings. If there is one to tell it
to force a load that might be simpler than the driver approach.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

Thanks again for the advice and the information. I’ll let you know how I
get on.

Trevor Bimler