/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.

ESD protection is better than no esd protection, so row 7 would be preferable
-ESD is mostly a problem when you do the actual work on the circuit, static discharges from your clothes/carpet and such stuff.

Looking at the specification for the TWL5030/TPS65950, then it seems to be a generic 8x8 matrix, so it would most likely work.

That should be okay.

@electroaudio
I guess you are right about ESD protection. I was under influence of my first findings about solution for hardware keypad issues in n900, only one found was blaming ESD filter (which have nothing to do with my case).

Ok, so in theory hardware part of mod should work, I would gladly try it out and report back with effect but I'm completely stuck with software basics.

First issue : where can I monitor activity of keypad? Modprobe does not recognize keypad module (its called twl4030_keypad or omap_twl4030keypad for some reason), dmesg ignores key events, and Xev from X11-utils is giving some output about key events but nothing useful really. I would especially like to see key names useful for remapping.
Next problem is that I don't have slightest clue where and how are are defined key names in in Maemo, which is needed to map those new (or old reused) keys. All files with configs, and all remapping instructions reuse predefined key names, which correlate only to where those keys are physically on n900 keyboard and have nothing to do with actual key-row combination. Even read source for keypad driver and still have no idea what to make of it.
In my noobish way I can actually get keycode readout simply by pressing keys in backupmenu.
Probably those things might be obvious for programmers, but for me it is still unrevealed mystery where for example letter "L", with keycode of 38 is transformed into "key <AC09>" in maemo.

I'll wait with applying this potentially harmful modification until I figure out how it could be used for key events in Maemo.

As for hardware part of mod, for connecting keys and adding new ones, old keypad i removed from nokia 5310xm seems like perfect fit

after some work with of course.