libfprint/tests/README-umockdev

53 lines
1.9 KiB
Text
Raw Normal View History

To create a new umockdev test, you should:
1. Decide on what to test, the easiest case is just using the existing
capture test case.
2. Find the USB device you are testing with lsusb, e.g.:
Bus 001 Device 005: ID 138a:0090 Validity Sensors, Inc. VFS7500 Touch Fingerprint Sensor
This means we need to record USB device /dev/bus/usb/001/005
3. Run "umockdev-record /dev/bus/usb/001/005 >device"
This records the information about device, it should be placed into test/DRIVER/device
4. Run the test, for a capture test this would be:
umockdev-record -i /dev/bus/usb/001/005=capture.ioctl -- ./capture.py capture.png
This will create a capture.ioctl and capture.png file.
Please set the FP_DEVICE_EMULATION=1 environment variable. You may need
to adjust the driver to adapt to the emulated environment (mainly if it
uses random numbers, see synaptics.c for an example).
5. Place all files into the driver subdirectory test/DRIVER,
i.e. device, capture.ioctl, capture.png
6. Add glue to meson.build
7. Test whether everything works as expected
Please note, there is no need to use a real finger print in this case. If
you would like to avoid submitting your own fingerprint then please just
use e.g. the side of your finger, arm, or anything else that will produce
an image with the device.
Note that umockdev-record groups URBs aggressively. In most cases, manual
intervention is unfortunately required. In most cases, drivers do a chain
of commands like e.g. A then B each with a different reply. Umockdev will
create a file like:
A
reply 1
reply 2
B
reply 1
reply 2
which then needs to be re-ordered to be:
A
reply 1
B
reply 1
A
reply 2
B
reply 2
Other changes may be needed to get everything working. For example the elan
driver relies on a timeout that is not reported correctly. In this case the
driver works around it by interpreting the protocol error differently in
the virtual environment.