From patchwork Wed Apr 10 14:54:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 10894071 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A095313B5 for ; Wed, 10 Apr 2019 14:55:12 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 821F1286A7 for ; Wed, 10 Apr 2019 14:55:12 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 73FE72873E; Wed, 10 Apr 2019 14:55:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 01C23286A7 for ; Wed, 10 Apr 2019 14:55:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732910AbfDJOzL (ORCPT ); Wed, 10 Apr 2019 10:55:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51348 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732779AbfDJOzL (ORCPT ); Wed, 10 Apr 2019 10:55:11 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D23AAE3E14; Wed, 10 Apr 2019 14:55:10 +0000 (UTC) Received: from shalem.localdomain.com (ovpn-116-249.ams2.redhat.com [10.36.116.249]) by smtp.corp.redhat.com (Postfix) with ESMTP id D85AB179EE; Wed, 10 Apr 2019 14:55:00 +0000 (UTC) From: Hans de Goede To: Jiri Kosina , Benjamin Tissoires Cc: Hans de Goede , Nestor Lopez Casado , linux-input@vger.kernel.org Subject: [PATCH v2 00/37] HID: logitech: Handling of non DJ receivers in hid-logitech-dj Date: Wed, 10 Apr 2019 16:54:22 +0200 Message-Id: <20190410145459.11430-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 10 Apr 2019 14:55:10 +0000 (UTC) Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi All, Here is v2 of Benjamin's and mine series to enumerate the devices behind various non DJ receivers instead of relying on their HID proxy mode. There are 3 major changes in v2: 1) Add a new HID group for 27 MHz devices, this has 2 advantages: 1a) It allows the logitech-hidpp code to identity 27 Mhz devices and to automatically enable some HID++ quirls for these, such as e.g. HID++ mouse-wheel handling (fixing some hwheel issues) 1b) Since the logitech-hidpp code can now identify these the logitech-dj code for 27 MHz devices no longer needs separate 27 MHz descriptors for the consumer and HID++ reports. 2) Add support Logitech Bluetooth receivers in HID proxy mode, tested with a MX5000 keyboard + receiver. This allows e.g. battery monitoring of the kbd. 3) Rework HID++ mouse-wheel and extra-buttons support making it more generic and cleaner and add HID++ consumer-keys report. Using the HID++ consumer keys reports fixes several keys not working on some kbds. Per patch info, unlisted patches are unchanged: [PATCH 01/37] HID: quirks: do not blacklist Logitech devices -New patch split of from a cleanup patch from Benjamin which was touching many different drivers at once. This removes a dep on that patch. [PATCH 12/37] HID: logitech-dj: support sharing struct dj_receiver_dev between USB-interfaces -Fixed calling hid_err on a NULL hdev [PATCH 16/37] HID: logitech-dj: add support for 27 MHz receivers -Remove chunk to pick a better name for hidpp devices, see new patch below -Add support for mouse on index 2, numeric-keypad on index 4 -Use a new group for 27MHz devices [PATCH 20/37] HID: logitech-dj: pick a better name for non-unifying receivers -New patch replacing the dropped chunk from patch 16 as well as replacing "HID: logitech-hidpp: create a name based on the type if non available" from v1 [PATCH 21/37] HID: logitech-dj: remove false-positive error ... -New misc. fix patch [PATCH 22/37] HID: logitech-dj: make appending of the HID++ ... [PATCH 23/37] HID: logitech-dj: add support for Logitech Bluetooth -2 new patches adding support for Logitech BT receivers in HID proxy mode [PATCH 26/37] HID: logitech-hidpp: ignore very-short or empty [PATCH 27/37] HID: logitech-hidpp: do not make failure to get the [PATCH 28/37] HID: logitech-hidpp: remove double assignment from [PATCH 29/37] HID: logitech-hidpp: remove unused -4 new patches (misc. fixes / cleanups) [PATCH 31/37] HID: logitech-hidpp: handle devices attached to -Add support for the new 27 MHz lg devices hid group [PATCH 32/37] HID: logitech-hidpp: do not hardcode very long -This fixes logitech-hidpp rejecting the mx5000 keyboard when paired over BT [PATCH 34/37] HID: logitech-hidpp: make hidpp10_set_register_bit a [PATCH 35/37] HID: logitech-hidpp: add support for HID++ 1.0 wheel [PATCH 36/37] HID: logitech-hidpp: add support for HID++ 1.0 extra [PATCH 37/37] HID: logitech-hidpp: add support for HID++ 1.0 -Reworked HID++ mouse-wheel and extra-buttons support making it more generic and add HID++ consumer-keys report support For reference here is the cover letter of v1 of the series: Here is a series Benjamin and I have been working on, before this series we treat Logitech wireless mice / keyboards connected through a non-unifying receiver as generic HID devices, using the generic HID emulation of the receiver. This causes several problems: -We cannot properly support some special keys / buttons on some keyboards / mice since we cannot properly identify / talk to the device behind the recv. -We cannot monitor the battery in these devices This series addresses this by actually enumerating (and talking to) the devices behind the receiver, rather then solely relying on the receiver's generic HID emulation. Note this series applies on top of the: "[PATCH] HID: force setting drvdata to NULL when removing the driver" patch which Benjamin send out 2 days ago. Regards, Hans