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 <fpc-pascal-boun...@lists.freepascal.org> On Behalf Of James
Richters
Sent: Wednesday, August 28, 2019 5:03 AM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
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 <fpc-pascal-boun...@lists.freepascal.org> On Behalf Of Stefan
V. Pantazi
Sent: Tuesday, August 27, 2019 10:35 PM
To: fpc-pascal@lists.freepascal.org
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 <fpc-pascal-boun...@lists.freepascal.org> On Behalf
Of Stefan V. Pantazi
Sent: Friday, August 23, 2019 10:54 AM
To: fpc-pascal@lists.freepascal.org
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 - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
_______________________________________________________
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
_______________________________________________________
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
_______________________________________________________
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
