On Fri, 28 Nov 2008, Alan Stern wrote:
> > > I don't understand this comment. Do you mean that you can't tell
> > > which underlying USB interface or device is associated with a
> > > particular hidraw device file?
> > Right. In the hiddev-driver the device-info structure has everything one could
> > possibly need to know:
> > struct hiddev_devinfo {
> > __u32 bustype;
> > __u32 busnum;
> > __u32 devnum;
> > __u32 ifnum;
> > __s16 vendor;
> > __s16 product;
> > __s16 version;
> > __u32 num_applications;
> > };
> > And for some reason I don't understand, this is what's exposed of the
> > above by the hidraw driver (which keeps a struct hid_device internally
> > and simply copies all the information from there):
> > struct hidraw_devinfo {
> > __u32 bustype;
> > __s16 vendor;
> > __s16 product;
> > };
> > At least knowing the interface-number is essential I think
The main reason is that hidraw is meant to be independent on transport
layer. USB has concept of interfaces, yes. But other underlying layers,
that might be able to transfer data compliant with HID specification,
don't necessarily have to have concept of interfaces at all.
> > I going to prepare for the hidraw driver since it basically works fine
> > for my specific device.
> I still think it's worthwhile to bring this to the attention of the
> appropriate kernel developers. In fact, I'll get the process started:
> Dmitry, is there any way to accomplish what Eberhard wants to do?
I am probably more appropriate victim than Dmitry when asking about
hidraw, as I wrote and maitain that particular code.
For 2.6.29, I have queued a patch that allows to get a ->phys out of
hidraw device node using HIDIOCGRAWPHYS command, similar to what hiddev
provides through HIDIOCGPHYS.
--
Jiri Kosina
SUSE Labs
