This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs.

Testing and Debugging Your Driver

You can use the standard debugger to debug your driver code or you can use the old printf() method.

---

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.

---

Debugging a keyboard/mouse driver

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 that you can run your driver without graphics being started simply by starting the Photon server first.

---

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.