[Nut-upsdev] usbhid-ups: shutdown testing needed

Arjen de Korte nut+devel at de-korte.org
Tue Sep 25 20:25:24 UTC 2007


Arnaud Quette wrote:

[...]

>> Neither of these can be backported easily, since they require changes in
>> *many* places of the code, so we would basically have to copy what is in
>> the trunk to Testing to make these effective.
> indeed, I don't like that at all!

Neither do I, but I don't see another alternative. :-(

> And even more the fact that some of our users can be left alone in the dark...
> So, can you backport the necessary changes?

You mean backporting the *new* usbhid-ups driver from the trunk and the
changes to the other USB driver, so that they no longer depend on libhid?

> we'll go on a longer -pre stage and test more this time.

That would be necessary indeed.

> btw, i've not had time to bounce on the ShutdownImminent thread and
> can't go into a lengthy explanation now. But this really has to
> trigger an FSD, at least for MGE units.
> Can you also take care of that Arjen?

Sure, it has been like that for a long time, so I don't think it would
hurt to keep it like this until we have found a better solution.

I'm still wondering why this is needed however, since I can't seem to
make my Evolution 650 signal this, although it is listed in the report
descriptor. Which condition will trigger this for MGE units?

> And if someone has a HID/PDC question, Dominique Lallement (the PDC
> chairman) is a member of the NUT project ;-)

Good. Would he be able to explain what condition triggers
ShutdownImminent? I still think mapping this to LB (only) is a bad idea,
so if the system really should shutdown, it should be mapped to LB+OB or
(better yet) FSD. But in the latter case, we should make sure this is
handled correctly by the server/clients.

Best regards, Arjen



More information about the Nut-upsdev mailing list