Re: Status of the HID backend

On Sun, Jan 31, 2010 at 10:49 PM, Pete Batard <pbatard <at> gmail.com> wrote:
> Thus, right now, the interrupt code for HID has not been properly
> tested, and I'll be relying on you guys to tell me if it needs
> modifications. Or if you know of an USB device that is handled by the
> generic HID driver, and provides interrupt transfers through that driver
> on Windows, I'll see what I can do to get my hands on it.
>
> I'd guess a HID device where firmware can be upgraded would probably
> fall into that category, although any USB keyboard or mouse would be
> useless, as another limitation of Windows is that it doesn't provide r/w
> access to HID system devices (http://www.lvr.com/hidfaq.htm: "Why do I
> receive "Access denied" when attempting to access my HID?")
>

Yes those USB demo board would fit the need quite well. I have
bought some demo boards from Microchip which can function
as generic HID device with their example firmware. I also have
the PICkit 2 programmer which is a generic HID device as well.

Jan Axelson's website also lists many other boards which
can load the HID related firmware. She also has the excellent
generic HID firmware for some of the boards.
http://www.lvr.com/hidpage.htm

Last time I wrote a simple libusb program to test her generic HID
example with libusb 0.1 but it can be easily converter to the
synchronous API of libusb 1.0.
http://www.microchip.com/forums/tm.aspx?m=340898

BTW, her generic WinUSB firmware example can be a good

Re: WinUSB INF template

On Sun, Jan 31, 2010 at 10:29 PM, Pete Batard <pbatard <at> gmail.com> wrote:
> Yes, I remember having the "The folder you specified doesn't contain a
> compatible software" message when trying to force the WinUSB driver on
> Windows.
>
> I think if you select update driver and only select browse, you will get
> that message. In the browse dialog, you need to select "let me pick from
> a list" and then point to the driver directory.

I did do that but somehow it still happens. This is under Vista Home
Premium 32bit.

> No idea why Windows thinks its should ignore the driver in the first case...
>
> Yet some more details I need to include into the WinUSB installation
> guide, although I doubt many people will want to replace existing Mass
> Storage drivers, as you then lose all access to the devide except
> through libusb.

Yes I agree with you. This is just for testing purpose. Now that I know
the WinUSB backend works properly, I can test other generic device
using libusb 1.0 WinUSB backend.

--

-- 
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts

Re: pthreads on 64bit Windows

Pete Batard wrote:
> Note that with r127, the timer functions are now handled by a separate 
> thread (with its affinity set to the first core), so libusb on Windows 
> is now running at least 2 separate threads.

Sorry if this discussion has been had before, but can I
ask a dumb question: Why is a timer needed at all, and
why does it need to be high precision ?

libusb 0.1 doesn't have OS specific timing structures
like timespec visible in the API and doesn't deal with
absolute time anyway, and the OS backends deal with the
system specific issues. Why isn't libusb 1.0 taking the same approach ?

Do you really need better than 1msec precision on this anyway ?
(ie. why aren't the win32 primitives that take timeouts in msec
+ timeGetTime() sufficient for MSWindows back end ?)

Graeme Gill.

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

Re: pthreads on 64bit Windows

Graeme Gill wrote:
>> Pete Batard wrote:
>> > Note that with r127, the timer functions are now handled by a separate
>> > thread (with its affinity set to the first core), so libusb on Windows
>> > is now running at least 2 separate threads.
>>
>> Sorry if this discussion has been had before, but can I
>> ask a dumb question: Why is a timer needed at all, and
>> why does it need to be high precision ?
>>
>> libusb 0.1 doesn't have OS specific timing structures
>> like timespec visible in the API and doesn't deal with
>> absolute time anyway, and the OS backends deal with the
>> system specific issues. Why isn't libusb 1.0 taking the same approach ?

Well, looking at libusb-win32 0.1, anyway, the timeouts are relative, but
they're relative to when you try to reap in the async api
(usb_reap_async()).  In the sync api, you don't have more than one going on
from a given thread, so relative is fine.  So I believe that the reason for
absolute times is to have multiple operations going.

As to *accuracy* (forget precision for a moment), yes, we did have this
discussion, and Tim has seen up to 0.5 seconds of skew between processors on
the HF performance counter:

http://old.nabble.com/Re%3A--PATCH%3A-winusb--hires-timer-fix-p26749357.html

The reason for the thread is so we can lock it to one processor without
screwing up all the threads in an app.  I expect some delay to be introduced
in the context switches to get the time, but I think it's better than what

Re: msvc warning in libusb.h about zero-sized array

Francesco wrote:
> I'm not sure to understand why libusb uses:
> #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
> 	[] /* valid C99 code */
> #else
> 	[0] /* non-standard, but usually working code */
> #endif
> 	;
> instead of a simple pointer declaration...

As was mentioned, array entry 0 is stored where this struct member
starts, followed by entry 1, and so on. It's not a pointer, it's an
array - but with unknown length. All places where the struct size
needs to be known must somehow find out how many array entries are
included in it - sizeof() and other compiler helpers do not work.

> anyway I fear that the fact MSVC is unable to generate the
> copy-ctor or the copy-assignment operators may create some
> very-hard-to-detect bugs (since you can still write "t1 = t2;"
> where t1,t2 are libusb_transfer structs!)...

That will not work. You must manually handle all of the array
entries; first alloc enough memory for t1 so that there is room, then
possibly you can use t1=t2; but you must manually copy the array
entries anyway, so you might as well just copy the entire struct
instead and have less code.

> PS: btw setting /W4 makes the compiler spit out lots of other warnings
> and some of them could be pointing to real problems; e.g.
> 

Re: msvc warning in libusb.h about zero-sized array

Peter Stuge wrote:
>> > PS: btw setting /W4 makes the compiler spit out lots of other warnings
>> > and some of them could be pointing to real problems; e.g.
>> >
>> >  warning C4305: 'type cast' : truncation from 'list_head *' to
'unsigned long'
>> >  warning C4306: 'type cast' : conversion from 'int' to 'HANDLE' of
greater size
>> >  warning C4706: assignment within conditional expression
>>
>> Interesting! Can you show the places in the code that triggers these?

I only see the last one, and that shows up wherever the libusb-win32
DLL_LOAD() macro is used.  Those uses look ok, but would also be trivial to
clean up.  I don't have the other 2 warnings, but they sound like 64-bit
issues, so, like you said, line #'s would help.  Generally, most of the /W4
stuff has been spurious in my experience, but it'd still be good to look at
those.

Michael

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

Re: msvc warning in libusb.h about zero-sized array

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: msvc warning in libusb.h about zero-sized array

Orin Eman wrote:
>> This one in whatever version I have is real:
>>
>> 1>.\libusb\os\windows_usb.c(2749) : warning C4305: 'type cast' :
truncation from 'int *' to 'ULONG'
>> if (HidD_GetPhysicalDescriptor(hid_handle, data, (ULONG)size))
>>

I don't know much about HID, but it looks like that should be

-if (HidD_GetPhysicalDescriptor(hid_handle, data, (ULONG)size))
+if (HidD_GetPhysicalDescriptor(hid_handle, data, (ULONG)(*size) ))

Michael

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

Re: msvc warning in libusb.h about zero-sized array

Michael Plante wrote:
> >> 1>.\libusb\os\windows_usb.c(2749) : warning C4305: 'type cast' :
> truncation from 'int *' to 'ULONG'
> >> if (HidD_GetPhysicalDescriptor(hid_handle, data, (ULONG)size))
> 
> I don't know much about HID, but it looks like that should be
> 
> -if (HidD_GetPhysicalDescriptor(hid_handle, data, (ULONG)size))
> +if (HidD_GetPhysicalDescriptor(hid_handle, data, (ULONG)(*size) ))

Yep - that's correct.

//Peter

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

Re: pthreads on 64bit Windows

Michael Plante wrote:
> Well, looking at libusb-win32 0.1, anyway, the timeouts are relative, but
> they're relative to when you try to reap in the async api
> (usb_reap_async()).  In the sync api, you don't have more than one going on
> from a given thread, so relative is fine.  So I believe that the reason for
> absolute times is to have multiple operations going.

I've had a look at some of the doco but I can't say I'm understanding
it. There is the statement:

"* - libusb also needs to be called into at certain fixed points in time in
  * order to accurately handle transfer timeouts."

but this seems to me to be complicating the API unnecessarily to cope
with certain platforms. libusb 0.1 didn't have these complications,
hiding platform dependencies in the implementation. The libusb 1.0
async scheme seems similar to MSWindows OVERLAPPED type approach,
but it doesn't need absolute time, so I'm struggling to understand
why libusb 1.0 does. Don't you kick off an operation with a given
timeout, and then get called back when it completes or times out ?
Why do you have to poll it ? Why should different operations in the
same thread interfere with each other ?

> As to *accuracy* (forget precision for a moment), yes, we did have this
> discussion, and Tim has seen up to 0.5 seconds of skew between processors on
> the HF performance counter:

Right, but why use them if you don't need too given the complication
of needing a thread with affinity ?

> Hrm.  I don't recall if we've discussed that option.  timeGetTime() sounds
> monotonic if your system can't stay up 50 days, which is a good bet on
> Windows... :) 

It's supposed to be monotonic if you use the recommended 32 bit
modulo arithmetic, even over and after 50 days. Since MSWindows
timeout API's all take values in msec, and given the multi-core
and speed throttling issues with the HP timers, I would guess this
is what they are using internally

Graeme Gill.

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com