----- Original message ----- > On Mon, 24 May 2010, Rafi Rubin wrote: > > > Ok, pardon that excessive attachments. Attached is a snip of the kernel code, > > just the sysfs function, the user space equivalent, and logs of both (with the > > time stamps cropped out for comparison. > > Since the logs are the same, up to the point where the interrupt-IN > request is cancelled, it's logical to assume that the difference was > caused by something that happened before you began the usbmon traces. > > Do it again, only this time start the traces before plugging in the > device. That way we'll get a complete record. And don't worry about > cropping out the timestamps; sometimes they reveal useful information. > For example, here they would have told us if the interrupt-IN request > failed because it timed out too quickly. > > > Also please put on slop code filter glasses before reading the code, I hold no > > responsibility to damaged eyes or loss of sanity. It will be cleaned up, > > later. > > Aside from not using the predefined constants for the bRequestType > values, what stands out most is that you're using I/O buffers allocated > on the stack. That's a no-no (not all architectures are capable of > doing DMA to stack-based locations); I/O buffers should be allocated > dynamically using kmalloc. > > Alan Stern thanks for the feedback. The events are really fast on one of my digitizer, yet seem to be not returning on another. I'm also starting to think that some of the returns that I thought were erroneous on the good device, might have a different meaning, such as perhaps "already well calibrated, nothing interesting to report". Sorry about the raw values for request types, I've been keeping them visually similar to the usbmon traffic for my benefit, until I'm comfortable that I've got it all good enough. As for the logs, I cropped copies for inspection with a highlighting diff tool, I will make sure to send the full versions in the future. I need to tweak it a bit more, and then should be able to give more details about what's going right and wrong. Rafi -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
