From: Xiaofan C. <xia...@gm...> - 2015-03-10 06:36:02
|
On Tue, Mar 10, 2015 at 8:00 AM, Graeme Gill <gr...@ar...> wrote: > Xiaofan Chen wrote: >> the preferred general purpose driver in the future. libusb0.sys does >> not matter too much for libusb Windows backend since its unique >> filter capability does not work too well for many device. > > Are there any contemporary reports of problems with libusb0.sys > as a filter driver ? - I've not noticed any on the libusb-win32 list, > just the references to the historical problems before Travis fixed it. It does not work on device with (most of the?) UMDF driver which seems to be preferred driver model for many USB device. The problem with current libusb Windows backend is that libusb0.sys does not work well, especially the filter mode. Therefore it can not be recommended to be used now with the libusb Windows backend (libusb-1.0 API). Probably this should be fixed but I think it is not the focus now. >> WinUSB >> has bridged libusbK's main advantage (isoc transfer) in Windows 8.1 >> so that libusbK's limited use will probably for those who like the >> Windows only libusbK API. > > The inability to control certain aspects of WinUSB enumeration behavior > (making it incompatible with some USB devices I support) makes it > a non-choice for my particular application, so don't draw > the conclusion that libusb0 is deprecated - it's not. I never say that libusb0.sys (or libusb-win32 project) is deprecated. In fact, it is in bug-fix only mode but still supported. It is just that it does not work with the current libusb Windows backend. >> UsbDk's dynamic driver switching capability is interesting. So I think >> it may well have some niches as well. > > It's attractive from the point of view of inter-working with existing > vendor devices system drivers (just like libusb0 filter mode), perhaps > avoiding the need to swap drivers simply to use alternate user applications. -- Xiaofan |