I'm working on a keyboard class upper filter driver, based on the DDK
kbfiltr sample.
Succeed to get data send from the controller through i8042.

Now I want to send commands to the keyboard controller from my filter
driver, meaning send data to be written to port 60\64.
can it be done?
which IRP i should use?

10X in advance
Tamar.

Use IOCTL_INTERNAL_I8042_KEYBOARD_WRITE_BUFFER to write commands to the
keyboard via the data port (and use the ISR callback to receive the
responses).

There's no officially supported way to write to the command port. If
you're excruciatingly careful it's technically possible to write to the
command port directly using WRITE_PORT_UCHAR while synchronized with the
i8042prt ISR, but this can lead to numerous problems and should be
avoided unless absolutely necessary.

You can also use an initialization callback routine and write to the
keyboard in that context with PI8042_SYNCH_WRITE_PORT.

All of this is documented in the DDK.

Note, however, that i8042 doesn't provide any mechanism to write atomic
sequences of commands to the port that have responses. You can spew a
sequence of bytes atomically, but multiple calls are needed to send a
command, get a response, send another command and get another response.
This defeats the synchronization mechanism, so you're susceptible to
interference from other drivers including i8042prt itself.

tamar wrote:

--
.../ray\..

Thanks for your answer.

I try to get a "pointer" to i8042 using IoGetDeviceObjectPointer , it
fail , return status = 34 (STATUS_OBJECT_NAME_NOT_FOUND)



RtlInitUnicodeString(&ObjectName, "\\Device\\i8042prt");

status = IoGetDeviceObjectPointer(&ObjectName, FILE_READ_DATA ,
&pFileObj, &pDeviceObj);

where i go wrong?

Thanks
Tamar

For what? Use the KBDFILTR-style filter instead.

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

"tamar" <tamarlev@hotmail.com> wrote in message
news:1120663707.630444.228930@g14g2000cwa.googlegr oups.com...

If you're an upper filter, you should have gotten a PDO in AddDevice
that you pass to IoAttachDeviceToDeviceStack, which returns a pointer to
the driver you want to send all your IOCTLs too.

Even if you were able to get a direct i8042prt pointer, you wouldn't
want to bypass any other filters that might be attached between it and you.

tamar wrote:

--
.../ray\..

Thanks ray.

now i have additional question -
Shall i send syncronic (using IoBuildDeviceIoControlRequest)
or asyncronic (using IoAllocateIrp) request ?

Thanks, ray.

I have additional question
shall i send a synchronic IRP ( build using
IoBuildDeviceIoControlRequest )
or asynchronic one (build using IoAllocateIrp ) ?

Tamar.

i think you should send an asynchronous request

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"tamar" <tamarlev@hotmail.com> wrote in message
news:1122909416.395152.295710@f14g2000cwb.googlegr oups.com...

Doron Holan [MS] wrote:
He should certainly *send it* asynchronously (it's always going to
return STATUS_PENDING if it succeeds anyway, so there's not much real
choice, except whether you wait on the event or set a completion routine).

But isn't IoBuildDeviceIoControlRequest a much easier way to create this
IRP than calling IoAllocateIrp and filling in everything by hand (and
hoping you get everything right)?

Or maybe I'm missing some subtlety :-).
--
.../ray\..

IoBuildDeviceIoControlRequest is a threaded IRP API, the irp must be
completed on the same thread. from MSDN:

The IoBuildDeviceIoControlRequest routine allocates and sets up an IRP for a
synchronously processed device control request

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Ray Trent" <rat@nospam.nospam> wrote in message
news:%23GlWYsvlFHA.2904@TK2MSFTNGP14.phx.gbl...

IoBuildDeviceIoControlRequest assigns the IRP to the thread, which is not
always good.

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

"Ray Trent" <rat@nospam.nospam> wrote in message
news:%23GlWYsvlFHA.2904@TK2MSFTNGP14.phx.gbl...