how difficult is making a PC-keyboard?

[legacy]

so, I am considering all the notes written about Japanese keyboards made for optimizing Unix and emacs, and I am a bit irritated that such keyboards are only available with USB interface and need to be imported from Japan (to Europe) with a final cost of 350 euro.

That's absolutely crazy.

Besides for my Sonoko project, I need extra functions such as "KVM" explicit buttons for controlling my homebrew KVM and other things.

In short, I am now considering (just to take a decision) how difficult will be making a PC keyboard from the scratch.

Assuming I can get all the plastic keys by recycling an existing keyboard, the problem is now the PCB and the plastic.

About the MPU side, I am thinking about a thing between 60 and 83 keys, with both a serial RS232 and a PS/2 interface.

The serial line is for programming all the special keys and modes.

[tsman]

There are lots of people making their own custom keyboards so they get the precise layout and model of keyswitches they want. Usually they use something like QMK but that is USB based. For your PS/2 interface, you'll need https://sourceforge.net/projects/ps2avr/ which uses a ATmega16.

[Doctorandus_P]

The most difficult part of an USB keyboard project is the software for the USB port.
USB is a pretty complicated protocol (compared to legacy stuff).

PS/2 keyboards were common hobby projects from before USB keyboards existed, and have probably been done for the majority of uC families.
Do a search directly on github / gitlab. Regular search engines do not index it properly.

How much money are you willing to spend on keys?
For cheap and universal you could go for capacitive keys  on a PCB and overlay it with colored paper for the keys.

For the real key feel there are also a lot of options.
You could start searching at:
https://www.aliexpress.com/wholesale?SearchText=key+caps+keyboard
https://www.aliexpress.com/wholesale?SearchText=mechanical+keyboard+pcb

I've also seen keys with transparent caps, and you can put colored paper between them for the key labels.
There are many options. Just browse around a little to see what's available.

[legacy]

The most difficult part of an USB keyboard project is

I am more worried about the mechanical part. Which keys to choose, how to make the enclosure, etc.
Ideally, I'd also like to integrate a TrackPoint.

[SiliconWizard]

Popular and good mechanical key switches are the Cherry MX series. You can't go wrong with those.
A few companies also sell key caps, either as common sets or fully custom. You can get an idea here: https://mechanicalkeyboards.com/shop/index.php?l=product_list&c=40

As to the enclosure, that's trickier. You could have your first prototype(s) 3D printed to check that eveything is fine, but if you want to make that a product, molded ABS (or equivalent) is probably the way to go. The NRE cost will be a bit on the high side.

[Mr. Scram]

Making a keyboard shouldn't be too hard. There are a lot of projects out there you could borrow from. The PCB shouldn't be too complicated, although it's simply a large and therefore not entirely cheap board. Doing plastics could be a bit complicated, but luckily small scale metalwork is within consumer range nowadays and that would help the rigidity immensely too.

However, don't expect it too be much cheaper than buying one if you're doing everything yourself, not even considering the hours spent.

[ZayneTech]

A USB-HID compatible device such as the Arduino Micro should be able to do the job. Just find the right code, map the keys to the AVR using a PCB and you're done. Shouldn't be too hard, just be careful about the current load if you're using a backlight, and If you are, try using a transistor/relay to handle the current the LEDs draw depending on the datasheet. And if you really want to be safe, put an optocoupler between the relay and the AVR or just use an optocoupler if you dont want to use a relay. That should prevent any surges between the AVR and the LEDs.

[Nominal Animal]

If you use a Teensy, the software side is really easy, because Teensyduino includes a library for this.  MechanicalKeyboards SiliconWizard linked to even sells Teensy 2.0s (ATmega32u4) to be used as keyboard controllers.  Unlike later Teensies (LC, 3.x) or Arduinos (Pro Micro, Leonardo), there is a "bare-metal" USB keyboard library for Teensy 2.0 and 2.0++ (also mouse and raw HID), so you only need avr-binutils, avr-gcc, avr-libc, the aforementioned library, and teensy_loader_cli to upload the sources to the Teensy via USB.  (The PS/2 library is designed for use in the Arduino environment, but I think you could adapt it to Teensy 2.0 bare-metal without too much hassle. Note that for PS/2 port, the irq pin must be one of those marked D0, D1, D2, or D3 just below the chip, and the other data pin can be any other I/O pin except D6 in the corner, connected to the LED.)

Arduino Pro Micros also use ATmega32u4, and are essentially clones of the SparkFun Pro Micro with an Arduino Leonardo bootloader (so you need to choose Arduino Leonardo in Arduino development environment). There are plenty of tutorials, hackaday work logs, and so on, for implementing a keyboard; just use "pro micro" as the search key.  On those, you can use the aforementioned PS/2 library too, but note that you'll probably want to use pin 7 as the irq pin, and pin 5 for data.

The downside is that you'll need basically all of the I/O pins for a full keyboard matrix; N input and M output pins for N×M keys. You'll need a diode in series with each key, to avoid "phantom" keys.  Because only one of the M output pins is active at any time, you can use an external mux chip or even a counter and a mux to pull each one of the M output pins high, using just 2-3 pins on the microcontroller.  I personally have a couple of Teensy 2.0++'s, with an Atmega AT90USB1286, which has almost double the I/O pins, lots more flash (130048 bytes) and RAM (8192) and EEPROM (4096 bytes); I'd definitely use one of these for a full-sized keyboard (say, more than 64 keys) rather than an ATmega32u4 one.  The same libraries support 2.0++ just as well as 2.0, and the pinout and pin selection is actually much easier (eight interrupt-capable pins, almost all output pins in consecutive order).

Key debouncing is an art in and of itself, and various implementations exist, especially in the Arduino environment.  I personally prefer a different debouncer, using a dead-time counter, so that each key changes state immediately, and just has a fixed period afterwards when additional changes are ignored. The counters require a byte per physical button of RAM (including the state bit), but ATmega32u4 has 2560 bytes of RAM, so it is not a problem.  (AT90USB1286 has 8192 bytes, so it is even less of a problem there.)  I also prefer to use at least a 2 kHz scan rate (each key checked at 0.5 ms intervals), in which case the dead time is adjustable from 0.5ms to 63.5ms, keeping the USB HID latency (hopefully, not measured!) under 2 ms.  My Pro Micro Gamepad project I linked to in the other thread, having only ten buttons, does not use a matrix at all, just internal pullups and an input pin per button.  I did design a Teensy LC button matrix board with 32 buttons and 9 potentiometers as an example for use in a DIY arcade cabinet or control console, but I never built it myself; the idea is that you solder wires or connectors and the diode pairs at the same time, but I don't know how fiddly that gets.  I just tried to keep the parts count (cost!) down.

[legacy]

Time ago I designed a keyboard controller in HDL for an 83 key-matrix. The debounce was hardware, with an intriguing circuit. Unfortunately, the project cannot be converted to PS/2 because it's based on a custom protocol that is completely incompatible with PS/2 and the conversion is not worth with the effort. Besides, using a CPLD is more expensive than an MPU.

Talking about the mouse, I really *love* the custom protocol invented by SONY for the PSX-mouse. It's simple, neat, elegant, WOW! The PS/2 mouse is not so neat.

Today I also found an assembly list for an old 8049 chip used by IBM for a PS/2 keyboard, and I am surprised because the list says that it's key scan set3, which is considered the most advanced ever X____X

Good guys, they programmed in assembly on a chip that doesn't look "friendly".

Anyway, now I have the doc for the set3. I am completed 

Impressed. Really!

[SiliconWizard]

So, what MCU are you going to use?

Regarding cost, are you sure the CPLD/MCU is really going to be a factor compared to the cost of all the mechanical parts? Or are you talking about development cost?
(That said, I would go for an MCU as well anyway...)

[legacy]

So, what MCU are you going to use?

probably an Avr8, even if Elisabeth yesterday was considering a bunch of Hitachi SH1 that she has in stock (200 chip).

we don't have any Teensy, but it looks "too much meat" on the fire for this specific project.

Regarding cost, are you sure the CPLD/MCU is really going to be a factor compared to the cost of all the mechanical parts?

Well, 0.40 Euro for an Avr8 chip vs 4 Euro for a CPLD is 1:10, the rest of the circuit is about the same, a SIL package, capacitors, and alike ... nothing special so it's not too bad but the development-time will take for sure more time for the HDL stuff, and this is bad because we have a deadline for the event.

The mechanical parts are not a problem now since we are recycling old keyboards. We believe that we cannot make a keyboard from scratch so we have already reverse-engineered the key matrix of a couple of keyboards and we are developing our control board.

I say "we" because there are two persons involved 

[Kleinstein]

I don't know about Japanese keyboards and the special functions needed for this. With normal (e.g. English) keyboards the µC inside the keyboard is not doing really much. Mainly scanning the keys and sending key codes - most of the decoding is already done in the PC. So one can just switch between different KB mappings (e.g. English, French, Russian.. ) with the same hardware only on the PC side.
So I am not sure if the Japanese KB would need different hardware, except different labels on the caps.

[Doctorandus_P]

... , the problem is now the PCB and the plastic.

On:
http://www.kicad-pcb.org/made-with-kicad/page/2/
I found a link to:
http://blog.komar.be/projects/gh60-programmable-keyboard/
The pictures on his site look like (at least the first prototypes) are put into a housing of lasercut acrylic.

And when you type "GH60" into Ali, you will find lots of links to PCB's and plastic, very similar to what I already posted a few days ago.

You can clone the whole project from github:
git clone [url]https://github.com/komar007/gh60.git]https://github.com/komar007/gh60.git] [url]https://github.com/komar007/gh60.git[/url]

As I type I have the GH60 project open in KiCad and I'm looking at the PCB.

The last thing missing seems to be the firmware for the atmega32u4...
[edit]
But it seems very plausible that the project from the same author with the title:
"Universal Keyboard Controller - a firmware for programmable keyboards based on Atmel's USB-enabled microcontrollers" will fit 
https://github.com/komar007/ukbdc

[/edit]

[legacy]

summarizing the PS/2, this document is for the scan set2, we are now working on set3.

[Doctorandus_P]

This afternoon I accidentally bumped into a forum which seems to be dedicated to keyboards.
https://geekhack.org/

[SiliconWizard]

Speaking of japanese: https://www.hhkeyboard.com/

[legacy]

not completed, and not tested yet, but this is a preliminary comparison between set2 vs set1 and set3

[Nominal Animal]

Having separate matrixes for the meta keys is useful, as it lets you easily scan their state much more often than the other keys.  It can make a significant difference to UX when typing: consider what happens when someone presses a meta key and a non-meta key at the same time, just before the non-meta key is scanned.  Me, I'd probably just try and put them on dedicated rows.  Some cheapies could also do it to reduce the number of diodes needed, by allowing ghosting for key combinations that are not normally used.

[Doctorandus_P]

It is impossible to "press 2 keys at the same time".
What kind of resolution are you thinking about?
milli seconds? pico seconds?

Scanning speed is limited by uC speed, but probably more by wire capacitance and EMI concerns. a uC wold have no problem in scanning a 10x12 keyboard matrix at a few kHz.

But when you consider contact bounce it becomes a non-issue.
Any lag experienced is very likely simply due to badly or sloppy software in the uC of (cheap?) keyboards.

[Nominal Animal]

What kind of resolution are you thinking about?

On the order of hundredths of a second.

While human reaction system works on the order of few tens of milliseconds, we can still detect surprisingly small differences in event timing: things like whether two pebbles hit the ground exactly the same moment, or at different times.  The exact resolution varies depending on both the senses involved, and whether we talk about observation or manipulation.  Consider musicians and pro e-gamers for the extreme cases.

Typical keyboards only scan at 50 - 100 Hz rate, typically because it is the simplest and cheapest way to do it sufficiently well.  Such a low rate and the conductor capacitances means contact bounce is irrelevant, and they don't need complex buffering or anything like that (they usually only remember the first N depressed keys without recording the state for each key, so they really only need a dozen bytes of RAM or so).   This is well within human detection capability, but most humans won't notice it; only when they type at very high rates, or expect perfect response from every key every time.

If you have never washed your keyboards because you suspect there is a hair or a piece of dust causing a key or two to behave less than satisfactorily, you probably won't know what I am talking about.

Any lag experienced is very likely simply due to badly or sloppy software in the uC of (cheap?) keyboards.

Lag? Agreed. The most typical cause is buffer bloat; having a keyboard scanning chip that talks to an USB buffer chip.  Or even a microcontroller-based one, with high scanning frequency, but a typical debounce routine which introduces a 10ms - 20ms latency to every single keypress.

But lag or latency is not what I was describing.  I was describing user experience with modifier keys and non-modifier keys behaviour, and that at typical keyboard scan rates (50 - 100 Hz), for typists that use modifier keys at high frequency, it makes sense to use a separate matrix for the modifier keys.  By scanning the modifier keys separately, they can keep the low scan rate and very cheap implementation, but also shrink the minimum interval between modifier key and non-modifier key press required.

(If you increase the scan rate, you get into debouncing issues.  I like to overengineer the hell out of it, minimizing the latency to twice the minimum imposed by USB HID (1ms), keeping configuration options at maximum. Key-specific dead-time configuration at 0.5ms intervals for example is definitely nice when you use different types of Cherry switches for specific keys. Doing it the way I suggested for mass production is probably crazy, but for small product runs, the configurability might be worth the extra cost.)

In fact, I would bet a nice beer, that if you measured programmers or heavy typists, you'd notice that they consistently press the modifier keys 10ms - 20ms before the non-modifier keys.  The way you learn to type means that the faster typist you are, the smaller that interval tends to shrink -- until it starts to generate errors.  And on typical keyboards, you do need to press the modifier key first to keep a zero error rate; it is only a matter of how much earlier.  Using a separate scanning matrix for modifier keys allows you to use the same scanning rate, but shrink that interval.

(My own forever project is to build a semi-transparent capacitive keyboard, where each keypress is not detected based on proximity or touch, but by velocity and acceleration.  The main idea is to separate hand movements from key presses, and also allow the entire surface to be used as a 2.5D trackpad, with sensitivity up to 5-8mm over the surface.)

[Doctorandus_P]

Just for fun I made a pickup by connecting the GND loop of my scope to the tip of the probe and laying it over my keyboard.

I pick up a repetitive pattern of 18 pulses and it seems that scan time of a row varies between 85 and 110us.
After a full scan of the keyboard ( 1600us) it's a bit quiet and then the 18 pulses repeat.
Full scan of the whole matrix is repeated every 3.8ms.

And I do not believe this keyboard is anything special.
I do believe the world is full of mediocre and sloppy programmers.
I tend to buy 2nd hand keyboards. I got this one for EUR 5 because it still has such an old fashioned round connector. It's an HP model: KB-0316. I've also liked the Dell keyboards.

If one of my keyboards seems to fail, I do not go hunting for hairs, I have a far bigger tendency to throw it in the bin. Unless of couse it's one of my trusty known good ones.
With mice, and sometimes keyboards the most common failure I encounter are broken wires, usually where they come out of the housing. These I usually fix by shortening the cord by 10cm or so.

I assume you've also looked into control for those other keyboards. Those noisy ones (Not because of the buttons, but electrical noise. Aaahhrrgg...

.... Think a bit....
It's acoustical keyboards.
 Those big boxes with a single row of intermittent short black and long white keys. Timing is probably a lot more critical with those musical keyboards, and they also have velocity sensing and such.

[Nominal Animal]

Because a regular person is not able to press or release 2 keys at exactly the same time

It's not about that.  It is about the minimum interval between a modifier key and a normal key, for the normal key to be correctly modified every time.  Human neural response, especially to time-wise events, is extremely adaptive.  See e.g. Human time perception and its illusions (by David M. Eagleman).  The longer that interval must be for zero error rate, the slower fast typists are with modifier-heavy work.

I don't think it reaches under 5ms as Doctorandus_P measured on their keyboard (mine are all 10 years or older; a couple of Logitech keyboards, and one probably 20-year-old Keytronics), and believe it is on the order of 10-20ms for even the fastest typists.  (The effect being that if the required interval between the modifier keypress and the modified keypress is longer than that, they are no longer motorically a single movement, and are performed as separate actions; increasing cognitive load and slowing the typist down.)

The only proof of this is anecdotal (modified keypress error rate much higher on certain keyboards, with worse "feel" to fast typists), and what I have read about psychology of perception in peer-reviewed journals.

with fast enough scanning we can assume that between two scans of the entire matrix no more than one key will change its state.

You'll find that that won't work well.  Ghosting is no fun at all.  No need to believe me; you'll find it out when someone else uses it the first time to write any significant amount of text, or sooner, if they try to play any game with fast reaction times.

Note that a single modifier key is often not enough.  On my current mapping, I need to press Shift + AltGr + Ö to get Ø.  For keyboard-based games you'll want three, minimum.  Six to eight is typical.  So, I definitely suggest adding the diodes to the matrix, perhaps a dual SOT-23-3 Schottky per key pair on the same row if making your own circuit boards.

If the keyboard controller blocks every key whose both column and row already have a pressed key, some keys will not be registered depending on the state of other keys.

For the same effort, if you have at least one bit of RAM per key, you can support any number of simultaneous keys without any limitations, including providing both press and release events (and even autorepeat). With one byte of RAM per key, firmware-adjustable software debouncing too.  So, why do it easy when you can overengineer the heck out of it and make it use-case-proof, with approximately the same cost and effort? (The Schottky diodes are 0.018€ in a full reel of 3000, so less than 1€ per keyboard in added parts cost.  So perhaps double that for overall cost increase?).

AFAIK even 8049 has 128 bytes of RAM, so I don't understand why one would intentionally design a crippled keyboard, when they basically have the resources to do it better.  I guess it comes back to that same difference in viewpoint Doctorandus_P and I have, I guess.

[legacy]

So, I definitely suggest adding the diodes to the matrix

the problem is when you are recycling a keyboard matrix and it doesn't have diodes.
e.g. apple laptop's keyboards do not have any diodes.
e.g. texas instruments' keyboards (ti92) do not have any diodes.

[nsrmagazin]

You need the key combinations and to send them to the PC, from there you need a driver.

Key combinations example: 0xADFC, 0x12FC and etc. Check the ASCI machine set keyboard key combinations.

[Nominal Animal]

So, I definitely suggest adding the diodes to the matrix, ... if making your own circuit boards.

the problem is when you are recycling a keyboard matrix and it doesn't have diodes.

That's exactly why I suggested that if you are making your own circuit boards.

various other limitations of the communication ports

USB HID supports up to six keys plus modifiers per event, with keypress, keyrelease, and autorepeat as different events.  PS/2 has separate keypress and keyrelease events, with autorepeat implemented using the keypress.  So, both USB HID and PS/2 support fully independent key events. The trick is that because the key events cannot be communicated atomically (in PS/2 at least), you need to have a buffer which contains the events that are yet to be communicated to the host.  In simple implementations, this latter buffer is just a ~ 16-byte buffer, and is what limits the concurrency in typical PC USB and PS/2 keyboards.  (I do not have "pure" USB keyboards without PS/2 support, so I do not know if there are any that limit to the 6 + modifiers allowed by the USB HID protocol.)  This part is just a software issue, and something I myself would "do better" (=overengineer), since it is just a small one-time software development cost.

If your keyboard matrix does not have diodes, and therefore suffers from ghosting, it is a shitty keyboard.  How shitty, it depends on the keyboard matrix, and how it is used.  At minimum, a PC-compatible keyboard needs to support any combination of Shift, Ctrl, and Alt, plus a fourth non-modifier key (letters at minimum), because these are used as keyboard shortcuts.  In some keymaps, that is actually four plus, because left Alt is separate from the right Alt (which is AltGr).  Even more so in Linux, as X11 supports up to eight modifier keys, and typically the "window" and "menu" keys are treated as modifier keys (so, in my case, there are six modifier keys, and they are all supported separately, for up to 31 combinations per non-modifier key).  To be able to use the keyboard as a game controller, you need to allow at least three or four simultaneous non-modifier keys to be detected separately.  Even the earliest PS/2 keyboards supported 6 to 8 simultaneous independent non-modifier keypresses.

I do not know basically anything about the other HID/keyboard protocols, and assumed this discussion was about USB and PS/2.  (Well, I do remember that the old Commodore 64 had a 8×8 keyboard matrix without diodes, which limited which keys could be used for simultaneous keypresses, but it wasn't a problem because everyone had joysticks.)