Keyboard class driver problem - NEW

Hi,

I have written a driver, which

  • is installed under the keyboard device class in my INF
  • is installed by using devcon.exe, because it is a root enumerated device
  • calls ClassServiceCallback routine of kbdclass
  • uses IOCTL_INTERNAL_KEYBOARD_CONNECT for getting the ServiceCallback
    routin

My driver

  • uses no bus driver (?), because the device is mapped to the memory
  • uses no hardware interrupt (because its a timer based driver)

My driver calls KeyboardClassServiceCallback routine of kbdclass, which
queues my input to its own keyboard input queue: WinDbg shows, that DataIn
and InputCount are increased.
But DataOut is not changed, KeyboardClassStartIo routine is never called, so
my keystrokes can not be seen on the screen. (DataOut is set only by
KeyboardClassStartIo )

While booting I get one error message: ***IopQueryLegacyBusInformation -
Driver nctfewkb returned STATUS_SUCCESS for
IRP_MN_QUERY_LEGACY_BUS_INFORMATION, and a NULL POINTER.

The DDK says that IRP_MN_QUERY_LEGACY_BUS_INFORMATION is reserved for system
use. This IRP is passed to the lower level driver (to the bus driver?) in
the i8042prt sample. But my default routin completes the IRP with
STATUS_SUCCESS, because I have no lower driver (I think, it was also set by
the INF). Is it good?

Why is KeyboardClassStartIo never called? Because the error of
QUERY_LEGACY_BUS_INFORMATION?

Please help!

Thanks,
Ferenc

Do you have a PDO (ie, an AddDevice routine that gets called when the driver is loaded)? By saying you have a root enumerated device, I would think so (and since you are getting PNP irps). If so, you are “using” a bus driver (the root enumerator) and all the std PNP documentation applies, just forward the requests on to the PDO. That means that any PNP related IRP that you don’t understand, you do not change the status of and just fwd on to the PDO. The query legacy bus info should not be hindering the function of the keyboard.

Check that kbdclass is setting the device interface state to TRUE. The raw input thread opens up the keyboard based on the arrival of this interface guid. Also, make sure that you are calling the ClassServiceCallback at DISPATCH_LEVEL. If you are calling it from your timer DPC, there is no need to call KeRaiseIrql since you are already at dispatch.

D

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

-----Original Message-----
From: Ferenc De?k [mailto:xxxxx@nct.hu]
Sent: Monday, February 03, 2003 8:43 AM
To: NT Developers Interest List
Subject: [ntdev] Keyboard class driver problem - NEW

Hi,

I have written a driver, which

  • is installed under the keyboard device class in my INF
  • is installed by using devcon.exe, because it is a root enumerated device
  • calls ClassServiceCallback routine of kbdclass
  • uses IOCTL_INTERNAL_KEYBOARD_CONNECT for getting the ServiceCallback
    routin

My driver

  • uses no bus driver (?), because the device is mapped to the memory
  • uses no hardware interrupt (because its a timer based driver)

My driver calls KeyboardClassServiceCallback routine of kbdclass, which
queues my input to its own keyboard input queue: WinDbg shows, that DataIn
and InputCount are increased.
But DataOut is not changed, KeyboardClassStartIo routine is never called, so
my keystrokes can not be seen on the screen. (DataOut is set only by
KeyboardClassStartIo )

While booting I get one error message: ***IopQueryLegacyBusInformation -
Driver nctfewkb returned STATUS_SUCCESS for
IRP_MN_QUERY_LEGACY_BUS_INFORMATION, and a NULL POINTER.

The DDK says that IRP_MN_QUERY_LEGACY_BUS_INFORMATION is reserved for system
use. This IRP is passed to the lower level driver (to the bus driver?) in
the i8042prt sample. But my default routin completes the IRP with
STATUS_SUCCESS, because I have no lower driver (I think, it was also set by
the INF). Is it good?

Why is KeyboardClassStartIo never called? Because the error of
QUERY_LEGACY_BUS_INFORMATION?

Please help!

Thanks,
Ferenc


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

> Hi,

I have written a driver, which

  • is installed under the keyboard device class in my INF
  • is installed by using devcon.exe, because it is a root enumerated device
  • calls ClassServiceCallback routine of kbdclass
  • uses IOCTL_INTERNAL_KEYBOARD_CONNECT for getting the ServiceCallback
    routin

My driver

  • uses no bus driver (?), because the device is mapped to the memory
  • uses no hardware interrupt (because its a timer based driver)

While booting I get one error message: ***IopQueryLegacyBusInformation -
Driver nctfewkb returned STATUS_SUCCESS for
IRP_MN_QUERY_LEGACY_BUS_INFORMATION, and a NULL POINTER.

The DDK says that IRP_MN_QUERY_LEGACY_BUS_INFORMATION is reserved for system
use. This IRP is passed to the lower level driver (to the bus driver?) in
the i8042prt sample. But my default routin completes the IRP with
STATUS_SUCCESS, because I have no lower driver (I think, it was also set by
the INF). Is it good?

You do have a BUS! Being root enumerated you puts your device on a
different
bus driver. You should be passing the PNP and Power IRP’s down like any
other
WDM driver, this should fix a lot of your problems.

Don Burn
Egenera, Inc

“Check that kbdclass is setting the device interface state to TRUE.”

How? (What is device interface state?)

I have an error message in WinDbg:
KBDCLASS-KbdDeterminePortsServiced: RtlQueryValues failed with 0xc0000034
(STATUS_OBJECT_NAME_NOT_FOUND)

KbdDeterminePortsServiced returns zero, the comment says “then all ports
will be dynamically PnP added later”

It is good, isn’t it?

Thanks,

Ferenc

----- Original Message -----
From: “Doron Holan”
To: “NT Developers Interest List”
Sent: Monday, February 03, 2003 6:29 PM
Subject: [ntdev] RE: Keyboard class driver problem - NEW

Do you have a PDO (ie, an AddDevice routine that gets called when the driver
is loaded)? By saying you have a root enumerated device, I would think so
(and since you are getting PNP irps). If so, you are “using” a bus driver
(the root enumerator) and all the std PNP documentation applies, just
forward the requests on to the PDO. That means that any PNP related IRP
that you don’t understand, you do not change the status of and just fwd on
to the PDO. The query legacy bus info should not be hindering the function
of the keyboard.

Check that kbdclass is setting the device interface state to TRUE. The raw
input thread opens up the keyboard based on the arrival of this interface
guid. Also, make sure that you are calling the ClassServiceCallback at
DISPATCH_LEVEL. If you are calling it from your timer DPC, there is no need
to call KeRaiseIrql since you are already at dispatch.

D

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

-----Original Message-----
From: Ferenc Deák [mailto:xxxxx@nct.hu]
Sent: Monday, February 03, 2003 8:43 AM
To: NT Developers Interest List
Subject: [ntdev] Keyboard class driver problem - NEW

Hi,

I have written a driver, which
- is installed under the keyboard device class in my INF
- is installed by using devcon.exe, because it is a root enumerated device
- calls ClassServiceCallback routine of kbdclass
- uses IOCTL_INTERNAL_KEYBOARD_CONNECT for getting the ServiceCallback
routin

My driver
- uses no bus driver (?), because the device is mapped to the memory
- uses no hardware interrupt (because its a timer based driver)

My driver calls KeyboardClassServiceCallback routine of kbdclass, which
queues my input to its own keyboard input queue: WinDbg shows, that DataIn
and InputCount are increased.
But DataOut is not changed, KeyboardClassStartIo routine is never called, so
my keystrokes can not be seen on the screen. (DataOut is set only by
KeyboardClassStartIo )

While booting I get one error message: ***IopQueryLegacyBusInformation -
Driver nctfewkb returned STATUS_SUCCESS for
IRP_MN_QUERY_LEGACY_BUS_INFORMATION, and a NULL POINTER.

The DDK says that IRP_MN_QUERY_LEGACY_BUS_INFORMATION is reserved for system
use. This IRP is passed to the lower level driver (to the bus driver?) in
the i8042prt sample. But my default routin completes the IRP with
STATUS_SUCCESS, because I have no lower driver (I think, it was also set by
the INF). Is it good?

Why is KeyboardClassStartIo never called? Because the error of
QUERY_LEGACY_BUS_INFORMATION?

Please help!

Thanks,
Ferenc


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


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

since it appears to me you are either running a debug version of kbdclass or built your own to debug your problem. Device interfaces are a way of using a GUID to notify anybody who is listening for the device’s arrival and departure. Kbdclass uses the device interface to notify user32 and the raw input thread (RIT) that a keyboard has arrived. In kbdclass’s handling of IRP_MN_START_DEVICE, it sets the interface state to TRUE at the end of init. Look there and either step through the code or build your own that has your own instrumentation.

Also, in XP, kbdclass no longer uses startio. It just uses its own cancel safe queue. Either way, put a bp on kbdclass!KeyboardClassRead and see if it hits. If so, the RIT has opened the keyboard and is reading from it.

D

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

-----Original Message-----
From: Ferenc De?k [mailto:xxxxx@nct.hu]
Sent: Tuesday, February 04, 2003 8:32 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Keyboard class driver problem - NEW

“Check that kbdclass is setting the device interface state to TRUE.”

How? (What is device interface state?)

I have an error message in WinDbg:
KBDCLASS-KbdDeterminePortsServiced: RtlQueryValues failed with 0xc0000034
(STATUS_OBJECT_NAME_NOT_FOUND)

KbdDeterminePortsServiced returns zero, the comment says “then all ports
will be dynamically PnP added later”

It is good, isn’t it?

Thanks,

Ferenc

----- Original Message -----
From: “Doron Holan”
To: “NT Developers Interest List”
Sent: Monday, February 03, 2003 6:29 PM
Subject: [ntdev] RE: Keyboard class driver problem - NEW

Do you have a PDO (ie, an AddDevice routine that gets called when the driver
is loaded)? By saying you have a root enumerated device, I would think so
(and since you are getting PNP irps). If so, you are “using” a bus driver
(the root enumerator) and all the std PNP documentation applies, just
forward the requests on to the PDO. That means that any PNP related IRP
that you don’t understand, you do not change the status of and just fwd on
to the PDO. The query legacy bus info should not be hindering the function
of the keyboard.

Check that kbdclass is setting the device interface state to TRUE. The raw
input thread opens up the keyboard based on the arrival of this interface
guid. Also, make sure that you are calling the ClassServiceCallback at
DISPATCH_LEVEL. If you are calling it from your timer DPC, there is no need
to call KeRaiseIrql since you are already at dispatch.

D

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

-----Original Message-----
From: Ferenc De?k [mailto:xxxxx@nct.hu]
Sent: Monday, February 03, 2003 8:43 AM
To: NT Developers Interest List
Subject: [ntdev] Keyboard class driver problem - NEW

Hi,

I have written a driver, which
- is installed under the keyboard device class in my INF
- is installed by using devcon.exe, because it is a root enumerated device
- calls ClassServiceCallback routine of kbdclass
- uses IOCTL_INTERNAL_KEYBOARD_CONNECT for getting the ServiceCallback
routin

My driver
- uses no bus driver (?), because the device is mapped to the memory
- uses no hardware interrupt (because its a timer based driver)

My driver calls KeyboardClassServiceCallback routine of kbdclass, which
queues my input to its own keyboard input queue: WinDbg shows, that DataIn
and InputCount are increased.
But DataOut is not changed, KeyboardClassStartIo routine is never called, so
my keystrokes can not be seen on the screen. (DataOut is set only by
KeyboardClassStartIo )

While booting I get one error message: ***IopQueryLegacyBusInformation -
Driver nctfewkb returned STATUS_SUCCESS for
IRP_MN_QUERY_LEGACY_BUS_INFORMATION, and a NULL POINTER.

The DDK says that IRP_MN_QUERY_LEGACY_BUS_INFORMATION is reserved for system
use. This IRP is passed to the lower level driver (to the bus driver?) in
the i8042prt sample. But my default routin completes the IRP with
STATUS_SUCCESS, because I have no lower driver (I think, it was also set by
the INF). Is it good?

Why is KeyboardClassStartIo never called? Because the error of
QUERY_LEGACY_BUS_INFORMATION?

Please help!

Thanks,
Ferenc


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


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


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