[Nut-upsuser] blazer_usb - short reply

[Alexander I. Gordeev]

First of all, IMO you should trust me more because I now have an 06da:0003 
Ippon device.

Attached some logs which should show what's going on.
*.dump.txt are produced by usbmon.
UsbSnoop.log shows how it is done in the Windows driver.

On Sunday 22 March 2009 13:31:54 Arjen de Korte wrote:
> Citeren Arjen de Korte <nut+users at de-korte.org>:
> >> I've just commited a fix for the blazer_usb driver. I'm still trying to
> >> fix megatec_usb also. There is a very odd and interesting problem which
> >> I want to resolve.
> >
> > I've reverted your fix. This breaks other devices where we need to
> > read until '\r' and will continue to report nonsense infinitly
> > afterwards. So we probably should create a separate subdriver for this
> > device that needs reading until timeout.
>
> Note that I'm not convinced that reading until a timeout is received
> is a good idea at all. So maybe we should just create a separate
> subdriver here and allow people to override the build in automatic
> subdriver selection (which is possible for blazer_usb).

This is just flushing the channel. I remember that you previously had an 
opposite opinion about flushing.

> As for the OP's problem, I'm not convinced that your patch would work.
> This could also very well be a problem with the UPS not understanding
> that we want to read the rating (and locking up afterwards). So unless
> we get a reply on this question, I don't think making any
> modifications at all would be a good idea.

I'm pretty sure it'll work because it works well for me. You can see it in the 
attached logs. The UPS answers both F and I requests so this is not a 
problem.
You can see in the UsbSnoop.log that the Windows driver reads until timeout.
It even does it asynchronously, which is bad for us since libusb-0.1 doesn't 
support asynchronous IO. It's a big luck that the synchronous IO works as 
well.
I think, other logs very well prove that reading until timeout is necessary.

> After all, it looks like the OP also tried the megatec_usb which
> didn't work either, although this one does read until timeout (so this
> probably isn't the problem here).

There is another problem. You can see it in the logs. I still don't know why 
UPS's responces are mangled.

--
  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.tar.bz2
Type: application/x-tbz
Size: 41330 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20090322/a9d08499/attachment-0001.bin