Hi Benjamin On Wed, Feb 27, 2013 at 4:38 PM, Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> wrote: > Hi guys, > > Well, this series of two patches aims at removing the dependence between usb > and hid-multitouch. > I put a RFC and not a patch as I'm not satisfied with the result: > - adding this callback for one use may not be accurate > - the parameters may not be good either (HID_REQ_SET_IDLE is the only valid > value for now as noone seems to be using HID_REQ_GET_IDLE) > - the return value is clearly not very interesting. > - maybe we should just add HID_REQ_SET_IDLE to .request, but this will require > a few changes in the parameters. > > The main purpose of this RFC was to share it with David this new ll callback, so > that we can have a global view of what is needed. I actually never read the specs for SET/GET_IDLE. The Bluetooth HID Profile deprecated these and I haven't seen a Bluetooth device that relies on it. Any reasons why I should implement them? Also, for things like UHID I think we can safely drop this request. Considering that, I think the patches can be applied as they are, so: Reviewed-by: David Herrmann <dh.herrmann@xxxxxxxxx> The Bluetooth HID Profile actually implements some other SUSPEND calls, but these are supposed to be handled by the Bluetooth stack independently of the HID driver. So if there is no other magic going on with SET_IDLE, I'd just leave it for usbhid. (does anyone know whether i2c-hid support these?) Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
