And the keyboard lose the match

Ok this is becoming a rite: everytime I buy a new keyboard, something is just wrong and I need to fix it. This time the problem was the extended keys as I already told in the previous blog entries. Well today I think I have dominated it completely, now it works 😀

The solution of this required quite a bit of work, but 34 hours after I bought the keyboard, it was working fine. I have prepared a patch which can be used to make it working, but it’s not complete yet.

If you want to know in deep which problem was it, the solution I found and the way to make it work if you have one, continue the read of this entry.

The problem

X.org uses a 8-bit field to contain the keycode of a given key, this because of the limitation of AT and other protocols. This field is actually used with 7-bit in AT-compatible keyboards (like classic PS2 ones) because of a protocol limitation: the 8th bit (0x80) is used to deal with keyup/keydown event. That is, the sequence of event seen by the keyboard manager is, for example for the ‘V’ key: 0x2F 0xAF; the keyboard manager then &0x7F to have the keycode and &0x80 to recognize the keyup/down.

This limits the number of possible keys on AT protocols to 128 (well actually a bit less as 8 codes are reserved so you have 120 keys). My keyboard, like many of the ones I considered to buy, have more than 128 keys (note that the basic keyboard is usually 105 keys).

The kernel was reporting in atkbd just the “base” keys which was able to be read by scancodes with the 7-bit + 1 field to Xorg with the normal keyboard driver, so I thought of using the new evdev one which uses the input event driver, where I was able to see all the keys of the keyboard

The problem is: as the extra keys have a code > 127, they should go in the range 0x80-0xFF.. but those are codes used by atkbd to see the keyup/keydown, so how Logitech dealt with them?

The solution was probably simple at their eyes, USB supports 16-bit codes, and so the input event driver does, so they just used codes >0xFF.

So I selected the evdev driver in X, and then tried it.. ZoomIn key was seen as ‘V’, becasue its code should have been 0x12F, with V code being 0x2F.

As the first try to enlarge the size of the code field in X resulted in a complete failure, I started thinking for alternative less-invasive solutions.

The solution

The binary code for a base key is: X n n n n n n n, where n is a bit and X is ignored as keyup/keydown bit. The binary code for an extended is n X n n n n n n n. The evdev driver doesn’t need to know about the keyup/keydown bit; actually the codes it receives have that bit stripped off anyway, as the event type deals with keyup/keydown.

At this point the solution was clear, as the resulting code is a 9-bit field with 8 meaningful bits and 1 bit discarded, I just needed to remove that single bit and then have n n n n n n n n as the keycode. Easy said, difficult to do actually.

The problem resided in the fact that there was a “key translation” code in the evdev driver, as the keys seen via evdev are quite different from the ones seen by the atkbd driver so to avoid rewriting all the rules, they just added a code which translates the evdev codes in atkbd compatible codes, but this crimpled a lot fo the extra keys I have, so I managed to remove all that cruft, and then I needed to remap all the base key which used a different code (arrows, ins/del/pgdown/pgup and so on). This took quite a while to find out how to do that as there aren’t docs about this on X.org site as far as I could see, so it required many hours to me to hack that.

Then I configured the extra keys with codes/keysysm pairs for a new “logilx700” model, so to have the key available in KDE.

Unfortunately, it wasn’t all clear.

The problems still present

There are still a couple of issues I wasn’t able to smash this night but I hope to do soon;

• the WIN key doesn’t react as it should and is ignored by KDE (note: I found the problem while I was here so this should be fixed in the patch I linked before but I haven’t tried it right now);
• the ZoomIn/ZoomOut keys aren’t well-read by the system, and I’m not able to use them on KDE for now;
• the mouse’s buttons are seen like buttons as they are and they aren’t remappable on KDE.. this is something which needs to be changed in kdelibs.. I’ll try;
• this is the major problem: some keys are “ghosts” of other, for example if I press the “windows list” key it acts like a Stop key. I’m not sure what’s the deal with them but I’ll try to find out soon, they are just a few, the main ones works fine as they should.

Anyway the keyboard itself works well and is quite comfortable to use, a good choice 🙂

As soon as I’ve cleared out the above problems I’ll submit the patch to Xorg to see if it’s good enough.