Jump to content
Corsair Community

K90 issues on Linux (64-bit)


Hell4You

Recommended Posts

I have a M60 and a K90 with the US international keyboard layout and I'm using them under Linux, kernel version 3.4.5. Overall, they are working OK, but there are still some pending issues with the keyboard.

 

Keyboard firmware: 1.18

Mouse firmware: 1.11

 

Issues already been tackled:

  1. Keyboard keeps being reset and enumerated on a USB2.0 (EHCI) controller.
    After extensive testing with kernel configuration options I found out I had to enable 'Improved Transaction Translator scheduling (CONFIG_USB_EHCI_TT_NEWSCHED)'.
  2. Numlock, Capslock and Scrollock lights do not work.
    A forum user named swm advised to switch the keyboard mode to UTF8 with: kbd_mode -u

Blocking issues that are really annoying:

  1. When typing the pipe symbol ( | ) and the shift button is released before the pipe button, an additional \ is typed ( the symbol for that button without shift ). Result: |\. This behaviour does not occur on Windows.
  2. Media keys do not work when caps lock is enabled. This behaviour does not occur on Windows.
  3. Occasionally keys get 'stuck', probably meaning KEY_DOWN is received but KEY_UP is not. Pressing another key releases the key that is 'stuck'. This behaviour does also occur on Windows.

Additionally, some issues I can live with not working under Linux:

  1. The G keys and associated macro keys do not work.
  2. It's (obviously) not possible to configure the keyboard using the Corsair software.

 

Does someone have a solution for any of these issues? I'm happily willing to try and test any suggestions you may have.

 

Thank you.

 

P.S.

I have some (constructive) feedback for the mechanical part of the M60 mouse:

  • The build quality is rock solid and nearly indestructible.
  • It looks really nice.
  • I don't like the edge near the Corsair logo, because the palm of my hand is resting right there, resulting in a discomfort.
  • The right click button has a very low click threshold. I cannot rest my finger on the button, because it immediately clicks. I have added a little foam underneath to prevent it.
  • The screwing thread of one of the weights gets damaged really easily

Link to comment
Share on other sites

I've been running fedora with Gnome or something and my capslock and scroll lock keys dont light up and Gkeys don't work.

Num Lock light works fine.

Media Keys work fine with caps enabled.

\|||| Dont know about the pipe symbol. Seems to work for me.

Link to comment
Share on other sites

  • 2 weeks later...

Hello,

I got my K90 today (belgian layout). I run Gentoo Linux in 64 bits and experience the same issues as you, except | is done with "alt-gr 1" and does not seem to produce extra &.

Thank you very much for your utf8 hint, it worked like a charm.

I'll start searching for a solution for the G keys in a few days, when I've a bit of free time and will post any update here if found.

 

edit:

___________

I just found another real anoying bug: when I use the "alt-leftarrow" combination (like to go back in firefox), I am thrown out of X and switched to another terminal. X isn't killed however, as alt-f7 restores my graphic session where it was. I will try to investigate this later.

Does anyone have the same issue?

Link to comment
Share on other sites

Hello,

I got my K90 today (belgian layout). I run Gentoo Linux in 64 bits and experience the same issues as you, except | is done with "alt-gr 1" and does not seem to produce extra &.

Thank you very much for your utf8 hint, it worked like a charm.

I'll start searching for a solution for the G keys in a few days, when I've a bit of free time and will post any update here if found.

 

edit:

___________

I just found another real anoying bug: when I use the "alt-leftarrow" combination (like to go back in firefox), I am thrown out of X and switched to another terminal. X isn't killed however, as alt-f7 restores my graphic session where it was. I will try to investigate this later.

Does anyone have the same issue?

 

Just installed Linux Mint 13, caps lock key does not work. The utf8 trick did not work for me. Oh well.

 

Box 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Link to comment
Share on other sites

Hello,

I got my K90 today (belgian layout). I run Gentoo Linux in 64 bits and experience the same issues as you, (...)

Two questions:

  • Did you test the media keys with caps-lock enabled?
  • Did you had to enable the CONFIG_USB_EHCI_TT_NEWSCHED kernel option for the keyboard to work on USB2.0?

I just found another real anoying bug: when I use the "alt-leftarrow" combination (like to go back in firefox), I am thrown out of X and switched to another terminal. X isn't killed however, as alt-f7 restores my graphic session where it was. I will try to investigate this later.

Does anyone have the same issue?

 

I posted in the topic where i found the solution for this issue, and swm did suggest a fix, but I haven't tried so far.

Link to comment
Share on other sites

@Hell4You

Sorry for the lag, I spent the last 4 days fighting UEFI

 

Yes the media keys work with caps lock enabled - I thest with mplayer though, so I can't say for next and previous.

 

I don't know if I had to enable it, but I enabled it before trying the keyboard and it works indeed... I can try to compile a kernel without that support when I find some time to see if it is related.

 

Thanks for the meta-solution, it seems to work, although I disabled the fix for the time being: I must do an optimised static config first as I loose autodetection of everything with that solution (I'll try to get that running tomorrow and will confirm if it works).

Link to comment
Share on other sites

Re,

 

I might have found a possible way to get our K90 to work with pinguins: this is my path of reflexion, it is based on the

gentoo wiki

 

First of all, when I tried to scan the keycodes with xev, I saw that all keys don't seem to have codes.

While all "normal" keys have; only three of the 18 G keys do actually send back codes (G9=107, G17=162 and G18=164)

 

This is interesting because it spawned the idea that as the device uses 2 USB cables to connect to the computer, it might actually be seen as two devices.

 

I thus checked it in my /dev/ filesystem :

 

# ls -al /dev/input/by-id/

lrwxrwxrwx 1 root root 10 Aug 31 08:18 usb-Corsair_Corsair_Vengeance_K90_Keyboard-event-if01 -> ../event14

lrwxrwxrwx 1 root root 10 Aug 31 08:18 usb-Corsair_Corsair_Vengeance_K90_Keyboard-event-kbd -> ../event13

lrwxrwxrwx 1 root root 10 Aug 31 08:18 usb-Corsair_Corsair_Vengeance_K90_Keyboard-if02-event-kbd -> ../event15

 

Bingo: It seems to be seen as 3 devices (not sure what is what yet.

 

Now to get some keycodes ^^

I found part of the keytouch utility named getscancodes at http://sourceforge.net/projects/keytouch/files/

uncompressed and compiled, then ran it with root to check some keycodes:

 

JuPiTeR getscancodes # ./getscancodes /dev/input/event14

didn't give anything interesting

 

JuPiTeR getscancodes # ./getscancodes /dev/input/event15

Gives me control codes when I type on the regular keys, but nothing when I type on the GXX keys

 

JuPiTeR getscancodes # ./getscancodes /dev/input/event13

Gives me control codes when I hit the GXX keys and letters and numbers when I hit the keyboard.

 

Here are the codes I found for the G keys through event13

 

G01 - 458960

G02 - 458961

G03 - 458962

G04 - 458963

G05 - 458964

G06 - 458965

G07 - 458966

G08 - 458967

G09 - 458968 + Buggy Codes

G10 - 458969

G11 - 458970

G12 - 458971

G13 - 458972

G14 - 458973

G15 - 458974

G16 - 458975

G17 - 458984 + Buggy Codes

G18 - 458985 + Buggy Codes

 

As you can see, the 3 GXX keys with buggy codes are the ones that worked natively with xev

 

==> I am quite sure we can use the GXX keys simply by linking those codes to behaviours with lineakd or keytouch.

 

I don't know what the event14 is used for, maybe for multiplexing entries of event 13 and event 15...

Link to comment
Share on other sites

Re,

 

Searching a bit more about the keyboard,

Seems to indicate there is a 360k memory in the keyboard that can store macros so they would work on a computer without the software.

 

If this is the case, it might be possible to program the macros on a windows computer and then use them on a Linux comp.

Link to comment
Share on other sites

This is going way faster than expected, I know have an 80% functionnal framework to use the keyboard with Linux... It is probably not the nicest way to tackle the problem, but is works like a charm... so far :laughing:

 

So far these are my main objectives. The app is running at the moment on my computer, but I'd rather complete and test it a bit before posting it.

 

I hope I'll be able to send a first alpha version by tonight (count 8 to 10 more hours), as I'm quite bad at writing scripts, constructive help and improvements will be very welcome ;)

 

My implementation allows to bind some scripts to the G1-G18 keys.

The main downside, compared to the windows app, is that there is no app, just a bash script to adapt to your needs.

Also to mention, I didn't work out yet how to emulate keyboard inputs in bash, so that I could code inputs (like a gaming keyboard) - but it should be possible, probably with xmacro or xsendkeycode.

 

The main upside, is that I managed to run scripts, based on key inputs... This what I'm actually working on:

 

- Mute button enable/disables all other custom keys (handy to avoid errors if somebody else uses your keyboard) (this still doesn't work at all)

 

- M1 does a system update (to tune according to your system)

- M2 does a X restart

- M3 reboots the machine

- Lock/unlock=start/stop SSH (or firewall... what you prefer)

- Launch a backup

- Launch an app

- Flash a raspberri pi image on an sd card

- backup or sync android sd card

- mount /boot /boot/efi and upgrade my kernel

- play the latest avi/mkv/mp4 in a given folder

 

Of course, some of these features should be used with card, which is why I'm implementing some confirmation procedure.

 

Please let me know your thoughts ;)

Link to comment
Share on other sites

Nice!

 

I have some questions though:

- Is it possible somehow to use the G-keys for binds in games?

- Is there a keycode for the 'disable windows-key'-key, or is it handled internally in the keyboard?

- How do you estimate the chance of getting to control the keyboards backlight and other features?

- Did you adjust swm's xorg.conf much to fix the ALT issue (switching terminals)? If so, could you post your edits please?

- Do you experience any other out of the ordinary issues on Linux?

 

To be honest, I don't really mind the G-keys don't work as I don't use them very much. But it sure would be a nice addition! If only I had some more time ... I would love to sort of reverse engineer the protocol to control the keyboards special functions and write some kind of libusb(?) wrapper to access them.

 

The only issue I would really like to have a solution for is "|\". Do you maybe have some suggestions where to look? I just don't know where to start.

 

Thank you for looking into the Linux support for the K90! :biggrin:

Link to comment
Share on other sites

Re, the script is going forward well, I just hit a few unexpected issues, nothing to worry about. I hope... I will be able to post a half-decent version (with comments and examples) tomorrow.

 

For your questions:

- Is it possible somehow to use the G-keys for binds in games?

As my script is a level below, it should be possible to simulate a combination of keystrokes (up, up, down, left, a, wait 3 seconds, space, space, p, ...), although this is at system level, so I'm not sure (I didn't try it). Again, here you might give xmacro or xsendkeycode a try for a small shellscript.

 

 

- Is there a keycode for the 'disable windows-key'-key, or is it handled internally in the keyboard?

xev reports a keycode 115, so this is a native keyboard key (not on the same event interface as the g keys).

 

- How do you estimate the chance of getting to control the keyboards backlight and other features?

Here the backlight works as expected with the backlight key. For what I see, this is controlled internally by the keyboard (thus no controlling trough the OS).

 

- Did you adjust swm's xorg.conf much to fix the ALT issue (switching terminals)? If so, could you post your edits please?

I adjusted my xorg.conf with swm's fix, but my xorg.conf is completely handcrafted, so few are the chances that it's compatible with your setup. Note that there is still one extra issue I need to solve there too, as smv's fix broke my mouse's 'next' and 'previous' buttons. Anyway, it's here: xorg.conf

 

- Do you experience any other out of the ordinary issues on Linux?

The G9, G17 and G18 buttons send signal on the 2 channels, making them quite buggy (ex: G17 is like play/pause and G18 is like stop). This means I won't use them in my script - we're left with a total of 21 signals to customize from :)

 

EDIT:

I just found out that cron only allows per minute granularity, this will make it hard to use this script for gaming purposes (unless if you can wait one minute per executer command). It is possible to attain more granularity by combining multiple cron jobs & sleep, but there is no clean way to do it that way.

Live use should be possible by taking the input from an alternate way, I might look into this for a further version. (I tried to get a bit of modularity in the script)

Link to comment
Share on other sites

I will respond to your answers on my questions and review your script this week-end. Quick peek: nice job.:biggrin:

 

Edit:

 

About your answers to my questions:

 

Here the backlight works as expected with the backlight key. For what I see, this is controlled internally by the keyboard (thus no controlling through the OS).

 

The backlight actually works as expected, sure, but I know the windows drivers can control the intensity by using the official Corsair software. I suppose they are not prepared to just hand over the protocol so it's a (low priority) possibility to sniff the usb traffic and figure it out on our own :biggrin:

 

I adjusted my xorg.conf with swm's fix, but my xorg.conf is completely handcrafted, so few are the chances that it's compatible with your setup. Note that there is still one extra issue I need to solve there too, as smv's fix broke my mouse's 'next' and 'previous' buttons. Anyway, it's here: xorg.conf

Doesn't your Xorg work out of the box? The latest versions should, but you'll need customizations when using proprietary drivers. I'll try the fix at a later time.

 

(ex: G17 is like play/pause and G18 is like stop)

This behaviour is exactly the same here, but somehow Corsair managed to keep them apart. Maybe worth looking into when the rest is finished ;)

 

I reviewed your script:

 

  • The script also depends on x11-apps/xhost
  • Line 148: You should use $(dirname $0) to determine the directory
  • Line 182: You could use user=${USER} or possibly ${SUDO_USER}
  • It would be better if all the parameters where on top, or where in a config file. Remember most people are lazy and they just want a quick start. When it doesn't work, most will abandon it and only some of them will actually read what you typed. Nonetheless, good documentation is essential.
  • Personally, I would figure that there must be some way in linux to directly listen to the events and immediately take action, instead of waiting for a while. In my opinion, cronjobs are not the way to tackle this issue. Maybe this would help: http://stackoverflow.com/questions/1262310/simulate-keypress-in-a-linux-c-console-application As you can simulate keypresses of keys that aren't actually on the keyboard (F13, F14 ..), or maybe there actually are events for Gxx keys!? Could possibly also help with the bind keys in games issue. Don't take this as the only solution: There may be even better ways to solve this!
  • You even managed to add some of the questions I had to the script! Great!

 

Finally I must say I really appreciate your efforts and your doing the open source community and of course also Corsair a great favor. They should be grateful. Thanks! :sunglasse

Link to comment
Share on other sites

Sent from my mobile on holliday, i'll be brief.

 

Tnx for the feedback,

 

1. I'll update the code with proposed changes as soon as back from holliday, tnx for the code review.

 

2. I agree getting the usb codes wiretapping windows usb would indeed be the easiest way of getting the low level control codes, unfortunately I don't know the fragile OS well enoigh to do so.

 

3. I have some trouble with parameter order as some require functions to be initialised.. I'll try to work on conf file when I'm back.

 

4. Just before leaving, I tested to solve the cron issue. It should be easy to replace with a tail function, but I'm planning to leave the cron possibility as well, as it is usefullto be able to cancel for sysadmin.

 

5. For the G9 17 18 issues, I believe the solution woud require multiplexing events, but also to disable X listening for some inputs on its keyboard event.

 

6. My xorg works on default, but does not function with dual display by default.

 

Tnx again for feedback, I'll be back next week.

Link to comment
Share on other sites

The basic functions probably do work as advertised, but you will most likely also experience (some) issues discussed in the topic start.

 

Edit:

As the K60 does not have G-keys, you dont have to worry about that so I guess you're good to go.

 

Thanks for your heads up !!! Was actually thinking of ordering the K90 mostly cause of the blue back lights since I don't use the G keys (mostly play FPS games) but then again I would be paying for features that I don't use, in the end I think the k60 is a better buy in my case(no blue lights though :[pouts:).

Link to comment
Share on other sites

I've changed the variables you pointed me and did a separate conf file.

 

I'm working towards gaming mode support, although this implies some major changes in the code...

I thus pushed the actual changes as version 1.0 (check github) and just started working on version 1.5 with.

 

In this version I'm trying to get a separate file for each layout, as well as the said real time mode implemented.

 

edit:

just pushed 1.6 ... code has been heavily reflifted, it's a dev release and is still a bit incomplete

Link to comment
Share on other sites

  • 2 weeks later...

Hi, I recently stumbled across the exact same issue with my mouse (razer imperator), and as expected, this scripts allows me to catch the clicks that go on another /dev/eventxx than the usual mouse clicks.

 

I thus decided to rename the git repo to be more general than just K90 bound.

Please update your links to

https://github.com/jupiter126/Linux_Custom_Control_Device

Link to comment
Share on other sites

  • 2 months later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...