I'm continuing to use my ancient Northgate OmniKey Ultra keyboard, which has outlived a variety of computers I've owned over the past (more than) twenty years, although it is now connected through several adaptors. But, I can type, and it's simply better than any of the toy keyboards sitting in my closet unused. Its only drawback is that it has no "Windows" key - known by Linux users as the "Super" key, and this is used commonly in both operating systems and various applications.

I've made several attempts in the past to "map" the [Omni] key to serve that function, but have never been successful. The web is, of course, full of suggestions, most of which are outdated, or simply don't work, so I thought I'd give it another shot to see if anyone can tell me what I'm missing.

Here's the background: The alphabet keys are standard English, and there is a set of normal function keys to the left, a separate set of mappable function keys across the top (which default to acting like Shift+Function keys), and a normal navigation/numeric keypad on the far right.

Between the central alphabet keys section and the navigation/numeric keypad on the far right is a separate keypad which is only for navigation - thus the normal state of things is that NumLock is generally always ON. This is, in other words, a 105 key keyboard. The [Omni] key is located in the center of this latter cluster with the left and right arrows on its left and right respectively, and the up and down arrows above and below it respectively. This is the key I would like to reassign to the Windows/Super key.

I'm using 64 bit Ubuntu 14.04.3 LTS, which no longer uses xmodmap, having switched to xkb a few versions ago. None of the usual high-level or GUI methods of reassigning keys respond at all to the key; these include the stock 'System Settings > Keyboard' utility and the CompizConfig Settings Manager's 'Ubuntu Unity Plugin.'

The responses seem to indicate to me that the key simply isn't detected, implying (I think) that the issue needs to be addressed at a lower level.

Using the xev utility from the command line, I have confirmed that the operating system "sees" the key. This is the output of xev when the key is pressed and released:

KeyPress event, serial 37, synthetic NO, window 0x3c00001,
root 0x2c5, subw 0x3c00002, time 55775673, (16,47), root1258,93),
state 0x0, keycode 120 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x3c00001,
root 0x2c5, subw 0x3c00002, time 55775817, (16,47), root1258,93),
state 0x0, keycode 120 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

So, the keycode for the [Omni] key is 120, but "keysym" has a 0 value (Home, for instance, has a keycode of 110 and a keysym value of 0xff50).

Again, using the terminal command:
sudo dpkg-reconfigure keyboard-configurations
confirms that I am using the "Generic 105 key (Intl) PC" keyboard layout, just as I selected during installation (actually, it was auto-detected, but who am I to argue?) In the drop-down, I noticed that there was actually a separate entry for the Northgate keyboards; I played around with that for a bit, but that didn't seem to make any difference.

From what I could glean from various internet postings, the mappings for xkb are located under /usr/share/X11/xkb/, the subdirectories of which are geometry, symbols, and keycodes.

/usr/share/X11/xkb/geometry contains graphic instructions for drawing the keyboard on the screen, so this isn't it.

/usr/share/X11/xkb/symbols contains a list of mnemonics like the line:
key <AE03> { [ 3, numbersign ] };
showing the interpretation of [A]lphabet section, row [E] switch when unshifted (3) and shifted (#). Similarly, the line
key <BKSL> { [ backslash, bar ] };
shows the interpretation of BKSL when unshifted (\) and shifted (|).

Straightforward enough, but what I need is where the definition of the mnemonics are.

These seem to be in /usr/share/X11/xkb/keycodes.
/usr/share/X11/xkb/keycodes/xfree86 for example has lines like:
<LWIN> = 115;
<RWIN> = 116;
So it seemed that I could change those lines to:
<LWIN> = 120;
<RWIN> = 120;
and be done with it.

That had no effect at all, so I tried the same thing with /usr/share/X11/xkb/keycodes/evdev, which also had no effect. There are a number of other files under /usr/share/X11/xkb/keycodes, but many of them, even ibm, had no definition for Windows keys. So I suspect I may be barking up the wrong tree. This is reinforced by the fact that xev shows that the keycodes 115 and 116 (identified as <LWIN> and <RWIN> above) are returned when I press [End] and the down arrow respectively on the dedicated Navigation keypad. I suspect this might mean that I'm lost.

So I have a couple questions that I would love to have answers to if anyone can help:

1) Is this the right area in which to be exploring and, if not, where should I be looking?
2) Assuming this is the right area, is there some way to determine which of the files under /usr/share/X11/xkb/keycodes is actually being used?
3) Do changes to these files (such as the substitution of <LWIN> above need to be compiled or merged into some other binary somewhere and, if so, how?

It should just be a matter of going into the settings and rebinding the key. You did try that, didn't you? I know that can be a little finicky at times, but it does work.

Attached Thumbnails

 

Thanks for the info and screen shot.

Yes, I tried that several times. The response (as if nothing was pressed at all) seems to suggest that the key is not recognized at some lower level. Actually I've tried all these things each time some new release of the OS comes out. Since I had to install everything new when I put in a new SSD, this is just my latest attempt to see if I can get things to work.

The screen shot you provided is what I was referring to when I mentioned "the stock 'System Settings > Keyboard' utility" above - I wasn't quite sure what to call it.

Hello CVAlkan,

It's been over 3 years, just wondering if you have made any progress or resolved the question. I have the identical keyboard, on Kubuntu 16.04, and like you would love to remap the otherwise useless [OMNI] key to Win, or Meta, or Super, or whatever the Linux community calls it this week.

I have a less than ideal solution, using a Soarer's Converter cable, that has a programmable chip inside the USB connector. Even there, it's sub-optimal, I had to create a temporary layer: Hit my Insert key on the navigation portion of the keyboard (you can pick your own) that temporarily sets Left-Alt to Left-Win, Right-Alt to Right-Win (again, you can remap any key to any key), which stays in effect until you press the Insert key again. Then the ALT keys go back to their normal behavior.

Anything but the [OMNI] key works.

There is also a companion listening utility. It does react when you hit the [OMNI] key, here's the output:
rE0 r12 +00 rE0 r73
rE0 rF0 r73 -00 rE0 rF0 r12

The significant part here is the "+00" and "-00" which are the make and break for that key. Unfortunately, this cannot be assigned to any remap on the "converter" chip.

Looking forward to see if you've made any progress.

Thanks!

Wow, it's been that long??? The short answer, sadly, is "No."

I suspect that your discovery of the "+00" and "-00" (which seems to be consistent with the "keysym 0x0" xev reports that I mentioned above) is the reason.

All the various suggestions I've tried seem to treat "0" as if it were invalid, although I don't recall ever seeing any error messages.

The good news is, of course, that the Northgate is still chugging along nicely, and is still the best keyboard I've ever used for serious typing.

I'd thought many times about pulling out a soldering iron, but I'm too damn old for that (maybe if one of the grandkids wants to learn something ???)

But thanks for asking, and be sure to post back if you ever run across something resembling a practical solution ...

I'm using a keyboard at this moment that had LCTL, LALT, RCTL, RALT. It now has, by way of altering the evdev file, LCTL, LALT, RWIN, COMP. I wonder if your problem was due to defining LWIN and RWIN as the same code and thereby confusing the system? Try just defining LWIN and leaving RWIN out.

Hi David:

I began kicking myself immediately when I read your suggestion. It makes good sense, and it had never occurred to me.

Sadly, though, it made no difference whatsoever.

But thanks much for pointing out a condition I had missed.

Maybe in another three years ...