On Wed, Feb 27, 2013 at 6:48 PM, David Herrmann [off-list ref] wrote:

Hi Benjamin

On Wed, Feb 27, 2013 at 4:38 PM, Benjamin Tissoires
[off-list ref] wrote:

quoted

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 [off-list ref]

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