On Wed, 30 Jun 2010, Alan Ott wrote: > > > ioctl which sets a flag so that when device sends a report , report > > > id& report type is prefixed > > > to output of read() . > > > i mean when application calls read , it gets input report as<report > > > id><report type><payload> > > > right now we get<payload> only . > > > > > Please see the commit 5a38f2c7c4dd53d5be097930902c108e362584a3. That makes > > sure that report id should be there properly. Do you still see any problem > > with this commit applied? (2.6.34 is the first kernel to have this one). > > > > That commit removes an extra byte from the beginning of reports handed to > read(). If I understand correctly, it doesn't do what he's asking. > > For devices which use numbered reports, reports which come from read() have > the report ID at the beginning, in the form: > <report_id><payload> > > For devices which do _not_ use numbered reports, only the payload is sent. Of > course, since the device only uses a single report, a report number does not > even make sense, and is not needed, since you know which report it is (as > there is only one). The form is: > <payload> > > It is not necessary to return the report type, because the read() interface > will only give you INPUT reports which come over the INTERRUPT IN endpoint > (usually EP 1 IN). FEATURE reports must come through the GET_FEATURE request > over the CONTROL endpoint, initiated by the HIDIOCGFEATURE ioctl (Note that > this ioctl is part of what Jiri has staged for the next merge window, and is > not part of the current 2.6.34 Kernel). OUTPUT reports are never sent from the > device on the INTERRUPT IN endpoint. In short, if it comes from read(), it's > always an INPUT report. Ah, OK, I likely misunderstood what Amit has been actually asking for. The situation is exactly the way Alan has described it. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
