similar to: usb_device_id_t structure

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Mon Nov 24 13:13:44 2008 > New Revision: 1578 > > Log: > Use new usb_device_id_t and is_usb_device_supported() > for selection of the subdriver. Alexander, It would be nice if you could double check that I didn't horribly break something here. I don't expect any

Hi all, I attached a driver for MiniBox openUPS device ( http://www.mini-box.com/OpenUPS) and a dump of the hid usages. I had the possibility to make a few adjustments to the device firmware for HID usages, and although I haven't managed to produce a good structure many issues from previous firmware were at least fixed and new information added. ATM the driver only shows pertaining

On Wed, 2011-09-14 at 12:25 +0000, Charles Lepple wrote: > Author: clepple-guest > Date: Wed Sep 14 12:25:03 2011 > New Revision: 3226 > URL: http://trac.networkupstools.org/projects/nut/changeset/3226 > > Log: > Include <string.h> for nut-scanner > > Modified: > trunk/tools/nut-scanner/scan_snmp.c > trunk/tools/nut-scanner/scan_usb.c > >

These patches allow this device to function in nut.. diff --git a/trunk/drivers/tripplite-hid.c b/new/drivers/tripplite-hid.c index c36da98..dddd13c 100644 --- a/trunk/drivers/tripplite-hid.c +++ b/new/drivers/tripplite-hid.c @@ -71,6 +71,8 @@ static usb_device_id_t tripplite_usb_device_table[] = { { USB_DEVICE(TRIPPLITE_VENDORID, 0x2005), battery_scale_0dot1 }, /* e.g. TrippLite

I don't understand how the info_len element from the hid_info_t structure is used in usbhid-ups. It appears to me that the only use of this element is now to indicate the length of the string: > float info_len; /* if ST_FLAG_STRING: length of the string */ The above is clear, if the element is flagged as a string, the size of this string is put in this variable, so that we can use this in

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Sun Nov 16 13:00:30 2008 > New Revision: 1560 > > Log: > Generated by libtool and should not be versioned. > > Modified: > trunk/ (props changed) Right, that didn't work out quite the way I intended. Can someone please set the svn:ignore property on

Citeren Arjen de Korte <adkorte-guest op alioth.debian.org>: > Log: > Use the 'nss_compat_ossl' compatibility layer to use the Mozilla NSS > library instead of OpenSSL (we might want to include native support > in the future, but this will at least allow a quick migration for > testing purposes) I don't recall that we ever discussed the possibility of

Arnaud, If memory serves, you're the one that 'invented' the upsdrv_info_t subdriver description structure. We seem to have an issue with this on Solaris. I suspect that we're introducing GCC specific behavior here. Technically the typedef here isn't possible in C89, since this suggests that sizeof(upsdrv_info_t) can be determined. This obvious is not the case, since

On 13. Aug 2020, at 11.29, Timo Sirainen <timo at sirainen.com> wrote: > > On 13. Aug 2020, at 11.00, Arjen de Korte <build+dovecot at de-korte.org> wrote: >> >> I allow users to run 'doveadm' for mailbox maintenance (to expunge mail for instance). Since the upgrade to 2.3.11.3, this no longer works and results in the following error message: >>

Charles, I was looking into why CGI isn't build on the Ubuntu box. Although everything seems to be available, it is currently showing checking for gd version via gdlib-config... 2.0.35 checking for gd include flags... -I/usr/include checking for gd library flags... -L/usr/lib -Wl,-Bsymbolic-functions -ljpeg -lfreetype -lpng12 -lz -lm checking for gd.h... yes checking for gdfontmb.h...

I allow users to run 'doveadm' for mailbox maintenance (to expunge mail for instance). Since the upgrade to 2.3.11.3, this no longer works and results in the following error message: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 13: ssl_key: Can't open file /etc/ssl/private/de-korte.org.key: Permission denied This is no surprise, as

I have the following UPS that I'm trying to get to work with NUT: SU3000RTXL3U I have it connected via USB. My ups.conf looks like: [test] driver = usbhid-ups vendorid = 09ae port = auto When I run upsdrvctl -DD start, I get: Network UPS Tools - UPS driver controller 2.4.1 Starting UPS: test exec: /lib/nut/usbhid-ups -a test Network UPS Tools - Generic HID driver 0.34 (2.4.1)

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Thu Jan 15 11:54:05 2009 > New Revision: 1728 > > Log: > Another stab at this. > > Modified: > trunk/tools/Makefile.am And failing miserably... :-( Can someone more fluent in 'autotoolish' fix this problem? Currently the BuildBot is broken by update r1718

Citeren Arnaud Quette <aquette op alioth.debian.org>: > Author: aquette > Date: Sat Dec 11 12:31:21 2010 > New Revision: 2731 > URL: http://trac.networkupstools.org/projects/nut/changeset/2731 > > Log: > Complete the list of Subversion ignored files, with AsciiDoc > generated contents (no functional changes) Is there a particular reason for having both the man/

On Thu, Aug 13, 2020 at 21:16:42 +0200, Arjen de Korte wrote: > Citeren Timo Sirainen <timo at sirainen.com>: > > !include_try ssl-keys.conf > > That will only work to include an optional configuration file and > suppress errors if it doesn't exist. I put > > ssl_key = </etc/ssl/private/de-korte.org.key > > in a separate configuration file and it

Dear Sirs, First of all I would like to thank you for support PCM product in your project. Kindly please be informed that POWERCOM launch new USB-controller with productID 0X04. Updated USB-controller compatible with previous version which supported by your usbhid-ups driver. There is added some command and changed idProduct. Vendor ID stay the same 0X0d9f without changes. Detailed information

I guess this means we won't have access to SVN, right? Is there a timeline available when this will be fixed? Sadly enough, my keys were generated on an openSUSE system and are probably not affected by this vulnerability anyway. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 -------------- next part -------------- An

THANKS, but the 'megatec' driver only works whith windows OS via USB, and i need it for red hat OS with USB-serial connection... Please, anybody can help me.... nut-upsuser-request@lists.alioth.debian.org escribi?: Send Nut-upsuser mailing list submissions to nut-upsuser@lists.alioth.debian.org To subscribe or unsubscribe via the World Wide Web, visit

I would like to report a working device to add to the hardware compatibility list, but cannot find a way on the website. Would this list be OK for that purpose? Best regards, Ernest

Citeren Arnaud Quette <aquette.dev at gmail.com>: > Author: aquette > Date: Sat Nov 15 22:47:26 2008 > New Revision: 1557 > > Log: > GNU libtool update > > Modified: > trunk/ChangeLog > trunk/configure.in > trunk/ltmain.sh I think 'ltmain.sh' is a generated file (at least, I hope it is), this change severely broke compilation here. I had to