Thanks for the reply. I was considering the same approach but hesitate for two reasons. 1) The existing Windows Software/Firmware has worked in this way for over 10 years. 2) It would make debugging a nightmare if the device reset while the host code was under the control of the debugger and not running. I will go that way if it's absolutely necessary, but for the time being, I am just curious of there is way of detecting client disconnect within a driver. FWIW, the windows driver is designed to treat the pipes as files and thus when the app crashes, the file handle is released and the driver receives an IRP_MJ_CLOSE request. https://msdn.microsoft.com/en-us/library/windows/hardware/ff548621%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
On Fri, Sep 29, 2017 at 5:19 AM, Kustaa Nyholm <[email protected]> wrote: > > > > > > On 29/09/2017 15:16, "Usb on behalf of [email protected]" > <[email protected] on behalf of > [email protected]> wrote: > > >I have to say I'd be tempted to do the reverse. Ping the device at a > regular interval with a vendor packet from your control panel app (or > similar) and have it shut down if nothing is received after said interval > has elapsed. > > I would second that, much safer for the device to perform this than the > host. > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Usb mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/usb/jtummond%40gmail.com > > This email sent to [email protected] >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com This email sent to [email protected]
