Menu
▾
▴
libusb-win32-devel
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(27) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(19) |
Mar
(13) |
Apr
(15) |
May
(11) |
Jun
(17) |
Jul
(31) |
Aug
(45) |
Sep
(10) |
Oct
(40) |
Nov
(39) |
Dec
(45) |
| 2005 |
Jan
(113) |
Feb
(45) |
Mar
(38) |
Apr
(53) |
May
(11) |
Jun
(42) |
Jul
(56) |
Aug
(50) |
Sep
(32) |
Oct
(32) |
Nov
(47) |
Dec
(22) |
| 2006 |
Jan
(19) |
Feb
(32) |
Mar
(40) |
Apr
(40) |
May
(41) |
Jun
(44) |
Jul
(37) |
Aug
(51) |
Sep
(30) |
Oct
(30) |
Nov
(51) |
Dec
(20) |
| 2007 |
Jan
(7) |
Feb
(20) |
Mar
(17) |
Apr
(67) |
May
(13) |
Jun
(73) |
Jul
(16) |
Aug
(58) |
Sep
(29) |
Oct
(5) |
Nov
(74) |
Dec
(9) |
| 2008 |
Jan
(17) |
Feb
(12) |
Mar
(65) |
Apr
(22) |
May
(40) |
Jun
(32) |
Jul
(11) |
Aug
(8) |
Sep
(3) |
Oct
(41) |
Nov
(34) |
Dec
(12) |
| 2009 |
Jan
(44) |
Feb
(33) |
Mar
(16) |
Apr
(109) |
May
(11) |
Jun
(22) |
Jul
(21) |
Aug
(37) |
Sep
(5) |
Oct
(23) |
Nov
(7) |
Dec
(7) |
| 2010 |
Jan
(36) |
Feb
(40) |
Mar
(35) |
Apr
(45) |
May
(42) |
Jun
(104) |
Jul
(135) |
Aug
(50) |
Sep
(65) |
Oct
(110) |
Nov
(129) |
Dec
(75) |
| 2011 |
Jan
(105) |
Feb
(48) |
Mar
(93) |
Apr
(166) |
May
(169) |
Jun
(188) |
Jul
(106) |
Aug
(33) |
Sep
(85) |
Oct
(46) |
Nov
(102) |
Dec
(105) |
| 2012 |
Jan
(81) |
Feb
(115) |
Mar
(56) |
Apr
(93) |
May
(56) |
Jun
(77) |
Jul
(88) |
Aug
(52) |
Sep
(72) |
Oct
(16) |
Nov
(70) |
Dec
(70) |
| 2013 |
Jan
(23) |
Feb
(85) |
Mar
(38) |
Apr
(48) |
May
(40) |
Jun
(49) |
Jul
(33) |
Aug
(28) |
Sep
(66) |
Oct
(28) |
Nov
(28) |
Dec
(16) |
| 2014 |
Jan
(33) |
Feb
(58) |
Mar
(17) |
Apr
(50) |
May
(16) |
Jun
(24) |
Jul
(19) |
Aug
(32) |
Sep
(10) |
Oct
(10) |
Nov
(4) |
Dec
(10) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(4) |
Apr
(14) |
May
(1) |
Jun
(6) |
Jul
(16) |
Aug
(29) |
Sep
(6) |
Oct
(26) |
Nov
(10) |
Dec
|
| 2016 |
Jan
|
Feb
(20) |
Mar
(6) |
Apr
|
May
(3) |
Jun
(3) |
Jul
|
Aug
(16) |
Sep
(6) |
Oct
|
Nov
(15) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2018 |
Jan
|
Feb
(8) |
Mar
(10) |
Apr
(16) |
May
|
Jun
(15) |
Jul
|
Aug
(3) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(6) |
Oct
(2) |
Nov
(4) |
Dec
|
| 2022 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(1) |
May
(11) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(3) |
Dec
|
|
From: Stephan M. <Ste...@ia...> - 2007-11-20 09:37:56
|
VGhpcyBsb29rcyBsaWtlIGEgY29udHJvbCBtZXNzYWdlIG5vdCBsaWtlDQphbiBpbnRlcnJ1cHQg cmVxdWVzdC4NClRyeSA6IHZiX3VzYl9jb250cm9sX21zZyh1c2JfZGV2X2hhbmRsZSAqZGV2LCBp bnQgcmVxdWVzdHR5cGUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgcmVx dWVzdCwgaW50IHZhbHVlLCBpbnQgaW5kZXgsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY2hhciAqYnl0ZXMsIGludCBzaXplLCBpbnQgdGltZW91dCkNClN0ZXBoYW4NCg0KDQo+ IEhpIFN0ZXBoYW4sDQo+IA0KPiBJJ20gdHJ1bHkgdGhhbmtmdWwgZm9yIHRoZSBjb2RlLiBJIHRy aWVkIGl0IGFuZCBpdCB3b3JrcyB3ZWxsIGFuZCANCj4gYWJsZSB0byBkZXRlY3QgbXkgZGV2aWNl LiBJZiB5b3UgZG9uJ3QgbWluZCwgSSB3b3VsZCBsaWtlIHRvIGFzayBhIA0KPiBxdWVzdGlvbiBv biBpbnRlcnJ1cHQgdHJhbnNmZXIuDQo+IA0KPiBJIHRyaWVkIHRoZSB1c2Jfb3BlbiBjb2RlIGFu ZCBpdCBpcyBhYmxlIHRvIGdldCBhIGhhbmRsZSBvbiBteSANCj4gZGV2aWNlLiBBZnRlciB1c2Jf b3BlbiwgbGV0J3Mgc2F5IEkgd2FudCB0byBjYWxsIGEgY3VzdG9tIGNvbW1hbmQgbGlrZSANCmJl bG93Ow0KPiANCj4gVHlwZSAgIFJlcSAgIFZhbHVlICAgSW5kZXggICBMZW5ndGgNCj4gQzAgICAg ICAwMSAgICAgMDAgMDAgICAgMDAgMDAgICAwMSAwMCANCj4gDQo+IEhvdyBjYW4gSSBkbyB0aGF0 IHVzaW5nICJ2Yl91c2JfaW50ZXJydXB0X3JlYWQgKGRldiwgZXAsIGJ1Ziwgc2l6ZSwgDQp0aW1l b3V0KSI/DQo+IA0KPiANCj4gDQo+IA0KPiBTdGVwaGFuIE1leWVyIDxTdGVwaGFuLk1leWVyQGlh di5kZT4gd3JvdGU6DQo+IEkgd3JvdGUgYSBsaWJ1c2IgVkI2IG1vZHVsZSBhIHdoaWxlIGFnbyAo c2VlIGF0dGFjaGVtZW50KS4NCj4gSXQncyBub3Qgd2VsbCB0ZXN0ZWQgYW5kIG1pZ2h0IGNvbnRh aW4gYnVncyBidXQgeW91IGNhbg0KPiB1c2UgaXQgYXMgYSBiYXNpcyBmb3IgeW91ciBkZXZlbG9w bWVudC4NCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgeW91IGNhbid0IGFjY2VzcyBsaWJ1c2IwLmRs bCBmcm9tIFZCDQo+IGRpcmVjdGx5LCB5b3UgaGF2ZSB0byBhY2Nlc3MgdGhlIERMTCB0aHJvdWdo IGxpYnVzYnZiMC5kbGwNCj4gY29udGFpbmVkIGluIHRoZSB6aXAtZmlsZS4gVGhlIHJlYXNvbiBm b3IgdGhpcyBpcyB0aGF0IA0KPiBhbGwgbGlidXNiMC5kbGwgZnVuY3Rpb25zIHVzZSB0aGUgJ2Nk ZWNsJyBjYWxsaW5nIGNvbnZlbnRpb24sDQo+IHdoZXJlYXMgVkIgb25seSBzdXBwb3J0cyAnc3Rk Y2FsbCcuDQo+IA0KPiBTdGVwaGFuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gPiBEZWFyIEFsbCwN Cj4gPiANCj4gPiBJw6LigqzihKJtIGxvb2tpbmcgZm9yIGluZm9ybWF0aW9uIG9uIGhvdyB0byB1 c2UgVkI2LjAgdG8gY29tbXVuaWNhdGUgd2l0aCANCg0KPiBsaWJ1c2IuIA0KPiA+IFdoYXQgSSBj YW4gZmluZCBmcm9tIHRoZSBpbnRlcm5ldCB0aGF0IHdvcmtzOw0KPiA+IERlY2xhcmUgU3ViIHVz Yl9pbml0IExpYiAibGlidXNiMC5kbGwiICgpDQo+ID4gRGVjbGFyZSBGdW5jdGlvbiB1c2JfZmlu ZF9idXNzZXMgTGliICJsaWJ1c2IwLmRsbCIgKCkgQXMgSW50ZWdlcg0KPiA+IERlY2xhcmUgRnVu Y3Rpb24gdXNiX2ZpbmRfZGV2aWNlcyBMaWIgImxpYnVzYjAuZGxsIiAoKSBBcyBJbnRlZ2VyDQo+ ID4gdXNiX2luaXQoKQ0KPiA+IG5CdXNzZXMgPSB1c2JfZmluZF9idXNzZXMoKQ0KPiA+IG5EZXZp Y2VzID0gdXNiX2ZpbmRfZGV2aWNlcygpDQo+ID4gTGFiZWwxLlRleHQgPSAiRGV2aWNlcyAiICYg bkRldmljZXMNCj4gPiBMYWJlbDIuVGV4dCA9ICJCdXNzZXMgIiAmIG5CdXNzZXMNCj4gPiANCj4g PiBJcyB0aGVyZSBhbnlvbmUgb3V0IHRoZXJlIHRoYXQgaGFzIHN1Y2Nlc3NmdWxseSBkb25lIGl0 IGluIFZCNi4wIHRvIA0KPiA+IGNhbGwgb3RoZXIgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IMOi4oKs xZN1c2Jfb3BlbsOi4oKswp0sIA0Kw6LigqzFk1VTQl9JbnRlcnJ1cHRfUmVhZMOi4oKswp0gDQo+ ID4gYW5kIMOi4oKsxZNVU0JfSW50ZXJydXB0X1dyaXRlw6LigqzCnT8NCj4gPiBJIHdvdWxkIGFw cHJlY2lhdGUgZm9yIGFueSBhZHZpY2Ugb3Igc2hhcmluZyBvZiB0aGUgY29kZSAoaWYgYW55LCAN Cj4gPiBwbGVhc2Ugc2VuZCB0byBtZSBsZW9uYWxsX29uZ0B5YWhvby5jb20pLiANCj4gPiBUaGFu ayB5b3UuDQo+ID4gDQo+ID4gR2V0IGVhc3ksIG9uZS1jbGljayBhY2Nlc3MgdG8geW91ciBmYXZv cml0ZXMuIE1ha2UgWWFob28hIHlvdXIgDQo+IGhvbWVwYWdlLiANCj4gPiANCj4gDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4gVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBNaWNyb3Nv ZnQNCj4gPiBEZWZ5IGFsbCBjaGFsbGVuZ2VzLiBNaWNyb3NvZnQoUikgVmlzdWFsIFN0dWRpbyAy MDA1Lg0KPiA+IGh0dHA6Ly9jbGsuYXRkbXQuY29tL01SVC9nby92c2UwMTIwMDAwMDcwbXJ0L2Rp cmVjdC8wMS8NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IExpYnVzYi13aW4zMi1kZXZlbCBtYWlsaW5nIGxpc3QNCj4gPiBMaWJ1c2Itd2lu MzItZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+ID4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vm b3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbGlidXNiLXdpbjMyLWRldmVsDQo+IA0KPiANCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBNaWNyb3Nv ZnQNCj4gRGVmeSBhbGwgY2hhbGxlbmdlcy4gTWljcm9zb2Z0KFIpIFZpc3VhbCBTdHVkaW8gMjAw NS4NCj4gaHR0cDovL2Nsay5hdGRtdC4NCj4gDQpjb20vTVJUL2dvL3ZzZTAxMjAwMDAwNzBtcnQv ZGlyZWN0LzAxL19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IExpYnVzYi13aW4zMi1kZXZlbCBtYWlsaW5nIGxpc3QNCj4gTGlidXNiLXdpbjMyLWRldmVs QGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9s aXN0cy9saXN0aW5mby9saWJ1c2Itd2luMzItZGV2ZWwNCj4gDQo+ICBCZSBhIGJldHRlciBzcG9y dHMgbnV0ISBMZXQgeW91ciB0ZWFtcyBmb2xsb3cgeW91IHdpdGggWWFob28gTW9iaWxlLiANCj4g VHJ5IGl0IG5vdy4NCj4gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRoaXMgU0YubmV0IGVtYWlsIGlz IHNwb25zb3JlZCBieTogTWljcm9zb2Z0DQo+IERlZnkgYWxsIGNoYWxsZW5nZXMuIE1pY3Jvc29m dChSKSBWaXN1YWwgU3R1ZGlvIDIwMDUuDQo+IGh0dHA6Ly9jbGsuYXRkbXQuY29tL01SVC9nby92 c2UwMTIwMDAwMDcwbXJ0L2RpcmVjdC8wMS8NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gTGlidXNiLXdpbjMyLWRldmVsIG1haWxpbmcgbGlzdA0K PiBMaWJ1c2Itd2luMzItZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+IGh0dHBzOi8vbGlz dHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2xpYnVzYi13aW4zMi1kZXZlbA0KDQo= |
|
From: ong l. <leo...@ya...> - 2007-11-20 09:15:45
|
Hi Stephan, Please ignore my first reply, control and interrupt is absolutely different format. So, I tried the using control transfer instead. If i want to send "C0 01 0000 0000 0100 (Type Req Value Index Length), is what I did below correct? Dim my_handle my_handle = UsbOpen(0, &H192F, &H216) If my_handle = 0 Then Debug.Print " No such device " text1 = UsbControlMsg(my_handle, "C0", "01", "0000", "0000", buf , "0100", timeout) What should be filled for "buf" and "timeout"? Thanks. ong leonall <leo...@ya...> wrote: Hi Stephan, I'm truly thankful for the code. I tried it and it works well and able to detect my device. If you don't mind, I would like to ask a question on interrupt transfer. I tried the usb_open code and it is able to get a handle on my device. After usb_open, let's say I want to call a custom command like below; Type Req Value Index Length C0 01 00 00 00 00 01 00 How can I do that using "vb_usb_interrupt_read (dev, ep, buf, size, timeout)"? Stephan Meyer <Ste...@ia...> wrote: I wrote a libusb VB6 module a while ago (see attachement). It's not well tested and might contain bugs but you can use it as a basis for your development. Please note that you can't access libusb0.dll from VB directly, you have to access the DLL through libusbvb0.dll contained in the zip-file. The reason for this is that all libusb0.dll functions use the 'cdecl' calling convention, whereas VB only supports 'stdcall'. Stephan > Dear All, > > Iâm looking for information on how to use VB6.0 to communicate with libusb. > What I can find from the internet that works; > Declare Sub usb_init Lib "libusb0.dll" () > Declare Function usb_find_busses Lib "libusb0.dll" () As Integer > Declare Function usb_find_devices Lib "libusb0.dll" () As Integer > usb_init() > nBusses = usb_find_busses() > nDevices = usb_find_devices() > Label1.Text = "Devices " & nDevices > Label2.Text = "Busses " & nBusses > > Is there anyone out there that has successfully done it in VB6.0 to > call other functions, especially âusb_openâ, âUSB_Interrupt_Readâ > and âUSB_Interrupt_Writeâ? > I would appreciate for any advice or sharing of the code (if any, > please send to me leo...@ya...). > Thank you. > > Get easy, one-click access to your favorites. Make Yahoo! your homepage. > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Libusb-win32-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ Libusb-win32-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel --------------------------------- Get easy, one-click access to your favorites. Make Yahoo! your homepage. --------------------------------- Get easy, one-click access to your favorites. Make Yahoo! your homepage. |
|
From: ong l. <leo...@ya...> - 2007-11-20 08:20:54
|
Hi Stephan, I'm truly thankful for the code. I tried it and it works well and able to detect my device. If you don't mind, I would like to ask a question on interrupt transfer. I tried the usb_open code and it is able to get a handle on my device. After usb_open, let's say I want to call a custom command like below; Type Req Value Index Length C0 01 00 00 00 00 01 00 How can I do that using "vb_usb_interrupt_read (dev, ep, buf, size, timeout)"? Stephan Meyer <Ste...@ia...> wrote: I wrote a libusb VB6 module a while ago (see attachement). It's not well tested and might contain bugs but you can use it as a basis for your development. Please note that you can't access libusb0.dll from VB directly, you have to access the DLL through libusbvb0.dll contained in the zip-file. The reason for this is that all libusb0.dll functions use the 'cdecl' calling convention, whereas VB only supports 'stdcall'. Stephan > Dear All, > > Iâm looking for information on how to use VB6.0 to communicate with libusb. > What I can find from the internet that works; > Declare Sub usb_init Lib "libusb0.dll" () > Declare Function usb_find_busses Lib "libusb0.dll" () As Integer > Declare Function usb_find_devices Lib "libusb0.dll" () As Integer > usb_init() > nBusses = usb_find_busses() > nDevices = usb_find_devices() > Label1.Text = "Devices " & nDevices > Label2.Text = "Busses " & nBusses > > Is there anyone out there that has successfully done it in VB6.0 to > call other functions, especially âusb_openâ, âUSB_Interrupt_Readâ > and âUSB_Interrupt_Writeâ? > I would appreciate for any advice or sharing of the code (if any, > please send to me leo...@ya...). > Thank you. > > Get easy, one-click access to your favorites. Make Yahoo! your homepage. > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Libusb-win32-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ Libusb-win32-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel --------------------------------- Get easy, one-click access to your favorites. Make Yahoo! your homepage. |
|
From: ong l. <leo...@ya...> - 2007-11-20 08:06:40
|
Hi Stephan, I'm truly thankful for the code. I tried it and it works well and able to detect my device. If you don't mind, I would like to ask a question on interrupt transfer. I tried the usb_open code and it is able to get a handle on my device. After usb_open, let's say I want to call a custom command like below; Type Req Value Index Length C0 01 00 00 00 00 01 00 How can I do that using "vb_usb_interrupt_read (dev, ep, buf, size, timeout)"? Stephan Meyer <Ste...@ia...> wrote: I wrote a libusb VB6 module a while ago (see attachement). It's not well tested and might contain bugs but you can use it as a basis for your development. Please note that you can't access libusb0.dll from VB directly, you have to access the DLL through libusbvb0.dll contained in the zip-file. The reason for this is that all libusb0.dll functions use the 'cdecl' calling convention, whereas VB only supports 'stdcall'. Stephan > Dear All, > > Iâm looking for information on how to use VB6.0 to communicate with libusb. > What I can find from the internet that works; > Declare Sub usb_init Lib "libusb0.dll" () > Declare Function usb_find_busses Lib "libusb0.dll" () As Integer > Declare Function usb_find_devices Lib "libusb0.dll" () As Integer > usb_init() > nBusses = usb_find_busses() > nDevices = usb_find_devices() > Label1.Text = "Devices " & nDevices > Label2.Text = "Busses " & nBusses > > Is there anyone out there that has successfully done it in VB6.0 to > call other functions, especially âusb_openâ, âUSB_Interrupt_Readâ > and âUSB_Interrupt_Writeâ? > I would appreciate for any advice or sharing of the code (if any, > please send to me leo...@ya...). > Thank you. > > Get easy, one-click access to your favorites. Make Yahoo! your homepage. > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Libusb-win32-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ Libusb-win32-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel --------------------------------- Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. |
|
From: Stephan M. <Ste...@ia...> - 2007-11-20 07:26:39
|
SSB3cm90ZSBhIGxpYnVzYiBWQjYgbW9kdWxlIGEgd2hpbGUgYWdvIChzZWUgYXR0YWNoZW1lbnQp Lg0KSXQncyBub3Qgd2VsbCB0ZXN0ZWQgYW5kIG1pZ2h0IGNvbnRhaW4gYnVncyBidXQgeW91IGNh bg0KdXNlIGl0IGFzIGEgYmFzaXMgZm9yIHlvdXIgZGV2ZWxvcG1lbnQuDQoNClBsZWFzZSBub3Rl IHRoYXQgeW91IGNhbid0IGFjY2VzcyBsaWJ1c2IwLmRsbCBmcm9tIFZCDQpkaXJlY3RseSwgeW91 IGhhdmUgdG8gYWNjZXNzIHRoZSBETEwgdGhyb3VnaCBsaWJ1c2J2YjAuZGxsDQpjb250YWluZWQg aW4gdGhlIHppcC1maWxlLiBUaGUgcmVhc29uIGZvciB0aGlzIGlzIHRoYXQgDQphbGwgbGlidXNi MC5kbGwgZnVuY3Rpb25zIHVzZSB0aGUgJ2NkZWNsJyBjYWxsaW5nIGNvbnZlbnRpb24sDQp3aGVy ZWFzIFZCIG9ubHkgc3VwcG9ydHMgJ3N0ZGNhbGwnLg0KDQpTdGVwaGFuDQoNCg0KDQoNCg0KPiBE ZWFyIEFsbCwNCj4gDQo+IEnigJltIGxvb2tpbmcgZm9yIGluZm9ybWF0aW9uIG9uIGhvdyB0byB1 c2UgVkI2LjAgdG8gY29tbXVuaWNhdGUgd2l0aCANCmxpYnVzYi4gDQo+IFdoYXQgSSBjYW4gZmlu ZCBmcm9tIHRoZSBpbnRlcm5ldCB0aGF0IHdvcmtzOw0KPiBEZWNsYXJlIFN1YiB1c2JfaW5pdCBM aWIgImxpYnVzYjAuZGxsIiAoKQ0KPiBEZWNsYXJlIEZ1bmN0aW9uIHVzYl9maW5kX2J1c3NlcyBM aWIgImxpYnVzYjAuZGxsIiAoKSBBcyBJbnRlZ2VyDQo+IERlY2xhcmUgRnVuY3Rpb24gdXNiX2Zp bmRfZGV2aWNlcyBMaWIgImxpYnVzYjAuZGxsIiAoKSBBcyBJbnRlZ2VyDQo+IHVzYl9pbml0KCkN Cj4gbkJ1c3NlcyA9IHVzYl9maW5kX2J1c3NlcygpDQo+IG5EZXZpY2VzID0gdXNiX2ZpbmRfZGV2 aWNlcygpDQo+IExhYmVsMS5UZXh0ID0gIkRldmljZXMgIiAmIG5EZXZpY2VzDQo+IExhYmVsMi5U ZXh0ID0gIkJ1c3NlcyAiICYgbkJ1c3Nlcw0KPiANCj4gSXMgdGhlcmUgYW55b25lIG91dCB0aGVy ZSB0aGF0IGhhcyBzdWNjZXNzZnVsbHkgZG9uZSBpdCBpbiBWQjYuMCB0byANCj4gY2FsbCBvdGhl ciBmdW5jdGlvbnMsIGVzcGVjaWFsbHkg4oCcdXNiX29wZW7igJ0sIOKAnFVTQl9JbnRlcnJ1cHRf UmVhZOKAnSANCj4gYW5kIOKAnFVTQl9JbnRlcnJ1cHRfV3JpdGXigJ0/DQo+IEkgd291bGQgYXBw cmVjaWF0ZSBmb3IgYW55IGFkdmljZSBvciBzaGFyaW5nIG9mIHRoZSBjb2RlIChpZiBhbnksIA0K PiBwbGVhc2Ugc2VuZCB0byBtZSBsZW9uYWxsX29uZ0B5YWhvby5jb20pLiANCj4gVGhhbmsgeW91 Lg0KPiANCj4gIEdldCBlYXN5LCBvbmUtY2xpY2sgYWNjZXNzIHRvIHlvdXIgZmF2b3JpdGVzLiBN YWtlIFlhaG9vISB5b3VyIA0KaG9tZXBhZ2UuIA0KPiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhp cyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBNaWNyb3NvZnQNCj4gRGVmeSBhbGwgY2hh bGxlbmdlcy4gTWljcm9zb2Z0KFIpIFZpc3VhbCBTdHVkaW8gMjAwNS4NCj4gaHR0cDovL2Nsay5h dGRtdC5jb20vTVJUL2dvL3ZzZTAxMjAwMDAwNzBtcnQvZGlyZWN0LzAxLw0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMaWJ1c2Itd2luMzItZGV2 ZWwgbWFpbGluZyBsaXN0DQo+IExpYnVzYi13aW4zMi1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5u ZXQNCj4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbGlidXNi LXdpbjMyLWRldmVsDQoNCg== |
|
From: ong l. <leo...@ya...> - 2007-11-19 07:56:51
|
Dear All,
Im looking for information on how to use VB6.0 to communicate with libusb.
What I can find from the internet that works;
Declare Sub usb_init Lib "libusb0.dll" ()
Declare Function usb_find_busses Lib "libusb0.dll" () As Integer
Declare Function usb_find_devices Lib "libusb0.dll" () As Integer
usb_init()
nBusses = usb_find_busses()
nDevices = usb_find_devices()
Label1.Text = "Devices " & nDevices
Label2.Text = "Busses " & nBusses
Is there anyone out there that has successfully done it in VB6.0 to call other functions, especially usb_open, USB_Interrupt_Read and USB_Interrupt_Write?
I would appreciate for any advice or sharing of the code (if any, please send to me leo...@ya...).
Thank you.
---------------------------------
Get easy, one-click access to your favorites. Make Yahoo! your homepage. |
|
From: Xiaofan C. <xia...@gm...> - 2007-11-14 23:51:50
|
On Nov 15, 2007 4:18 AM, Vishal Vibhandik <vis...@gm...> wrote: > hi, > I have downloaded the libusb-win32 release 0.1.12.1 from > http://libusb-win32.sourceforge.net/ > But i could not install the driver properly. and hence when i run the test > program ( JavaxUsbTest.java) i get following error: - This is not a libusb-win32 problem but your JAVA USB wrapper problem. The test program for libusb-win32 is testlibusb-win.exe. Is that working? If that is working, you have to contact the author of the JAVA wrapper. Xiaofan |
|
From: Vishal V. <vis...@gm...> - 2007-11-14 20:18:25
|
hi, I have downloaded the libusb-win32 release 0.1.12.1 from http://libusb-win32.sourceforge.net/ But i could not install the driver properly. and hence when i run the test program (JavaxUsbTest.java) i get following error: - 1) javaw.exe - Ordinal Not Found The ordinal 44 could not be located in the dynamic link library libusb0.dll. 2) javax.usb.UsbException: Error while loading shared library LibusbJNI.dll: C:\LibusbJNI.dll: The operating system cannot run %1 at com.mcreations.usb.windows.JavaxUsb.loadLibrary(JavaxUsb.java:400) at com.mcreations.usb.windows.JavaxUsb.initialise(JavaxUsb.java:329) at com.mcreations.usb.windows.JavaxUsbTest.testInitialise(JavaxUsbTest.java :155) at com.mcreations.usb.windows.JavaxUsbTest.main(JavaxUsbTest.java:174) Am using windows XP OS. and JDK 1.4.2 I have placed the LibusbJNI.dll and libusbo.dll under windows\system32. Is this the correct location? Where am i going wrong? * If anybody has steps for using libusb for windows please share. I need this info urgent. Thanks! * -- ~vishal. |
|
From: Ronny O. <ob...@vh...> - 2007-11-14 16:56:20
|
Hi guys, which usb driver should I use? I want to operate with an FT2232D from FTDI. When using FTDI's D2XX driver testlibusb-win.exe works fine. The generation of the libusb-driver was a bit tricky, because the FT2232D has two channels. inf-wizard.exe generates one driver, which couldn't be installed. Then I created two different drivers out of the one inf-file with some information gained from the hardware manager by modifying the [Devices] block. After installing each driver testlibusb-win.exe worked also fine. So which driver will be the best for proceeding? Thanks in advance, Ronny |
|
From: <ro...@li...> - 2007-11-14 14:33:49
|
Hi, I'm currently implementing support of the latest Texas Instruments' graphing calculator for TiLP (www.tilp.info). This hand-held works under Linux but run into troubles with libusb-win32. What's difference? TI's software raises an IOCTL_INTERNAL_USB_RESET_PORT to reset hand-held and triggers device address request/assignation. I have the same with libusb under Linux thru usb_reset(). libusb-win32 raises an IOCTL_INTERNAL_USB_RESET_PORT immediately followed by an IOCTL_INTERNAL_USB_CYCLE_PORT. I think this is the wrong behaviour (see below) so I'm actually using a modified version of libusb-win32 driver to prevent this... By comparing libusb-win32 and linux kernel behaviour from source code, I can see: 1) linux: libusb_reset() call linux/kernel/drivers/usb/hub.c: /** * usb_reset_device - perform a USB port reset to reinitialize a device * @udev: device to reset (not in SUSPENDED or NOTATTACHED state) * * WARNING - don't use this routine to reset a composite device * (one with multiple interfaces owned by separate drivers)! * Use usb_reset_composite_device() instead. * * Do a port reset, reassign the device's address, and establish its * former operating configuration. If the reset fails, or the device's => this is equivalent to RESET_PORT * descriptors change from their values before the reset, or the original * configuration and altsettings cannot be restored, a flag will be set * telling khubd to pretend the device has been disconnected and then * re-connected. All drivers will be unbound, and the device will be * re-enumerated and probed all over again. => this is equivalent to CYCLE_PORT _but_ only if reset fails. * * Returns 0 if the reset succeeded, -ENODEV if the device has been 2) win32: libusb_reset() call src/drivers/reset_device.c: << status = call_usbd(dev, NULL, IOCTL_INTERNAL_USB_RESET_PORT, timeout); if(!NT_SUCCESS(status)) { DEBUG_ERROR("reset_device(): IOCTL_INTERNAL_USB_RESET_PORT failed: " "status: 0x%x", status); } status = call_usbd(dev, NULL, IOCTL_INTERNAL_USB_CYCLE_PORT, timeout); if(!NT_SUCCESS(status)) { DEBUG_ERROR("reset_device(): IOCTL_INTERNAL_USB_CYCLE_PORT failed: " "status: 0x%x", status); } >> So, libusb-win32 raises both IOCTL. I will suggest to raises the second IOCTL if the previous IOCTL fails. Like that: << if(!NT_SUCCESS(status)) { DEBUG_ERROR("reset_device(): IOCTL_INTERNAL_USB_RESET_PORT failed: " "status: 0x%x", status); status = call_usbd(dev, NULL, IOCTL_INTERNAL_USB_CYCLE_PORT, timeout); if(!NT_SUCCESS(status)) { DEBUG_ERROR("reset_device(): IOCTL_INTERNAL_USB_CYCLE_PORT failed: " "status: 0x%x", status); } } >> Regards, Romain. |
|
From: Xiaofan C. <xia...@gm...> - 2007-11-13 23:31:39
|
Just out of curiosity, I searched a bit on libusb-win32 based projects in the cooperate world. Maxim/Dallas: One-Wire Public Domain Kit ttp://www.maxim-ic.com/products/ibutton/software/1wire/wirekit.cfm SecuGen SDK: http://sgdn.secugen.com/developer/default.asp There should be more. Xiaofan |
|
From: Paarvai N. <ope...@gm...> - 2007-11-13 21:51:30
|
HI Robert, If you have KMCS, my understanding is that you can install the driver on Vista 64 regardless of WHQL. The reason to get of WHQL however is so that the user does not get prompted when the INF is used for the install. But if you don't have it, I think the user can just choose to install the driver anyway. Paarvai On Nov 12, 2007 8:38 AM, Krakora, Robert V <rob...@de...> wrote: > > Paarvai: > > I meant to say KMCS instead of WHQL in my original e-mail. Sorry for the confusion. However, if the libusb-win32 kernel driver gets KMCS certification and I code an application that makes use of a device that I have designed and the application uses libusb-win32 to access the device, is WHQL certification then required? I believe Total Phase (www.totalphase.com) makes use of both libusb and libusb-win32 to allow their USB-to-I2C/SPI/USB devices to be used/accessed under Windows and Linux via their applications and accompanying APIs. > > Best Regards, > > Rob Krakora > Software Engineer > Delphi Electronics & Safety > e-mail: rob...@de... > phone: 765-451-8574 > > ________________________________ |
|
From: Graeme G. <gr...@ar...> - 2007-11-12 21:50:00
|
Dan Ellis wrote: > Having a configuration descriptor with a value of zero is very broken - > there is no way to select it. When the host issues SET_CONFIGURATION > with wValue = 0, to select that configuration, the device should enter > the low power state, and the host should assume that the device has no > active endpoints. > > The library doesn't have a coherent way of dealing with a device with a > configuration with value zero, since it keeps track of which endpoints > are valid to send data on. > > What would be your suggestion for a solution? I would imagine that the simplest thing may be to assume that the descriptor is in error, since (from what you say), it would make no sense for a device to actually have a maximum configuration value of 0. The sort of thing I've done in such cases (dealing with broken implementation of standards) is to have a configurable "forgiving" mode, with appropriate debug messages being available to track what's going on. So with libusb set to a "try and correct broken configuration desciptors" mode, it would internally treat a configuration descriptor with a value of zero as a value of 1, which (I would guess), might solve the original posters problem. Graeme Gill. |
|
From: Krakora, R. V <rob...@de...> - 2007-11-12 16:44:55
|
Paarvai: =20 I meant to say KMCS instead of WHQL in my original e-mail. Sorry for the= confusion. However, if the libusb-win32 kernel driver gets KMCS= certification and I code an application that makes use of a device that I= have designed and the application uses libusb-win32 to access the device,= is WHQL certification then required? I believe Total Phase= (www.totalphase.com) makes use of both libusb and libusb-win32 to allow= their USB-to-I2C/SPI/USB devices to be used/accessed under Windows and= Linux via their applications and accompanying APIs. =20 Best Regards, =20 Rob Krakora Software Engineer Delphi Electronics & Safety e-mail: rob...@de... phone: 765-451-8574 ________________________________ From: lib...@li... on behalf of= lib...@li... Sent: Mon 11/12/2007 10:47 AM To: lib...@li... Subject: Libusb-win32-devel Digest, Vol 18, Issue 12 Send Libusb-win32-devel mailing list submissions to lib...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel or, via email, send a message with subject or body 'help' to lib...@li... You can reach the person managing the list at lib...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Libusb-win32-devel digest..." Today's Topics: 1. usb_set_configuration / filter driver removal (soundman32) 2. WinUSB (Krakora, Robert V) 3. Re: WinUSB (Xiaofan Chen) 4. Re: usb_set_configuration / filter driver removal (Xiaofan Chen) 5. Re: WinUSB (Paarvai Naai) ---------------------------------------------------------------------- Message: 1 Date: Mon, 12 Nov 2007 01:05:05 -0800 (PST) From: soundman32 <nei...@go...> Subject: [Libusb-win32-devel] usb_set_configuration / filter driver removal To: lib...@li... Message-ID: <137...@ta...> Content-Type: text/plain; charset=3Dus-ascii I'm getting a bit confused :-) I'm trying to communicate with a HID device. When I call usb_set_configuration(dev, 1) it hangs. A previous message suggested I remove the filter driver. If I remove the filter driver I lose access to the device.=20 TestLibUsb returns: Dll version: 0.1.12.1 Driver version: -1.-1.-1.-1 And no devices are listed. As I understand it, the way libusb works is there is a user mode dll that talks to the kernel mode driver which talks to the device. The kernel mode driver sits somewhere in the usb stack for every usb device so the dll can talk to it. Is the kernel mode driver the 'filter' driver? I can create and install a .inf file for this device, which gives me access to the device again, but then all the other usb devices dissapear again! How can I remove the filter driver and still access the device? Neil -- View this message in context:= http://www.nabble.com/usb_set_configuration---filter-driver-removal-tf4789= 807.html#a13702111 Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. ------------------------------ Message: 2 Date: Mon, 12 Nov 2007 09:11:57 -0500 From: "Krakora, Robert V" <rob...@de...> Subject: [Libusb-win32-devel] WinUSB To: <lib...@li...> Message-ID: = <3C7...@US...= to.net> =20 Content-Type: text/plain; charset=3D"us-ascii" All: According to http://msdn2.microsoft.com/en-us/library/aa476426.aspx: You cannot use the WinUSB mechanism for: Data streaming through isochronous endpoints. Functions that already have kernel-mode support in the Windows operating system, such as modem functions (which TAPI supports) or LAN functions (which NDIS supports). You must use the interface that the Usbser.sys driver supports to manage modem devices with user-mode software. Therefore, WinUSB seems to be very limiting compared to libusb-win32. There are several other companies out there such as Jungo that provide true user-mode USB solutions with WHQL signed underlying kernel drivers. However, they cost $$. The best solution is to find a "sugar daddy" to pay for the WHQL signing of the libusb-win32 kernel driver. I have had very few problems with libusb-win32 and all of you have been very responsive when I have had problems and Stefan has done a great job managing the project. Best Regards, Rob Krakora Software Engineer Delphi Electronics & Safety e-mail: rob...@de... phone: 765-451-8574 -----Original Message----- From: lib...@li... [mailto:lib...@li...] On Behalf Of lib...@li... Sent: Sunday, November 11, 2007 3:04 PM To: lib...@li... Subject: Libusb-win32-devel Digest, Vol 18, Issue 11 Send Libusb-win32-devel mailing list submissions to lib...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel or, via email, send a message with subject or body 'help' to lib...@li... You can reach the person managing the list at lib...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Libusb-win32-devel digest..." Today's Topics: 1. Re: libusb-win32 and OpenUsb (Xiaofan Chen) 2. Re: Antwort: 64-bit support (Spiro Trikaliotis) 3. Re: libusb-win32 and OpenUsb (Spiro Trikaliotis) 4. Re: Antwort: 64-bit support (Xiaofan Chen) 5. Re: Antwort: 64-bit support (Xiaofan Chen) 6. Re: Antwort: 64-bit support (Paarvai Naai) 7. Re: Antwort: 64-bit support (Paarvai Naai) ---------------------------------------------------------------------- Message: 1 Date: Sun, 11 Nov 2007 08:39:33 +0800 From: "Xiaofan Chen" <xia...@gm...> Subject: Re: [Libusb-win32-devel] libusb-win32 and OpenUsb To: lib...@li... Message-ID: <a27...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 11, 2007 12:23 AM, Spiro Trikaliotis <an-...@sp...> wrote: > > http://openusb.sourceforge.net/ > > > > OpenUSB currently only works under Solaris and Linux. But they > > would like to extend the support to Mac OS X, Win32 and BSDs. > > I failed to see the advantage of using OpenUSB. Can you please elaborate > why one should want this? > OpenUSB is supposed to be based on the libusb 1.0 API and has the aim to be thread safe and support isochronous transfer (libusb-win32 already support iso transfer). It also has a compatibility layer so that libusb-0.1 based program will still run. I am not too much into the technical details of OpenUSB. I just think it would be nice for libusb-win32 to be in-sync to l with OpenUSB which is a fork of libusb 1.0 (libusb 1.0 is kind of dormant now). One more thing, OpenUSB is backed by SUN, a corporration. This can be a good (or not so good) depending on your interpretation. For me I think so far it is positive. OpenUSB is still in the development stage but the API, the frontend and Solaris/Linux backend are almost finished. To make OpenUSB cross-platform, Win32 is important. So I think if SUN really persists, they will come out a Win32 port. Then it might not be a good idea to have two incompatible API for Windows. Xiaofan http://mcuee.blogspot.com <http://mcuee.blogspot.com/>=20 ------------------------------ Message: 2 Date: Sun, 11 Nov 2007 10:50:50 +0100 From: Spiro Trikaliotis <an-...@sp...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <200...@tr...> Content-Type: text/plain; charset=3Diso-8859-1 Hello Paarvai, * On Sat, Nov 10, 2007 at 11:01:17AM -0800 Paarvai Naai wrote: > The > impression I had was that Microsoft wants to keep the kernel mode code > signing (KMCS) separate from WHQL. The INF gets signed and hashed as > part of the WHQL process. Indeed, you are right. I confused all of this. > There is discussion in the kmsigning.doc that specifically says that > you can release a driver *without* WHQL as long as you follow KMCS. Yes, I was aware of this, but I totally forgot that signing the INF is part of WHQL, not of KMCS. > Sprio, did you look through that document above and find something > contradictory, or are you working of some other reference? I have had a look into that document more than once, but not recently. What I had written was from my memory, and it seems I was confused "a little bit". So, please disregard my previous statements. > Personally, I'm unclear on all of this and Microsoft's documentation > hasn't been the greatest here. Sadly, the only way to really be sure > would be to try this all out or here from someone who has. We could ask this question on the MS newsgroups; questions regarding signing are rather common there. It might be better to search for something there, as there have been many questions regarding this. However, even if this is possible: We would still need someone who is willing to sign the driver. BTW: I have another driver project (http://sf.net/projects/opencbm) where I would want at least the 64 bit driver to be signed. ;) Gru?, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ ------------------------------ Message: 3 Date: Sun, 11 Nov 2007 10:53:26 +0100 From: Spiro Trikaliotis <an-...@sp...> Subject: Re: [Libusb-win32-devel] libusb-win32 and OpenUsb To: lib...@li... Message-ID: <200...@tr...> Content-Type: text/plain; charset=3Dus-ascii Hello, * On Sun, Nov 11, 2007 at 08:39:33AM +0800 Xiaofan Chen wrote: > On Nov 11, 2007 12:23 AM, Spiro Trikaliotis > <an-...@sp...> wrote: > > I failed to see the advantage of using OpenUSB. Can you please elaborate > > why one should want this? > > > > OpenUSB is supposed to be based on the libusb 1.0 API and has the > aim to be thread safe and support isochronous transfer (libusb-win32 > already support iso transfer). It also has a compatibility layer so > that libusb-0.1 based program will still run. Oh... It seems I totally missed that OpenUSB wants to REPLACE libusb. I had the impression that it is just another layer on top of libusb. > One more thing, OpenUSB is backed by SUN, a corporration. This > can be a good (or not so good) depending on your interpretation. The only positive aspect I can think of: SUN might want to afford the $$$ needed to sign the Windows driver. ;) > To make OpenUSB cross-platform, Win32 is important. So I think if > SUN really persists, they will come out a Win32 port. Then it > might not be a good idea to have two incompatible API for > Windows. The Windows API is there, they are free to use that. (just kidding) Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ ------------------------------ Message: 4 Date: Sun, 11 Nov 2007 20:55:17 +0800 From: "Xiaofan Chen" <xia...@gm...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <a27...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 10, 2007 2:47 AM, Paarvai Naai <ope...@gm...> wrote: > I think what Graeme probably meant to say was that Microsoft allows > drivers to be self-signed as opposed to being self-signed and then > also signed by Microsoft. Thank you for clarifying that since it is > definitely an important distinction. > > The interesting question that remains is whether the INF file needs to > be signed to actually allow the driver to install and load. Do you > know anything about this? > I do not know much about this topic but I think the INF files does not need to be signed to load the driver. Of course this will not fulfill the WHQL requirement (then you need to sign the INF file as well). Example: this guy (J1M) has done the WinUSB C# Example on Vista 64. So he must be able to load the driver and I do not think he will have the INF signed. http://forum.microchip.com/tm.aspx?m=3D283064&mpage=3D2 This may be similar to CDC device using usbser.sys. The INF file needs to be signed to have WHQL, if it is not necessary, then the INF file does not need to be signed. Xiaofan ------------------------------ Message: 5 Date: Sun, 11 Nov 2007 21:00:05 +0800 From: "Xiaofan Chen" <xia...@gm...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <a27...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 11, 2007 5:50 PM, Spiro Trikaliotis <an-...@sp...> wrote: > However, even if this is possible: We would still need someone who is > willing to sign the driver. > > BTW: I have another driver project (http://sf.net/projects/opencbm) > where I would want at least the 64 bit driver to be signed. ;) I believe the WinUSB backend will solve the main issues. Not WHQL but at least the user will be able to load the INF file associated with WinUSB. Xiaofan ------------------------------ Message: 6 Date: Sun, 11 Nov 2007 08:05:18 -0800 From: "Paarvai Naai" <ope...@gm...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <521...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 11, 2007 4:55 AM, Xiaofan Chen <xia...@gm...> wrote: > I do not know much about this topic but I think the INF files does not > need to be signed to load the driver. Of course this will not fulfill > the WHQL requirement (then you need to sign the INF file as well). > > Example: this guy (J1M) has done the WinUSB C# Example > on Vista 64. So he must be able to load the driver and I do not > think he will have the INF signed. > http://forum.microchip.com/tm.aspx?m=3D283064&mpage=3D2 Yes, this was exactly my thinking and I alluded to that in my second email on this thread. Great to know others are also thinking of it the same way! Best regards, Paarvai ------------------------------ Message: 7 Date: Sun, 11 Nov 2007 08:08:49 -0800 From: "Paarvai Naai" <ope...@gm...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <521...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 I agree that WinUSB will solve this but right now we don't have a proper migration from the current libusb-win32 to the winusb-based version. Unfortunately our end-users are using Vista 64 more and more. Unless a winusb-based libusb-win32 is around the corner, we have to find an alternate solution in the meantime (i.e., sign the current 64-bit kernel-mode driver). As for who will sign the kernel-mode driver, I think it should be signed by the libusb-win32 project. I think we can probably find someone to subsidize the cost of buying the certificates if libusb-win32 is willing to do the signing. Best regards, Paarvai On Nov 11, 2007 5:00 AM, Xiaofan Chen <xia...@gm...> wrote: > On Nov 11, 2007 5:50 PM, Spiro Trikaliotis > <an-...@sp...> wrote: > > However, even if this is possible: We would still need someone who is > > willing to sign the driver. > > > > BTW: I have another driver project (http://sf.net/projects/opencbm) > > where I would want at least the 64 bit driver to be signed. ;) > > I believe the WinUSB backend will solve the main issues. > Not WHQL but at least the user will be able to load the INF file > associated with WinUSB. > > Xiaofan > > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Libusb-win32-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel > ------------------------------ ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ------------------------------ _______________________________________________ Libusb-win32-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel End of Libusb-win32-devel Digest, Vol 18, Issue 11 ************************************************** ***************************************************************************= ************* Note: If the reader of this message is not the intended recipient, or an= employee or agent responsible for delivering this message to the intended= recipient, you are hereby notified that any dissemination, distribution or= copying of this communication is strictly prohibited. If you have received= this communication in error, please notify us immediately by replying to= the message and deleting it from your computer. Thank you. ***************************************************************************= ************* ------------------------------ Message: 3 Date: Mon, 12 Nov 2007 22:25:02 +0800 From: "Xiaofan Chen" <xia...@gm...> Subject: Re: [Libusb-win32-devel] WinUSB To: lib...@li... Message-ID: <a27...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 12, 2007 10:11 PM, Krakora, Robert V <rob...@de...>= wrote: > > > All: > > According to http://msdn2.microsoft.com/en-us/library/aa476426.aspx: > > You cannot use the WinUSB mechanism for: > > Data streaming through isochronous endpoints. Can we use isousb (in WDK) as another backend? Sorry I think this might not be a good idea... > Functions that already have kernel-mode support in the Windows operating > system, such as modem functions (which TAPI supports) or LAN functions > (which NDIS supports). You must use the interface that the Usbser.sys > driver supports to manage modem devices with user-mode software. Maybe it is better to use the kernel mode driver anyway. > Therefore, WinUSB seems to be very limiting compared to libusb-win32. Kind of true. > There are several other companies out there such as Jungo that provide > true user-mode USB solutions with WHQL signed underlying kernel drivers. > However, they cost $$. The best solution is to find a "sugar daddy" to > pay for the WHQL signing of the libusb-win32 kernel driver. I have had > very few problems with libusb-win32 and all of you have been very > responsive when I have had problems and Stefan has done a great job > managing the project. > Maybe this is a good idea. But anyway, Vista 64 is not that popular. So this is at least not that urgent. Xiaofan ------------------------------ Message: 4 Date: Mon, 12 Nov 2007 22:28:12 +0800 From: "Xiaofan Chen" <xia...@gm...> Subject: Re: [Libusb-win32-devel] usb_set_configuration / filter driver removal To: lib...@li... Message-ID: <a27...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 12, 2007 5:05 PM, soundman32 <nei...@go...> wrote: > > I'm getting a bit confused :-) > > I'm trying to communicate with a HID device. > > I can create and install a .inf file for this device, which gives me= access > to the device again, but then all the other usb devices dissapear again! > > How can I remove the filter driver and still access the device? > Filter driver is problematic with HID device. So you have to use the device driver (INF) at least for the interrupt read/write and then you will lose the original functionality. You will have to wait for libusb-win32 1.0 to solve the problem. Or you want to use native HID API instead of libusb-win32. Xiaofan ------------------------------ Message: 5 Date: Mon, 12 Nov 2007 07:47:00 -0800 From: "Paarvai Naai" <ope...@gm...> Subject: Re: [Libusb-win32-devel] WinUSB To: lib...@li... Message-ID: <521...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 Hi Rob, As I have stated in a number of recent emails, signing the INF (WHQL) is not what is needed. Regardless, it isn't practical to have the INF signed in advance by libusb-win32 anyway. The INF has the VID/PID combination that is specific to the vendor that distributes libusb-win32! Therefore, the vendor that wishes to distribute libusb-win32 must do their own signing after they have changed the INF file to suit their needs. What is needed here is to sign the SYS file in accordance with the KMCS requirements. Please have a look at the links I send over the past few days on this list. Hopefully that will clarify things. I agree that this is already a very confusing so it will be helpful to read those carefully. Best regards, Paarvai On Nov 12, 2007 6:11 AM, Krakora, Robert V <rob...@de...>= wrote: > Therefore, WinUSB seems to be very limiting compared to libusb-win32. > There are several other companies out there such as Jungo that provide > true user-mode USB solutions with WHQL signed underlying kernel drivers. > However, they cost $$. The best solution is to find a "sugar daddy" to > pay for the WHQL signing of the libusb-win32 kernel driver. I have had > very few problems with libusb-win32 and all of you have been very > responsive when I have had problems and Stefan has done a great job > managing the project. > > Best Regards, > > Rob Krakora > Software Engineer > Delphi Electronics & Safety > e-mail: rob...@de... > phone: 765-451-8574 ------------------------------ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ------------------------------ _______________________________________________ Libusb-win32-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel End of Libusb-win32-devel Digest, Vol 18, Issue 12 ************************************************** ***************************************************************************= ************* Note: If the reader of this message is not the intended recipient, or an= employee or agent responsible for delivering this message to the intended= recipient, you are hereby notified that any dissemination, distribution or= copying of this communication is strictly prohibited. If you have received= this communication in error, please notify us immediately by replying to= the message and deleting it from your computer. Thank you.=20 ***************************************************************************= ************* |
|
From: Paarvai N. <ope...@gm...> - 2007-11-12 15:48:51
|
Hi Xiofan, > Maybe this is a good idea. But anyway, Vista 64 is not that popular. > So this is at least not that urgent. I disagree. We are starting to see more and more customers asking about Vista 64 (our products currently target developers). I think Vista 64 will be much more popular than WinXP 64. Best regards, Paarvai |
|
From: Dan E. <dan...@ne...> - 2007-11-12 15:47:07
|
Graeme Gill wrote: > > Stephan Meyer wrote: > > A configuration value of '0' is invalid (see USB spec > > for details). So the only solution is to fix your device's > > firmware. > > You're absolutely right, but it doesn't solve the users > problem, and they can't solve it either, since they > aren't responsible for creating the device. libusb-win32 looks > bad if the device used to work, and (presumably) still works > with other usb drivers. > > Is there a way of making libusb-win32 more robust in the > face of such (badly behaved) devices, rather than simply > failing ? > Having a configuration descriptor with a value of zero is very broken - there is no way to select it. When the host issues SET_CONFIGURATION with wValue = 0, to select that configuration, the device should enter the low power state, and the host should assume that the device has no active endpoints. The library doesn't have a coherent way of dealing with a device with a configuration with value zero, since it keeps track of which endpoints are valid to send data on. What would be your suggestion for a solution? Dan. |
|
From: Paarvai N. <ope...@gm...> - 2007-11-12 15:47:06
|
Hi Rob, As I have stated in a number of recent emails, signing the INF (WHQL) is not what is needed. Regardless, it isn't practical to have the INF signed in advance by libusb-win32 anyway. The INF has the VID/PID combination that is specific to the vendor that distributes libusb-win32! Therefore, the vendor that wishes to distribute libusb-win32 must do their own signing after they have changed the INF file to suit their needs. What is needed here is to sign the SYS file in accordance with the KMCS requirements. Please have a look at the links I send over the past few days on this list. Hopefully that will clarify things. I agree that this is already a very confusing so it will be helpful to read those carefully. Best regards, Paarvai On Nov 12, 2007 6:11 AM, Krakora, Robert V <rob...@de...> wrote: > Therefore, WinUSB seems to be very limiting compared to libusb-win32. > There are several other companies out there such as Jungo that provide > true user-mode USB solutions with WHQL signed underlying kernel drivers. > However, they cost $$. The best solution is to find a "sugar daddy" to > pay for the WHQL signing of the libusb-win32 kernel driver. I have had > very few problems with libusb-win32 and all of you have been very > responsive when I have had problems and Stefan has done a great job > managing the project. > > Best Regards, > > Rob Krakora > Software Engineer > Delphi Electronics & Safety > e-mail: rob...@de... > phone: 765-451-8574 |
|
From: Xiaofan C. <xia...@gm...> - 2007-11-12 14:28:14
|
On Nov 12, 2007 5:05 PM, soundman32 <nei...@go...> wrote: > > I'm getting a bit confused :-) > > I'm trying to communicate with a HID device. > > I can create and install a .inf file for this device, which gives me access > to the device again, but then all the other usb devices dissapear again! > > How can I remove the filter driver and still access the device? > Filter driver is problematic with HID device. So you have to use the device driver (INF) at least for the interrupt read/write and then you will lose the original functionality. You will have to wait for libusb-win32 1.0 to solve the problem. Or you want to use native HID API instead of libusb-win32. Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2007-11-12 14:25:05
|
On Nov 12, 2007 10:11 PM, Krakora, Robert V <rob...@de...> wrote: > > > All: > > According to http://msdn2.microsoft.com/en-us/library/aa476426.aspx: > > You cannot use the WinUSB mechanism for: > > Data streaming through isochronous endpoints. Can we use isousb (in WDK) as another backend? Sorry I think this might not be a good idea... > Functions that already have kernel-mode support in the Windows operating > system, such as modem functions (which TAPI supports) or LAN functions > (which NDIS supports). You must use the interface that the Usbser.sys > driver supports to manage modem devices with user-mode software. Maybe it is better to use the kernel mode driver anyway. > Therefore, WinUSB seems to be very limiting compared to libusb-win32. Kind of true. > There are several other companies out there such as Jungo that provide > true user-mode USB solutions with WHQL signed underlying kernel drivers. > However, they cost $$. The best solution is to find a "sugar daddy" to > pay for the WHQL signing of the libusb-win32 kernel driver. I have had > very few problems with libusb-win32 and all of you have been very > responsive when I have had problems and Stefan has done a great job > managing the project. > Maybe this is a good idea. But anyway, Vista 64 is not that popular. So this is at least not that urgent. Xiaofan |
|
From: Krakora, R. V <rob...@de...> - 2007-11-12 14:17:59
|
All: According to http://msdn2.microsoft.com/en-us/library/aa476426.aspx: You cannot use the WinUSB mechanism for: Data streaming through isochronous endpoints.=20 Functions that already have kernel-mode support in the Windows operating system, such as modem functions (which TAPI supports) or LAN functions (which NDIS supports). You must use the interface that the Usbser.sys driver supports to manage modem devices with user-mode software. Therefore, WinUSB seems to be very limiting compared to libusb-win32. There are several other companies out there such as Jungo that provide true user-mode USB solutions with WHQL signed underlying kernel drivers. However, they cost $$. The best solution is to find a "sugar daddy" to pay for the WHQL signing of the libusb-win32 kernel driver. I have had very few problems with libusb-win32 and all of you have been very responsive when I have had problems and Stefan has done a great job managing the project. Best Regards, Rob Krakora Software Engineer Delphi Electronics & Safety e-mail: rob...@de... phone: 765-451-8574 -----Original Message----- From: lib...@li... [mailto:lib...@li...] On Behalf Of lib...@li... Sent: Sunday, November 11, 2007 3:04 PM To: lib...@li... Subject: Libusb-win32-devel Digest, Vol 18, Issue 11 Send Libusb-win32-devel mailing list submissions to lib...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel or, via email, send a message with subject or body 'help' to lib...@li... You can reach the person managing the list at lib...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Libusb-win32-devel digest..." Today's Topics: 1. Re: libusb-win32 and OpenUsb (Xiaofan Chen) 2. Re: Antwort: 64-bit support (Spiro Trikaliotis) 3. Re: libusb-win32 and OpenUsb (Spiro Trikaliotis) 4. Re: Antwort: 64-bit support (Xiaofan Chen) 5. Re: Antwort: 64-bit support (Xiaofan Chen) 6. Re: Antwort: 64-bit support (Paarvai Naai) 7. Re: Antwort: 64-bit support (Paarvai Naai) ---------------------------------------------------------------------- Message: 1 Date: Sun, 11 Nov 2007 08:39:33 +0800 From: "Xiaofan Chen" <xia...@gm...> Subject: Re: [Libusb-win32-devel] libusb-win32 and OpenUsb To: lib...@li... Message-ID: <a27...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 11, 2007 12:23 AM, Spiro Trikaliotis <an-...@sp...> wrote: > > http://openusb.sourceforge.net/ > > > > OpenUSB currently only works under Solaris and Linux. But they > > would like to extend the support to Mac OS X, Win32 and BSDs. > > I failed to see the advantage of using OpenUSB. Can you please elaborate > why one should want this? > OpenUSB is supposed to be based on the libusb 1.0 API and has the aim to be thread safe and support isochronous transfer (libusb-win32 already support iso transfer). It also has a compatibility layer so that libusb-0.1 based program will still run. I am not too much into the technical details of OpenUSB. I just think it would be nice for libusb-win32 to be in-sync to l with OpenUSB which is a fork of libusb 1.0 (libusb 1.0 is kind of dormant now). One more thing, OpenUSB is backed by SUN, a corporration. This can be a good (or not so good) depending on your interpretation. For me I think so far it is positive. OpenUSB is still in the development stage but the API, the frontend and Solaris/Linux backend are almost finished. To make OpenUSB cross-platform, Win32 is important. So I think if SUN really persists, they will come out a Win32 port. Then it might not be a good idea to have two incompatible API for Windows. Xiaofan http://mcuee.blogspot.com ------------------------------ Message: 2 Date: Sun, 11 Nov 2007 10:50:50 +0100 From: Spiro Trikaliotis <an-...@sp...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <200...@tr...> Content-Type: text/plain; charset=3Diso-8859-1 Hello Paarvai, * On Sat, Nov 10, 2007 at 11:01:17AM -0800 Paarvai Naai wrote: > The > impression I had was that Microsoft wants to keep the kernel mode code > signing (KMCS) separate from WHQL. The INF gets signed and hashed as > part of the WHQL process. Indeed, you are right. I confused all of this. > There is discussion in the kmsigning.doc that specifically says that > you can release a driver *without* WHQL as long as you follow KMCS. Yes, I was aware of this, but I totally forgot that signing the INF is part of WHQL, not of KMCS. > Sprio, did you look through that document above and find something > contradictory, or are you working of some other reference? I have had a look into that document more than once, but not recently. What I had written was from my memory, and it seems I was confused "a little bit". So, please disregard my previous statements. > Personally, I'm unclear on all of this and Microsoft's documentation > hasn't been the greatest here. Sadly, the only way to really be sure > would be to try this all out or here from someone who has. We could ask this question on the MS newsgroups; questions regarding signing are rather common there. It might be better to search for something there, as there have been many questions regarding this. However, even if this is possible: We would still need someone who is willing to sign the driver. BTW: I have another driver project (http://sf.net/projects/opencbm) where I would want at least the 64 bit driver to be signed. ;) Gru?, Spiro. --=20 Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ ------------------------------ Message: 3 Date: Sun, 11 Nov 2007 10:53:26 +0100 From: Spiro Trikaliotis <an-...@sp...> Subject: Re: [Libusb-win32-devel] libusb-win32 and OpenUsb To: lib...@li... Message-ID: <200...@tr...> Content-Type: text/plain; charset=3Dus-ascii Hello, * On Sun, Nov 11, 2007 at 08:39:33AM +0800 Xiaofan Chen wrote: > On Nov 11, 2007 12:23 AM, Spiro Trikaliotis > <an-...@sp...> wrote: > > I failed to see the advantage of using OpenUSB. Can you please elaborate > > why one should want this? > > >=20 > OpenUSB is supposed to be based on the libusb 1.0 API and has the > aim to be thread safe and support isochronous transfer (libusb-win32 > already support iso transfer). It also has a compatibility layer so > that libusb-0.1 based program will still run. Oh... It seems I totally missed that OpenUSB wants to REPLACE libusb. I had the impression that it is just another layer on top of libusb. =20 > One more thing, OpenUSB is backed by SUN, a corporration. This > can be a good (or not so good) depending on your interpretation. The only positive aspect I can think of: SUN might want to afford the $$$ needed to sign the Windows driver. ;) =20 > To make OpenUSB cross-platform, Win32 is important. So I think if > SUN really persists, they will come out a Win32 port. Then it > might not be a good idea to have two incompatible API for > Windows. The Windows API is there, they are free to use that. (just kidding) Regards, Spiro. --=20 Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ ------------------------------ Message: 4 Date: Sun, 11 Nov 2007 20:55:17 +0800 From: "Xiaofan Chen" <xia...@gm...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <a27...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 10, 2007 2:47 AM, Paarvai Naai <ope...@gm...> wrote: > I think what Graeme probably meant to say was that Microsoft allows > drivers to be self-signed as opposed to being self-signed and then > also signed by Microsoft. Thank you for clarifying that since it is > definitely an important distinction. > > The interesting question that remains is whether the INF file needs to > be signed to actually allow the driver to install and load. Do you > know anything about this? > I do not know much about this topic but I think the INF files does not need to be signed to load the driver. Of course this will not fulfill the WHQL requirement (then you need to sign the INF file as well). Example: this guy (J1M) has done the WinUSB C# Example on Vista 64. So he must be able to load the driver and I do not think he will have the INF signed. http://forum.microchip.com/tm.aspx?m=3D283064&mpage=3D2 This may be similar to CDC device using usbser.sys. The INF file needs to be signed to have WHQL, if it is not necessary, then the INF file does not need to be signed. Xiaofan ------------------------------ Message: 5 Date: Sun, 11 Nov 2007 21:00:05 +0800 From: "Xiaofan Chen" <xia...@gm...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <a27...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 11, 2007 5:50 PM, Spiro Trikaliotis <an-...@sp...> wrote: > However, even if this is possible: We would still need someone who is > willing to sign the driver. > > BTW: I have another driver project (http://sf.net/projects/opencbm) > where I would want at least the 64 bit driver to be signed. ;) I believe the WinUSB backend will solve the main issues. Not WHQL but at least the user will be able to load the INF file associated with WinUSB. Xiaofan ------------------------------ Message: 6 Date: Sun, 11 Nov 2007 08:05:18 -0800 From: "Paarvai Naai" <ope...@gm...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <521...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 On Nov 11, 2007 4:55 AM, Xiaofan Chen <xia...@gm...> wrote: > I do not know much about this topic but I think the INF files does not > need to be signed to load the driver. Of course this will not fulfill > the WHQL requirement (then you need to sign the INF file as well). > > Example: this guy (J1M) has done the WinUSB C# Example > on Vista 64. So he must be able to load the driver and I do not > think he will have the INF signed. > http://forum.microchip.com/tm.aspx?m=3D283064&mpage=3D2 Yes, this was exactly my thinking and I alluded to that in my second email on this thread. Great to know others are also thinking of it the same way! Best regards, Paarvai ------------------------------ Message: 7 Date: Sun, 11 Nov 2007 08:08:49 -0800 From: "Paarvai Naai" <ope...@gm...> Subject: Re: [Libusb-win32-devel] Antwort: 64-bit support To: lib...@li... Message-ID: <521...@ma...> Content-Type: text/plain; charset=3DISO-8859-1 I agree that WinUSB will solve this but right now we don't have a proper migration from the current libusb-win32 to the winusb-based version. Unfortunately our end-users are using Vista 64 more and more. Unless a winusb-based libusb-win32 is around the corner, we have to find an alternate solution in the meantime (i.e., sign the current 64-bit kernel-mode driver). As for who will sign the kernel-mode driver, I think it should be signed by the libusb-win32 project. I think we can probably find someone to subsidize the cost of buying the certificates if libusb-win32 is willing to do the signing. Best regards, Paarvai On Nov 11, 2007 5:00 AM, Xiaofan Chen <xia...@gm...> wrote: > On Nov 11, 2007 5:50 PM, Spiro Trikaliotis > <an-...@sp...> wrote: > > However, even if this is possible: We would still need someone who is > > willing to sign the driver. > > > > BTW: I have another driver project (http://sf.net/projects/opencbm) > > where I would want at least the 64 bit driver to be signed. ;) > > I believe the WinUSB backend will solve the main issues. > Not WHQL but at least the user will be able to load the INF file > associated with WinUSB. > > Xiaofan > > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Libusb-win32-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel > ------------------------------ ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ------------------------------ _______________________________________________ Libusb-win32-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel End of Libusb-win32-devel Digest, Vol 18, Issue 11 ************************************************** ***************************************************************************= ************* Note: If the reader of this message is not the intended recipient, or an= employee or agent responsible for delivering this message to the intended= recipient, you are hereby notified that any dissemination, distribution or= copying of this communication is strictly prohibited. If you have received= this communication in error, please notify us immediately by replying to= the message and deleting it from your computer. Thank you.=20 ***************************************************************************= ************* |
|
From: soundman32 <nei...@go...> - 2007-11-12 09:05:06
|
I'm getting a bit confused :-) I'm trying to communicate with a HID device. When I call usb_set_configuration(dev, 1) it hangs. A previous message suggested I remove the filter driver. If I remove the filter driver I lose access to the device. TestLibUsb returns: Dll version: 0.1.12.1 Driver version: -1.-1.-1.-1 And no devices are listed. As I understand it, the way libusb works is there is a user mode dll that talks to the kernel mode driver which talks to the device. The kernel mode driver sits somewhere in the usb stack for every usb device so the dll can talk to it. Is the kernel mode driver the 'filter' driver? I can create and install a .inf file for this device, which gives me access to the device again, but then all the other usb devices dissapear again! How can I remove the filter driver and still access the device? Neil -- View this message in context: http://www.nabble.com/usb_set_configuration---filter-driver-removal-tf4789807.html#a13702111 Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
|
From: Paarvai N. <ope...@gm...> - 2007-11-11 16:08:51
|
I agree that WinUSB will solve this but right now we don't have a proper migration from the current libusb-win32 to the winusb-based version. Unfortunately our end-users are using Vista 64 more and more. Unless a winusb-based libusb-win32 is around the corner, we have to find an alternate solution in the meantime (i.e., sign the current 64-bit kernel-mode driver). As for who will sign the kernel-mode driver, I think it should be signed by the libusb-win32 project. I think we can probably find someone to subsidize the cost of buying the certificates if libusb-win32 is willing to do the signing. Best regards, Paarvai On Nov 11, 2007 5:00 AM, Xiaofan Chen <xia...@gm...> wrote: > On Nov 11, 2007 5:50 PM, Spiro Trikaliotis > <an-...@sp...> wrote: > > However, even if this is possible: We would still need someone who is > > willing to sign the driver. > > > > BTW: I have another driver project (http://sf.net/projects/opencbm) > > where I would want at least the 64 bit driver to be signed. ;) > > I believe the WinUSB backend will solve the main issues. > Not WHQL but at least the user will be able to load the INF file > associated with WinUSB. > > Xiaofan > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Libusb-win32-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel > |
|
From: Paarvai N. <ope...@gm...> - 2007-11-11 16:05:21
|
On Nov 11, 2007 4:55 AM, Xiaofan Chen <xia...@gm...> wrote: > I do not know much about this topic but I think the INF files does not > need to be signed to load the driver. Of course this will not fulfill > the WHQL requirement (then you need to sign the INF file as well). > > Example: this guy (J1M) has done the WinUSB C# Example > on Vista 64. So he must be able to load the driver and I do not > think he will have the INF signed. > http://forum.microchip.com/tm.aspx?m=283064&mpage=2 Yes, this was exactly my thinking and I alluded to that in my second email on this thread. Great to know others are also thinking of it the same way! Best regards, Paarvai |
|
From: Xiaofan C. <xia...@gm...> - 2007-11-11 13:00:26
|
On Nov 11, 2007 5:50 PM, Spiro Trikaliotis <an-...@sp...> wrote: > However, even if this is possible: We would still need someone who is > willing to sign the driver. > > BTW: I have another driver project (http://sf.net/projects/opencbm) > where I would want at least the 64 bit driver to be signed. ;) I believe the WinUSB backend will solve the main issues. Not WHQL but at least the user will be able to load the INF file associated with WinUSB. Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2007-11-11 12:55:20
|
On Nov 10, 2007 2:47 AM, Paarvai Naai <ope...@gm...> wrote: > I think what Graeme probably meant to say was that Microsoft allows > drivers to be self-signed as opposed to being self-signed and then > also signed by Microsoft. Thank you for clarifying that since it is > definitely an important distinction. > > The interesting question that remains is whether the INF file needs to > be signed to actually allow the driver to install and load. Do you > know anything about this? > I do not know much about this topic but I think the INF files does not need to be signed to load the driver. Of course this will not fulfill the WHQL requirement (then you need to sign the INF file as well). Example: this guy (J1M) has done the WinUSB C# Example on Vista 64. So he must be able to load the driver and I do not think he will have the INF signed. http://forum.microchip.com/tm.aspx?m=283064&mpage=2 This may be similar to CDC device using usbser.sys. The INF file needs to be signed to have WHQL, if it is not necessary, then the INF file does not need to be signed. Xiaofan |
50 messages has been excluded from this view by a project administrator.
