On Mon, 21 May 2007, Oliver Neukum wrote:
> > - what to do with devices with force feedback? (or PID devices in
> > general). The effect could have up to infinite duration (until it is
> > stopped by appropriate "stop" method), and we definitely absolutely
> > must not autosuspend a device that is currently in a process of
> > playback.
> I suggest we don't suspend them. We'd increment the pm usage count on
> open and decrement it on close, basically the same we need to do for
> generic HID devices. I just need a way to identify PID devices.
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;
}
> > - 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.
> > - (and of course coding style)
> It shall be done, but not until the principal features are clear.
Of course.
Thanks,
--
Jiri Kosina
-------------------------------------------------------------------------
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
