linux-kernel - [PATCH 0/1] Corsair Vengeance K90 driver

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>] [day] [month] [year] [list]

Message-ID: <55E1BBA8.9040505@gmail.com>
Date:	Sat, 29 Aug 2015 16:03:21 +0200
From:	Clément Vuchener <clement.vuchener@...il.com>
To:	jkosina@...e.com
Cc:	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-input@...r.kernel.org
Subject: [PATCH 0/1] Corsair Vengeance K90 driver

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

--
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/