> Maybe we can avoid sending the paths every time by moving the filtering to plugplay, adapting the interface a bit for this. There could be additional methods to register paths / get plugplay handles in return, and later use these handle as device handles.
Perhaps, but wouldn't this make both plugplay service, and the notification code sechost/service.c a lot more stateful as a result? Re: device handles, if you're referring to the `dbch_handle` field in `DEV_BROADCAST_HANDLE`, we already get that from the user using `RegisterDeviceNotification`, and the current code just uses them for sending notifications.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80535
On Fri Aug 30 05:47:12 2024 +0000, Rémi Bernon wrote:
> > @rbernon I'm okay with using reserved as an offset to pass the device
> path, but we'd still have to pass it for every message for filtering. I
> didn't want to utilize `reserved` mostly out of caution, if it ever
> turned out to be that the field did have some undocumented semantics
> after all.
> Maybe we can avoid sending the paths every time by moving the filtering
> to plugplay, adapting the interface a bit for this. There could be
> additional methods to register paths / get plugplay handles in return,
> and later use these handle as device handles.
That seems like an awful lot of complication just to avoid defining a structure?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80533