plugins/lenovo-accessory: new plugin for Lenovo accessories #9721
Conversation
| fu_lenovo_hid_firmware_parse(FuFirmware *firmware, | ||
| GInputStream *stream, | ||
| FuFirmwareParseFlags flags, | ||
| GError **error) | ||
| { | ||
| return TRUE; | ||
| } |
There was a problem hiding this comment.
is this firmware firmware documented anywhere? if it's just a binary blob with no format then this parser doesn't need to exist :)
There was a problem hiding this comment.
Even if it's not a full parser - could we at least parse the firmware is valid from the header and a version field?
There was a problem hiding this comment.
Thanks for the guidance. To clarify, we actually have two types of firmware files: .bin and .hex. The .hex file, in particular, likely requires proper parsing to be handled correctly.
I implemented fu_lenovo_hid_firmware_parse as a placeholder because I'm still learning the framework and noticed other plugins using it. However, during my local testing with fwupdtool install ../fw/Lenovo-hid_6201-vs1.0.2.cab --allow-older, I found that the execution never actually enters this parse function. This is why I haven't implemented the specific logic yet.
I would like to follow @superm1's suggestion to at least implement a header and version check. Could you help me understand how to correctly link this firmware parser to my device so it gets triggered during the installation process? Once I can verify the function is being called, I will update it with the necessary parsing logic for both formats.
There was a problem hiding this comment.
how to correctly link this firmware parser to my device
You can either implement a FuDeviceClass->prepare_firmware() where you can create an instance using fu_lenovo_hid_firmware_new() (if you need to check that VIDs/PIDs are valid) or you can use fu_device_set_firmware_gtype() in fu_lenovo_accessory_hid_device_init() if you want the daemon to just do it for you.
There was a problem hiding this comment.
Thank you very much for the explanation
| error)) | ||
| return FALSE; | ||
| if (usb_pid == 0x629d) | ||
| fu_device_add_instance_id(device, "HIDRAW\\VEN_17EF&DEV_629D"); |
There was a problem hiding this comment.
i think you want _build_instance_id here
There was a problem hiding this comment.
Yes, that's correct. When the device is being updated, it enters bootloader mode, and in this state, the PID for all devices changes to 0x6194. I added the instance_id here specifically to differentiate between different devices while they are in this shared bootloader state.
|
|
||
| fu_progress_set_id(progress, G_STRLOC); | ||
| fu_progress_add_step(progress, FWUPD_STATUS_DEVICE_RESTART, 100, "switch-dfu"); | ||
| fu_lenovo_accessory_command_dfu_set_devicemode(FU_HIDRAW_DEVICE(self), |
There was a problem hiding this comment.
needs to check return value if setting gerror
|
Apologies for the noise. I made a mistake while trying to squash my commits from the lenovo-ble branch and force-pushing them to lenovo-accessory. It seems I accidentally cleared the history on the target branch. |
|
@lenovo-li lets move this to the origin remote so we can all polish it up a bit. Give me a couple of mins. |
|
@lenovo-li I've moved this to #9760 -- give me a couple of hours and I'll fix up some of the issues myself. I've added com.lenovo.accessory to the LVFS -- so it should be possible (and is a requirement for merging to main!) to create an emulation of both wired and BLE updates so we can prevent future regressions. If you need a hand with that please let me know. |
Pull request was closed
Summary
Introduce
lenovo-accessoryplugin to support firmware updates for Lenovo USB-HID accessories.Scope
17ef:629d17ef:6201(USB dongle)Implementation
plugins/lenovo-accessory/with device quirks, plugin code and self-test./dev/hidraw*; udev rule grants user access./dev/bus/usb.Checklist (new plugin)