USB Human Interface Devices

classic Classic list List threaded Threaded
165 messages Options
1 ... 56789
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Stefan V. Pantazi

>
> libusbhid_interrupt_read. failed! return code: -1
> 0libusb: error [winusbx_submit_bulk_transfer] ReadPipe/WritePipe failed: [2] The system cannot find the file specified.
>
> But I don't really know how I can detect this and exit the process and signal my other program that the device is no longer present.   My read command:
>        hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report length, varies by device}, {timeout=}50);
> only reports the number of bytes read, and when the device is removed, the result of the libusbhid_interrupt_read seems to be 64.   I’m wondering what the proper way to gracefully detect the device has been disconnected is so I can just exit out of the mode the uses the device and return to normal processing without generating any errors.

You can try to handle the error return code by checking that a device
that was present before has actually disappeared for the libusb device list.

It also appears that in newer versions of libusb, there are provisions
for registering and unregistering a hotplug callback.

http://libusb.sourceforge.net/api-1.0/hotplug.html

It it easy to add the calls to libusbx but they need to be tested that
they actually work as expected.

>
> Any ideas?
>
> James
>
>
> -----Original Message-----
> From: fpc-pascal <[hidden email]> On Behalf Of Stefan V. Pantazi
> Sent: Friday, August 23, 2019 10:54 AM
> To: [hidden email]
> Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> Thanks for pushing on this. I think any pending timeout/transfer must be explicitly canceled before closing the USB device, so that the thread can end gracefully.
>
> The only way I see is to use something like
>
> libusb_handle_events_timeout_completed
>
> http://libusb.sourceforge.net/api-1.0/group__poll.html#ga43e52b912a760b41a0cf8a4a472fbd5b
>
>
> before closing the USB device context.
>
> That function is not currently part of the libusbx and has a time_t parameter that appears C-specific but for some reason is not included in ctypes unit. But I am sure Pascal equivalents can be defined. I will do some tests to include the libusb_handle_events_timeout_completed in libusbx and libusbhid and let you know.
>
>
>
> On 8/23/19 7:07 AM, James Richters wrote:
>> Stefan ,
>> Do you get the following errors when you exit your program?   Is there some way I should shut down the read thread so I don't get this error?  I've been using a timeout of 0
>>
>>
>> libusb: error [do_close] Device handle closed while transfer was still
>> being processed, but the device is still connected as far as we know
>> libusb: error [do_close] A cancellation hasn't even been scheduled on
>> the transfer for which the device is closing
>> libusb: warning [libusb_exit] some libusb_devices were leaked
>> Assertion failed!
>>
>> Program: i:\programming\gcode\libusbxhid\whb04b-4_test.exe
>> File: os/poll_windows.c, Line 145
>>
>> Expression: fd != NULL
>> Heap dump by heaptrc unit of
>> i:\programming\gcode\libusbxhid\whb04b-4_test.exe
>> 50 memory blocks allocated : 1782/1968
>> 50 memory blocks freed     : 1782/1968
>> 0 unfreed memory blocks : 0
>> True heap size : 131072 (160 used in System startup) True free heap :
>> 130912 _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
>
> --
> _______________________________________________________
> _______________________________________________
> fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

--
_______________________________________________________
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
Thanks for adding the hotplug functions and the sample program.  I will give that a try.  

I have come up with another solution before I saw you added the hotplug functions:

My thinking is that the interrupt read is going to know about the missing device before anything because it will be constantly reading as fast is it can and my main thread will be cycling much slower,  so detecting the failure of the interrupt read would be the fastest way to know the device was not connected anymore.
I noticed that lib_interupt_transfer produces a return code if anything prevents the transfer from being completed.  But this information is only used for optional debug reports, and not returned from the libusbhid_interrupt_write and libusbhid_interrupt_read functions,  they only return the number of bytes transferred.  Since the number of bytes read or sent is irrelevant due to an error, and the error codes seem to always be negative, then there is no ambiguity if we return the error if it is negative or bytes transferred if it is not negative. That way calls to libusbhid_interrupt_write and libusbhid_interrupt_read can quckly get the return code and / or the number of bytes transferred, just by checking if the result is negative or not. Since the interrupt read is happening in a tight loop and running way faster than anything else, it's likely that this will be the fastest way to stop the read thread when the device is unplugged, then I can go back to looking for it in the main program again.  The first read that produces an error will stop the thread.

I have tested this on my test branch. I get one negative return code during normal use... and that is if I get a timeout, I get a -7, perhaps because I asked for 8 bytes maybe? This is also useful information to have in my loop as if I get a -7, I don't need to bother checking the data at all since it was not read, it was just a timeout.  https://github.com/Zaaphod/libusbxhid/tree/Test


James
-----Original Message-----
From: fpc-pascal <[hidden email]> On Behalf Of Stefan V. Pantazi
Sent: Tuesday, August 27, 2019 10:35 PM
To: [hidden email]
Subject: Re: [fpc-pascal] USB Human Interface Devices


>
> libusbhid_interrupt_read. failed! return code: -1
> 0libusb: error [winusbx_submit_bulk_transfer] ReadPipe/WritePipe failed: [2] The system cannot find the file specified.
>
> But I don't really know how I can detect this and exit the process and signal my other program that the device is no longer present.   My read command:
>        hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report length, varies by device}, {timeout=}50);
> only reports the number of bytes read, and when the device is removed, the result of the libusbhid_interrupt_read seems to be 64.   I’m wondering what the proper way to gracefully detect the device has been disconnected is so I can just exit out of the mode the uses the device and return to normal processing without generating any errors.

You can try to handle the error return code by checking that a device that was present before has actually disappeared for the libusb device list.

It also appears that in newer versions of libusb, there are provisions for registering and unregistering a hotplug callback.

http://libusb.sourceforge.net/api-1.0/hotplug.html

It it easy to add the calls to libusbx but they need to be tested that they actually work as expected.

>
> Any ideas?
>
> James
>
>
> -----Original Message-----
> From: fpc-pascal <[hidden email]> On Behalf
> Of Stefan V. Pantazi
> Sent: Friday, August 23, 2019 10:54 AM
> To: [hidden email]
> Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> Thanks for pushing on this. I think any pending timeout/transfer must be explicitly canceled before closing the USB device, so that the thread can end gracefully.
>
> The only way I see is to use something like
>
> libusb_handle_events_timeout_completed
>
> http://libusb.sourceforge.net/api-1.0/group__poll.html#ga43e52b912a760
> b41a0cf8a4a472fbd5b
>
>
> before closing the USB device context.
>
> That function is not currently part of the libusbx and has a time_t parameter that appears C-specific but for some reason is not included in ctypes unit. But I am sure Pascal equivalents can be defined. I will do some tests to include the libusb_handle_events_timeout_completed in libusbx and libusbhid and let you know.
>
>
>
> On 8/23/19 7:07 AM, James Richters wrote:
>> Stefan ,
>> Do you get the following errors when you exit your program?   Is there some way I should shut down the read thread so I don't get this error?  I've been using a timeout of 0
>>
>>
>> libusb: error [do_close] Device handle closed while transfer was
>> still being processed, but the device is still connected as far as we
>> know
>> libusb: error [do_close] A cancellation hasn't even been scheduled on
>> the transfer for which the device is closing
>> libusb: warning [libusb_exit] some libusb_devices were leaked
>> Assertion failed!
>>
>> Program: i:\programming\gcode\libusbxhid\whb04b-4_test.exe
>> File: os/poll_windows.c, Line 145
>>
>> Expression: fd != NULL
>> Heap dump by heaptrc unit of
>> i:\programming\gcode\libusbxhid\whb04b-4_test.exe
>> 50 memory blocks allocated : 1782/1968
>> 50 memory blocks freed     : 1782/1968
>> 0 unfreed memory blocks : 0
>> True heap size : 131072 (160 used in System startup) True free heap :
>> 130912 _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
>
> --
> _______________________________________________________
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

--
_______________________________________________________
_______________________________________________
fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
I tried the hotplug test on Windows with my device, but I am getting a return code of -12 from libusb_hotplug_register_callback  I put some extra writeln's the test program:  https://github.com/Zaaphod/libusbxhid/blob/Test/libusbx_hotplug_test.pp

Here is the output:

Running "i:\programming\gcode\libusbxhid\libusbx_hotplug_test.exe "
Testing With: $10CE $EB93 0
Libusb Initialized
register done, Result:-12
Heap dump by heaptrc unit of i:\programming\gcode\libusbxhid\libusbx_hotplug_test.exe
54 memory blocks allocated : 1913/2120
54 memory blocks freed     : 1913/2120
0 unfreed memory blocks : 0
True heap size : 98304 (192 used in System startup)
True free heap : 98112

James

-----Original Message-----
From: fpc-pascal <[hidden email]> On Behalf Of James Richters
Sent: Wednesday, August 28, 2019 5:03 AM
To: 'FPC-Pascal users discussions' <[hidden email]>
Subject: Re: [fpc-pascal] USB Human Interface Devices

Thanks for adding the hotplug functions and the sample program.  I will give that a try.  

I have come up with another solution before I saw you added the hotplug functions:

My thinking is that the interrupt read is going to know about the missing device before anything because it will be constantly reading as fast is it can and my main thread will be cycling much slower,  so detecting the failure of the interrupt read would be the fastest way to know the device was not connected anymore.
I noticed that lib_interupt_transfer produces a return code if anything prevents the transfer from being completed.  But this information is only used for optional debug reports, and not returned from the libusbhid_interrupt_write and libusbhid_interrupt_read functions,  they only return the number of bytes transferred.  Since the number of bytes read or sent is irrelevant due to an error, and the error codes seem to always be negative, then there is no ambiguity if we return the error if it is negative or bytes transferred if it is not negative. That way calls to libusbhid_interrupt_write and libusbhid_interrupt_read can quckly get the return code and / or the number of bytes transferred, just by checking if the result is negative or not. Since the interrupt read is happening in a tight loop and running way faster than anything else, it's likely that this will be the fastest way to stop the read thread when the device is unplugged, then I can go back to looking for it in the main program again.  The first read that produces an error will stop the thread.

I have tested this on my test branch. I get one negative return code during normal use... and that is if I get a timeout, I get a -7, perhaps because I asked for 8 bytes maybe? This is also useful information to have in my loop as if I get a -7, I don't need to bother checking the data at all since it was not read, it was just a timeout.  https://github.com/Zaaphod/libusbxhid/tree/Test


James
-----Original Message-----
From: fpc-pascal <[hidden email]> On Behalf Of Stefan V. Pantazi
Sent: Tuesday, August 27, 2019 10:35 PM
To: [hidden email]
Subject: Re: [fpc-pascal] USB Human Interface Devices


>
> libusbhid_interrupt_read. failed! return code: -1
> 0libusb: error [winusbx_submit_bulk_transfer] ReadPipe/WritePipe failed: [2] The system cannot find the file specified.
>
> But I don't really know how I can detect this and exit the process and signal my other program that the device is no longer present.   My read command:
>        hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report length, varies by device}, {timeout=}50);
> only reports the number of bytes read, and when the device is removed, the result of the libusbhid_interrupt_read seems to be 64.   I’m wondering what the proper way to gracefully detect the device has been disconnected is so I can just exit out of the mode the uses the device and return to normal processing without generating any errors.

You can try to handle the error return code by checking that a device that was present before has actually disappeared for the libusb device list.

It also appears that in newer versions of libusb, there are provisions for registering and unregistering a hotplug callback.

http://libusb.sourceforge.net/api-1.0/hotplug.html

It it easy to add the calls to libusbx but they need to be tested that they actually work as expected.

>
> Any ideas?
>
> James
>
>
> -----Original Message-----
> From: fpc-pascal <[hidden email]> On Behalf
> Of Stefan V. Pantazi
> Sent: Friday, August 23, 2019 10:54 AM
> To: [hidden email]
> Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> Thanks for pushing on this. I think any pending timeout/transfer must be explicitly canceled before closing the USB device, so that the thread can end gracefully.
>
> The only way I see is to use something like
>
> libusb_handle_events_timeout_completed
>
> http://libusb.sourceforge.net/api-1.0/group__poll.html#ga43e52b912a760
> b41a0cf8a4a472fbd5b
>
>
> before closing the USB device context.
>
> That function is not currently part of the libusbx and has a time_t parameter that appears C-specific but for some reason is not included in ctypes unit. But I am sure Pascal equivalents can be defined. I will do some tests to include the libusb_handle_events_timeout_completed in libusbx and libusbhid and let you know.
>
>
>
> On 8/23/19 7:07 AM, James Richters wrote:
>> Stefan ,
>> Do you get the following errors when you exit your program?   Is there some way I should shut down the read thread so I don't get this error?  I've been using a timeout of 0
>>
>>
>> libusb: error [do_close] Device handle closed while transfer was
>> still being processed, but the device is still connected as far as we
>> know
>> libusb: error [do_close] A cancellation hasn't even been scheduled on
>> the transfer for which the device is closing
>> libusb: warning [libusb_exit] some libusb_devices were leaked
>> Assertion failed!
>>
>> Program: i:\programming\gcode\libusbxhid\whb04b-4_test.exe
>> File: os/poll_windows.c, Line 145
>>
>> Expression: fd != NULL
>> Heap dump by heaptrc unit of
>> i:\programming\gcode\libusbxhid\whb04b-4_test.exe
>> 50 memory blocks allocated : 1782/1968
>> 50 memory blocks freed     : 1782/1968
>> 0 unfreed memory blocks : 0
>> True heap size : 131072 (160 used in System startup) True free heap :
>> 130912 _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
>
> --
> _______________________________________________________
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

--
_______________________________________________________
_______________________________________________
fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Jean SUZINEAU
In reply to this post by Zaaphod
Hello,

It seems you didn't initialized you critical section using
InitCriticalSection.
The documentation of EnterCriticalSection :
https://www.freepascal.org/docs-html/rtl/system/entercriticalsection.html
The one of InitCriticalSection:
https://www.freepascal.org/docs-html/rtl/system/initcriticalsection.html

At the end, you need to call DoneCriticalSection  to release the
associated system resources (
https://www.freepascal.org/docs-html/rtl/system/donecriticalsection.html).

Note: these is related to freepascal implementation of critical
sections, in windows API, the function names are slightly different,
InitializeCriticalSection/EnterCriticalSection/DeleteCriticalSection
(https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-entercriticalsection)


Le 28/08/2019 à 01:50, James Richters a écrit :

> One thing I wasn't able to duplicate however was the use of      EnterCriticalsection(criticalSection);  and  LeaveCriticalsection(criticalSection);  when writing to shared variables.  If I try to ever use EnterCriticalsection(criticalSection); in the read thread, My program just instantly locks up and I can't even break out of it.    If I try to use it in the main program I instantly get
> EAccessViolation: Access violation
>    $00007FFF18A2DF23
>    $00007FFF189E9BBC
>    $00007FFF189E9AD0
>    $000000010000DCDA
>    $000000010000D54B
>    $000000010000218B  PROCESS_USB_DATA,  line 475 of WHB04B-4_test.pas
>    $0000000100002B37  SIMPLETERMINAL,  line 641 of WHB04B-4_test.pas
>    $0000000100002DDD  USE_MPG_DEVICE,  line 675 of WHB04B-4_test.pas
>    $0000000100002F93  main,  line 699 of WHB04B-4_test.pas
>    $0000000100002FE6
>    $0000000100011350
>    $0000000100001980
>    $00007FFF17B47E94
>    $00007FFF18A4A251
> Line 475 is    EnterCriticalsection(criticalSection);
> I left where I had the criticalsection stuff in the program but commented out.   It does seem to work fine without it though.. since the read, I am curious what I'm doing wrong, or if I need to do something else because I'm on Windows.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
Thanks for figuring out the critical section needs to be initialized.  Stefan's example did not do this:
https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_with_thread.pp

maybe it's something you can get away with on Linux...

I'll put in the init and done.   Should I enter critical section only for writing to shared variables, or also when reading them?

I'm also wondering if there is some way to tell if a thread is currently running or not... I don't want to try to start it again if it's already running.  I can make some flag that the threat sets when it starts and clears when it exits, but I am wondering if there already something in place to check to see if a thread exists.

James


-----Original Message-----
From: fpc-pascal <[hidden email]> On Behalf Of Jean SUZINEAU
Sent: Wednesday, August 28, 2019 7:04 AM
To: [hidden email]
Subject: Re: [fpc-pascal] USB Human Interface Devices

Hello,

It seems you didn't initialized you critical section using InitCriticalSection.
The documentation of EnterCriticalSection :
https://www.freepascal.org/docs-html/rtl/system/entercriticalsection.html
The one of InitCriticalSection:
https://www.freepascal.org/docs-html/rtl/system/initcriticalsection.html

At the end, you need to call DoneCriticalSection  to release the associated system resources ( https://www.freepascal.org/docs-html/rtl/system/donecriticalsection.html).

Note: these is related to freepascal implementation of critical sections, in windows API, the function names are slightly different, InitializeCriticalSection/EnterCriticalSection/DeleteCriticalSection
(https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-entercriticalsection)


Le 28/08/2019 à 01:50, James Richters a écrit :

> One thing I wasn't able to duplicate however was the use of      EnterCriticalsection(criticalSection);  and  LeaveCriticalsection(criticalSection);  when writing to shared variables.  If I try to ever use EnterCriticalsection(criticalSection); in the read thread, My program just instantly locks up and I can't even break out of it.    If I try to use it in the main program I instantly get
> EAccessViolation: Access violation
>    $00007FFF18A2DF23
>    $00007FFF189E9BBC
>    $00007FFF189E9AD0
>    $000000010000DCDA
>    $000000010000D54B
>    $000000010000218B  PROCESS_USB_DATA,  line 475 of WHB04B-4_test.pas
>    $0000000100002B37  SIMPLETERMINAL,  line 641 of WHB04B-4_test.pas
>    $0000000100002DDD  USE_MPG_DEVICE,  line 675 of WHB04B-4_test.pas
>    $0000000100002F93  main,  line 699 of WHB04B-4_test.pas
>    $0000000100002FE6
>    $0000000100011350
>    $0000000100001980
>    $00007FFF17B47E94
>    $00007FFF18A4A251
> Line 475 is    EnterCriticalsection(criticalSection);
> I left where I had the criticalsection stuff in the program but commented out.   It does seem to work fine without it though.. since the read, I am curious what I'm doing wrong, or if I need to do something else because I'm on Windows.

_______________________________________________
fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Jean SUZINEAU
Le 28/08/2019 à 13:26, James Richters a écrit :
> Thanks for figuring out the critical section needs to be initialized.  Stefan's example did not do this:
> https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_with_thread.pp
>
> maybe it's something you can get away with on Linux...
Maybe, it seems EnterCriticalSection is defined by the current thread
manager. But if your variable is uninitialized, you can have anything in
it, I think EnterCriticalSection cannot do anything reliable with it.
> I'll put in the init and done.   Should I enter critical section only for writing to shared variables, or also when reading them?

You don't need to enter the Critical section to read the variable.

The critical section is essentially used to prevent the case where your
main thread and your read  thread write two different values to the same
variable at the same time. In this case without a critical section, you
cannot predict the value of the variable. If the variable is always
written by the same thread, you don't need the critical section.

> I'm also wondering if there is some way to tell if a thread is currently running or not... I don't want to try to start it again if it's already running.  I can make some flag that the threat sets when it starts and clears when it exits, but I am wondering if there already something in place to check to see if a thread exists.

You can find whether your thread is running or not with the
readThread.Suspended property,

but in your program, your thread is always running, it's nether
suspended. It's just blocked in a call (to libusbhid_interrupt_read I guess)


_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
Thanks for the information
I'm going to end the thread if the USB device is unplugged,  so then I need the main program to also know the thread has ended so it can go back to occasionally checking to see if the device was plugged back in.

>You can find whether your thread is running or not with the readThread.Suspended property,

>but in your program, your thread is always running, it's nether suspended. It's just blocked in a call (to libusbhid_interrupt_read I guess)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Stefan V. Pantazi
In reply to this post by Zaaphod
I agree with you: the libusbhid_interrupt_read and
libusb_interrupt_transfer are very close semantically and returning as a
result either the length of transferred data or the error code would
make a lot of sense. But in rare cases one may still need to check both
parameters:

http://libusb.sourceforge.net/api-1.0/group__syncio.html#gac412bda21b7ecf57e4c76877d78e6486
"Also check transferred when dealing with a timeout error code. libusb
may have to split your transfer into a number of chunks to satisfy
underlying O/S requirements, meaning that the timeout may expire after
the first few chunks have completed. libusb is careful not to lose any
data that may have been transferred; do not assume that timeout
conditions indicate a complete lack of I/O."

At any rate, switching around and returning both: the error code as the
result of libusb_interrupt_transfer and the length of data transfer as
an out parameter maybe the right thing to do. That would probably make
the semantics of libusbhid_interrupt_read and libusb_interrupt_transfer
almost identical.

On 8/28/19 5:03 AM, James Richters wrote:

> Thanks for adding the hotplug functions and the sample program.  I will give that a try.
>
> I have come up with another solution before I saw you added the hotplug functions:
>
> My thinking is that the interrupt read is going to know about the missing device before anything because it will be constantly reading as fast is it can and my main thread will be cycling much slower,  so detecting the failure of the interrupt read would be the fastest way to know the device was not connected anymore.
> I noticed that lib_interupt_transfer produces a return code if anything prevents the transfer from being completed.  But this information is only used for optional debug reports, and not returned from the libusbhid_interrupt_write and libusbhid_interrupt_read functions,  they only return the number of bytes transferred.  Since the number of bytes read or sent is irrelevant due to an error, and the error codes seem to always be negative, then there is no ambiguity if we return the error if it is negative or bytes transferred if it is not negative. That way calls to libusbhid_interrupt_write and libusbhid_interrupt_read can quckly get the return code and / or the number of bytes transferred, just by checking if the result is negative or not. Since the interrupt read is happening in a tight loop and running way faster than anything else, it's likely that this will be the fastest way to stop the read thread when the device is unplugged, then I can go back to looking for it in the main program again.  The first read that produces an error will stop the thread.
>
> I have tested this on my test branch. I get one negative return code during normal use... and that is if I get a timeout, I get a -7, perhaps because I asked for 8 bytes maybe? This is also useful information to have in my loop as if I get a -7, I don't need to bother checking the data at all since it was not read, it was just a timeout.  https://github.com/Zaaphod/libusbxhid/tree/Test
>
>
> James
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Stefan V. Pantazi
In reply to this post by Zaaphod
Yeah you are right, Windows was less forgiving. Sorry about that and
thank you Jean.

For simple data structures written only from one thread, using critical
section may be overkill. But if your data structure is a queue or a
longer buffer, with length, etc. that is being produced by one thread
and consumed by another (i.e., modified by more than one thread) then
you should use some form of synchronization such as a critical section.


On 8/28/19 7:26 AM, James Richters wrote:

> Thanks for figuring out the critical section needs to be initialized.  Stefan's example did not do this:
> https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_with_thread.pp
>
> maybe it's something you can get away with on Linux...
>
> I'll put in the init and done.   Should I enter critical section only for writing to shared variables, or also when reading them?
>
> I'm also wondering if there is some way to tell if a thread is currently running or not... I don't want to try to start it again if it's already running.  I can make some flag that the threat sets when it starts and clears when it exits, but I am wondering if there already something in place to check to see if a thread exists.
>
> James
>
>
> -----Original Message-----
> From: fpc-pascal <[hidden email]> On Behalf Of Jean SUZINEAU
> Sent: Wednesday, August 28, 2019 7:04 AM
> To: [hidden email]
> Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> Hello,
>
> It seems you didn't initialized you critical section using InitCriticalSection.
> The documentation of EnterCriticalSection :
> https://www.freepascal.org/docs-html/rtl/system/entercriticalsection.html
> The one of InitCriticalSection:
> https://www.freepascal.org/docs-html/rtl/system/initcriticalsection.html
>
> At the end, you need to call DoneCriticalSection  to release the associated system resources ( https://www.freepascal.org/docs-html/rtl/system/donecriticalsection.html).
>
> Note: these is related to freepascal implementation of critical sections, in windows API, the function names are slightly different, InitializeCriticalSection/EnterCriticalSection/DeleteCriticalSection
> (https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-entercriticalsection)
>
>
> Le 28/08/2019 à 01:50, James Richters a écrit :
>> One thing I wasn't able to duplicate however was the use of      EnterCriticalsection(criticalSection);  and  LeaveCriticalsection(criticalSection);  when writing to shared variables.  If I try to ever use EnterCriticalsection(criticalSection); in the read thread, My program just instantly locks up and I can't even break out of it.    If I try to use it in the main program I instantly get
>> EAccessViolation: Access violation
>>     $00007FFF18A2DF23
>>     $00007FFF189E9BBC
>>     $00007FFF189E9AD0
>>     $000000010000DCDA
>>     $000000010000D54B
>>     $000000010000218B  PROCESS_USB_DATA,  line 475 of WHB04B-4_test.pas
>>     $0000000100002B37  SIMPLETERMINAL,  line 641 of WHB04B-4_test.pas
>>     $0000000100002DDD  USE_MPG_DEVICE,  line 675 of WHB04B-4_test.pas
>>     $0000000100002F93  main,  line 699 of WHB04B-4_test.pas
>>     $0000000100002FE6
>>     $0000000100011350
>>     $0000000100001980
>>     $00007FFF17B47E94
>>     $00007FFF18A4A251
>> Line 475 is    EnterCriticalsection(criticalSection);
>> I left where I had the criticalsection stuff in the program but commented out.   It does seem to work fine without it though.. since the read, I am curious what I'm doing wrong, or if I need to do something else because I'm on Windows.
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

--
_______________________________________________________
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Stefan V. Pantazi
In reply to this post by Zaaphod
I was wondering whether it works on Windows - I only had time to test on
Linux. It looks like bad news. Error code -12 is

LIBUSB_ERROR_NOT_SUPPORTED
Operation not supported or unimplemented on this platform.


On 8/28/19 6:24 AM, James Richters wrote:

> I tried the hotplug test on Windows with my device, but I am getting a return code of -12 from libusb_hotplug_register_callback  I put some extra writeln's the test program:  https://github.com/Zaaphod/libusbxhid/blob/Test/libusbx_hotplug_test.pp
>
> Here is the output:
>
> Running "i:\programming\gcode\libusbxhid\libusbx_hotplug_test.exe "
> Testing With: $10CE $EB93 0
> Libusb Initialized
> register done, Result:-12
> Heap dump by heaptrc unit of i:\programming\gcode\libusbxhid\libusbx_hotplug_test.exe
> 54 memory blocks allocated : 1913/2120
> 54 memory blocks freed     : 1913/2120
> 0 unfreed memory blocks : 0
> True heap size : 98304 (192 used in System startup)
> True free heap : 98112
>
> James
>
> -----Original Message-----
> From: fpc-pascal <[hidden email]> On Behalf Of James Richters
> Sent: Wednesday, August 28, 2019 5:03 AM
> To: 'FPC-Pascal users discussions' <[hidden email]>
> Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> Thanks for adding the hotplug functions and the sample program.  I will give that a try.
>
> I have come up with another solution before I saw you added the hotplug functions:
>
> My thinking is that the interrupt read is going to know about the missing device before anything because it will be constantly reading as fast is it can and my main thread will be cycling much slower,  so detecting the failure of the interrupt read would be the fastest way to know the device was not connected anymore.
> I noticed that lib_interupt_transfer produces a return code if anything prevents the transfer from being completed.  But this information is only used for optional debug reports, and not returned from the libusbhid_interrupt_write and libusbhid_interrupt_read functions,  they only return the number of bytes transferred.  Since the number of bytes read or sent is irrelevant due to an error, and the error codes seem to always be negative, then there is no ambiguity if we return the error if it is negative or bytes transferred if it is not negative. That way calls to libusbhid_interrupt_write and libusbhid_interrupt_read can quckly get the return code and / or the number of bytes transferred, just by checking if the result is negative or not. Since the interrupt read is happening in a tight loop and running way faster than anything else, it's likely that this will be the fastest way to stop the read thread when the device is unplugged, then I can go back to looking for it in the main program again.  The first read that produces an error will stop the thread.
>
> I have tested this on my test branch. I get one negative return code during normal use... and that is if I get a timeout, I get a -7, perhaps because I asked for 8 bytes maybe? This is also useful information to have in my loop as if I get a -7, I don't need to bother checking the data at all since it was not read, it was just a timeout.  https://github.com/Zaaphod/libusbxhid/tree/Test
>
>
> James
> -----Original Message-----
> From: fpc-pascal <[hidden email]> On Behalf Of Stefan V. Pantazi
> Sent: Tuesday, August 27, 2019 10:35 PM
> To: [hidden email]
> Subject: Re: [fpc-pascal] USB Human Interface Devices
>
>
>>
>> libusbhid_interrupt_read. failed! return code: -1
>> 0libusb: error [winusbx_submit_bulk_transfer] ReadPipe/WritePipe failed: [2] The system cannot find the file specified.
>>
>> But I don't really know how I can detect this and exit the process and signal my other program that the device is no longer present.   My read command:
>>         hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report length, varies by device}, {timeout=}50);
>> only reports the number of bytes read, and when the device is removed, the result of the libusbhid_interrupt_read seems to be 64.   I’m wondering what the proper way to gracefully detect the device has been disconnected is so I can just exit out of the mode the uses the device and return to normal processing without generating any errors.
>
> You can try to handle the error return code by checking that a device that was present before has actually disappeared for the libusb device list.
>
> It also appears that in newer versions of libusb, there are provisions for registering and unregistering a hotplug callback.
>
> http://libusb.sourceforge.net/api-1.0/hotplug.html
>
> It it easy to add the calls to libusbx but they need to be tested that they actually work as expected.
>
>>
>> Any ideas?
>>
>> James
>>
>>
>> -----Original Message-----
>> From: fpc-pascal <[hidden email]> On Behalf
>> Of Stefan V. Pantazi
>> Sent: Friday, August 23, 2019 10:54 AM
>> To: [hidden email]
>> Subject: Re: [fpc-pascal] USB Human Interface Devices
>>
>> Thanks for pushing on this. I think any pending timeout/transfer must be explicitly canceled before closing the USB device, so that the thread can end gracefully.
>>
>> The only way I see is to use something like
>>
>> libusb_handle_events_timeout_completed
>>
>> http://libusb.sourceforge.net/api-1.0/group__poll.html#ga43e52b912a760
>> b41a0cf8a4a472fbd5b
>>
>>
>> before closing the USB device context.
>>
>> That function is not currently part of the libusbx and has a time_t parameter that appears C-specific but for some reason is not included in ctypes unit. But I am sure Pascal equivalents can be defined. I will do some tests to include the libusb_handle_events_timeout_completed in libusbx and libusbhid and let you know.
>>
>>
>>
>> On 8/23/19 7:07 AM, James Richters wrote:
>>> Stefan ,
>>> Do you get the following errors when you exit your program?   Is there some way I should shut down the read thread so I don't get this error?  I've been using a timeout of 0
>>>
>>>
>>> libusb: error [do_close] Device handle closed while transfer was
>>> still being processed, but the device is still connected as far as we
>>> know
>>> libusb: error [do_close] A cancellation hasn't even been scheduled on
>>> the transfer for which the device is closing
>>> libusb: warning [libusb_exit] some libusb_devices were leaked
>>> Assertion failed!
>>>
>>> Program: i:\programming\gcode\libusbxhid\whb04b-4_test.exe
>>> File: os/poll_windows.c, Line 145
>>>
>>> Expression: fd != NULL
>>> Heap dump by heaptrc unit of
>>> i:\programming\gcode\libusbxhid\whb04b-4_test.exe
>>> 50 memory blocks allocated : 1782/1968
>>> 50 memory blocks freed     : 1782/1968
>>> 0 unfreed memory blocks : 0
>>> True heap size : 131072 (160 used in System startup) True free heap :
>>> 130912 _______________________________________________
>>> fpc-pascal maillist  -  [hidden email]
>>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>>
>>
>> --
>> _______________________________________________________
>> _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>> _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
>
> --
> _______________________________________________________
> _______________________________________________
> fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

--
_______________________________________________________
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
In reply to this post by Stefan V. Pantazi
I have the critical section working now with init and done.  Thanks for the information!   For my test program I don't think I need it, but when I integrate it into the real project I will need to write to the same variables at different times, so I'll make sure to define the writes in critical sections.

James
-----Original Message-----
From: fpc-pascal <[hidden email]> On Behalf Of Stefan V. Pantazi
Sent: Wednesday, August 28, 2019 5:46 PM
To: [hidden email]
Subject: Re: [fpc-pascal] USB Human Interface Devices

Yeah you are right, Windows was less forgiving. Sorry about that and thank you Jean.

For simple data structures written only from one thread, using critical section may be overkill. But if your data structure is a queue or a longer buffer, with length, etc. that is being produced by one thread and consumed by another (i.e., modified by more than one thread) then you should use some form of synchronization such as a critical section.


On 8/28/19 7:26 AM, James Richters wrote:

> Thanks for figuring out the critical section needs to be initialized.  Stefan's example did not do this:
> https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_wit
> h_thread.pp
>
> maybe it's something you can get away with on Linux...
>
> I'll put in the init and done.   Should I enter critical section only for writing to shared variables, or also when reading them?
>
> I'm also wondering if there is some way to tell if a thread is currently running or not... I don't want to try to start it again if it's already running.  I can make some flag that the threat sets when it starts and clears when it exits, but I am wondering if there already something in place to check to see if a thread exists.
>
> James
>
>
> -----Original Message-----
> From: fpc-pascal <[hidden email]> On Behalf
> Of Jean SUZINEAU
> Sent: Wednesday, August 28, 2019 7:04 AM
> To: [hidden email]
> Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> Hello,
>
> It seems you didn't initialized you critical section using InitCriticalSection.
> The documentation of EnterCriticalSection :
> https://www.freepascal.org/docs-html/rtl/system/entercriticalsection.h
> tml
> The one of InitCriticalSection:
> https://www.freepascal.org/docs-html/rtl/system/initcriticalsection.ht
> ml
>
> At the end, you need to call DoneCriticalSection  to release the associated system resources ( https://www.freepascal.org/docs-html/rtl/system/donecriticalsection.html).
>
> Note: these is related to freepascal implementation of critical
> sections, in windows API, the function names are slightly different,
> InitializeCriticalSection/EnterCriticalSection/DeleteCriticalSection
> (https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-syncha
> pi-entercriticalsection)
>
>
> Le 28/08/2019 à 01:50, James Richters a écrit :
>> One thing I wasn't able to duplicate however was the use of      EnterCriticalsection(criticalSection);  and  LeaveCriticalsection(criticalSection);  when writing to shared variables.  If I try to ever use EnterCriticalsection(criticalSection); in the read thread, My program just instantly locks up and I can't even break out of it.    If I try to use it in the main program I instantly get
>> EAccessViolation: Access violation
>>     $00007FFF18A2DF23
>>     $00007FFF189E9BBC
>>     $00007FFF189E9AD0
>>     $000000010000DCDA
>>     $000000010000D54B
>>     $000000010000218B  PROCESS_USB_DATA,  line 475 of WHB04B-4_test.pas
>>     $0000000100002B37  SIMPLETERMINAL,  line 641 of WHB04B-4_test.pas
>>     $0000000100002DDD  USE_MPG_DEVICE,  line 675 of WHB04B-4_test.pas
>>     $0000000100002F93  main,  line 699 of WHB04B-4_test.pas
>>     $0000000100002FE6
>>     $0000000100011350
>>     $0000000100001980
>>     $00007FFF17B47E94
>>     $00007FFF18A4A251
>> Line 475 is    EnterCriticalsection(criticalSection);
>> I left where I had the criticalsection stuff in the program but commented out.   It does seem to work fine without it though.. since the read, I am curious what I'm doing wrong, or if I need to do something else because I'm on Windows.
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

--
_______________________________________________________
_______________________________________________
fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
In reply to this post by Stefan V. Pantazi
I have a system working by just checking error codes and shutting down the thread and starting it as needed and using a few flags to know when thread is running or not.  

James
-----Original Message-----
From: fpc-pascal <[hidden email]> On Behalf Of Stefan V. Pantazi
Sent: Wednesday, August 28, 2019 5:50 PM
To: [hidden email]
Subject: Re: [fpc-pascal] USB Human Interface Devices

I was wondering whether it works on Windows - I only had time to test on Linux. It looks like bad news. Error code -12 is

LIBUSB_ERROR_NOT_SUPPORTED
Operation not supported or unimplemented on this platform.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Brian
A few general thoughts. Having been in similar situations when dealing with
hardware interfaces .. the hardware is what it is .. and annoying as it is
you have to work around it , as the hardware isn't going to change.

It seems you have two problems 1) the USB hardware and 2) your program , in
which you are not certain if it is doing something wrong .. been there many
times.

Sometimes it helps to make a simulator program which simulates (how you
think the hardware is supposed to work) , and use that to shake out the bugs
in your software. It is a lot of extra work but sometime there is no
alternative. For example use a 2nd PC and an Ethernet UDP connection to test
your software concept.

Also rather than using critical sections , use syncobs to ensure that you
are not trying to read and write to the same USB address or your data
memory.

https://www.freepascal.org/docs-html/current/fcl/syncobjs/teventobject.html

Most guys/gals when writing interrupt handlers tend to use as simple a
mechanism as possible .. from previous bad experiences.

Try testing on Linux as you can run your program in graphics mode ( if that
is what it does) while viewing events by writing write() messages to a
terminal. This occurs if you launch your program from a terminal , then all
writeln() messages go to the text terminal.



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Brian
In reply to this post by Zaaphod
A bit of clarification ..

Also rather than using critical sections , use syncobs to ensure that you
are not trying to /SIMULTANEOUSLY/ read and write to the same USB address or
your data memory.

Try using an Ethernet UDP connection to simulate the USB connection as it
may illuminate an issue in your program.

The Synapse UDP function works well



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
Thanks for the Sybcobs suggestion, I didn't know there was such a thing but it seems like a great way to prevent simultaneous data/hardware events.

James
-----Original Message-----
From: fpc-pascal <[hidden email]> On Behalf Of Brian
Sent: Thursday, August 29, 2019 10:50 AM
To: [hidden email]
Subject: Re: [fpc-pascal] USB Human Interface Devices

A bit of clarification ..

Also rather than using critical sections , use syncobs to ensure that you are not trying to /SIMULTANEOUSLY/ read and write to the same USB address or your data memory.

Try using an Ethernet UDP connection to simulate the USB connection as it may illuminate an issue in your program.

The Synapse UDP function works well



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Brian
Yes , and it works well on Linux.

I use it on a circular (ring) buffer where the main program reads data from
the circular buffer and increments the read index while a totally random
thread reads data from an incoming Ethernet UDP , serial port or a custom
hardware port , writes to the circular buffer and increments the write
index.

The functions used are :
procedure ResetEvent;
procedure SetEvent;
function WaitFor();  // one of the events in your program READ or WRITE must
wait until the other event finishes.
       

The condition for a read of the circular buffer is WriteIndex <> ReadIndex
which is in the main loop (not a thread) which is continuously polled in the
main loop.

Hope this helps. I can send a code clip but not until next week (out of the
office) , showing how it is configured.



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
In reply to this post by Zaaphod
Now I have a new strange issue.   I've been working with my sample program here: https://github.com/Zaaphod/libusbxhid/blob/WHB04B-4/whb04b.pas 

And it's been working just fine for me.. just some minor little tweaks and adding new functionality.. etc..  I was just about to start to merge this into my large project when I sent the sample program to my dad... on his system he just gets a screen full of errors... but on mine, it's nice and clean.  I don't understand what is happening.. I reduced my test program down to the most basic sample that demonstrates the issue here:   https://github.com/Zaaphod/libusbxhid/blob/System_Specific_Bug/bugtest.pas

All this program does is checks to see if a specific device exists.. this program works perfectly on 4 computers and has no issue, but on one of my dad's computers I get the following errors:

libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\00000830' is no longer connected!
libusb: error [init_device] device 'USB\VID_1778&PID_0224\40000030' is no longer connected!
libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning.
libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected!


I don't know why Libusb is reporting this, no one tried to open anything so who cares if some devices are not  connected, and how does it know they were connected at one time... this is not even an error..  if it's not connected, just ignore it, nobody cares about that device anyway.  
So I have two questions:
1. any idea why these errors are being generated and how to fix it?
2. Is there a way to turn off libusb errors, info and warnings?

All systems are windows 10 Pro 64 bit, program was compiled for windows 64bit as well.

Here is the complete output with debug info:

K:\ProAuto>bugtest.exe
libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\00000830' is no longer connected!
libusb: error [init_device] device 'USB\VID_1778&PID_0224\40000030' is no longer connected!
libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning.
libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected!
Looking for $10CE, $EB93: DEBUG Found 20 devices attached
DEBUG 1038:1310, bus: 7, address: 6
DEBUG 1002:4399, bus: 10, address: 0
DEBUG 1B21:1142, bus: 3, address: 0
DEBUG 046D:C31C, bus: 7, address: 3
DEBUG 1B21:1142, bus: 1, address: 0
DEBUG 2109:0812, bus: 1, address: 1
DEBUG 2109:2812, bus: 7, address: 2
DEBUG 1002:4397, bus: 6, address: 0
DEBUG 1002:4397, bus: 5, address: 0
DEBUG 0A12:0001, bus: 5, address: 1
DEBUG 2109:2811, bus: 7, address: 9
DEBUG 1002:4397, bus: 9, address: 0
DEBUG 0C45:7403, bus: 7, address: 4
DEBUG 1002:4396, bus: 8, address: 0
DEBUG 1002:4396, bus: 7, address: 0
DEBUG 0E50:0002, bus: 7, address: 7
DEBUG 1B21:1142, bus: 2, address: 0
DEBUG 1002:4396, bus: 4, address: 0
DEBUG 1A40:0101, bus: 7, address: 1
DEBUG 2109:2812, bus: 7, address: 5
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 20 devices
DEBUG USB device list freed. good boy!
FALSE
libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\00000830' is no longer connected!
libusb: error [init_device] device 'USB\VID_1778&PID_0224\40000030' is no longer connected!
libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning.
libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected!
Looking for $10CE, $EB93: DEBUG Found 20 devices attached
DEBUG 1038:1310, bus: 7, address: 6
DEBUG 1002:4399, bus: 10, address: 0
DEBUG 1B21:1142, bus: 3, address: 0
DEBUG 046D:C31C, bus: 7, address: 3
DEBUG 1B21:1142, bus: 1, address: 0
DEBUG 2109:0812, bus: 1, address: 1
DEBUG 2109:2812, bus: 7, address: 2
DEBUG 1002:4397, bus: 6, address: 0
DEBUG 1002:4397, bus: 5, address: 0
DEBUG 0A12:0001, bus: 5, address: 1
DEBUG 2109:2811, bus: 7, address: 9
DEBUG 1002:4397, bus: 9, address: 0
DEBUG 0C45:7403, bus: 7, address: 4
DEBUG 1002:4396, bus: 8, address: 0
DEBUG 1002:4396, bus: 7, address: 0
DEBUG 0E50:0002, bus: 7, address: 7
DEBUG 1B21:1142, bus: 2, address: 0
DEBUG 1002:4396, bus: 4, address: 0
DEBUG 1A40:0101, bus: 7, address: 1
DEBUG 2109:2812, bus: 7, address: 5
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 20 devices
DEBUG USB device list freed. good boy!
FALSE
libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\00000830' is no longer connected!
libusb: error [init_device] device 'USB\VID_1778&PID_0224\40000030' is no longer connected!
libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning.
libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected!
Looking for $10CE, $EB93: DEBUG Found 20 devices attached
DEBUG 1038:1310, bus: 7, address: 6
DEBUG 1002:4399, bus: 10, address: 0
DEBUG 1B21:1142, bus: 3, address: 0
DEBUG 046D:C31C, bus: 7, address: 3
DEBUG 1B21:1142, bus: 1, address: 0
DEBUG 2109:0812, bus: 1, address: 1
DEBUG 2109:2812, bus: 7, address: 2
DEBUG 1002:4397, bus: 6, address: 0
DEBUG 1002:4397, bus: 5, address: 0
DEBUG 0A12:0001, bus: 5, address: 1
DEBUG 2109:2811, bus: 7, address: 9
DEBUG 1002:4397, bus: 9, address: 0
DEBUG 0C45:7403, bus: 7, address: 4
DEBUG 1002:4396, bus: 8, address: 0
DEBUG 1002:4396, bus: 7, address: 0
DEBUG 0E50:0002, bus: 7, address: 7
DEBUG 1B21:1142, bus: 2, address: 0
DEBUG 1002:4396, bus: 4, address: 0
DEBUG 1A40:0101, bus: 7, address: 1
DEBUG 2109:2812, bus: 7, address: 5
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 20 devices
DEBUG USB device list freed. good boy!
FALSE
Heap dump by heaptrc unit of K:\ProAuto\bugtest.exe
685 memory blocks allocated : 33042/37272
685 memory blocks freed     : 33042/37272
0 unfreed memory blocks : 0
True heap size : 163840 (128 used in System startup)
True free heap : 163712

When I run it on any other computer I get:
I:\Programming\Gcode\bug>bugtest.exe
Looking for $10CE, $EB93: DEBUG Found 17 devices attached
DEBUG 8086:A36D, bus: 1, address: 0
DEBUG 8087:0AAA, bus: 1, address: 8
DEBUG 05E3:0612, bus: 1, address: 18
DEBUG 0424:2734, bus: 1, address: 42
DEBUG 1D50:6015, bus: 1, address: 14
DEBUG 05E3:0743, bus: 1, address: 22
DEBUG 1B1C:0C15, bus: 1, address: 9
DEBUG 05E3:0610, bus: 1, address: 21
DEBUG 05E3:0610, bus: 1, address: 6
DEBUG 04E8:61F5, bus: 1, address: 1
DEBUG 1B1C:0C10, bus: 1, address: 7
DEBUG 0424:274C, bus: 1, address: 43
DEBUG 1B1C:1B4F, bus: 1, address: 41
DEBUG 1A40:0101, bus: 1, address: 2
DEBUG 0C45:7403, bus: 1, address: 26
DEBUG 0E50:0002, bus: 1, address: 60
DEBUG 10C4:EA60, bus: 1, address: 4
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 17 devices
DEBUG USB device list freed. good boy!
FALSE
Looking for $10CE, $EB93: DEBUG Found 17 devices attached
DEBUG 8086:A36D, bus: 1, address: 0
DEBUG 8087:0AAA, bus: 1, address: 8
DEBUG 05E3:0612, bus: 1, address: 18
DEBUG 0424:2734, bus: 1, address: 42
DEBUG 1D50:6015, bus: 1, address: 14
DEBUG 05E3:0743, bus: 1, address: 22
DEBUG 1B1C:0C15, bus: 1, address: 9
DEBUG 05E3:0610, bus: 1, address: 21
DEBUG 05E3:0610, bus: 1, address: 6
DEBUG 04E8:61F5, bus: 1, address: 1
DEBUG 1B1C:0C10, bus: 1, address: 7
DEBUG 0424:274C, bus: 1, address: 43
DEBUG 1B1C:1B4F, bus: 1, address: 41
DEBUG 1A40:0101, bus: 1, address: 2
DEBUG 0C45:7403, bus: 1, address: 26
DEBUG 0E50:0002, bus: 1, address: 60
DEBUG 10C4:EA60, bus: 1, address: 4
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 17 devices
DEBUG USB device list freed. good boy!
FALSE
Looking for $10CE, $EB93: DEBUG Found 17 devices attached
DEBUG 8086:A36D, bus: 1, address: 0
DEBUG 8087:0AAA, bus: 1, address: 8
DEBUG 05E3:0612, bus: 1, address: 18
DEBUG 0424:2734, bus: 1, address: 42
DEBUG 1D50:6015, bus: 1, address: 14
DEBUG 05E3:0743, bus: 1, address: 22
DEBUG 1B1C:0C15, bus: 1, address: 9
DEBUG 05E3:0610, bus: 1, address: 21
DEBUG 05E3:0610, bus: 1, address: 6
DEBUG 04E8:61F5, bus: 1, address: 1
DEBUG 1B1C:0C10, bus: 1, address: 7
DEBUG 0424:274C, bus: 1, address: 43
DEBUG 1B1C:1B4F, bus: 1, address: 41
DEBUG 1A40:0101, bus: 1, address: 2
DEBUG 0C45:7403, bus: 1, address: 26
DEBUG 0E50:0002, bus: 1, address: 60
DEBUG 10C4:EA60, bus: 1, address: 4
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 17 devices
DEBUG USB device list freed. good boy!
FALSE
Heap dump by heaptrc unit of I:\Programming\Gcode\bug\bugtest.exe
595 memory blocks allocated : 28731/32376
595 memory blocks freed     : 28731/32376
0 unfreed memory blocks : 0
True heap size : 163840 (160 used in System startup)
True free heap : 163680

James
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
In reply to this post by Brian
I use circular buffers for another project as well, but I made my own.. and the program doesn't use threads... it's buffering data being sent to a serial port in a really complicated way with a series of loops and timers to manage to function in a single thread...  I'm thinking of overhauling it to work with threads as it will greatly simplify things and probably perform better as well.    It sounds like there is already circular buffer functions available in FPC?  I would really like to see your code sample if you don't mind, it all sounds very useful!  

James

-----Original Message-----
From: fpc-pascal <[hidden email]> On Behalf Of Brian
Sent: Thursday, August 29, 2019 11:57 AM
To: [hidden email]
Subject: Re: [fpc-pascal] USB Human Interface Devices

Yes , and it works well on Linux.

I use it on a circular (ring) buffer where the main program reads data from the circular buffer and increments the read index while a totally random thread reads data from an incoming Ethernet UDP , serial port or a custom hardware port , writes to the circular buffer and increments the write index.

The functions used are :
procedure ResetEvent;
procedure SetEvent;
function WaitFor();  // one of the events in your program READ or WRITE must wait until the other event finishes.
       

The condition for a read of the circular buffer is WriteIndex <> ReadIndex which is in the main loop (not a thread) which is continuously polled in the main loop.

Hope this helps. I can send a code clip but not until next week (out of the
office) , showing how it is configured.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Stefan V. Pantazi
In reply to this post by Zaaphod
libusb has a debug verbosity level which currently is set to 3 (i.e., very verbose) in the device open function.
There is a define in libusbx.pas that you can change to shut off debug messages.


On Thu, Aug 29, 2019 at 12:03 PM James Richters <[hidden email]> wrote:
Now I have a new strange issue.   I've been working with my sample program here: https://github.com/Zaaphod/libusbxhid/blob/WHB04B-4/whb04b.pas

And it's been working just fine for me.. just some minor little tweaks and adding new functionality.. etc..  I was just about to start to merge this into my large project when I sent the sample program to my dad... on his system he just gets a screen full of errors... but on mine, it's nice and clean.  I don't understand what is happening.. I reduced my test program down to the most basic sample that demonstrates the issue here:   https://github.com/Zaaphod/libusbxhid/blob/System_Specific_Bug/bugtest.pas

All this program does is checks to see if a specific device exists.. this program works perfectly on 4 computers and has no issue, but on one of my dad's computers I get the following errors:

libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\00000830' is no longer connected!
libusb: error [init_device] device 'USB\VID_1778&PID_0224\40000030' is no longer connected!
libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning.
libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected!


I don't know why Libusb is reporting this, no one tried to open anything so who cares if some devices are not  connected, and how does it know they were connected at one time... this is not even an error..  if it's not connected, just ignore it, nobody cares about that device anyway.   
So I have two questions:
1. any idea why these errors are being generated and how to fix it?
2. Is there a way to turn off libusb errors, info and warnings?

All systems are windows 10 Pro 64 bit, program was compiled for windows 64bit as well.

Here is the complete output with debug info:

K:\ProAuto>bugtest.exe
libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\00000830' is no longer connected!
libusb: error [init_device] device 'USB\VID_1778&PID_0224\40000030' is no longer connected!
libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning.
libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected!
Looking for $10CE, $EB93: DEBUG Found 20 devices attached
DEBUG 1038:1310, bus: 7, address: 6
DEBUG 1002:4399, bus: 10, address: 0
DEBUG 1B21:1142, bus: 3, address: 0
DEBUG 046D:C31C, bus: 7, address: 3
DEBUG 1B21:1142, bus: 1, address: 0
DEBUG 2109:0812, bus: 1, address: 1
DEBUG 2109:2812, bus: 7, address: 2
DEBUG 1002:4397, bus: 6, address: 0
DEBUG 1002:4397, bus: 5, address: 0
DEBUG 0A12:0001, bus: 5, address: 1
DEBUG 2109:2811, bus: 7, address: 9
DEBUG 1002:4397, bus: 9, address: 0
DEBUG 0C45:7403, bus: 7, address: 4
DEBUG 1002:4396, bus: 8, address: 0
DEBUG 1002:4396, bus: 7, address: 0
DEBUG 0E50:0002, bus: 7, address: 7
DEBUG 1B21:1142, bus: 2, address: 0
DEBUG 1002:4396, bus: 4, address: 0
DEBUG 1A40:0101, bus: 7, address: 1
DEBUG 2109:2812, bus: 7, address: 5
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 20 devices
DEBUG USB device list freed. good boy!
FALSE
libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\00000830' is no longer connected!
libusb: error [init_device] device 'USB\VID_1778&PID_0224\40000030' is no longer connected!
libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning.
libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected!
Looking for $10CE, $EB93: DEBUG Found 20 devices attached
DEBUG 1038:1310, bus: 7, address: 6
DEBUG 1002:4399, bus: 10, address: 0
DEBUG 1B21:1142, bus: 3, address: 0
DEBUG 046D:C31C, bus: 7, address: 3
DEBUG 1B21:1142, bus: 1, address: 0
DEBUG 2109:0812, bus: 1, address: 1
DEBUG 2109:2812, bus: 7, address: 2
DEBUG 1002:4397, bus: 6, address: 0
DEBUG 1002:4397, bus: 5, address: 0
DEBUG 0A12:0001, bus: 5, address: 1
DEBUG 2109:2811, bus: 7, address: 9
DEBUG 1002:4397, bus: 9, address: 0
DEBUG 0C45:7403, bus: 7, address: 4
DEBUG 1002:4396, bus: 8, address: 0
DEBUG 1002:4396, bus: 7, address: 0
DEBUG 0E50:0002, bus: 7, address: 7
DEBUG 1B21:1142, bus: 2, address: 0
DEBUG 1002:4396, bus: 4, address: 0
DEBUG 1A40:0101, bus: 7, address: 1
DEBUG 2109:2812, bus: 7, address: 5
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 20 devices
DEBUG USB device list freed. good boy!
FALSE
libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\00000830' is no longer connected!
libusb: error [init_device] device 'USB\VID_1778&PID_0224\40000030' is no longer connected!
libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning.
libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected!
Looking for $10CE, $EB93: DEBUG Found 20 devices attached
DEBUG 1038:1310, bus: 7, address: 6
DEBUG 1002:4399, bus: 10, address: 0
DEBUG 1B21:1142, bus: 3, address: 0
DEBUG 046D:C31C, bus: 7, address: 3
DEBUG 1B21:1142, bus: 1, address: 0
DEBUG 2109:0812, bus: 1, address: 1
DEBUG 2109:2812, bus: 7, address: 2
DEBUG 1002:4397, bus: 6, address: 0
DEBUG 1002:4397, bus: 5, address: 0
DEBUG 0A12:0001, bus: 5, address: 1
DEBUG 2109:2811, bus: 7, address: 9
DEBUG 1002:4397, bus: 9, address: 0
DEBUG 0C45:7403, bus: 7, address: 4
DEBUG 1002:4396, bus: 8, address: 0
DEBUG 1002:4396, bus: 7, address: 0
DEBUG 0E50:0002, bus: 7, address: 7
DEBUG 1B21:1142, bus: 2, address: 0
DEBUG 1002:4396, bus: 4, address: 0
DEBUG 1A40:0101, bus: 7, address: 1
DEBUG 2109:2812, bus: 7, address: 5
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 20 devices
DEBUG USB device list freed. good boy!
FALSE
Heap dump by heaptrc unit of K:\ProAuto\bugtest.exe
685 memory blocks allocated : 33042/37272
685 memory blocks freed     : 33042/37272
0 unfreed memory blocks : 0
True heap size : 163840 (128 used in System startup)
True free heap : 163712

When I run it on any other computer I get:
I:\Programming\Gcode\bug>bugtest.exe
Looking for $10CE, $EB93: DEBUG Found 17 devices attached
DEBUG 8086:A36D, bus: 1, address: 0
DEBUG 8087:0AAA, bus: 1, address: 8
DEBUG 05E3:0612, bus: 1, address: 18
DEBUG 0424:2734, bus: 1, address: 42
DEBUG 1D50:6015, bus: 1, address: 14
DEBUG 05E3:0743, bus: 1, address: 22
DEBUG 1B1C:0C15, bus: 1, address: 9
DEBUG 05E3:0610, bus: 1, address: 21
DEBUG 05E3:0610, bus: 1, address: 6
DEBUG 04E8:61F5, bus: 1, address: 1
DEBUG 1B1C:0C10, bus: 1, address: 7
DEBUG 0424:274C, bus: 1, address: 43
DEBUG 1B1C:1B4F, bus: 1, address: 41
DEBUG 1A40:0101, bus: 1, address: 2
DEBUG 0C45:7403, bus: 1, address: 26
DEBUG 0E50:0002, bus: 1, address: 60
DEBUG 10C4:EA60, bus: 1, address: 4
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 17 devices
DEBUG USB device list freed. good boy!
FALSE
Looking for $10CE, $EB93: DEBUG Found 17 devices attached
DEBUG 8086:A36D, bus: 1, address: 0
DEBUG 8087:0AAA, bus: 1, address: 8
DEBUG 05E3:0612, bus: 1, address: 18
DEBUG 0424:2734, bus: 1, address: 42
DEBUG 1D50:6015, bus: 1, address: 14
DEBUG 05E3:0743, bus: 1, address: 22
DEBUG 1B1C:0C15, bus: 1, address: 9
DEBUG 05E3:0610, bus: 1, address: 21
DEBUG 05E3:0610, bus: 1, address: 6
DEBUG 04E8:61F5, bus: 1, address: 1
DEBUG 1B1C:0C10, bus: 1, address: 7
DEBUG 0424:274C, bus: 1, address: 43
DEBUG 1B1C:1B4F, bus: 1, address: 41
DEBUG 1A40:0101, bus: 1, address: 2
DEBUG 0C45:7403, bus: 1, address: 26
DEBUG 0E50:0002, bus: 1, address: 60
DEBUG 10C4:EA60, bus: 1, address: 4
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 17 devices
DEBUG USB device list freed. good boy!
FALSE
Looking for $10CE, $EB93: DEBUG Found 17 devices attached
DEBUG 8086:A36D, bus: 1, address: 0
DEBUG 8087:0AAA, bus: 1, address: 8
DEBUG 05E3:0612, bus: 1, address: 18
DEBUG 0424:2734, bus: 1, address: 42
DEBUG 1D50:6015, bus: 1, address: 14
DEBUG 05E3:0743, bus: 1, address: 22
DEBUG 1B1C:0C15, bus: 1, address: 9
DEBUG 05E3:0610, bus: 1, address: 21
DEBUG 05E3:0610, bus: 1, address: 6
DEBUG 04E8:61F5, bus: 1, address: 1
DEBUG 1B1C:0C10, bus: 1, address: 7
DEBUG 0424:274C, bus: 1, address: 43
DEBUG 1B1C:1B4F, bus: 1, address: 41
DEBUG 1A40:0101, bus: 1, address: 2
DEBUG 0C45:7403, bus: 1, address: 26
DEBUG 0E50:0002, bus: 1, address: 60
DEBUG 10C4:EA60, bus: 1, address: 4
DEBUG Index of device 4302:60307=-1
DEBUG Freeing device list with 17 devices
DEBUG USB device list freed. good boy!
FALSE
Heap dump by heaptrc unit of I:\Programming\Gcode\bug\bugtest.exe
595 memory blocks allocated : 28731/32376
595 memory blocks freed     : 28731/32376
0 unfreed memory blocks : 0
True heap size : 163840 (160 used in System startup)
True free heap : 163680

James
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: USB Human Interface Devices

Zaaphod
In reply to this post by Zaaphod

Looks like email removed all my linefeeds...
Here is the output with errors on just the one sytem:
https://pastebin.com/axtH3hvn

Here is typical output on all other sytems:
https://pastebin.com/ZaJYU3ak

James

-----Original Message-----
From: fpc-pascal <[hidden email]> On Behalf Of James Richters
Sent: Thursday, August 29, 2019 12:03 PM
To: 'FPC-Pascal users discussions' <[hidden email]>
Subject: Re: [fpc-pascal] USB Human Interface Devices

Now I have a new strange issue.   I've been working with my sample program here: https://github.com/Zaaphod/libusbxhid/blob/WHB04B-4/whb04b.pas 

And it's been working just fine for me.. just some minor little tweaks and adding new functionality.. etc..  I was just about to start to merge this into my large project when I sent the sample program to my dad... on his system he just gets a screen full of errors... but on mine, it's nice and clean.  I don't understand what is happening.. I reduced my test program down to the most basic sample that demonstrates the issue here:   https://github.com/Zaaphod/libusbxhid/blob/System_Specific_Bug/bugtest.pas

All this program does is checks to see if a specific device exists.. this program works perfectly on 4 computers and has no issue, but on one of my dad's computers I get the following errors:

libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\00000830' is no longer connected!
libusb: error [init_device] device 'USB\VID_1778&PID_0224\40000030' is no longer connected!
libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning.
libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected!


I don't know why Libusb is reporting this, no one tried to open anything so who cares if some devices are not  connected, and how does it know they were connected at one time... this is not even an error..  if it's not connected, just ignore it, nobody cares about that device anyway.  
So I have two questions:
1. any idea why these errors are being generated and how to fix it?
2. Is there a way to turn off libusb errors, info and warnings?

All systems are windows 10 Pro 64 bit, program was compiled for windows 64bit as well.

Here is the complete output with debug info:
<snip>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
1 ... 56789