@lenovo-li I've done quite a few fixups -- I really hope I've not broken anything -- apologies if so.

@lenovo-li maybe it's obvious to say but please just commit fixes to the lenovo-li/lenovo-accessory branch on origin -- there's no need to do a new PR to merge fixes.

@lenovo-li and if you want to send me hardware in the UK to help test this (or to generate the emulation) that's totally fine too -- just email me and I'll share my postal address with you. 100% okay if you don't want (or can't) do this. :)

Hi @hughsie,

Thank you so much for your kind offer to help with testing and emulation! We truly appreciate you taking the extra time to support this plugin.

I've consulted with my supervisor, and we'd be happy to send you the hardware! Please send your postal address to my email ([email protected]), and I will arrange the shipment as soon as possible.

I will also push the code fixes (README updates, udev removal, GET/SET macro fix, and the enum/address cleanups we discussed) to this branch shortly. Thanks again for your guidance!

@lenovo-li yell when you've pushed your changes -- I think there's quite a bit simplification if we use a GObject interface -- i.e. the only difference between fu_lenovo_accessory_ble_*() and fu_lenovo_accessory_hid_*() is the message processing; the request and responses look the same. I'm happy to do this, but I don't want to clash with your changes.

@hughsie I've pushed the updates to the branch.

Regarding your plan to use a GObject interface, I would truly appreciate your help with that! To be honest, I'm not yet very proficient with GObject, and I was worried my implementation might be a bit messy. Thank you so much for taking the time to refactor and simplify the code!
Ready for your further review!

@lenovo-li I've split it out as an interface as we talked about and I think it's a lot cleaner. The BLE and HID devices now implement FuLenovoAccessoryImplInterface which has ->read(), ->write() and ->process() optional vfuncs. All the common code is now in fu-lenovo-accessory-impl.c

I wasn't sure if fu_lenovo_accessory_impl_get_mode() was needed -- it looks unused now perhaps. I've also simplified how you were constructing the HID Set/Get reports -- i.e. only putting the protocol payload data in the .rs file structs and hardcoding the reportid in the code.

It's highly likely I've broken this on real hardware, and apologies if so :) Once this plugin has an emulation recorded and uploaded to the LVFS (which I can do for you if required...) I'd be happy to approve merging.

@hughsie Regarding fu_lenovo_accessory_impl_get_mode(), I added this interface because I anticipate we will need it in the future to determine the device's state—specifically, whether it is currently in firmware update (FW) mode or normal operational mode. I'd prefer to keep it for now as a placeholder for that functionality.

because I anticipate we will need it in the future to determine the device's state

Should we do this in FuLenovoAccessoryHidDevice->setup or FuLenovoAccessoryBleDevice->setup perhaps?

I don't think we need to add it there. The HID device is already in the bootloader state when in DFU mode, so it behaves as a separate device entity. Also, for BLE devices, the fu_lenovo_accessory_impl_get_mode command isn't supported yet.

Hi,@hughsie
Thanks a lot for taking the time to refactor the code! The new interface approach looks much cleaner indeed.
I've finished polishing the remaining details based on your changes and have verified it on real hardware—firmware updates are working successfully now.
Please let me know if there’s anything else I should focus on or if you have further guidance.
Thanks again for your help!