TMK PS/2 to USB keyboard converter

[hasu]

This won't be updated and supported actively anymore.
Use new coverter firmware for IBM PC(XT, PS/2 and Terminal) instead now. (2020-07-02)
https://geekhack.org/index.php?topic=103648.0



This is a PS/2 to USB keyboard converter with some nice features.


Preassembled TMK PS/2-USB converter is available here!

HISTORY

• 2011/01/23  Initial version
  
• 2011/01/24  FIX: handle keys which need exceptional treatment
  
• 2011/02/25  added V-USB support
  
• 2011/05/31  PS/2 Multimedia key support.
  
• 2011/12/05  ISO/JIS keyboard support.
  
• 2013/12/02 Fix bugs and refactor. Pin configuration is changed.
  
• 2016/09/16 Keymap editor is available now!
  
• 2019/09/09 Update README and Makefiles
  

FEATURES

• Mouse keys
      You can emulates mouse move and button click using keyboard.
  
• Multimedia keys
      You can send key event like: system control(Power down, sleep,...), Volume down/up and Mute, Media control, Application launch, Browser control.
  
• USB NKRO(actually 120KRO+8Modifiers)
      You can tolggles NKRO/6KRO feature.
  
• Keymap customization
      You can customize keymaps easily by editing source code.
  

BUILD CONVERTER
You can build your own converter.
Connect CLOCK line to PD1 pin and DATA line to PD0 pin. You need pull-up resistors on both signal lines.
Needless to say, you need to wire Vcc and GND line too. You can change pin configuration by editing config.h.

And consult with README file.
https://github.com/tmk/tmk_keyboard/tree/master/converter/ps2_usb


BUILD FIRMWARE
Check this first.
https://github.com/tmk/tmk_keyboard/wiki#build-firmware

Get source code from here and go to converter/ps2_usb directory.
https://github.com/tmk/tmk_keyboard

For TMK converter Rev.2:

$ make -f Makefile.rev2 clean
$ make -f Makefile.rev2 KEYMAP=plain
$ make -f Makefile.rev2 KEYMAP=plain dfu

If your use your own DIY converter with ATMega32u4 you can use Makefile.32u4 instead, but note that progarmming with 'dfu' may not work for your converter.

[theferenc]

So with this, we could implement any minor changes in key layout we've done, prior to it even getting to the controller?

This is genius!

I've got a bolt modded model M that I split the backspace into 2 keys, and rearranged others (see link in sig, if you're curious).

If I'm reading this correctly, I could use this project to modify the keymap in the converter, thereby obviating the necessity of registry hacks or xmodmap or whatever. Is this correct?

If so, I might need to finally order a teensy.

[Soarer]

I like the github 404 :-p

(https://github.com/tmk/tmk_keyboard/ps2_usb/ should be https://github.com/tmk/tmk_keyboard/tree/master/ps2_usb, I think).

Nice work, again, hasu :-)

[hasu]

I've got a bolt modded model M that I split the backspace into 2 keys, and rearranged others (see link in sig, if you're curious).

If I'm reading this correctly, I could use this project to modify the keymap in the converter, thereby obviating the necessity of registry hacks or xmodmap or whatever. Is this correct?

I think so.
This converter allows you to remap scan code from PS/2 keyboard to any USB code. If your split 2 keys have different PS/2 scan code each, you can rearrange those keys as you like.
Using this converter, I think you will not need registry hacks and AHK for rearrangement of keys.

Get a Teensy and try this!
I need feedback, suggestions and advices to improve my project.

I like the github 404 :-p

(https://github.com/tmk/tmk_keyboard/ps2_usb/ should be https://github.com/tmk/tmk_keyboard/tree/master/ps2_usb, I think).

Nice work, again, hasu :-)

Thank you, Soarer.
I fixed it.

[theferenc]

Just to check, will this work with a teensy++, or just a teensy? I ask because the teensy is currently out of stock. I assume teensy only, so I guess I will just have to wait, which is a shame.

I'm definitely interested in trying this out and providing feedback. Especially since right now, the registry hack thing is only a viable solution for windows. This will make the keyboard work properly, regardless of physical system it is connected to.

Also, the split backspace does send distinct scan codes, so it theoretically should work.

Thanks, Hasu!

[hasu]

theferenc,

I believe it should work on Teensy++. Though I didn't confirm that.
My Teensy++ is located inside my HHKB and is not available for testing now.

Just to check, will this work with a teensy++, or just a teensy? I ask because the teensy is currently out of stock. I assume teensy only, so I guess I will just have to wait, which is a shame.

I'm definitely interested in trying this out and providing feedback. Especially since right now, the registry hack thing is only a viable solution for windows. This will make the keyboard work properly, regardless of physical system it is connected to.

Also, the split backspace does send distinct scan codes, so it theoretically should work.

Thanks, Hasu!

[symphonic1985]

I really love this idea. I have to work on Ubuntu at work where I have much less experience with Autohotkey type things. I'd much rather do things in hardware than have to learn lots of different remapping and hotkey systems.

Once the guilt from all my keyboard purchases has worn off I think that I'll probably grab a teensy to play with this kind of awesomeness.

[sixty]

Great work! I would love to try it, sadly Teensy is entirely sold out everywhere in Germany since everyone uses it for PS3 piracy.

[Soarer]

Great work! I would love to try it, sadly Teensy is entirely sold out everywhere in Germany since everyone uses it for PS3 piracy.

You could try one of these: http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=280606391720&ssPageName=STRK:MEWAX:IT

It's one of the few Teensy alternatives that actually looks OK Many of them are copies of the original Teensy, not the 2.0 version with atmega32u4 chip. I've just ordered one to test it out... we'll see...

[Soarer]

Hasu, the PrintScreen shouldn't be handled as a sequence, but the fix is easy...

code E0 12 should be ignored
code E0 7C should map to PrtSc HID code

The E0 12 is a fake shift for when E0 is not handled, e.g. a computer that thinks it has an 84 key keyboard attached. Since you handle E0, you don't need to handle the PrtSc sequence specifically. In fact, it makes a bug when PrtSc is held down and repeats! (also maybe when shift is held?)

Basically, this means it can be handled the same as any other normal key :-)

[hasu]

Soarer, thank you for your feedback!

I have fixed the problem you described.

It took some time to check out complex behavior of PS/2 keyboard.
The PS/2 scan code(set 2) is chaos I am not sure why they do like that even though they needed backward compatibility.



This is my result of research.

Code: [Select]

/*
 * PS/2 Scan Code Set 2: Exceptional Handling
 *
 * There are several keys to be handled exceptionally.
 * The scan code for these keys are varied or prefix/postfix'd
 * depending on modifier key state.
 *
 * References:
 *     http://www.microsoft.com/whdc/archive/scancode.mspx
 *     http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/scancode.doc
 *
 *
 * Insert, Delete, Home, End, PageUp, PageDown, Up, Down, Right, Left:
 *     Num Lock: off
 *     modifiers | make                      | break
 *     ----------+---------------------------+----------------------
 *     Ohter     |                    <make> | <break>
 *     LShift    | E0 F0 12           <make> | <break>  E0 12
 *     RShift    | E0 F0 59           <make> | <break>  E0 59
 *     L+RShift  | E0 F0 12  E0 F0 59 <make> | <break>  E0 59 E0 12
 *
 *     Num Lock: on
 *     modifiers | make                      | break
 *     ----------+---------------------------+----------------------
 *     Other     | E0 12              <make> | <break>  E0 F0 12
 *     Shift'd   |                    <make> | <break>
 *
 *     Handling: ignore these prefix/postfix codes
 *
 *
 * Keypad-/:
 *     modifiers | make                      | break
 *     ----------+---------------------------+----------------------
 *     Ohter     |                    <make> | <break>
 *     LShift    | E0 F0 12           <make> | <break>  E0 12
 *     RShift    | E0 F0 59           <make> | <break>  E0 59
 *     L+RShift  | E0 F0 12  E0 F0 59 <make> | <break>  E0 59 E0 12
 *
 *     Handling: ignore these prefix/postfix codes
 *
 *
 * PrintScreen:
 *     With hoding down modifiers, the scan code is sent as following:
 *
 *     modifiers | make         | break
 *     ----------+--------------+-----------------------------------
 *     Other     | E0 12  E0 7C | E0 F0 7C  E0 F0 12
 *     Shift'd   |        E0 7C | E0 F0 7C
 *     Control'd |        E0 7C | E0 F0 7C
 *     Alt'd     |           84 | F0 84
 *
 *     Handling: ignore prefix/postfix codes and treat both scan code
 *               E0 7C and 84 as PrintScreen.
 *
 * Pause:
 *     With hoding down modifiers, the scan code is sent as following:
 *
 *     modifiers | make(no break code)
 *     ----------+--------------------------------------------------
 *     no mods   | E1 14 77 E1 F0 14 F0 77
 *     Control'd | E0 7E E0 F0 7E
 *
 *     Handling: treat these two code sequence as Pause
 *
 */


[Soarer]

Yes, that's how I handle all of those, in fact the only one that actually needs special code is Pause. (As far as I know so far, anyway!)

All very convoluted, and tedious to check them all, but mostly ignoring them seems to be the right thing to do!

[hasu]

Great work! I would love to try it, sadly Teensy is entirely sold out everywhere in Germany since everyone uses it for PS3 piracy.

You could try one of these: http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=280606391720&ssPageName=STRK:MEWAX:IT

It's one of the few Teensy alternatives that actually looks OK Many of them are copies of the original Teensy, not the 2.0 version with atmega32u4 chip. I've just ordered one to test it out... we'll see...

Teensy is a great platform for easy & rapid development.
But I need more option for hardware. I mean my next target will be V-USB stack with ATmega, tiny is too tight for my firmware.

This is my testbed of V-USB using arduino I setup today.

[theferenc]

hasu, is it possible, using this method, to map the extra keys on a terminal emulator that are usually just ignored by converters? Looking at your keymap layers, it appears that I would just have to add in the extra keys by hand, but that's no big deal for me.

Honestly, I don't really care what the keys are supposed to do, as long as they send unique scan codes from the teensy to the workstation.

[hasu]

theferenc,

I don't know the "terminal emulator" keyboard at all, in particular its scan codes.

My converter supports PS/2(AT) signaling and scan code set 2, if the keyboard uses these you can map easily by just editing keymap.c.
But if scan codes for the extra keys are very different from PS/2 scan code set 2, you will have to write some codes in C to decode them.

[theferenc]

It's the 122 key IBM keyboards. Hopefully it won't be too complicated to decode them. Low level C is sort of my area (I'm a systems coder), so that part, at least, won't be an issue.

If I get it working, I will definitely pass it along.

[kishy]

122 emulator, yeah? There are two varieties AFAIK: ones that send modifier+another key, and ones that send mostly unique codes.

The latter is what sounds like it could be made to work with this doohicky. The first is probably not worth bothering with.

The real terminal keyboards are all Set 3, of course.

[theferenc]

I've got a Teensy++ on the way. So we'll also see if it would be a straight load on that, or if any modifications will be necessary. Based on specs, it should just work, since I don't need many inputs.

[REVENGE]

How hard would it be to change the firmware to accept an arbitrary input protocol (like terminal or XT for example)?

[hasu]

kishy,
I have read "USB converter" page in your signature, is dfj's converter firmware available to public? I couldn't found it by my quick search.
It must be very useful to us if its source code is also available.

REVENGE,
I think it depends on whether you could find enough documentation to implement the protocol.
In my case, PS/2 and ADB have many good resources on the net. Thanks to this I could write initial code and see scan codes from keyboard in first several hours, though
I used several days to research and understand the protocol.

[hasu]

kishy,
I have read "USB converter" page in your signature, is dfj's converter firmware available to public? I couldn't found it by my quick search.
It must be very useful to us if its source code is also available.

I found the answer in dfj's recent post.

Both teensy implementations are not-quite released as open-source yet,  but can be had from the folks on the IRC channel #geekhack if you can  stand it there.

[theferenc]

hasu,

Based on the code and the layout of the KEYMAP macro, it would appear there is a specific ordering to the keys. I assume this 8x22 map comes from the normal matrix of a keyboard somehow.

Basically, if I'm adding a key (I use a 102 key keyboard, as backspace has been split from a single key to 2 keys), do I have to put it in a very specific location, or can I simply replace one of the KB_NO locations, so long as I pick an appropriate name?

Any help would be appreciated!

[hasu]

theferenc,
At first , You need to know scan code for the key. once you know that, just replace KB_NO with matrix position of the code as you said.
Probably You can see the scan code in debug console if your keyboard sends scan code Set2. Run PJRC's hid_listen.exe then press LControl+RShift+d in your target keyboard.


Following is how the converter maps PS/2 codes to USB codes.

This converter stores a scan code from keyboard as a bit in matrix(uin8_t[32] array) in following rule.
For example 'A'(0x1C) is stored like: matrix[0x1C>>3] |= 1<<(0x1C&0x07);
0xE0 prefix code like'PG UP'(0xE0, 0x7D): matrix[(0x7D|0x80)>>3] |= 1<<(0x7D&0x07);
See matrix.c for details.

Then the matrix is mapped to USB code in keymap.c.
'A' is identify as 'K1C' and 'PG UP' as 'KFD'(0x7D|0x80=0XFD) in KEYMAP macro.

PS/2 scan code Set2
http://www.computer-engineering.org/ps2keyboard/scancodes2.html

[intealls]

Awesome work hasu!

I just wanted to quickly describe how to add support for the Europe 2 key (right of the shift key), in case people have trouble understanding shift operations and the like. Add 'K61,' next to 'K12,' on line 24. Change the second 'KB_NO,' on line 39 to  'KB_##61,'.

Then configure your keymaps to use NONUS_BSLASH where the Europe 2 key is located. If you want, you could add an extra #define in usb_keycodes.h like '#define KB_NUBS KB_NONUS_BSLASH', to keep everything nice and tidy in your keymap configuration.

[hasu]

intealls,

Thank you for your nice feedback!
I added short name you suggested and push it to github.


And I'd like to added useful resources for people want to define their own keymaps.

USB HID to PS/2 Translation Table:
You can see PS/2 scan codes and how to handle it in Windows.
http://www.microsoft.com/whdc/archive/scancode.mspx

HID usage table:
You can see all HID Usage IDs(USB keycodes).
http://www.usb.org/developers/hidpage#HID_Usage

[hasu]

V-USB is supported now.
Currently the converter on V-USB lacks some features: USB NKRO and System/Media control.

[doublethink]

Hasu,

This is very impressive.  What about designing a PCB on http://batchpcb.com and then keeping a list of parts from a distributor so people could build their own?

The advantage would be that you could have female ps/2 soldered right to the board, and we could size it to matchup with a plastic housing of some sort. ^_^

[doublethink]

Something like this guy:

http://www.pactecenclosures.com/product-detail.php?classid=31&seriesid=64

They have different sizes, etc.  Mouser is franchise for that company.

[intealls]

I've been using this for a couple of weeks now and I have to say it works great! The only problem I have encountered is that the adapter didn't work properly with my Model M's, after adding the 1K pull-up resistor to the data line (as described in the ADB-USB adapter thread) it works perfect! Typing on one now, feels kind of awesome having a fully programmable M without any hardware modifications. Thanks hasu!

[hasu]

intealls,
Thanks for your feedback! In particular, I'm happy to hear positive one
It seems we had better have pull-up resistors in case. Internal pull-up is not enough


doublethink,
I have not an experience on PCB design, but I'm planning to learn it using Kicad.
Thanks for suggestion.

[doublethink]

hasu,

I have only played with an arduino twice with a breadboard, I know the basics but am no expert.

If we could get this running on lets say 30$ worth of hardware from mouser, and it could be programmed using your firmware to give colemack or workman guys a hardware based interface, with NKRO that would be quite an accomplishment for the community.

of course it would probably piss off those qwerty -> dvorak usb key guys or whatever.  as long as we didn't blatantly monetize it they have no recourse though.

[REVENGE]

PJRC continues to be out of stock on those regular Teensys, any reason this wouldn't work on a DX copy?

http://www.dealextreme.com/p/designer-s-teensy-usb-development-board-for-ps3-47609

[REVENGE]

Whoah - lookee that.  I coulda bought that along with my HHKB Killer.

I only found it because PJRC has a big post against buying counterfeit Teensys. Go figure.

[Soarer]

A better deal is this one on ebay from noogroove: http://cgi.ebay.com/NooGroove-USB-Board-ATMEGA32-AT90USB162-AVR-Stick-DFU-/150568104102?pt=LH_DefaultDomain_2&hash=item230e8ef0a6

The ATMEGA32U2 has twice the RAM (1KB) of the dealextreme one (AT90USB162), but still less than the 2.5KB of a real PJRC Teensy 2.0 (ATMEGA32U4).

And you'll probably get it a lot quicker!

[REVENGE]

A better deal is this one on ebay from noogroove: http://cgi.ebay.com/NooGroove-USB-Board-ATMEGA32-AT90USB162-AVR-Stick-DFU-/150568104102?pt=LH_DefaultDomain_2&hash=item230e8ef0a6

The ATMEGA32U2 has twice the RAM (1KB) of the dealextreme one (AT90USB162), but still less than the 2.5KB of a real PJRC Teensy 2.0 (ATMEGA32U4).

And you'll probably get it a lot quicker!

Thanks! Nice find.

[Soarer]

No worries! I bought a couple of them, they got here (UK) in about a week which is pretty good. Not done a lot with them yet though, because I've got Teensy 2.0 and Teensy++ 2.0 boards to play with as well :-)

[REVENGE]

No worries! I bought a couple of them, they got here (UK) in about a week which is pretty good. Not done a lot with them yet though, because I've got Teensy 2.0 and Teensy++ 2.0 boards to play with as well :-)

There's an ATMEGA32U4 based board on eBay as well, have you checked it out?

[Soarer]

Yup - it's big! Drop shipped from India. Seems to work fine, but I keep going back to the Teensy for development because the loader is nicer.

[kps]

A better deal is this one on ebay from noogroove: http://cgi.ebay.com/NooGroove-USB-Board-ATMEGA32-AT90USB162-AVR-Stick-DFU-/150568104102?pt=LH_DefaultDomain_2&hash=item230e8ef0a6

Nice find, thank you! My last adapter I built using a $9 PS3 dongle, but I don't enjoy soldering wires onto TQFP pins.

[REVENGE]

Yup - it's big! Drop shipped from India. Seems to work fine, but I keep going back to the Teensy for development because the loader is nicer.

Haha, guess I need to find a bigger project box for that hes board.

[woody]

http://www.mattairtech.com/index.php/featured/atmega32u2-development-board.html

[doublethink]

hasu,

I'm pulling the data sheets to see whats going with Atmel at the moment.

The Teensy is based on the ATMEGA32U4-MU:

http://www.atmel.com/dyn/products/packagecard.asp?category_id=163&family_id=607&subfamily_id=760&part_id=4317&package_id=952&green=1

Basically 7x7mm footprint.  That chip is nowhere to be found because of the PS3 bull**** at the moment. 20 week lead time, and I wouldn't be surprised if it gets pushed out again.

However, the ATMEGA32U4-AU can be had, the spec is here:

http://www.atmel.com/dyn/products/packagecard.asp?category_id=163&family_id=607&subfamily_id=760&part_id=4317&package_id=616&green=1

TQFP package, which is 10x10mm. Slightly bigger but honestly who cares.

I am trying to figure out how we could make a design that would allow all the keyboard layouts with the 4 key rollover that usb supports, using your firmware.

So basically, what would you consider your ideal chip for this, perhaps something that could hold both the ADB and the layout swap in one.

[hasu]

I uses ATmega168p for this converter without problem now.
This means it works on 16KB flash and 1KB memory though I don't know real memory usage.

I think 32KB flash is needed for your purpose. ATmega32u(2|4) seems to be suitable.
Atmel has very small variety of USB AVR, we have no choice but it.

I think plain ATmega + V-USB is another choice.
But ATtiny is challenging in terms of size of this firmware.

[itisnt]

Hi Guys,

First of all thanks for that code, it gives me the change to reuse my old IBM-M Keyboard AND hopefully solve the problem i have with it (with a normal PS2/USB converter).
 
I am using an keyboard with US-layout, but with the German(Swiss) keyboard-layout on Linux and Windows-7. This works great, because i am able to use it in the "10-finger" system without looking on the keys. So i am not confused when other characters appear then i am hitting on :biggrin:

The problem i have is the fact that i am missing a key on my keyboard. On a European 102-key keyboard, there is a key between the LSHIFT and "Z" with "<", ">" and "\" on it.
So with the SwissGerman-Layout, there is no proper way to produce this three keys.  

I've found the way with replacing for example KB_VOLD with KB_NONUS_BSLASH. But i don't like that, because i have to use a lot of fingers to reach "\". FN1 + ALT + X

What i would like to do is catching the following key-sequences and replace them:

KB_RALT + Z -- replace with --> KB_RALT + KB_NONUS_BSLASH      --> "\"
KB_RALT + X -- replace with --> KB_NONUS_BSLASH                        --> "<"
KB_RALT + C -- replace with --> KB_RSHIFT + KB_NONUS_BSLASH --> ">"

I have a partial solution, but i does not work as expected, and i am not sure if i used the right place in the code to make my modifications.

keyboard.h:

Code: [Select]


#include <stdbool.h>
bool ralt_rec;


keyboard.c

Code: [Select]


            if (code == KB_RALT) {
               ralt_rec = true;
            }

            if (code == KB_NO) {
                // do nothing
            } else if (IS_MOD(code)) {
                host_add_mod_bit(MOD_BIT(code));
            } else if (IS_FN(code)) {
                fn_bits |= FN_BIT(code);
            }

            // Ugly hack to simulate the missing 102-european-key on IBM-M Keyboard

            // ">" on key "C"
            else if (( code == KB_C) && ( ralt_rec == true )) {
                host_add_key(KB_RSHIFT);
                host_add_key(KB_NONUS_BSLASH);
                _delay_ms(200);
                ralt_rec = false;
            // "<" on key "X"
            } else if (( code == KB_X) && ( ralt_rec == true )) {
                host_add_key(KB_NONUS_BSLASH);
                _delay_ms(200);
                ralt_rec = false;
            // "\" on key "Z"
            } else if (( code == KB_Z) && ( ralt_rec == true )) {
                host_add_key(KB_RALT);
                host_add_key(KB_NONUS_BSLASH);
                _delay_ms(200);
                ralt_rec = false;
            }
            else if (IS_KEY(code)) {
                host_add_key(code);
            }
#ifdef MOUSEKEY_ENABLE
            else if (IS_MOUSEKEY(code)) {
                mousekey_decode(code);
            }


It works, but only when i release the RightAlt key before i press one of the other keys. Together with RALT it always gives me "\".

I think, i didn't choose the proper way to do that, but i am a little bit lost in the code and don't know how to solve it.

I am using a original Teensy++
 
Thanks for any help.

Daniel

[theferenc]

You can easily handle this in linux by using xmodmap. Just remap your modeswitch to something handy, like right alt, then add something like
keycode 52 = z Z less greater
That would make the Z key send z by itself, Z if you press shift, < if you press modeswitch, and > if you press shift + modeswitch.

Alternatively, just do the international mod, since it's a Model M. Where are you located?

[itisnt]

I,am located in Switzerland. I know xmodmap and other mechanisems, but i work on different machines and don't wanna redo the configuration all the time.

But wath about this international mod ? I'll google that.

[itisnt]

Ok, i think you mean the article of ripster right ? That's not what i want, i like my keyboard as it is.
The only thing i need is an easy way to get the three characters "<", ">" and "\".

I think i am on the right way, but didn't find the proper solution.

But thanks anyway

[theferenc]

Fair enough. It just seems that if you are going to use a different logical layout that has a different physical layout, it makes sense to use the other physical layout.

But that still leaves you with the problem of mapping it on each computer you use it with, so this adapter is still the better option.

And yes, I did mean ripster's mod.

[intealls]

I can spot a number of problems, I think the first and most significant one (that would account for it working when RALT is released) is that the RALT modifier is registered even when you don't want it to.

Code: [Select]


            } else if (IS_MOD(code)) {
                host_add_mod_bit(MOD_BIT(code));

So, when you just want to do this

Code: [Select]


                host_add_key(KB_RSHIFT);
                host_add_key(KB_NONUS_BSLASH);
or this

Code: [Select]


                host_add_key(KB_NONUS_BSLASH);
you're actually doing this in beforehand

Code: [Select]


                host_add_mod_bit(MOD_BIT(code));
which won't generate what you want. Since you appear to reset the ralt_rec var when you've gotten Z, X, or C, this would account for the expected behaviour when RALT is released (and thus no longer being registered as a modifier).

[hasu]

Hi Daniel,

Try this dirty patch. I think you will get some success with this code.
But this is not straight solution for your problem, I can't come up with smart way now

Code: [Select]

diff --git a/keyboard.c b/keyboard.c
index 03db325..3e2a11c 100644
--- a/keyboard.c
+++ b/keyboard.c
@@ -33,6 +33,7 @@ void keyboard_init(void)
 void keyboard_proc(void)
 {
     uint8_t fn_bits = 0;
+    static bool remove_ralt = false;
 
     matrix_scan();
 
@@ -89,7 +90,37 @@ void keyboard_proc(void)
             }
 #endif
             else if (IS_KEY(code)) {
-                host_add_key(code);
+                if (keyboard_report_prev->mods & MOD_BIT(KB_RALT) || remove_ralt) {
+                    if (code == KB_Z) {
+                        // '\' on Swiss keyboard
+                        host_add_key(KB_NONUS_BSLASH);
+                        remove_ralt = false;            // keep RAlt
+                        // for test. You can remove this.
+                        //host_add_key(KB_TAB);         // Alt + Tab (for test)
+                        //remove_ralt = false;            // keep RAlt
+                    } else if (code == KB_X) {
+                        // '<' on Swiss keyboard
+                        host_add_key(KB_NONUS_BSLASH);
+                        remove_ralt = true;
+                        // for test. You can remove this.
+                        //host_add_mod_bit(MOD_BIT(KB_LSHIFT)); // LShfit + 2 (for test)
+                        //host_add_key(KB_2);
+                        //remove_ralt = true;
+                    } else if (code == KB_C) {
+                        // '>' on Swiss keyboard
+                        host_add_mod_bit(MOD_BIT(KB_LSHIFT));
+                        host_add_key(KB_NONUS_BSLASH);
+                        remove_ralt = true;
+                        // for test. You can remove this.
+                        //host_add_mod_bit(MOD_BIT(KB_RSHIFT)); // RShfit + 3
+                        //host_add_key(KB_3);
+                        //remove_ralt = true;
+                    } else {
+                        host_add_key(code);
+                    }
+                } else {
+                    host_add_key(code);
+                }
             }
 #ifdef MOUSEKEY_ENABLE
             else if (IS_MOUSEKEY(code)) {
@@ -101,6 +132,13 @@ void keyboard_proc(void)
             }
         }
     }
+    if (remove_ralt) {
+        if (keyboard_report->mods & MOD_BIT(KB_RALT)) {
+            host_set_mods(keyboard_report->mods & ~MOD_BIT(KB_RALT));
+        } else {
+            remove_ralt = false;
+        }
+    }
 
     layer_switching(fn_bits);