Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread James Richters
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 On Behalf Of Stefan V. Pantazi Sent: Wednesday, August 28, 2019 5:50 PM

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread James Richters
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

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread Stefan V. Pantazi
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

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread Stefan V. Pantazi
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

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread Stefan V. Pantazi
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:

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread James Richters
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

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread 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...

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread James Richters
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

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread Jean SUZINEAU
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:

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread James Richters
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

Re: [fpc-pascal] USB Human Interface Devices

2019-08-28 Thread James Richters
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