[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