linux-kernel - Re: [RFC 0/2] HID: Introduce .idle() to remove last usb dependence from hid-multitouch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANq1E4Q8_J6W0oH7QH=vamtg0HRjimzk6N4M-9oSMRzyD=o-7A@mail.gmail.com>
Date:	Wed, 27 Feb 2013 18:48:57 +0100
From:	David Herrmann <dh.herrmann@...il.com>
To:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:	Benjamin Tissoires <benjamin.tissoires@...il.com>,
	Henrik Rydberg <rydberg@...omail.se>,
	Jiri Kosina <jkosina@...e.cz>,
	Stephane Chatty <chatty@...c.fr>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/2] HID: Introduce .idle() to remove last usb dependence
 from hid-multitouch

Hi Benjamin

On Wed, Feb 27, 2013 at 4:38 PM, Benjamin Tissoires
<benjamin.tissoires@...hat.com> 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@...il.com>

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/