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 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#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 - 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
Re: [fpc-pascal] USB Human Interface Devices
I finally have this working fairly well. I used Stefan's sample program as a
guide and used classes to define my thread... and that seemed to solve the
crashing issue I was having when trying to write to the LCD from outside the
fast read thread. Here is the current version:
https://github.com/Zaaphod/libusbxhid/blob/Test/WHB04B-4_test.pas
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
$7FFF18A2DF23
$7FFF189E9BBC
$7FFF189E9AD0
$0001DCDA
$0001D54B
$0001218B PROCESS_USB_DATA, line 475 of WHB04B-4_test.pas
$00012B37 SIMPLETERMINAL, line 641 of WHB04B-4_test.pas
$00012DDD USE_MPG_DEVICE, line 675 of WHB04B-4_test.pas
$00012F93 main, line 699 of WHB04B-4_test.pas
$00012FE6
$000100011350
$00011980
$7FFF17B47E94
$7FFF18A4A251
Line 475 isEnterCriticalsection(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.
Also, there are two versions of this device, once is hard wired to the USB
port, the other is wireless. They both have power buttons on them. When I
turn off the power button on the wireless version, the transceiver still
plugged into the USB port just reports that the device is turned off.. but the
hard wired version just basically unplugs it from the USB port. When this
happens, my read loop generates:
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.
Any ideas?
James
-Original Message-
From: fpc-pascal 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#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 - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
--
___
___
Re: [fpc-pascal] how to convert JNByteBuffer variable type to type usable by fw.write
Thank you very much for yours kind acces to my plea. The question is, if compiled Android app by using FPCJVM Android target mode will be able to communicate with .so library with bass.so which will receive The stream from The internet and record received live stream input and store it to The phone flash storage. If it will not crash, bbecause I will not be able to use Java multi threading mode. What do you think? The author of bass library for Android have confirmed Me, that I can really record The content of variable from downloadproc. The only condition is, that buffer must have non zero lenght. So my way is good. I will try to analyse deeply Android APIS to call methods, which Java programmers uses by mporting .jar libraryes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Hello,
here's a minimal Pascal program to call XGetWindowProperty:
https://www.syncovery.com/minimalxtest.pas
Cheers,
Tobias
On Mon, 26 Aug 2019 23:22:01 +0200
Pierre Muller wrote:
>
>
> Le 26/08/2019 à 22:46, tobiasgie...@gmail.com a écrit :
> > Hi Jonas,
> >
> > fantastic, that looks great. I think now I can just wait until Pierre
> > Muller's snapshot is updated :=)
>
>
> As I followed the thread, I made a special issue for you,
> you should find the new snapshot of ftp site:
>
>
> $ cat ftp/snapshot/trunk/powerpc64-linux/README-powerpc64-linux
> This snapshot was generated 2019-08-26 using:
> make distclean singlezipinstall SNAPSHOT=1 NOGDB=1 DEBUG=1 NOWPOCYCLE=1 OPT="
> -Fl/usr/lib64 -Fl/lib64 -Fd -Fl/usr/lib/gcc/ppc64le-redhat-linux/4.8.5"
> started using /home/muller/pas/fpc-3.3.1/bin/ppcppc64
> ppcppc64 -iVDW output is: 3.3.1 2019/08/26 3.3.1
>
> uname -a of the machine is:
> Linux gcc2-power8.osuosl.org 3.10.0-957.10.1.el7.ppc64le #1 SMP Thu Mar 14
> 11:25:48 GMT 2019 ppc64le ppc64le ppc64le GNU/Linux
>
> "svnversion -c ." output is: 1:1415
>
> "svnversion -c fpcsrc" output is: 1:42841M
>
> Enjoy,
>
> Pierre Muller
>
> PS: note that I do have local modifications that I did not have time to
> really check...
> Most are probably not significant, but:
>
> [muller@gcc2-power8 fpcsrc]$ svn diff
> Index: rtl/linux/ostypes.inc
> ===
> --- rtl/linux/ostypes.inc (revision 42841)
> +++ rtl/linux/ostypes.inc (working copy)
> @@ -170,8 +170,8 @@
> FLock = Record
> l_type : cshort; { lock type: read/write, etc. }
> l_whence: cshort; { type of l_start }
> -l_start : kernel_off_t; { starting offset }
> -l_len : kernel_off_t; { len = 0 means until end of file }
> +l_start : off_t;{ starting offset }
> +l_len : off_t;{ len = 0 means until end of file }
> l_pid : pid_t;{ lock owner }
> {$if defined(cpusparc) or defined(cpusparc64)}
> __pad : cshort;
> @@ -386,7 +386,7 @@
>RLIMIT_LOCKS = 10;{ maximum file locks held }
>
> type
> - rlim_t = cULong;
> + rlim_t = cULongLong;
>PRLimit = ^TRLimit;
>TRLimit = record
> rlim_cur : rlim_t;
> Index: rtl/linux/powerpc/stat.inc
> ===
> --- rtl/linux/powerpc/stat.inc (revision 42841)
> +++ rtl/linux/powerpc/stat.inc (working copy)
> @@ -35,9 +35,9 @@
> st_rdev : culonglong;
> __pad2_: cushort;
> st_size : clonglong;
> -st_blksize: clong;
> +st_blksize: blksize_t;
>
> -st_blocks : clonglong;
> +st_blocks : culonglong;
> st_atime : clong;
> st_atime_nsec : culong;
> st_mtime : clong;
> Index: rtl/linux/powerpc64/stat.inc
> ===
> --- rtl/linux/powerpc64/stat.inc(revision 42841)
> +++ rtl/linux/powerpc64/stat.inc(working copy)
> @@ -43,5 +43,7 @@
>st_mtime_nsec : cULong;
>st_ctime : cULong;
>st_ctime_nsec : cULong;
> - __unused : array[0..2] of cULong;
> + __unused4 : culong;
> + __unused5 : culong;
> + __unused6 : culong;
>end;
> Index: rtl/linux/ptypes.inc
> ===
> --- rtl/linux/ptypes.inc(revision 42841)
> +++ rtl/linux/ptypes.inc(working copy)
> @@ -206,7 +206,7 @@
> bfree, { free blocks in system }
> bavail,{ Available free blocks to non-root users }
> files, { File nodes in system }
> -ffree : culong; { Free file nodes in system }
> +ffree :{$ifdef cpupowerpc}culonglong{$else}culong{$endif}; { Free
> file nodes in system }
> fsid: array[0..1] of cint; { File system ID }
> namelen, { Maximum name length in system }
> frsize : cint;
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Kind Regards,
Tobias Giesen
Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
48143 Münster, Germany
www.superflexible.com
www.tgtools.com
---
Registered at register court Münster as HRA 9716
Liability / general partner: TGTools GmbH
Registered at register court Münster as HRB 17763
Directors: Tobias Giesen and Claudia Giesen
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Am 27. August 2019 15:03:46 schrieb tobiasgie...@gmail.com: > Hello, > > yes I will send you a minimal program to call XGetWindowProperty. > > Cheers, > Tobias > > > > On Tue, 27 Aug 2019 11:35:01 +0200 > Pierre Muller wrote: > >> Hi, >> >> >> the testsuite results show no difference, >> this probably means that we have no test that checks >> GCC compatibility for more than 8 parameters... >> >> >> Tobias, could you send us a small source that allows to check this? I think we should extend tcalext with a test for more parameters. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Hello, yes I will send you a minimal program to call XGetWindowProperty. Cheers, Tobias On Tue, 27 Aug 2019 11:35:01 +0200 Pierre Muller wrote: > Hi, > > the testsuite results show no difference, > this probably means that we have no test that checks > GCC compatibility for more than 8 parameters... > > Tobias, could you send us a small source that allows to check this? > > Thanks in advance, > > Pierre > > > Le 26/08/2019 à 00:59, tobiasgie...@gmail.com a écrit : > > Hello, > > > > while examining a crash when running Lazarus on ppc64le, I found the > > following issue in function calls. > > > > Calls to functions with more than eight parameters seem to be > > implemented differently from how gcc does it in a C program. > > > > gcc uses the memory location 96(r1) for the ninth parameter, but FPC > > uses 112(r1). > > > > Therefore, calls to XGetWindowProperty crash. This function has 12 > > parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), > > 120(r1), > > and FPC into 112(r1), 120(r1), 128(r1), 136(r1). > > > > What can be done about this? > > > > I also noticed that the "file" command in Linux mentioned an additional > > property of the linked C program I wrote for testing: > > "for GNU/Linux 3.10.0" > > > > The FPC program did not have this tag. > > > > The complete "file" outputs are: > > > > a.out: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version > > 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, > > BuildID[sha1]=6c5d2b5c7408e74eeda95fbf8d120fe8de0f2f30, for GNU/Linux > > 3.10.0, with debug_info, not stripped > > > > minimalxcrash: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, > > version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, with > > debug_info, not stripped > > > > Hoping my find will be useful, > > Best wishes, > > Tobias Giesen > > > > ___ > > 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 Kind Regards, Tobias Giesen Super Flexible Software GmbH & Co. KG Buddenstr. 29-31 48143 Münster, Germany www.superflexible.com www.tgtools.com --- Registered at register court Münster as HRA 9716 Liability / general partner: TGTools GmbH Registered at register court Münster as HRB 17763 Directors: Tobias Giesen and Claudia Giesen ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Hi, the testsuite results show no difference, this probably means that we have no test that checks GCC compatibility for more than 8 parameters... Tobias, could you send us a small source that allows to check this? Thanks in advance, Pierre Le 26/08/2019 à 00:59, tobiasgie...@gmail.com a écrit : > Hello, > > while examining a crash when running Lazarus on ppc64le, I found the > following issue in function calls. > > Calls to functions with more than eight parameters seem to be > implemented differently from how gcc does it in a C program. > > gcc uses the memory location 96(r1) for the ninth parameter, but FPC > uses 112(r1). > > Therefore, calls to XGetWindowProperty crash. This function has 12 > parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), > 120(r1), > and FPC into 112(r1), 120(r1), 128(r1), 136(r1). > > What can be done about this? > > I also noticed that the "file" command in Linux mentioned an additional > property of the linked C program I wrote for testing: > "for GNU/Linux 3.10.0" > > The FPC program did not have this tag. > > The complete "file" outputs are: > > a.out: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version > 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, > BuildID[sha1]=6c5d2b5c7408e74eeda95fbf8d120fe8de0f2f30, for GNU/Linux > 3.10.0, with debug_info, not stripped > > minimalxcrash: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, > version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, with > debug_info, not stripped > > Hoping my find will be useful, > Best wishes, > Tobias Giesen > > ___ > 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
