You are not logged in.
Hi All,
I've just gone mechanical and bought a Gigabyte Osmium keyboard. Basic functionality is there and also the (fn) media keys, audio wheel and backlighting wheel work. It comes with five programmable macro keys, G1 to G5, and another (large) button which cycles five times to effectively give you five sets of those G keys. I didn't expect to assign macros to the keys under Linux but I was hoping they'd be recognised so I could assign to them with xbindkeys. Alas no.
The G keys and the "cycle" button show no output with "xbindkeys -mk" but do with "xinput --test-xi2"
xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech G9x Laser Mouse id=8 [slave pointer (2)]
⎜ ↳ Logitech G9x Laser Mouse id=9 [slave pointer (2)]
⎜ ↳ A1 Gaming keyboard id=11 [slave pointer (2)]
⎜ ↳ Osmium Interface id=13 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ A1 Gaming keyboard id=10 [slave keyboard (3)]
↳ A1 Gaming keyboard id=12 [slave keyboard (3)]
The "Osmium Interface" (pointer?) seems to be the culprit...
xinput --test-xi2 13
Osmium Interface id=13 [slave pointer (2)]
Reporting 12 classes:
Class originated from: 13. Type: XIButtonClass
Buttons supported: 13
Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" "Button Side" "Button Extra" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown"
Button state:
Class originated from: 13. Type: XIKeyClass
Keycodes supported: 248
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 0:
Label: Abs X
Range: 0.000000 - 32767.000000
Resolution: 0 units/m
Mode: absolute
Current value: 840.000000
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 1:
Label: Abs Y
Range: 0.000000 - 32767.000000
Resolution: 0 units/m
Mode: absolute
Current value: 525.000000
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 2:
Label: None
Range: 0.000000 - 767.000000
Resolution: 0 units/m
Mode: absolute
Current value: 0.000000
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 3:
Label: Abs Misc
Range: -128.000000 - 127.000000
Resolution: 0 units/m
Mode: absolute
Current value: 0.000000
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 4:
Label: Abs Misc
Range: -128.000000 - 127.000000
Resolution: 0 units/m
Mode: absolute
Current value: 0.000000
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 5:
Label: Abs Misc
Range: -128.000000 - 127.000000
Resolution: 0 units/m
Mode: absolute
Current value: 0.000000
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 6:
Label: Abs Misc
Range: -128.000000 - 127.000000
Resolution: 0 units/m
Mode: absolute
Current value: 9.000000
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 7:
Label: Abs Misc
Range: -128.000000 - 127.000000
Resolution: 0 units/m
Mode: absolute
Current value: 0.000000
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 8:
Label: Abs Misc
Range: -128.000000 - 127.000000
Resolution: 0 units/m
Mode: absolute
Current value: 0.000000
Class originated from: 13. Type: XIValuatorClass
Detail for Valuator 9:
Label: Abs Misc
Range: -128.000000 - 127.000000
Resolution: 0 units/m
Mode: absolute
Current value: 0.000000
Pressing G1 to G5...
EVENT type 17 (RawMotion)
device: 13 (13)
detail: 0
valuators:
flags:
6: 1.00 (1.00)
EVENT type 17 (RawMotion)
device: 13 (13)
detail: 0
valuators:
flags:
6: 2.00 (2.00)
EVENT type 17 (RawMotion)
device: 13 (13)
detail: 0
valuators:
flags:
6: 3.00 (3.00)
EVENT type 17 (RawMotion)
device: 13 (13)
detail: 0
valuators:
flags:
6: 4.00 (4.00)
EVENT type 17 (RawMotion)
device: 13 (13)
detail: 0
valuators:
flags:
6: 5.00 (5.00)
The "cycle" button (first press) gives
EVENT type 17 (RawMotion)
device: 13 (13)
detail: 0
valuators:
flags:
6: -52.00 (-52.00)
7: 0.00 (0.00)
9: 2.00 (2.00)
EVENT type 6 (Motion)
device: 13 (13)
detail: 0
flags:
root: 121.89/153.40
event: 115.89/107.40
buttons:
modifiers: locked 0x10 latched 0 base 0 effective: 0x10
group: locked 0 latched 0 base 0 effective: 0
valuators:
6: -52.00
7: 0.00
9: 2.00
windows: root 0x296 event 0x2200001 child 0x0
Is there any way I can utilise the output above so that I can put the extra keys to good use?
Interestingly there are lights for num lock, caps lock and scroll lock which work until I log in from the console, then no longer function but the keypresses do! There is this snippet from the log which may be relevant
Oct 31 17:15:50 arch64 kernel: hid-generic 0003:1044:7A03.000C: >input,hidraw5: USB HID v1.11 Device [Osmium Interface] on usb-0000:00:12.2-2.2/input2
Oct 31 17:15:50 arch64 kernel: input: Osmium Interface as /devices/pci0000:00/0000:00:12.2/usb3/3-2/3-2.2/3-2.2:1.1/input/input22
Oct 31 17:15:50 arch64 kernel: hid-generic 0003:1044:7A03.000D: >input,hiddev0,hidraw6: USB HID v1.11 Mouse [Osmium Interface] on usb-0000:00:12.2-2.2/input1
Oct 31 17:15:50 arch64 kernel: hid-generic 0003:1044:7A03.000E: >item 0 1 0 8 parsing failed
Oct 31 17:15:50 arch64 kernel: hid-generic: probe of 0003:1044:7A03.000E failed with error -22
I would really appreciate some help here and hopefully this could prove useful to future Linux Osmium owners
Edit: Also,
xinput --list-props 13
Device 'Osmium Interface':
Device Enabled (143): 1
Coordinate Transformation Matrix (145): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (274): 0
Device Accel Constant Deceleration (275): 1.000000
Device Accel Adaptive Deceleration (276): 1.000000
Device Accel Velocity Scaling (277): 10.000000
Device Product ID (263): 4164, 31235
Device Node (264): "/dev/input/event18"
Evdev Axis Inversion (278): 0, 0
Evdev Axis Calibration (279): <no items>
Evdev Axes Swap (280): 0
Axis Labels (281): "Abs X" (296), "Abs Y" (297), "None" (0), "Abs Misc" (298), "Abs Misc" (298), "Abs Misc" (298), "Abs Misc" (298), "Abs Misc" (298), "Abs Misc" (298), "Abs Misc" (298)
Button Labels (282): "Button Left" (146), "Button Middle" (147), "Button Right" (148), "Button Wheel Up" (149), "Button Wheel Down" (150), "Button Horiz Wheel Left" (151), "Button Horiz Wheel Right" (152), "Button Side" (267), "Button Extra" (268), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266), "Button Unknown" (266)
Evdev Middle Button Emulation (283): 0
Evdev Middle Button Timeout (284): 50
Evdev Third Button Emulation (285): 0
Evdev Third Button Emulation Timeout (286): 1000
Evdev Third Button Emulation Button (287): 3
Evdev Third Button Emulation Threshold (288): 20
Evdev Wheel Emulation (289): 0
Evdev Wheel Emulation Axes (290): 0, 0, 4, 5
Evdev Wheel Emulation Inertia (291): 10
Evdev Wheel Emulation Timeout (292): 200
Evdev Wheel Emulation Button (293): 4
Evdev Drag Lock Buttons (294): 0
Last edited by fabertawe (2012-10-31 18:28:52)
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
Some more info (a subtle bump)
lsmod | grep hid
hid_generic 1113 0
usbhid 36364 0
hid 85224 2 hid_generic,usbhid
usbcore 146026 9 uas,btusb,rt2x00usb,usb_storage,ohci_hcd,rt2800usb,ehci_hcd,usbhid,xhci_hcd
xinput --query-state 13
3 classes :
KeyClass
key[0]=up
key[1]=up
key[2]=up
key[3]=up
key[4]=up
key[5]=up
key[6]=up
key[7]=up
key[8]=up
key[9]=up
key[10]=up
key[11]=up
key[12]=up
key[13]=up
key[14]=up
key[15]=up
key[16]=up
key[17]=up
key[18]=up
key[19]=up
key[20]=up
key[21]=up
key[22]=up
key[23]=up
key[24]=up
key[25]=up
key[26]=up
key[27]=up
key[28]=up
key[29]=up
key[30]=up
key[31]=up
key[32]=up
key[33]=up
key[34]=up
key[35]=up
key[36]=up
key[37]=up
key[38]=up
key[39]=up
key[40]=up
key[41]=up
key[42]=up
key[43]=up
key[44]=up
key[45]=up
key[46]=up
key[47]=up
key[48]=up
key[49]=up
key[50]=up
key[51]=up
key[52]=up
key[53]=up
key[54]=up
key[55]=up
key[56]=up
key[57]=up
key[58]=up
key[59]=up
key[60]=up
key[61]=up
key[62]=up
key[63]=up
key[64]=up
key[65]=up
key[66]=up
key[67]=up
key[68]=up
key[69]=up
key[70]=up
key[71]=up
key[72]=up
key[73]=up
key[74]=up
key[75]=up
key[76]=up
key[77]=up
key[78]=up
key[79]=up
key[80]=up
key[81]=up
key[82]=up
key[83]=up
key[84]=up
key[85]=up
key[86]=up
key[87]=up
key[88]=up
key[89]=up
key[90]=up
key[91]=up
key[92]=up
key[93]=up
key[94]=up
key[95]=up
key[96]=up
key[97]=up
key[98]=up
key[99]=up
key[100]=up
key[101]=up
key[102]=up
key[103]=up
key[104]=up
key[105]=up
key[106]=up
key[107]=up
key[108]=up
key[109]=up
key[110]=up
key[111]=up
key[112]=up
key[113]=up
key[114]=up
key[115]=up
key[116]=up
key[117]=up
key[118]=up
key[119]=up
key[120]=up
key[121]=up
key[122]=up
key[123]=up
key[124]=up
key[125]=up
key[126]=up
key[127]=up
key[128]=up
key[129]=up
key[130]=up
key[131]=up
key[132]=up
key[133]=up
key[134]=up
key[135]=up
key[136]=up
key[137]=up
key[138]=up
key[139]=up
key[140]=up
key[141]=up
key[142]=up
key[143]=up
key[144]=up
key[145]=up
key[146]=up
key[147]=up
key[148]=up
key[149]=up
key[150]=up
key[151]=up
key[152]=up
key[153]=up
key[154]=up
key[155]=up
key[156]=up
key[157]=up
key[158]=up
key[159]=up
key[160]=up
key[161]=up
key[162]=up
key[163]=up
key[164]=up
key[165]=up
key[166]=up
key[167]=up
key[168]=up
key[169]=up
key[170]=up
key[171]=up
key[172]=up
key[173]=up
key[174]=up
key[175]=up
key[176]=up
key[177]=up
key[178]=up
key[179]=up
key[180]=up
key[181]=up
key[182]=up
key[183]=up
key[184]=up
key[185]=up
key[186]=up
key[187]=up
key[188]=up
key[189]=up
key[190]=up
key[191]=up
key[192]=up
key[193]=up
key[194]=up
key[195]=up
key[196]=up
key[197]=up
key[198]=up
key[199]=up
key[200]=up
key[201]=up
key[202]=up
key[203]=up
key[204]=up
key[205]=up
key[206]=up
key[207]=up
key[208]=up
key[209]=up
key[210]=up
key[211]=up
key[212]=up
key[213]=up
key[214]=up
key[215]=up
key[216]=up
key[217]=up
key[218]=up
key[219]=up
key[220]=up
key[221]=up
key[222]=up
key[223]=up
key[224]=up
key[225]=up
key[226]=up
key[227]=up
key[228]=up
key[229]=up
key[230]=up
key[231]=up
key[232]=up
key[233]=up
key[234]=up
key[235]=up
key[236]=up
key[237]=up
key[238]=up
key[239]=up
key[240]=up
key[241]=up
key[242]=up
key[243]=up
key[244]=up
key[245]=up
key[246]=up
key[247]=up
ButtonClass
button[1]=up
button[2]=up
button[3]=up
button[4]=up
button[5]=up
button[6]=up
button[7]=up
button[8]=up
button[9]=up
button[10]=up
button[11]=up
button[12]=up
button[13]=up
ValuatorClass Mode=Absolute Proximity=In
valuator[0]=840
valuator[1]=525
valuator[2]=0
valuator[3]=0
valuator[4]=1
valuator[5]=1
valuator[6]=12
valuator[7]=-52
valuator[8]=-80
valuator[9]=5
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
I'll work on a better reply later; however the "G" keys should be able to be remapped to usable buttons using the method I did for my Razer Naga
https://bbs.archlinux.org/viewtopic.php?pid=1181482
As far as the two "scrollwheels" those are likely the device listed as "Osmium Interface" you can probably remap those as well, but I'm not 100% sure how, you may have to edit a small C program (its already built for you, other than the keycodes) to capture input from the wheels and then send keypresses to the current window.
An unfortunate crux of the X11 system right now is not only that its very outdated and kind of clunky/bloated, but its documentation is now strewn about the internet, and difficult to understand. And many of those who knew the documentation well enough to provide assistance are no longer involved in the community. Fortunately, playing around with settings can get you pretty far pretty fast. You might be able to use xinput to monitor just device "13" and find what keypresses are actually used, and then just edit my script from the naga post above as neccessary. Basically the idea is that the designation between angle brackets is for the key that would normally be pressed, and the hex code was pulled from the symbols source file, and is the key that you want it to press.
Once you get it firing keypresses you can actually pick up on; you can use them for binding in games, or keybind them to bash scripts and the like. Pretty useful. I've got a multi-mode system setup on my Naga so that I can use WM functions when no games are in focus and only send the keypresses when the windows are in focus (a lot of wmctrl wizardry in the bash scripts, to make them NOT execute under certain conditions)
Offline
Thanks very much for replying Xaero252. I'm going to see how far I can get with the info you've kindly provided and report back.
Edit: I'm not making any progress with this. I can't find a "key <value>" for the "cycle" or "G" keys for a start.
"cat /dev/input/event18" is showing activity if that's relevant.
Last edited by fabertawe (2012-11-01 18:21:35)
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
Thanks very much for replying Xaero252. I'm going to see how far I can get with the info you've kindly provided and report back.
Edit: I'm not making any progress with this. I can't find a "key <value>" for the "cycle" or "G" keys for a start.
"cat /dev/input/event18" is showing activity if that's relevant.
Can you provide the output of xev after pressing and releasing one of the buttons? And also using each one of the wheels?
I have a feeling you will need to use the imwheel package to change the mapping of the two wheels; however if they are already firing keypress events then you will not.
I only need one of the buttons, however if you post all of them that is fine too. Basically what I am going to look for in the XEV:
KeyPress event, serial 43, synthetic NO, window 0x1200002,
root 0x502, subw 0x0, time 55872295, (171,-19), root:(177,30),
state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
XLookupString gives 1 bytes: (31) "1"
XmbLookupString gives 1 bytes: (31) "1"
XFilterEvent returns: False
This is the event for the button "1" on my Naga. You should see a similar output from the xev command for each of those keys. However, you may also see this tpe of response:
ButtonPress event, serial 39, synthetic NO, window 0x3200002,
root 0x502, subw 0x0, time 55933494, (72,108), root:(78,157),
state 0x0, button 1, same_screen YES
The above is for a mouse (or game controller) button event. This I have no experience remapping, but I'm sure enough digging can come up with an answer.
As you can see from the first event log, it returns keycode "10" which is associated with keysym 0x31, or the number "1" which correlates to <AE01 > Somehow a similar mapping solution must be possible. Basically what I'm using xmodmap to do is change the association (for my mouse only) of keycode 10 from "1" to a different keypress, so I can use it for keybinding without inhibiting normal keyboard use.
Offline
Can you provide the output of xev after pressing and releasing one of the buttons? And also using each one of the wheels?
I have a feeling you will need to use the imwheel package to change the mapping of the two wheels; however if they are already firing keypress events then you will not.
I only need one of the buttons, however if you post all of them that is fine too
The problem I have is that xev returns nothing for the "cycle" or "G" buttons. It does for the audio wheel but I don't want to remap the wheels. As I posted above the only output for those buttons is from "xinput --test-xi2 13", which is the "Osmium Interface", and /dev/input/event18. I suspect some kind of hid driver's needed. If there is some way of tapping the xinput output then great. Maybe some way of monitoring /dev/input/event18?
Thanks for all your help.
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
Xaero252 wrote:Can you provide the output of xev after pressing and releasing one of the buttons? And also using each one of the wheels?
I have a feeling you will need to use the imwheel package to change the mapping of the two wheels; however if they are already firing keypress events then you will not.
I only need one of the buttons, however if you post all of them that is fine too
The problem I have is that xev returns nothing for the "cycle" or "G" buttons. It does for the audio wheel but I don't want to remap the wheels. As I posted above the only output for those buttons is from "xinput --test-xi2 13", which is the "Osmium Interface", and /dev/input/event18. I suspect some kind of hid driver's needed. If there is some way of tapping the xinput output then great. Maybe some way of monitoring /dev/input/event18?
Thanks for all your help.
I think that you are probably right, kind of.
Doing a lot of reading on xi2 since your post.
This blog post brings up how to utilize the information provided by xi2 in an application (C program, device compatibility layer, etc.) and I think is probably the first step to a correct approach on this matter. Basically you have to hook into xi2, listen to the device, and then capture its keypresses, then send them back to the X session as different normal keypresses. This would be quite the pain to write, just to enable five keys.
However, I don't think the intention of xi2 is to make it impossible to remap something so simple. I think it simply means that its not the same information I'm used to seeing with xinput. I'm probably going to troll in IRC for an answer on how to accomplish things with xi2.
There is usable output from
xinput --test-xi2 13
In that, when you pressed G1-5 you got this output:
flags:
6: 1.00 (1.00)
Which incremented by exactly 1.00 for each key higher (ex. G2 was 2.00).
You could probably do some bash confoolery to read input from xinput and then output a keycode.
Another thing I remember that would be of use for this exact situation is the old workaround for Ventrilo's PTT under wine via a small C program "ventriloctrl"
/*******************************************************************/
/* This version of ventriloctl by Caleb Gray (caleb@calebgray.com) */
/*******************************************************************/
/* Console Output */
#include <stdio.h>
/* Input Detection */
#include <fcntl.h>
#include <linux/input.h>
/* X11 */
#include <X11/Xlib.h>
#include <X11/keysym.h>
/* Configuration */
#define SIMULATEKEY XK_A // Simulate Key Press
#define VENTRILO "Ventrilo" // Ventrilo Window Name
/* Global Variables */
Display *display;
Window window;
Window *windowVentrilo;
/* Functions */
XKeyEvent create_key_event(Display *display, Window window, Window windowRoot, int press, int keycode, int modifiers)
{
XKeyEvent event;
event.display = display;
event.window = window;
event.root = windowRoot;
event.subwindow = None;
event.time = CurrentTime;
event.x = 1;
event.y = 1;
event.x_root = 1;
event.y_root = 1;
event.same_screen = True;
event.keycode = keycode;
event.state = modifiers;
event.send_event = 1;
event.serial = 0;
if (press) { event.type = KeyPress; } else { event.type = KeyRelease; }
return event;
}
int ventrilo_still_running()
{
char *windowName = VENTRILO;
return XFetchName(display, *windowVentrilo, &windowName) != BadWindow;
}
Window *find_window(Display *display, Window parentWindow, const char *windowName)
{
// Variables
int i;
// Get the "Window" Tree
Window root;
Window parent;
Window *children = 0;
unsigned int childrenCount = 0;
XQueryTree(display, parentWindow, &root, &parent, &children, &childrenCount);
// Crawl the "Window" Tree
char *window_name = 0;
Window *window = 0;
for (i = 0; i < childrenCount; ++i) {
// Look For "windowName"
if (XFetchName(display, children[i], &window_name) == 1) {
if (strcmp(windowName, window_name) == 0) {
XFree(window_name);
return &children[i];
}
XFree(window_name);
}
// Crawl the Child and Look For "windowName"
window = find_window(display, children[i], windowName);
if (window != 0) {
XFree(children);
return window;
}
}
// Free the Children! lol
if (children != 0) XFree(children);
// Return
return 0;
}
int ventriloctl(int argc, char **argv)
{
// Usage
printf("\n");
// Initialize "Display"
display = XOpenDisplay(0);
if (display == NULL) {
printf("Error: Could not open display!\n");
return 1;
}
// Initialize Root "Window"
window = XDefaultRootWindow(display);
if (!window) {
printf("Error: Could not grab root window!\n");
return 2;
}
// Initialize Ventrilo "Window"
windowVentrilo = find_window(display, window, VENTRILO);
if (!windowVentrilo) {
printf("Error: Could not find Ventrilo window!\n");
return 3;
}
// Convert Key String to Number
unsigned int key = atoi(argv[2]);
unsigned int simulatekey = XKeysymToKeycode(display, SIMULATEKEY);
// Open the Input
int device = open(argv[1], O_RDONLY);
// Loop
struct input_event ev;
XKeyEvent event;
while (ventrilo_still_running()) {
// Read from the Input
read(device, &ev, sizeof(struct input_event));
// Check Input
if (ev.type == 1 && ev.code == key) {
// Simulate Key Press/Release
event = create_key_event(display, *windowVentrilo, window, ev.value, simulatekey, 0);
if (ev.value == 1) {
XSendEvent(event.display, event.window, True, KeyPressMask, (XEvent *) &event);
} else {
XSendEvent(event.display, event.window, True, KeyReleaseMask, (XEvent *) &event);
}
XFlush(display);
}
}
// Return
return 0;
}
int findkey(int argc, char **argv)
{
// Usage
printf("\n");
printf("Press the key you would like to use as\n");
printf("your Ventrilo Push-To-Talk key now,\n");
printf("then execute the command listed.\n");
printf("Press Ctrl+C when finished.\n");
printf("\n");
// Open the Input
int device = open(argv[1], O_RDONLY);
// Loop
struct input_event ev;
while (1) {
// Read from the Input
read(device, &ev, sizeof(struct input_event));
// Print the Command
if (ev.type == 1 && ev.value == 1) printf("%s %s %i\n", argv[0], argv[1], ev.code);
}
// Return
return 0;
}
/* Main Loop */
int main(int argc, char **argv)
{
// Programs
if(argc == 2) return findkey(argc, argv); // Find Key
if(argc == 3) return ventriloctl(argc, argv); // Ventrilo Ctrl
// Usage
printf("\n");
printf("Usage: %s <device> [key]\n", argv[0]);
printf("\n");
printf("Running this program without 'key' specified\n");
printf("will run the 'FindKey' sub-program.\n");
printf("\n");
// Return
return 0;
}
This simple application just watches for an XKeyEvent and then decides whether thats the key you want or not. Then if it is, it sends the key you want to the window titled "Ventrilo" Using the same methodology, you could watch for the Xi2 events (as detailed in the blog post) and then conditionally check for each key, and then send the key you desire to the PID of the current X session.
I wish for the life of me, that I was a more talented programmer; I envision there being a tool to handle device key mapping/remapping via GUI for X. No such proper tool exists.
Offline
Thanks again for all your help and the info. I'm afraid even simple programming is beyond me here. I'll read it all a few more times and see what sinks in! I did a tiny bit of c/c++ years ago but it's a distant blur now. I did enjoy Perl back in the day.
One thing puzzles me still - the lights for num lock, caps lock and scroll lock work *until* I log in from the console. The num lock then comes back on and stays on and can't be turned off. All those keys still work as expected though. Any thoughts?
Cheers.
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
They probably did some weird hardware confoolery with the lock lights as well. If when you turn your computer on the lights don't function, then that is the case. I don't like how manufacturers are starting to deviate more and more from the standards for input devices. I understand motion control devices and touchscreens are still young, but they do things like what you are experiencing with keyboards and mice. Would it be that hard to just implement it in the standard fashion?
I wouldn't doubt that the Num/Scroll/Capslock lights are part of the osmium interface and require the same HID driver to function via interrupt or something. I used to use some pretty exotic gaming keyboards in the day, but I've since switched to a Topre Realforce keyboard, and couldn't be happier with the purchase. Expensive, but durable, which is more than any of those so-called gaming keyboards could say. Also zero incompatibilities with any OS.
Offline
Hadn't heard of that keyboard, yeah a little above my budget. I thought this one was expensive I'm not disappointed with this purchase though, I never expected to get the macro keys working (not yet anyway). It's a lovely keyboard, beautiful to type on and looks great. I wasn't actually looking for a gaming keyboard as such (I'm not a big gamer but do like FPS) but had spent so long "researching" mechanical keyboards I was at the point where I needed to make a decision! The reviews were good, so I plumped for the Osmium. I also bought a Logitech G9X mouse after much researching and it works perfectly, very nice.
If any progress gets made I'll update the thread. I really appreciate all the your advice, it's been educational at least
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
Hi everyone,
Yes, sorry for resurrecting this old thread - could not find many other sources for my problem on the internet. Thought that since there are some people concerned about the MM keys they should have sorted this really annoying "feature" out first.
I am running CentOS6.4 (2.6.32-358.18.1.el6.x86_64) and recently purchased this keyboard. However, having issues with the pipe / backslash / bar key.
The key does not auto repeat and also when alternated with space as in space pipe space (or pipe with any other key) the pipe key repeats 2-3 times.
The exact same issue as described here for a corsair keyboard: http://forum.corsair.com/v3/showthread.php?t=119654
The gigabyte support is useless and they say it's only for Windows.
Any ideas? Tried changing the keys and xev and other things (which help, but this just changes the character, not the key behaviour.
Don't care about the MM keys, just want my pipe back.
Was running firmware 1.05 and the support sent me an older 0.96 firmware but no difference. Other keyboards are fine, and the gigabyte keyboard works as expected in windows.
Holding the \ key and pressing r in between does this:
\r\\\r\\\r\\\r\\\
KeyPress event, serial 33, synthetic NO, window 0x4200001,
root 0x176, subw 0x0, time 341003010, (714,498), root:(716,525),
state 0x0, keycode 27 (keysym 0x72, r), same_screen YES,
XLookupString gives 1 bytes: (72) "r"
XmbLookupString gives 1 bytes: (72) "r"
XFilterEvent returns: False
KeyPress event, serial 33, synthetic NO, window 0x4200001,
root 0x176, subw 0x0, time 341003010, (714,498), root:(716,525),
state 0x0, keycode 51 (keysym 0x5c, backslash), same_screen YES,
XLookupString gives 1 bytes: (5c) "\"
XmbLookupString gives 1 bytes: (5c) "\"
XFilterEvent returns: False
KeyRelease event, serial 33, synthetic NO, window 0x4200001,
root 0x176, subw 0x0, time 341003010, (714,498), root:(716,525),
state 0x0, keycode 51 (keysym 0x5c, backslash), same_screen YES,
XLookupString gives 1 bytes: (5c) "\"
XFilterEvent returns: False
KeyRelease event, serial 33, synthetic NO, window 0x4200001,
root 0x176, subw 0x0, time 341005003, (714,498), root:(716,525),
state 0x0, keycode 27 (keysym 0x72, r), same_screen YES,
XLookupString gives 1 bytes: (72) "r"
XFilterEvent returns: False
Thanks for your help in advance.
Offline
Hi lonestarr_333,
I'm not having the problem you describe with pressing keys and repeats. Sounds like a faulty board. Saying that, I sometimes get a problem when logging in from the console where it seems the keyboard has become super sensitive (manicly flashing cursor) and it's impossible to type anything that's recognised. This appears to happen if I accidentally press that big "Aivia" button though, so I'm careful with that (strangely, clicking the volume wheel sometimes stops it).
I blame all this on the "Osmium interface"... which also spams my login prompt at every boot...
Sep 12 10:52:41 arch64 kernel: usb 4-1.1: new full-speed USB device number 4 using ehci-pci
Sep 12 10:52:42 arch64 kernel: input: A1 Gaming keyboard as /devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.1/4-1.1:1.0/input/input15
Sep 12 10:52:42 arch64 kernel: hid-generic 0003:0665:6000.0003: input,hidraw2: USB HID v1.11 Keyboard [A1 Gaming keyboard] on usb-0000:00:13.2-1.1/input0
Sep 12 10:52:42 arch64 kernel: input: A1 Gaming keyboard as /devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.1/4-1.1:1.1/input/input16
Sep 12 10:52:42 arch64 kernel: hid-generic 0003:0665:6000.0004: input,hidraw3: USB HID v1.11 Device [A1 Gaming keyboard] on usb-0000:00:13.2-1.1/input1
Sep 12 10:52:42 arch64 kernel: input: A1 Gaming keyboard as /devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.1/4-1.1:1.2/input/input17
Sep 12 10:52:42 arch64 kernel: hid-generic 0003:0665:6000.0005: input,hidraw4: USB HID v1.11 Keyboard [A1 Gaming keyboard] on usb-0000:00:13.2-1.1/input2
Sep 12 10:52:42 arch64 mtp-probe[597]: checking bus 4, device 4: "/sys/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.1"
Sep 12 10:52:42 arch64 mtp-probe[597]: bus: 4, device: 4 was not an MTP device
Sep 12 10:52:42 arch64 kernel: usb 4-1.2: new full-speed USB device number 5 using ehci-pci
Sep 12 10:52:42 arch64 kernel: hid-generic 0003:1044:7A03.0006: item 0 1 0 8 parsing failed
Sep 12 10:52:42 arch64 kernel: hid-generic: probe of 0003:1044:7A03.0006 failed with error -22
Sep 12 10:52:42 arch64 kernel: input: Osmium Interface as /devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.2/4-1.2:1.1/input/input18
Sep 12 10:52:42 arch64 kernel: hid-generic 0003:1044:7A03.0007: input,hiddev0,hidraw5: USB HID v1.11 Mouse [Osmium Interface] on usb-0000:00:13.2-1.2/input1
Sep 12 10:52:42 arch64 kernel: hid-generic 0003:1044:7A03.0008: No inputs registered, leaving
Sep 12 10:52:42 arch64 kernel: hid-generic 0003:1044:7A03.0008: hidraw6: USB HID v1.11 Device [Osmium Interface] on usb-0000:00:13.2-1.2/input2
Sep 12 10:52:42 arch64 mtp-probe[614]: checking bus 4, device 5: "/sys/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.2"
Sep 12 10:52:42 arch64 mtp-probe[614]: bus: 4, device: 5 was not an MTP device
Anyone know if it's possible to "blacklist" or disable this interface completely? On reflection, I wouldn't advise anyone use this keyboard with Linux, although it's bearable.
Cheers.
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
I've recently got this keyboard (I liked the idea of a USB3 passthrough port, plus it looked like a decent unit). Same issues as lonestarr, backslash does not auto repeat and holding it down while pressing other random keys (space, any letters, numbers etc) causes excessive repeats of the backslash key, like this: \e\\\g\\\v\\\e\\\g\\\h\\\y\\\i\\\r\\\g\\\hj\\\j\\\. I've also got the issues of the num lock, scroll lock and caps lock lights not changing state on the keyboard lights, but the states actually do change. Pressing the Aivia button, or the G1-G5 keys cause weird issues where the keyboard appears to stop working, but I think it's a focus issue since selecting windows is impossible. Unplugging the keyboard fixes it, and sometimes the volume button (pressing the volume wheel on the keyboard) fixes it too.
I'm running Ubuntu 13.10 AMD64, however same happens on 14.04 as of yesterday's (2014-02-23) updates. Interestingly the problem of the backslash key doesn't occur in FreeBSD (10.0 AMD64, live USB, didn't install it to try X etc), nor in the BIOS (Gigabyte 990FXA-UD3), and of course it works fine in Windows.
I've tried blacklisting the Osmium Interface via a udev rule, but that doesn't seem to work.
$ cat /etc/udev/rules.d/99-gigabyte-osmium-interface.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="1044", ATTRS{idProduct}=="7a03", OPTIONS=="ignore_device"
$ lsusb
--snip--
Bus 001 Device 005: ID 1044:7a03 Chu Yuen Enterprise Co., Ltd
Just a thought.. would it be possible that the Osmium Interface should be registered as a keyboard rather than a pointer? (xinput list) Is there any way to test this?
Offline
Beijmn over on the Corsair forums has a Corsair Vengeance K70B keyboard, which had the same problem with the misbehaving backslash key. He also wrote a patch to the hid-generic driver that fixes the backslash key issue. See http://forum.corsair.com/v3/showthread.php?p=698944 for more details. I tried applying the patch to the Ubuntu 13.10 kernel, and it worked for the Osmium. Interesting that the two keyboards have the same issue, must use similar electronics?
edit: thought I'd better include Beijmn's patch here, in case the Corsair forum goes down or something. Not sure which version of the Linux kernel this is for, but I found where to put it in Ubuntu 13.10's 3.11 kernel (was around 50 lines earlier in the file from memory).
--- drivers/hid/hid-core.c 2014-01-19 16:27:37.674829730 -0500
+++ hid-core_patched.c 2014-01-19 16:24:39.992006709 -0500
@@ -1130,6 +1130,14 @@
{
struct hid_driver *hdrv = hid->driver;
int ret;
+ static bool skip = false;
+
+ if (skip) {
+ skip = false;
+ return;
+ }
+ if (usage->code == KEY_BACKSLASH && value == 1)
+ skip = true;
if (!list_empty(&hid->debug_list))
hid_dump_input(hid, usage, value);
Last edited by lem79 (2014-02-25 02:34:18)
Offline
Beijmn over on the Corsair forums has a Corsair Vengeance K70B keyboard, which had the same problem with the misbehaving backslash key.
lem79, it's very odd why I've not encountered this problem with the backslash key. Could it be something else interfering, like a DE component? I don't use a DE myself, I have Compiz as the WM and xsettingsd, not much more than that!
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
lem79 wrote:Beijmn over on the Corsair forums has a Corsair Vengeance K70B keyboard, which had the same problem with the misbehaving backslash key.
lem79, it's very odd why I've not encountered this problem with the backslash key. Could it be something else interfering, like a DE component? I don't use a DE myself, I have Compiz as the WM and xsettingsd, not much more than that!
Well, the problem occurs once a Linux kernel boots on my machine (tested Ubuntu 11.04, 13.10, 14.04, including in single user root console), but does not occur in BIOS or even the GRUB menu. That to me says Linux itself isn't handling these keyboards properly.
Gigabyte responded to me and offered the 0.96 firmware, which I could post somewhere if anyone is interested. I haven't tried it yet. They said they can't support Linux with this keyboard because they don't get the support from their manufacturer. I'm assuming Corsair and Gigabyte are using the same (or similar) keyboard controller. I asked Gigabyte just now who the manufacturer/supplier is, so that perhaps the Linux community can contact them for details on their chips, so maybe we can have a go at writing proper support. Here's hoping Gigabyte will tell me (not that I could write the support, but if I can at least get the info, that'll be a good step).
Offline
Gigabyte responded to me and offered the 0.96 firmware, which I could post somewhere if anyone is interested. I haven't tried it yet. They said they can't support Linux with this keyboard because they don't get the support from their manufacturer.
At least you got a reply from them, I had nothing back when I tried. Thanks for chasing it up.
How is the firmware upgraded? From Windows presumably? If you could post it I'd certainly take a look, thanks.
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
How is the firmware upgraded? From Windows presumably? If you could post it I'd certainly take a look, thanks.
Yep it uses a Windows tool. I don't know if it gives the option to backup the existing firmware, doesn't look like it from the PDF included in the archive. I've shared the updater via Ubuntu One, let me know if you have trouble downloading it: http://ubuntuone.com/6nAQpdsBC4UFj94WpAir68 (Firmware_updater_Osmium_V096.zip, 1.06M)
Offline
Lem79, I have the zip, thanks. Will fire up Virtualbox and take a look. Cheers.
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
Nothing really new to report, but I found switching to a VT (Ctrl-Alt-F1) and back fixes the unresponsiveness issues I get in X if I accidentally press the Aivia button or G1-G5 keys. Pressing either causes the keyboard (via the Osmium interface) to generate lots of input. Using the volume scrollwheel (which also reports its activity via the Osmium interface) stops that. But X remains unresponsive to keyboard input at that point, where I then need to switch to a VT and back, then everything is fine.
Weird.
I want to submit a bug to the upstream Linux kernel, but not really sure how that should be done. I'm convinced it's Linux handling the keyboard poorly (and the Corsair Vengeance K70B, and a few other mechanical keyboards), since the issues don't exist in BIOS, GRUB, FreeBSD 10, or Windows. I haven't tried any other OSes.
Offline
I have the same keyboard, any news about it?
Sorry for my bad english, I'm not english native
Offline
No news from me unfortunately. I have since purchased a few Deck Hassium (non-Pro, but they're essentially the same as the Pro) keyboards. They have a key on them that switches between n-key rollover (NKRO) and 6-key rollover (6KRO). They default to 6KRO, and work perfectly under Linux (Ubuntu 14.10 at time of writing), whereas the Osmium still has its issues mentioned above. When the Deck Hassium is in NKRO however, it has the same non-repeating backslash issue, but it generates one less key event when other keys are pressed, so instead of two backslashes, it only generates one.
Worthy of note is that the Roccat Ryos mechanical keyboard doesn't have the backslash key issue, even in NKRO mode (confirmed by Stefan Auschwitz, the Roccat Linux driver maintainer).
A friend of mine looked into it a bit, and about as far as we got was that the USB report size from these keyboards when they're in NKRO mode is significantly different to when they're in 6KRO mode. NKRO report size is like 14 bytes or something, whereas 6KRO is 8 bytes. That's from vague memory though, but this might be a big clue as to why a lot of NKRO chipsets don't work in Linux properly?
Offline
Some good news... the n-key rollover and backslash issue seems to be fixed in Ubuntu 14.10 as at 2015-04-02, though I'm not sure when this actually happened. My kernel version at the moment is 3.16.0-34-lowlatency #45-Ubuntu SMP PREEMPT.
Reported working from the current Fedora alpha as well. I will test my Gigabyte Osmium later. I've only tested my regular keyboard (Deck Hassium non-Pro) so far.
Can anyone else confirm?
edit: might be this? http://www.gossamer-threads.com/lists/l … el/2128750
edit2: Confirm that the Gigabyte Osmium works fine now. Backslash repeats, the G1-G5 macro keys and Aivia button don't lock keyboard input up, and, the Num and Caps Lock LEDs change state. Scroll Lock changes in a Linux VT but not in X (doesn't seem to matter), but Caps Lock LED doesn't (however the caps lock state actually does change). Well, not perfect, but pretty much is. It's no longer annoying at all.
Last edited by lem79 (2015-04-02 02:03:53)
Offline
Hi lem79, thanks for the update.
Caps Lock LED works for me. Scroll Lock works but takes the Num Lock LED off. I've never been affected by the backslash problem but it's good to know it's been fixed.
On the off chance I booted up Virtualbox and tried assigning stuff to the G keys in WinXP but the only thing that happens is a repeating "^@" in a VT. I never did try the firmware update btw.
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
Sorry to resurrect this old thread, but does anyone still have the firmware ?
My keyboard briefly disconnects from USB when the Windows (Meta) or Fn keys are pressed.
Since those keys correspond to special cases (the Fn key changing codes for F1-F4 keys, and the Windows key being ignored after toggling win lock on), I think it might be a firmware corruption, leading to a reset of the microcontroller.
The Gigabyte support doesn't seem to be very cooperative.
Offline