On Wed, Feb 27, 2013 at 6:48 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > 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? I don't want you to absolutely implement it. I just wanted to share it with you because all the commands set/get report, set/get idle, set/get protocol and set power are part of the "class specific requests". So I don't know if we should have distinct hid_hw_* calls for each of them, or if we should implement a big hid_hw_request() function. > > Also, for things like UHID I think we can safely drop this request. sure. > Considering that, I think the patches can be applied as they are, so: > Reviewed-by: David Herrmann <dh.herrmann@xxxxxxxxx> Thanks. > > 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?) It does, but it's also marked as deprecated. :) So I don't want to implement it either until we found weird devices requesting it. Cheers, Benjamin -- 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
