Re: errors in usage.c - libusbhid

2018-07-04 Thread David Bern
On Tue, 3 Jul 2018 07:55:47 +0200 Martin Pieuchot wrote: > > > > If wanted I can send the code I used to test this. > > It would be great if you could turn that into a regression test to put > in /usr/src/regress/lib/libusbhid/nameofyourtest :) Sure. Should say that my Bourne shell &

Re: errors in usage.c - libusbhid

2018-07-02 Thread Martin Pieuchot
On 02/07/18(Mon) 23:08, David Bern wrote: > > Is it necessary to parse these examples? Or maybe we can live with > > your strtonum() fix for now. > I can live with that. > > > I don't know. So unless somebody else gives us some input I'd suggest > > we move forward with your safe diff even if

Re: errors in usage.c - libusbhid

2018-07-02 Thread David Bern
> Is it necessary to parse these examples? Or maybe we can live with > your strtonum() fix for now. I can live with that. > I don't know. So unless somebody else gives us some input I'd suggest > we move forward with your safe diff even if it doesn't fix all the > cases. > > If it fixes your

Re: errors in usage.c - libusbhid

2018-07-01 Thread Martin Pieuchot
On 30/06/18(Sat) 23:47, David Bern wrote: > > Note that your diff doesn't apply. You have tab vs spaces issues. > Sorry about that, it seems like I need to setup a proper mail-client. > > > I don't understand what you're talking about. Can you give example of > > the 3 scenarios you're talking

errors in usage.c - libusbhid

2018-06-30 Thread David Bern
> Note that your diff doesn't apply. You have tab vs spaces issues. Sorry about that, it seems like I need to setup a proper mail-client. > I don't understand what you're talking about. Can you give example of > the 3 scenarios you're talking about. If you look inside

Re: errors in usage.c - libusbhid

2018-06-18 Thread David Bern
I take back my previous answer to this question: > Are you sure the name always contain an underscore? Can't it be > "Button:Button42" ? In my previous response I had only discovered three cases of usage -1. I took another look and discovered that there indeed is a scenario as you mention other

Re: errors in usage.c - libusbhid

2018-06-17 Thread David Bern
I have given the following part some more thought > + us = pages[k].page_contents[j].usage; > + if (us == -1) { > + usage_sep = strchr(sep, '_'); > + if (usage_sep == NULL) > + return -1; As I

Re: errors in usage.c - libusbhid

2018-06-14 Thread David Bern
Thank you mpi for the response. I will try to answer to the best of my knowledge. > Are you sure the name always contain an underscore? Can't it be > "Button:Button42" ? It depends. At the moment it is dictated by the default page /usr/share/misc/usb_hid_usages and the name looks more like

Re: errors in usage.c - libusbhid

2018-06-14 Thread Martin Pieuchot
On 29/05/18(Tue) 22:29, David Bern wrote: > Sorry for the spamming. > After some research and finding that my fix for issue nr: 2 ( > hid_usage_in_page() ) > will break the functionality inside /usr.bin/usbhidaction/usbhidaction.c > https://goo.gl/1cWFtR (link to usbhidaction.c) > > I now change

Re: errors in usage.c - libusbhid

2018-06-11 Thread David Bern
Bump. This patch fixes "runtime" error in libusbhid when parsing usage strings with usage defined in default usbhid table as a format string. On Tue, May 29, 2018, 10:29 PM David Bern wrote: > Sorry for the spamming. > After some research and finding that my fix for issue nr: 2 ( >

Re: errors in usage.c - libusbhid

2018-05-29 Thread David Bern
Sorry for the spamming. After some research and finding that my fix for issue nr: 2 ( hid_usage_in_page() ) will break the functionality inside /usr.bin/usbhidaction/usbhidaction.c https://goo.gl/1cWFtR (link to usbhidaction.c) I now change my patch to only include a fix for issue nr: 1 More

Re: errors in usage.c - libusbhid

2018-05-28 Thread David Bern
I was suggested off list to give an explanation on what the patch does. So please, tell me if I need to clarify more, or make further changes to the code. The patch tries to fix two things. 1. Changes in hid_parse_usage_in_page() fixes problems in parsing usages defined as: * Button %d

Re: errors in usage.c - libusbhid

2018-05-27 Thread Jason McIntyre
On Mon, May 21, 2018 at 11:12:37PM +0200, David Bern wrote: > First diff "solves" point 1 & 2. Second diff is on the parts of the manual > that does not match the usbhid.h > i've committed the man part - i have to leave the rest for someone else to hopefully pick up. jmc > Index: usage.c >

Re: errors in usage.c - libusbhid

2018-05-24 Thread David Bern
While I was waiting for comments and feedback I came up with some improvements. The "logic" is still the same, but the execution is hopefully more sane. Index: usage.c === RCS file: /cvs/src/lib/libusbhid/usage.c,v retrieving

Re: errors in usage.c - libusbhid

2018-05-21 Thread David Bern
First diff "solves" point 1 & 2. Second diff is on the parts of the manual that does not match the usbhid.h Index: usage.c === RCS file: /cvs/src/lib/libusbhid/usage.c,v retrieving revision 1.16 diff -u -p -r1.16 usage.c --- usage.c

Re: errors in usage.c - libusbhid

2018-05-21 Thread Martin Pieuchot
On 18/05/18(Fri) 10:01, David Bern wrote: > Hello! > > Have been using libusbhid and discovered a couple of discrepancies in > the man-page (libusbhid.3) and the source of usage.c > > Some are just factual misses, but I also got (what I think is) 2 errors. > I will try to explain them; > > 1.

errors in usage.c - libusbhid

2018-05-18 Thread David Bern
Hello! Have been using libusbhid and discovered a couple of discrepancies in the man-page (libusbhid.3) and the source of usage.c Some are just factual misses, but I also got (what I think is) 2 errors. I will try to explain them; 1. (This is the I think is an error but not sure). The man-page