Plugin pixart-rf has a coverage score of 11% #7095
Comments
|
@hughsie I follow this page Device Emulation to record behavior of my device, but have problem when I use Below is my command history : I unplug my device, then replug it. I am using docker with os ubuntu 24.04 Below is information of my device: |
Have you got three identical dongles attached? If so, can you try with just one attached? |
|
Actually, these three Device IDs all come from the same Dongle because the Dongle declares three Interfaces. However, this does not affect the firmware update; It can be selected any one of them to update the Dongle. |
|
@hughsie same problem with composite devices maybe? |
|
So fwupdmgr emulation function is not support composite devices? |
|
Sorry for the delay. I don't think it makes sense to show 6 devices for a dingle and a single mouse! :) Can we look at the interface field and ignore 2/3 of them perhaps? It's going to really confuse the various UIs we have for fwupd to see three devices when one is plugged in. |
|
@hughsie Sure, I will modify the device code so that it only displays one interface, and then test if it works properly. |
|
@hughsie , I have modified the device to display a single interface, but the emulation-save feature is still not working. fwupdmgr get-devices shows as below, can see just only one device Here is log history of operation: The following link is video demonstrates my process: fwupdmgr version: OS version in Docker container: |
|
Okay, so for some reason it's either not saving the "emulation-tag" flag for the device (seems unlikely) or it's not matching up the device on re-plug for some reason. Can you attach the output of Also, do I have any pixart hardware here? e.g. would something like the HP910 work in the same way? |
|
@hughsie Attached are output files, My device still has three interfaces(index 0~2) in the usb config description, so there are still three devices appearing in /dev.
I will discuss internally to see how we can prepare a hardware for you. |
|
Hardware would be great, thanks. Same address as last time. I have a suspicion: If you run e.g. I see |
The backend ID is typically a sysfs path or USB platform ID -- the latter working well for USB devices, but not working for devices with autoincrementing values (e.g. hidraw) or random values (e.g. bluetooth), for example: `/sys/devices/0000:00:14.0/usb1/1-3/1-3:1.1/0003:03F0:6841.010E/hidraw/hidraw6` Just use the device ID instead, as that's already made up of the physical and logical IDs combined, which is exactly what we want to use for identification. Fixes #7095
The backend ID is typically a sysfs path or USB platform ID -- the latter working well for USB devices, but not working for devices with autoincrementing values (e.g. hidraw) or random values (e.g. bluetooth), for example: `/sys/devices/0000:00:14.0/usb1/1-3/1-3:1.1/0003:03F0:6841.010E/hidraw/hidraw6` Just use the device ID instead, as that's already made up of the physical and logical IDs combined, which is exactly what we want to use for identification. Fixes #7095
@hughsie thank you! |
The pixart-rf fwupd plugin has a very low coverage score: https://coveralls.io/github/fwupd/fwupd -- This means it’s not being adequately tested during CI and pre-release testing, and might mean we release the plugin to end users with an accidental and unfortunate regression. The best way to make sure this doesn’t happen is to provide a device-test, and there are a lot of examples in https://github.com/fwupd/fwupd/tree/main/data/device-tests for existing hardware.
The emulated device test in CI downloads a “device emulation data” from the LVFS which sets up a virtual USB device that we can control from the daemon. Then we download a cab archive of the actual firmware for the device (also from the LVFS) and then install the real firmware archive on the virtual device. This usually tests out a lot of the plugin functionality, and is enough to make the plugin coverage rise up to 70-90% typically – which is great, and means we can refactor the common daemon code without risk of introducing a regression. All new USB plugins going into fwupd now must have an emulated test for CI, and we’re now trying to get the existing plugins up to the same standard.
We’re of course happy to help with this task, but we don’t have all the physical hardware needed to generate an emulation of the update being applied. This is why I’ve assigned the plugin owner to this issue :) What I’d like you to do is:
embargo,testing, orstableremote – it can remain in private if needed.fwupdmgr get-devicesoutput when the device is in the normal runtime modeWe can then test the emulation works on our system (without physical hardware), build the JSON file and add it to the fwupd repo for you. Although one firmware will work, ideally we want to test upgrading from 1.0.2 to 1.0.3 and downgrading from 1.0.3 to 1.0.2 (with example version numbers) rather than just reinstalling 1.0.3 onto itself. If you'd like to write the device-test JSON file yourself and submit a PR that's even better.
If you have any questions, queries or worries please let us know, either here or by email. Thanks!
The text was updated successfully, but these errors were encountered: