From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752594AbbH2OD0 (ORCPT ); Sat, 29 Aug 2015 10:03:26 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:37640 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbbH2ODY (ORCPT ); Sat, 29 Aug 2015 10:03:24 -0400 From: =?UTF-8?Q?Cl=c3=a9ment_Vuchener?= Subject: [PATCH 0/1] Corsair Vengeance K90 driver To: jkosina@suse.com Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org Message-ID: <55E1BBA8.9040505@gmail.com> Date: Sat, 29 Aug 2015 16:03:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch implements a HID driver for the Corsair Vengeance K90 keyboard. This keyboard has a backlight, macro keys (G1 to G18) and some other special keys (macro recording, profile switching, changing the light level or disabling the super/meta/"windows logo" keys). The macro playback can be switched between hardware or software (from the driver not a key). Using the generic HID driver, the macro keys and special keys send wrong key code or no key code at all (because of the HID usage code used by the keyboard). The purpose of this driver is to fix the behaviour of the keys using incorrect HID usage codes and expose the other features to the user space. This is my first Linux driver and I would like to get feedback for both my code and my choices for the user space interface. For the keyboard to work in software mode, a user program needs to be able to get key events. I am not sure about which key codes should be used for that. I choose the BTN_TRIGGER_HAPPY* as they seem to be used for devices with extra buttons. The other special keys does send any key codes. They are used to change the hardware state and user space should not need them directly. Playback mode and current profile can be read and written through simple sysfs attributes. The backlight is managed through a LED class device. Hardware macro profiles (there are three of them) are managed thanks to devices of the new k90_profile class. Data is sent through binary attributes in the same format sent to the hardware. I choose to do so to keep the driver simple. Should it use a more abstract ABI? Those attributes are write-only as is does not look like there is way to read them back (the Windows driver does not do it). The macro recording is not actually done from hardware and this driver does not implement it. The recording LED has its device, but having it on or pressing the button does not record anything. Clément Vuchener (1): Corsair Vengeance K90 driver Documentation/ABI/testing/sysfs-class-k90_profile | 55 ++ .../ABI/testing/sysfs-driver-hid-corsair-k90 | 15 + drivers/hid/Kconfig | 10 + drivers/hid/Makefile | 1 + drivers/hid/hid-core.c | 1 + drivers/hid/hid-corsair-k90.c | 690 +++++++++++++++++++++ drivers/hid/hid-ids.h | 3 + 7 files changed, 775 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-k90_profile create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-corsair-k90 create mode 100644 drivers/hid/hid-corsair-k90.c -- 2.4.3