From: Graeme G. <gr...@ar...> - 2010-04-24 15:37:14
|
For what it's worth, I've now tested all 10 of the USB devices my software supports, in combination with WinUSB, and 3 of them fail to work effectively. Yes it's because the devices are buggy in some way, but they all (can be made) to work on Linux, OS X and with libusb0.sys on MSWindows. I don't have an exact understanding of why 2 of them fail to work, but since the behaviour of the devices and WinUSB is pretty much out of my control, it's somewhat academic. Graeme Gill. |
From: Peter S. <pe...@st...> - 2010-04-24 16:23:24
|
Graeme Gill wrote: > For what it's worth, I've now tested all 10 of the USB devices my > software supports, in combination with WinUSB, and 3 of them fail > to work effectively. Thanks for reporting on the tests! > they all (can be made) to work on Linux, OS X and with libusb0.sys > on MSWindows. At least they work with libusb0.sys. Do you think it will be a big issue for your users to go with that driver instead of WinUSB? I guess there are 64-bit problems since a 64-version hasn't been signed AFAIU. //Peter |
From: Graeme G. <gr...@ar...> - 2010-04-25 02:24:39
|
Peter Stuge wrote: > At least they work with libusb0.sys. Do you think it will be a big > issue for your users to go with that driver instead of WinUSB? The main motivation for moving towards WinUSB was to avoid the 64 bit code signing issues. So this means that in general there is no alternative other than to purchase a code signing key at some stage. (or should that be "rent" - what a money making racket it is, worse even than domain names. Charging hundreds of dollars a year for one entry in a database.) Graeme Gill. |
From: Xiaofan C. <xia...@gm...> - 2010-04-25 03:12:13
|
On Sun, Apr 25, 2010 at 10:20 AM, Graeme Gill <gr...@ar...> wrote: > The main motivation for moving towards WinUSB was to avoid the > 64 bit code signing issues. So this means that in general > there is no alternative other than to purchase a code signing > key at some stage. I believe this is the case. Eventually we will fix it, I believe. On the other hand, since the libusb0.sys driver is GPLed. If some companies like it and get the WHQL for their packages, they would have to release the driver and you would probably use the signed .sys file with your own INF file (with your own VID/PIDs). You will get a warning but you can installed as it has already the KMCS ready. In this aspect, I like GPL. ;-) We will make sure as much as possible that the driver is ready for WHQL for the future versions, one thing is to bump the version to be above one. We are also in the process of fixing the filter driver issue thanks to the hints of Tim Roberts. http://sourceforge.net/tracker/?group_id=78138&atid=552262 http://sourceforge.net/tracker/?func=detail&aid=2658937&group_id=78138&atid=552262 -- Xiaofan http://mcuee.blogspot.com |
From: Xiaofan C. <xia...@gm...> - 2010-04-25 03:06:44
|
On Sat, Apr 24, 2010 at 11:33 PM, Graeme Gill <gr...@ar...> wrote: > I don't have an exact understanding > of why 2 of them fail to work, but since the behaviour of the devices > and WinUSB is pretty much out of my control, it's somewhat academic. That is why I think libusb-win32 project is still relevant. Travis and I have joined the project. http://sourceforge.net/projects/libusb-win32/ On the other hand, you can not control WinUSB as it is from Microsoft. But you can probably post the question to the newgroup microsoft.public.development.device.drivers. Microsoft employees and some driver experts outside of Microsoft (like Tim Roberts) are very helpful there. But you can also probably reject the support of the buggy device and ask the developer to fix the firmware if possible. -- Xiaofan http://mcuee.blogspot.com |
From: Graeme G. <gr...@ar...> - 2010-04-25 03:41:50
|
Xiaofan Chen wrote: > But you can also probably reject the support of the buggy device > and ask the developer to fix the firmware if possible. Not an option. If my software won't work with those devices, users will simply not use my software. (They've paid anywhere from $100 to thousands for the devices.) The Manufactures aren't going to be very interested, since the devices work with their drivers and their software on their supported OS's, and they are "old" as far as they are concerned - their R&D will be into new devices, not into issuing updates to devices in the field that "work fine" (even if it were technically possible). Graeme Gill. |