/UPDATE-
DON'T TRY THIS AT ALL
There is much better way to tap into keyboard matrix rows and columns than that what I described.
I found out that most of columns and rows for keyboard are accessible through pads placed above keypad, this does not require removing fragile domesheet from whole key.
It wasn't so obvious because there are only 12 of those pads for total 16 of cols and rows, obviously some are missing. I managed to positively identify cols 4, 5 and 6 and row 4 (damaged one) and at least four other rows, but I didn't had time and proper tools for further testing (improper usage of my bulky multimeter resulted in re-soldering one of volume buttons ).
I will make proper update on this topic as soon I'll gather useful data.
For now if I would have to guess which row/cols aren't represented by those pads my best bet would be row 7 + columns 0, 1 and 2.


Hi.
As result of damage I done to my n900 keyboard module* I spend some time analyzing connection schematics service manuals etc. focusing on keyboard circuit.
While I didn't find easy solution for my problem (I would have to replace whole GAIA/TWL5030 chip with no guaranties that it would help) I did came up with idea for hw mod for keyboard and dirty work around for damaged keys.
Basics :
How keyboard matrix works is well explained in maemo wiki http://wiki.maemo.org/N900_Hardware_Subsystems#Keyboard
Even using those informations it easy to tell that current design have lot of unused potential for extra keys in rows from 5 to 7, but there is very little information about how physical connections go.


So take a look at this huge (and censored a little) schematics :


Uploaded with ImageShack.us
Apparently row7 goes with different path than other rows (which are connected directly to TWL5030/TWL4030/GAIA chip) so i wouldn't bother using that row, event though it by far easiest to connect into.
Or maybe I'm wrong on that subject and row 7 should be used in first place as only one that is ESD protected? I leave that for discussion.
Anyway, looking at schematics and key-matrix table it would be most reasonable approach to connect into cols from 1 to 7 and rows 5 and 6 for additional 14 col-row combinations (keys).
Cols 1 and 2 are conveniently connected to sound keys, cols 3-7 are easily accessible with far most left and right keys (col3:"enter", col4:"backspace" or "ctrl", col5:"Fn", col6:"shift", col7:"s" or "arrow left") .
Connecting to row 5 and 6 could be little trickier , those are accessible only by "y" and "u" keys.

Ok, thats all just talking, not any real solution, how to actually connect with those cols and rows?
Well, another picture would help with that:

Someone might be lucky enough to solder wires into outer ring to gain connection to columns, but what about rows?
My idea is to cut single path from ZIF or some old flex connector, cut short exposed part of connector so it would fit in center of key without touching outer ring, and glue it to pcb (without glue on exposed part of this "wire", unless you would use some electro-conductive glue for that part). I assume it would be small and slim enough to keep "y" and "u" buttons working.
It is even easier to do with connecting to key columns.

Alternatively, if its safe, easiest setup would be connection between row7 (sound keys) and cols from 3 to 7.

Real question is, would GAIA chip handle those new signals out of box?
Is there any software tool to actually test those signals?
I'm considering attaching bridge between row4 and 5 by connecting "t" and "y" keys, because at the moment I don't have access to any of row4 keys :/


* Long story short : don't trust color codes on cheap USB cables when making DIY adapter, i ended up "charging" -5V to my n900 from 6 Amp capable "USB Plus" port, lost whole row_4 of keyboard. Since nothing else was damaged I consider my self almost lucky, almost....


/EDIT - replaced image with not resized one.