Re: autosuspend for hid

> 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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel