Re: usbdevs & hub ports status

2018-07-10 Thread David Bern
On Sun, 8 Jul 2018 22:09:02 +0200 Martin Pieuchot wrote: > On 04/07/18(Wed) 17:00, Martin Pieuchot wrote: > > Diff below adds support for printing USB ports status. It includes an > > ABI change as we currently do not export port status/change to userland. > > > > I'd really like to export the

Re: errors in usage.c - libusbhid

2018-07-04 Thread David Bern
sbhid/usage/parsetest.c --- /dev/null 1 Jan 1970 00:00:00 - +++ libusbhid/usage/parsetest.c 4 Jul 2018 14:33:06 - @@ -0,0 +1,50 @@ +/* $OpenBSD$ */ +/* + * Copyright (c) 2018 David Bern + * + * Permission to use, copy, modify, and distribute this software for any + * purpose wit

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 us

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 /usr/share/misc/usb_hid_usa

Re: errors in usage.c - libusbhid

2018-06-18 Thread David Bern
if (strcmp(pages[k].page_contents[j].name, sep) == 0) return (pages[k].usage << 16) | pages[k].page_contents[j].usage; + } return -1; } 2018-06-15 0:11 GMT+02:00 David Bern : > Thank you mpi for the response. > > I

Re: errors in usage.c - libusbhid

2018-06-17 Thread David Bern
"if (usage_sep != NULL)" instead or what do you think mpi@? 2018-06-15 0:11 GMT+02:00 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 >

Re: errors in usage.c - libusbhid

2018-06-14 Thread David Bern
lt;< 16) | pages[k].page_contents[j].usage; + } return -1; } 2018-06-14 14:54 GMT+02:00 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:

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

Re: errors in usage.c - libusbhid

2018-05-29 Thread David Bern
parsed_usage; + } if (strcmp(pages[k].page_contents[j].name, sep) == 0) return (pages[k].usage << 16) | pages[k].page_contents[j].usage; + } return -1; } comments? o

Re: errors in usage.c - libusbhid

2018-05-28 Thread David Bern
omething like "%s:Button_%d". The last step I use the fmt-string to create a complete string that will result in "Button:Button_1" 2018-05-24 18:44 GMT+02:00 David Bern : > While I was waiting for comments and fe

Re: errors in usage.c - libusbhid

2018-05-24 Thread David Bern
pages[k].page_contents[j].usage; + } return -1; } 2018-05-21 23:12 GMT+02:00 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 > ===

Re: errors in usage.c - libusbhid

2018-05-21 Thread David Bern
uot; .Ft void .Fn hid_init "char *file" .Ft int .Fn hid_start "char *file" -.Ft int +.Ft int32_t .Fn hid_get_data "void *data" "hid_item_t *h" .Ft void -.Fn hid_set_data "void *data" "hid_item_t *h" "u_int data" +.Fn hid_set_data

errors in usage.c - libusbhid

2018-05-18 Thread David Bern
quot; I would love to get as much feedback as possible so I can work on delivering a desirable and usable patch in my first try. As to the "factual" misses in the man-page, I found two prototype declarations that differs from the header file. Intend to send a man-page diff on the ones that I have bumped into. /David Bern