[fpc-pascal] USB Human Interface Devices

Stefan V. Pantazi svpantazi at gmail.com
Thu Aug 29 20:18:13 CEST 2019


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> 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> *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>
> *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> 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
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
> _______________________________________________
> fpc-pascal maillist  -  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/71e086bc/attachment.html>


More information about the fpc-pascal mailing list