similar to: USB HID Spec help (passing strings)

Displaying 20 results from an estimated 10000 matches similar to: "USB HID Spec help (passing strings)"

2015 Aug 31
2
USB HID Spec help (passing strings)
iSerialNumber does not need to be unique per device - it is not very many bits wide. I?m pretty sure I don?t *need* iSerialNumber?I mean, I could just remove it from the report descriptor altogether. But since it is available to give, and we are writing each board?s serial number into flash as part of the micro-controller programming (we aren?t talking a staggering number of boards per year
2015 Sep 02
1
USB HID Spec help (passing strings)
No, just as a variable string descriptor. By ?variable string descriptor?, do you mean what is contained in the example in the App Note? I?m just asking for clarification, in case variable string descriptor is something different than shown there. The way they do the string descriptors in the example is how I have mine now. They return a size and address, but it is to something that was
2015 Sep 16
2
UPS/NUT with openSUSE 13.1
I found something particularly strange while trying out different things: I started up upsdrvctl, upsd, and upsmon. I then stopped upsdrvctl, and tried starting the usbhid-ups driver a few times. Each time I executed the driver, it indicated an instance was already running, stopped it, and then started it again....which is what it should do. I then added -DDDD to the command....and then it
2015 Sep 09
6
UPS/NUT with openSUSE 13.1
On Sep 9, 2015, at 9:40 AM, Rob Groner <rgroner at RTD.com> wrote: > > I'm not sure which USB lib it compiled against. What does this return? ldd /path/to/driver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150909/ba08f4c0/attachment.html>
2015 Sep 09
3
UPS/NUT with openSUSE 13.1
> On Sep 9, 2015, at 10:12 AM, Rob Groner <rgroner at RTD.com> wrote: > > linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups > linux-vdso.so.1 (0x00007fff403fc000) > libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f7c34b56000) The last line seems to indicate that it is the real libusb-0.1, not -compat. What kernel version on openSUSE? --
2015 Sep 22
2
UPS/NUT with openSUSE 13.1
For fun, if you want to see where the system thinks it is linking a library from, you can use "ldconfig -p" and it will give you a path to all known libraries that it can find. If you have one loaded, and it can't find it (odd directory, etc.) you can always amend "LD_LIBRARY_PATH" the same way as PKG_CONFIG_PATH I mentioned earlier . . . . PKG . . . is for the build
2015 Sep 10
3
UPS/NUT with openSUSE 13.1
On Sep 10, 2015, at 8:49 AM, Rob Groner <rgroner at RTD.com> wrote: > > Charles, > > 3.16.6.-2-desktop I think that corresponds to this file: http://lxr.free-electrons.com/source/drivers/usb/core/devio.c?v=3.16 (but I don't see anything obvious there) What does "lsusb -vvv -d 2a37:" return? Usually I'd say run that as root when the driver isn't running,
2015 Mar 20
5
UPS commands
I'm doing testing of the UPS-side code, including being able to tell the UPS to shutdown and then come back up after a while (if power has returned). I'm trying to use upscmd so that I don't have to do an actual shutdown, but when I have it list the commands for my UPS, I just see 4 commands, and they're not the ones I thought I had specified. load.on load.off shutdown.return
2015 Sep 22
2
UPS/NUT with openSUSE 13.1
Rob - Just stepping in from the sidelines . . . with a few tidbits. Nut uses pkgconfig to find and identify stuff as part of it's build . . . So, depending on where your libusb install went, if it wasn't in the default "PKG_CONFIG_PATH" setting, it won't be found. Much like other shell variables, you can adjust that setting to find anything you like . . . IE
2015 Jul 07
4
upsd not starting sometimes (Porteus 3.1, nut 2.7.2)
I am running tests on my system and UPS, making sure that it is reliably able to come up, detect power loss, shutdown safely, and then come back up when the power returns. It does that MOST of the time. However, a significant part of the time, the system comes up, and then doesn't respond to loss of power. Doing some checking, I find that the reason is because upsd never started. Capturing
2015 Sep 24
2
UPS/NUT with openSUSE 13.1
And now....suddenly, and so far unexplainably....it works again. I did the same as before, installed openSUSE 13.1 from scratch, then installed the libusb* libraries. And now...it works, so far reliably. I'm certain that there is some micro-step I started doing different than last time. For example, I used to install jedit from the command line after install, but I had started installing
2015 Mar 09
2
Install problems (group permissions) with nut 2.7.2
Ok, I tried this from scratch on a fresh 2.7.2 directory. I followed the web instructions, specifically: + I generated the new subdriver for my UPS (rtd-hid.*) based on PATH info. + I put them in the drivers subdir + I added the include line (#include rtd-hid.h) in usbhid-ups.c (specifically in the #ifndef SHUT_MODE section) + I added &rtd_subdriver, to the subdriver_list in usbhid-ups.c
2015 Sep 08
3
UPS/NUT with openSUSE 13.1
On Tue, 8 Sep 2015, Rob Groner wrote: > I executed lsusb to verify the USB device is there, and it is. I tried > the shutdown command again with debug enabled, but it didn't seem to > reveal much more: > ----------------------------------------------------------------------------------------------- > rtd at linux-5048:~> sudo /usr/local/ups/sbin/upsdrvctl -DDDDD shutdown
2015 Sep 18
2
UPS/NUT with openSUSE 13.1
On Sep 18, 2015, at 2:45 PM, Rob Groner <rgroner at RTD.com> wrote: > > Well, I've spent a couple hours on this, unable to figure it out. I removed the libusb-compat-devel package using zypper. And I've downloaded, built, and installed libusb from sourceforge. But trying to configure nut now I get "USB drivers requested, but libusb not found", no matter what I put
2015 Aug 31
0
USB HID Spec help (passing strings)
On Aug 31, 2015, at 9:01 AM, Rob Groner <rgroner at RTD.com> wrote: > > iSerialNumber does not need to be unique per device - it is not very many bits wide. > > I?m pretty sure I don?t *need* iSerialNumber?I mean, I could just remove it from the report descriptor altogether. But since it is available to give, and we are writing each board?s serial number into flash as part of
2015 Sep 08
2
UPS/NUT with openSUSE 13.1
On Sep 8, 2015, at 4:48 PM, Rob Groner <rgroner at RTD.com> wrote: > > 0.005927 Device matches > 0.005940 failed to claim USB device: Device or resource busy > 0.005954 failed to detach kernel driver from USB device: No such file or directory Rob, this is a bit of a tough one to track down. The "Device or resource busy" message can either come from a kernel
2015 Aug 28
0
USB HID Spec help (passing strings)
On Aug 28, 2015, at 2:21 PM, Rob Groner <rgroner at RTD.com> wrote: > > We?re wrapping up our first version of the UPS we?re making, and so I?m going over the USB code and came across one loose end. The serial number of the unit (iSerialNumber according to the USB HID doc) is a constant, but it?s of course a different constant for each UPS. iSerialNumber does not need to be unique
2015 Mar 20
0
UPS commands
Hi Rob I still have an unset draft answer to your previous mail... but you seem to have progressed... 2015-03-20 16:32 GMT+01:00 Rob Groner <rgroner at rtd.com>: > I?m doing testing of the UPS-side code, including being able to tell the > UPS to shutdown and then come back up after a while (if power has returned). > > > > I?m trying to use upscmd so that I don?t have to
2015 Mar 10
4
Install problems (group permissions) with nut 2.7.2
On Mar 9, 2015, at 12:00 PM, Rob Groner <rgroner at RTD.com> wrote: > 1) Autoreconf *must* be run, and not ./configure? I had thought that putting in my *.c and *.h files and making the makefile changes and then executing ./configure for the first time would be enough. Each tool serves a different purpose. autoreconf (and NUT's autogen.sh, by inclusion) generates the ./configure
2015 Sep 21
3
UPS/NUT with openSUSE 13.1
On Sep 21, 2015, at 9:39 AM, Rob Groner <rgroner at RTD.com> wrote: > > I didn't think to look for a log (attached), but now looking in it, I don't see anything more than I already thought I knew. It's as cryptic as configure itself. > > It does reference the line in the configure where the test for USB failed, but I'd already been looking in there. I