[Nut-upsuser] suse linux and nut

[Peter Selinger]

Arnaud Quette wrote:
> 
> 2006/8/30, Peter Selinger <selinger at mathstat.dal.ca>:
> > Arnaud Quette wrote:
> > >
> > > Hi
> > >
> > > 2006/8/27, Peter Selinger <selinger at mathstat.dal.ca>:
> > > > ...
> > > > What's to do here for the NUT developers is: first, improve support
> > > > for interrupt transfers in newhidups.
> > >
> > > right, as we still rely on the (very) early code I first wrote.
> > > moreover, the big nested "if" in update is not clean and too heavy.
> > > lastly, I'm thinking for some time about adding threading support,
> > > which ie means in our case that we could have an interrupt dedicated
> > > thread + a polling thread, both feeding the main thread with HID
> > > objects. The main thread would then decode these and call
> > > dstate_setinfo()...
> >
> > This is not what I had in mind. I think that threading is too
> > complicated and heavy for such a simple task.
> 
> not that heavy, though it would need a rework of the newhidups core.
> But it would add more reliability to interrupt listening/handling,
> since we currently can miss events due to the design weakness.

Perhaps. But isn't this a question of the polling frequency? Right
now, this frequency is quite artificially limited. The real problem
seems to be that the current version of libusb does not provide for
non-blocking read operations, so one always has to specify a
timeout. I can see how having a dedicated thread would solve this
problem. 
 
> > The main problem with interrupt transfers at the moment is that
> > NUT somehow ignores all the variables that are not found during the
> > first run of dstate_setinfo(). Interrupt variables are not discovered
> > during this first run, and are therefore ignored. I am not sure at the
> > moment what causes this.
> 
> interrupt data not being exposed in the report descriptor?!

No, the report descriptor lists them. They are usually listed as items
of type "Input" (as opposed to "Feature", which refers to polled
data). Often, the same item may exists as both an "Input" and a
"Feature" item. 

> > Another, minor problem with interrupt transfers is that there exist
> > buggy UPSs (my Belkin UNV in particular), which allow the same
> > variable to be polled by interrupt and regular transfers, and give a
> > *different* result depending on the method! Unfortunately, this
> > happens for an important flag such as the "on battery" flag.
> 
> such units would so need to only depend upon interrupt?

No, for this particular unit, the interrupt value is the buggy one,
and the feature value is correct. 
 
> > I have started, some time ago, to improve the interrupt handling in
> > the "reportbuf" branch. The main reason I haven't merged this code
> > back into the trunk is that I first need to find a case-by-case
> > workaround to deal with buggy UPSs such as the Belkin.
> 
> the threaded method would allow, with some sub-drv config, to launch
> the polling thread and/or the interrupt thread. Either feeding the
> core is not important since the core wouldn't care about that.

I think is may make sense to have a thread for listening on the
interrupt pipeline, to overcome the problem with synchronous
communication. But why would you want a thread for features? These
have to be polled at regular intervals anyway, so this can still be
done from upsdrv_updateinfo. 

-- Peter