> Hi Oliver,
>
> what about something like
>
> int hidinput_has_ff(struct hid_device *hid)
> {
> struct hid_input *hidinput;
>
> list_for_each_entry(hidinput, &hid->inputs, list)
> if (test_bit(EV_FF, hidinput->input->evbit))
> return 1;
> return 0;
> }
Taken.
> > > - think again about the output reports queuing. I am now inclined to
> > > think
> > > that we should simply wake the device up once the output report is to
> > > be
> > > delivered to it. There might be different situations other than just
> > > keyboard LEDs (there can be simply any kind of exotic HID device being
> > > controlled through hiddev and userspace could want to deliver the
> > > output
> > > report to it immediately, without any queuing)
> > If we do "busy style" autosuspend only for devices we positively identify,
> > is the point rendered moot?
>
> Sorry, could you be please more specific? I don't think I understand the
> point here. Thanks.
Such devices would be claimed by hiddev, wouldn't they be?
So if hiddev's open() bumps the count they won't be autosuspended
anyway.
Regards
Oliver
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
