You can use the standard debugger to debug your driver code or
you can use the old printf() method.
Note:
If you're using printf(), make sure you specify
at least one -v command-line option to your
driver. Otherwise, the devi lib will close
stdout.
If you're going to use the standard debugger for a
keyboard/mouse driver, perhaps the most convenient method is
to use remote debugging via telnet.
This approach helps you avoid eventual problems caused by
the contamination of test data with debug input activity.
Note:
If you're writing a touchscreen driver and are just testing
out getting raw coordinates, then you can use the
-G option to devi-* to tell it not to
search for a graphics region when it starts up.
- PS/2 mouse
- While testing a PS/2-type of mouse, you can use the -d filename
parameter of the device-level module (see kb.c) in order to collect
and analyze raw data received from the device.
- Keyboard filter module
- In most cases, you don't need to redesign the keyboard filter module.
But if you need to, you can use the
-p filename command-line option
to devi-hirun in order to debug your program
separately without affecting the existing input system.
The protocol module kbd uses the supplied
filename to create and open a FIFO file and then duplicates
to this file all data passed to the standard filter module.
To access this data, your application should always be READ-blocked on this file.
Alternatively, you can use the -f filename option to
devi-hirun to simply create a separate file with
the same data and then use this data for debug purposes.