6716359fe8
umockdev recordings are usually not usable as is. Add some notes to the README to summarise what kind of changes may be required.
53 lines
No EOL
1.9 KiB
Text
53 lines
No EOL
1.9 KiB
Text
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. |