Simon Budig wrote: > Hi. > > I'm new to this list and want to shout out a "thank you" for all the > work you've done. > > I've yet to do a successful config update with linux though, since I hit > the very same problem as Kevin.
<SNIP> > I just tried it again with the usbhid and hid modules removed. Same > problem. It seems that the 525 gets confused badly in that process, > because subsequent attempts to contact the remote fail: OK, well we have three people with this error, all with the 52x remotes - I'd say that pretty definitively identifies the problem as associated with either the 52x series, or perhaps the whole of architecture 9 (36x, 52x, and 55x). Further, the fact that this happens with usbhid and hid modules removed (and I'm assuming after you saw the problem that udev/hotplug hadn't brought them back), implies it's not an unbinding problem. OK, well, another useful test would be to see if this happens with our WinHID code. Could one of you who's having the problem try our software in windows compiled with both libusb and winhid and see if you can reproduce it in each of them? And... create a bug, please. > Regarding the valgrind errors spotted by Kevin: In CRemote::GetIdentity > there is a HID_WriteReport() which does a usb_interrupt_write() with two > bytes of data, claiming to have 64 bytes of data (if I don't > misinterpret some of the output). So at best the usb request has 62 > bytes of uninitialized data. Maybe this might confuse the device? I see why you think that, but HID reports always have to be a set size. You determine the input and output report size (irl and orl) from the HID descriptor. You can run "harmony -iv" and it'll include the irl and orl). And while you'd think "what about the rest of that data?" but each command we send includes the size of the data as part of the protocol the harmonies use (the size of the data following the command is encoded into the first byte of the command - see specs/protocol.txt in CVS for details), so I don't think this is likely the problem. If it was, no one's remote would work. > What I find interesting: The ioctls don't really seem to indicate > something going wrong, except that before the 100% get reached a lot of > USBDEVFS_REAPURBNDELAYs happen, so that probably some timeout happens. > Libusb apparently spits out an obscure error which looks quite bogus to > me - I wonder if this is maybe an older error message sticking around. Yeah, there's a lot of delays, the remote can only take data so fast. Libusb abstracts that away from us, fortunately. > What could I do to help in this issue? I'd like to see if we have the same problem in Windows both with libusb and with winhid. Thanks. -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
