Writing a driver for the Corsair K90 keyboard

Writing a driver for the Corsair K90 keyboard

[Clément Vuchener]

Hello.

I first sent this email to kernel-mentors, but I got no response. So I 
am sending it again here.

I wrote a driver for the Corsair K90 keyboard, it is my first kernel 
development and I have a few questions about how to properly do a few 
things (mainly interactions with the user space).

The Corsair Vengeance K90 is a mechanical keyboard with a backlight, 
macro keys (G1 to G18) and some other special keys (macro recording, 
profile switching, changing the light level or disabling the "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 source for my driver can be found at this address: 
https://github.com/cvuchener/k90-linux-driver . It solves the problem of 
the generic driver and add some handling of the other features (see the 
README for more details).

So, my questions are about:

- Macro keys
For handling the macro keys from a software, they need to send some 
keycodes but I have no idea what to use. Currently I use F keys above 12 
and some MISC buttons and a parameter for changing that (at load time). 
Are there 18 keycodes reserved for custom uses? It would also be 
possible to send no keycode at all and use a specific software listening 
to the hidraw or hiddev devices, but I think it would be better to be 
able to use a generic software.

- Backlight
I chose to use a led class device to manage the backlight. It seems to 
work fine but when unregistering the driver, the light is set to 0. The 
keyboard remembers the previous light level and so nothing should be 
done when registering or unregistering the driver. Is the led class the 
right class for that? or am I using it wrong?

- Sending the macro profiles to the keyboard
I created a "profile" branch on my git repo for adding binary attributes 
used for sending macro data to the keyboard. But I am not sure it is a 
good idea, it may be better to leave that to the user space.

Any other comment is welcome.

Thanks,
Cl?ment

Writing a driver for the Corsair K90 keyboard

[Clément Vuchener]

It looks like no one had the answers to these questions. Is there a 
better place to ask them?

> Hello.
>
> I first sent this email to kernel-mentors, but I got no response. So I 
> am sending it again here.
>
> I wrote a driver for the Corsair K90 keyboard, it is my first kernel 
> development and I have a few questions about how to properly do a few 
> things (mainly interactions with the user space).
>
> The Corsair Vengeance K90 is a mechanical keyboard with a backlight, 
> macro keys (G1 to G18) and some other special keys (macro recording, 
> profile switching, changing the light level or disabling the "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 source for my driver can be found at this address: 
> https://github.com/cvuchener/k90-linux-driver . It solves the problem 
> of the generic driver and add some handling of the other features (see 
> the README for more details).
>
> So, my questions are about:
>
> - Macro keys
> For handling the macro keys from a software, they need to send some 
> keycodes but I have no idea what to use. Currently I use F keys above 
> 12 and some MISC buttons and a parameter for changing that (at load 
> time). Are there 18 keycodes reserved for custom uses? It would also 
> be possible to send no keycode at all and use a specific software 
> listening to the hidraw or hiddev devices, but I think it would be 
> better to be able to use a generic software.
>
> - Backlight
> I chose to use a led class device to manage the backlight. It seems to 
> work fine but when unregistering the driver, the light is set to 0. 
> The keyboard remembers the previous light level and so nothing should 
> be done when registering or unregistering the driver. Is the led class 
> the right class for that? or am I using it wrong?
>
> - Sending the macro profiles to the keyboard
> I created a "profile" branch on my git repo for adding binary 
> attributes used for sending macro data to the keyboard. But I am not 
> sure it is a good idea, it may be better to leave that to the user space.
>
> Any other comment is welcome.
>
> Thanks,
> Cl?ment

Writing a driver for the Corsair K90 keyboard

[Ricardo Ribalda Delgado]

Maybe http://vger.kernel.org/vger-lists.html#linux-input ?

On Mon, Aug 10, 2015 at 11:00 AM, Cl?ment Vuchener
<clement.vuchener@gmail.com> wrote:
> It looks like no one had the answers to these questions. Is there a
> better place to ask them?
>
>> Hello.
>>
>> I first sent this email to kernel-mentors, but I got no response. So I
>> am sending it again here.
>>
>> I wrote a driver for the Corsair K90 keyboard, it is my first kernel
>> development and I have a few questions about how to properly do a few
>> things (mainly interactions with the user space).
>>
>> The Corsair Vengeance K90 is a mechanical keyboard with a backlight,
>> macro keys (G1 to G18) and some other special keys (macro recording,
>> profile switching, changing the light level or disabling the "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 source for my driver can be found at this address:
>> https://github.com/cvuchener/k90-linux-driver . It solves the problem
>> of the generic driver and add some handling of the other features (see
>> the README for more details).
>>
>> So, my questions are about:
>>
>> - Macro keys
>> For handling the macro keys from a software, they need to send some
>> keycodes but I have no idea what to use. Currently I use F keys above
>> 12 and some MISC buttons and a parameter for changing that (at load
>> time). Are there 18 keycodes reserved for custom uses? It would also
>> be possible to send no keycode at all and use a specific software
>> listening to the hidraw or hiddev devices, but I think it would be
>> better to be able to use a generic software.
>>
>> - Backlight
>> I chose to use a led class device to manage the backlight. It seems to
>> work fine but when unregistering the driver, the light is set to 0.
>> The keyboard remembers the previous light level and so nothing should
>> be done when registering or unregistering the driver. Is the led class
>> the right class for that? or am I using it wrong?
>>
>> - Sending the macro profiles to the keyboard
>> I created a "profile" branch on my git repo for adding binary
>> attributes used for sending macro data to the keyboard. But I am not
>> sure it is a good idea, it may be better to leave that to the user space.
>>
>> Any other comment is welcome.
>>
>> Thanks,
>> Cl?ment
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
Ricardo Ribalda

Writing a driver for the Corsair K90 keyboard

[Clément Vuchener]

Thanks, I did not know about these lists. I see a leds mailing list too, 
I think I will split my backlight issue there.

> Maybe http://vger.kernel.org/vger-lists.html#linux-input ?
>
> On Mon, Aug 10, 2015 at 11:00 AM, Cl?ment Vuchener
> <clement.vuchener@gmail.com> wrote:
>> It looks like no one had the answers to these questions. Is there a
>> better place to ask them?
>>
>>> Hello.
>>>
>>> I first sent this email to kernel-mentors, but I got no response. So I
>>> am sending it again here.
>>>
>>> I wrote a driver for the Corsair K90 keyboard, it is my first kernel
>>> development and I have a few questions about how to properly do a few
>>> things (mainly interactions with the user space).
>>>
>>> The Corsair Vengeance K90 is a mechanical keyboard with a backlight,
>>> macro keys (G1 to G18) and some other special keys (macro recording,
>>> profile switching, changing the light level or disabling the "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 source for my driver can be found at this address:
>>> https://github.com/cvuchener/k90-linux-driver . It solves the problem
>>> of the generic driver and add some handling of the other features (see
>>> the README for more details).
>>>
>>> So, my questions are about:
>>>
>>> - Macro keys
>>> For handling the macro keys from a software, they need to send some
>>> keycodes but I have no idea what to use. Currently I use F keys above
>>> 12 and some MISC buttons and a parameter for changing that (at load
>>> time). Are there 18 keycodes reserved for custom uses? It would also
>>> be possible to send no keycode at all and use a specific software
>>> listening to the hidraw or hiddev devices, but I think it would be
>>> better to be able to use a generic software.
>>>
>>> - Backlight
>>> I chose to use a led class device to manage the backlight. It seems to
>>> work fine but when unregistering the driver, the light is set to 0.
>>> The keyboard remembers the previous light level and so nothing should
>>> be done when registering or unregistering the driver. Is the led class
>>> the right class for that? or am I using it wrong?
>>>
>>> - Sending the macro profiles to the keyboard
>>> I created a "profile" branch on my git repo for adding binary
>>> attributes used for sending macro data to the keyboard. But I am not
>>> sure it is a good idea, it may be better to leave that to the user space.
>>>
>>> Any other comment is welcome.
>>>
>>> Thanks,
>>> Cl?ment
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>