Ladies and Gentlemen, I have been playing around with Arnaud's new HAL stuff a bit, and have some questions and observations. First my configuration: my UPS (Peter may remember): ups.mfr: APC ups.model: Back-UPS ES 650 ups.productid: 0002 ups.firmware: 818.w1.D ups.firmware.aux: w1 kernel: 2.6.18-92.1.6.el5 hal-0.5.8.1-35.el5, nut based on nut-2.2.2.tar.gz, small changes to make build work I am currently running with this configuration, and everything seems to be working, except some of the hal interface stuff, which I know is still a work in progress, and so I enable the hal part only when playing around with it. I see a lot of kernel warnings because there are two processes that access the device like this: usbfs: process 19727 (usbhid-ups) did not claim interface 0 before use usbfs: process 19862 (hald-addon-usbh) did not claim interface 0 before use My question: is this due to my kernel version, the version of my libusb (libusb-0.1.12-5.1), or do I need a more up-to-date version of drivers/libusb.c? When I make a change to a HID variable that is marked as HU_FLAG_SEMI_STATIC using upsrw (e.g. battery.charge.low), the value is changed in the device (and shows changed with e.g. upsc), but the hal side never knows about the change (e.g. when looking at the hal data with hal-device-manager). I believe this is because the variable "data_has_changed" in the hald-addon version of the driver is never set, and so the value is never read from the device. Also, when I make a change on the hal side to such a variable (using /usr/bin/hal-set-property) the change happens on the hal side (as seen with hal-device-manager), but the change seems to be never propagated to the device. Here I presume the absence of any calls to "upsh.setvar()" in main-hal.c or dstate-hal.c means that things are just not done yet. Any suggestions would be appreciated. Thanks, AG -- ---------------------------------------------------------------------- Alfred Ganz alfred-ganz:at:agci.com AG Consulting, Inc. (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ----------------------------------------------------------------------
[...]> I see a lot of kernel warnings because there are two processes that > access the device like this: > usbfs: process 19727 (usbhid-ups) did not claim interface 0 before use > usbfs: process 19862 (hald-addon-usbh) did not claim interface 0 before > use > My question: is this due to my kernel version, the version of my libusb > (libusb-0.1.12-5.1), or do I need a more up-to-date version of > drivers/libusb.c?No, it is due to the fact that you can run either 'usbhid-ups' *or* 'hald-addon-usbhid-ups', but not concurrently. Apparently you missed the 'packaging' part in 'docs/nut-hal.txt' that mentions: "The HAL support in NUT must currently be packaged separatly (ie in a specific nut-hal package) and must conflict with the classic nut packages." Both drivers will attempt to (re)claim the USB device but only one driver can attach to the USB device at the same time. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57
Arjen, No, it is due to the fact that you can run either 'usbhid-ups' *or* 'hald-addon-usbhid-ups', but not concurrently. Apparently you missed the 'packaging' part in 'docs/nut-hal.txt' that mentions: "The HAL support in NUT must currently be packaged separatly (ie in a specific nut-hal package) and must conflict with the classic nut packages." You are correct, I have let myself be totally misled by the Fedora packaging, which I followed. It not only packages the hal-addons in one package with all the other drivers. In addition, if an appropriate UPS is present, the proper hal-addon will automatically be configured and started with any restart of the haldaemon. Using the same UPS in the conventional way requires disabling this behavior in addition to setting up the old style configuration files. And there is was looking forward to playing with Arnaud's new stuff while relying on the old standby at the same time! Thanks for your response, AG -- ---------------------------------------------------------------------- Alfred Ganz alfred-ganz:at:agci.com AG Consulting, Inc. (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ----------------------------------------------------------------------
Arjen, I just went back to look at the nut-2.2.2/packaging directory, and found that the redhat subdirectory has not been updated since nut-2.0.5. This is of course before the introduction of the hal-addon's. What would be the process to have this updated, which I would hope would then also avoid the problems I ran into with the hal-addon's. Thanks for your help, AG -- ---------------------------------------------------------------------- Alfred Ganz alfred-ganz:at:agci.com AG Consulting, Inc. (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ----------------------------------------------------------------------