[fpc-pascal] USB Human Interface Devices

James Richters james at productionautomation.net
Thu Aug 29 20:40:58 CEST 2019


Yes, that makes sense.. probably best not to over complicate it.  

 

James

 

From: fpc-pascal <fpc-pascal-bounces at lists.freepascal.org> On Behalf Of Stefan V. Pantazi
Sent: Thursday, August 29, 2019 2:18 PM
To: FPC-Pascal users discussions <fpc-pascal at lists.freepascal.org>
Subject: Re: [fpc-pascal] USB Human Interface Devices

 

I see your point. But since libusbhid is mostly a wrapper library, its messages are going to be a higher level of debugging anyway - mostly related to how you handle a particular device. So once you are confident that things are working for your device, turning debug off completely seems the way to go, programs will be smaller and faster (no continuous checking for debug messages are to be displayed). If bugs or problems resurface, the underlying libusb is going to yell at you anyway. Alternatively, you can just compile one release and one debug version of your executable.

 

On Thu, Aug 29, 2019 at 1:21 PM James Richters <james at productionautomation.net <mailto:james at productionautomation.net> > wrote:

Yes, and besides the errors, everything else seems to work properly.   I did notice that the one machine uses an AMD processor and all the others are Intel,  not sure what that would have to do with anything, but it is a major system configuration difference.

 

Thanks for the debug level information.  I will probably just shut off all messages but it would be nice to have a way to turn them on if I need to debug something on a remote system.  

 

How about the libusbxhid debug messages?   Since they are controlled with {$ifdef DEBUG_MSG} you can’t really turn them on and off without re-compiling.  Could another variable be used to make libusbxhid messages optional but only if {$ifdef DEBUG_MSG} is used?   It would be helpful to be able to hide them most of the time but show them if trying to debug without re-compiling.

 

James

 

From: fpc-pascal <fpc-pascal-bounces at lists.freepascal.org <mailto:fpc-pascal-bounces at lists.freepascal.org> > On Behalf Of Stefan V. Pantazi
Sent: Thursday, August 29, 2019 1:11 PM
To: FPC-Pascal users discussions <fpc-pascal at lists.freepascal.org <mailto:fpc-pascal at lists.freepascal.org> >
Subject: Re: [fpc-pascal] USB Human Interface Devices

 

I would chalk this up to differences between OS versions, configurations, devices, etc and move on. I see all memory is released. At  least it does not crash and burn badly. 

 

The function call you want to play with is:

libusb_set_debug

http://libusb.sourceforge.net/api-1.0/group__lib.html#ga5f8376b7a863a5a8d5b8824feb8a427a

 

Of course, you can set the level dynamically, from your program.

 

 

 

On Thu, Aug 29, 2019 at 12:34 PM James Richters <james at productionautomation.net <mailto:james at productionautomation.net> > wrote:

At least I can shut off the messages with that.. but any idea what these messages actually mean?   It’s an init_device error but no one was tying to do anything but get the list of devices from the system.

 

Is there a description of the verbosity level anywhere?

 

Is this a variable I can change during program execution without re-compiling it?  It would be helpful if I was having an issue to turn on debug info, then turn it back off without exiting my program or needing to compile.

 

James

 

 

>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.

_______________________________________________
fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org <mailto:fpc-pascal at lists.freepascal.org> 
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org <mailto:fpc-pascal at lists.freepascal.org> 
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20190829/04c2f8a2/attachment-0001.html>


More information about the fpc-pascal mailing list