On Tue Sep 3 13:56:42 2024 +0000, Brendan McGrath wrote:
> @nsivov Are you happy with this MR as is? Or does it something else?
I have a couple of comments, or maybe questions. Do you know how do we get in this state when it gets as far as ProcessSample(), but type is not set? SetCurrentMediaType() sets type both the mixer, and notifies the presenter. Do we need the same "loop" when other presenter methods fail similarly?
Regarding MEError, is that only to unblock waits? What might be interesting to test is if all common error codes produce MEError and not MENonFatalError. Those are listed at IMFStreamSink::ProcessSample doc page.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6059#note_80861
On Sat Aug 31 17:49:29 2024 +0000, Rémi Bernon wrote:
> > If you're referring to the new RPC structs, I understand. That being
> said, my one concern is whether stuffing the file path into `dbch_data`
> could potentially break some code out there that uses `dbch_size` to
> guess which event is being sent (something like `if (n->dbch_size ==
> (sizeof(DEV_BROADCAST_HANDLE) + sizeof(BTH_RADIO_IN_RANGE)`). It is an
> extremely stupid way to check for the event, but I'm not sure whether
> someone doing this can be safely discounted. I'll write some test code
> to see if this can be done on Windows to begin with.
> But as far as I understand, as `plugplay_send_event` is completely
> non-standard, these structs are only ever sent internally? So you don't
> really need to bother about abusing some fields or size for the internal
> notification, you even considered using custom structs which you would
> convert back and forth on both sides.
> Simply put whatever you need in the DEV_BROADCAST_HANDLE struct you
> send, using any unused field, or some other way, to put the device path
> in it if you need that, and just make sure you fix it up to a correct
> DEV_BROADCAST_HANDLE struct before calling the notification callback?
> Although I don't feel like it's even worth it you could even use a
> custom DEV_BROADCAST_HDR based struct, or extend DEV_BROADCAST_HANDLE
> with a custom derived struct which has an explicit device path, for the
> internal messages. I just don't think you need to change the
> DEV_BROADCAST_HDR base, or change the DEV_BROADCAST_DEVICEINTERFACE code
> in any significant way for this.
I have re-written this series to use `dbch_reserved` and implement `IoReportTargetDeviceChange` here, so I'll close this MR: https://gitlab.winehq.org/wine/wine/-/merge_requests/6437
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80855
On Tue Sep 3 11:03:31 2024 +0000, Ostap Brehin wrote:
> @Alcaro Thanks! I changed it back to `CALLBACK` now, it was a typo on my side.
Current SDK has is with WINAPI, and so do mingw-w64 headers. Which again, won't make any difference in practice.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6425#note_80851