Spontaneous numlock

[dsimic]

As @slyecho noted above, it would be advisable to try flashing the reverse-engineered version of the keyboard firmware.  Even if you end up with using 50% of the available writes (four out of eight), it would be worth a try, IMHO.

Edit: I would strongly suggest that you try using "showkey -s" and "showkey -k" on a virtual console to capture the scan codes and keycodes, respectively, for the troublesome Fn keys.  Then, we can compare those codes with the ones recorded for the same keys on my PineBook Pro.

[ab1jx]

I'd already done the showkey thing, and dumpkeys, and something else similar.  Anyway this is all Fn-NumLk.

Code:

kb mode was UNICODE [ if you are trying this under X, it might not work since the X server is also reading /dev/console ] press any key (program terminates 10s after last keypress)... 0x9c 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6 0x46 0xc6

[dsimic]

Below are the scan codes returned by "showkey -s" on my PineBook Pro, for pressing and releasing Fn+NumLock a total of three times (more precisely, for keeping Fn pressed, and pressing and releasing NumLock three times, but I also tested the "full-fat" version of pressing Fn, pressing NumLock, releasing NumLock and releasing Fn, and as expected there was no difference in the scan codes):

Code:

0x9c 0x45 0xc5 0x45 0xc5 0x45 0xc5

Somehow, the press scan codes (0x45 vs. 0x46) and release scan codes (0xc5 vs. 0xc6) for Fn+NumLock seem to be off by one on your keyboard.  However, the release scan code (0x9c) for Enter seems to be correct.

[ab1jx]

Another wacky thing is that Fn Priint Screen and Pause have the same scan code.  The F7 one for turning off the touchpad really turns off the touchpad, and Fn-F8 insert really works.  This is holding down the Fn and going through F1 through Power.  Esc/Z tries to suspend but it's not set up.

Code:

kb mode was UNICODE [ if you are trying this under X, it might not work since the X server is also reading /dev/console ] press any key (program terminates 10s after last keypress)... 0x9c 0x7d 0x19 0x19 0x99 0xfd 0x71 0x71 0xf1 0x72 0xf2 0x73 0xf3 0x6e 0xee 0x45 0xc5 0x46 0xc6 0x77 0xf7 0x45 0xc5 0x74 0xf4

But again the only reason I noticed this was that 3 times my num lock got turned on and pressing Fn-NumLk didn't turn it off, it's on 2 other keys instead.

[KC9UDX]

Reported earlier, the "unshifted" F keys are correct. It's only when they are "shifted" with Fn that they are wrong.

This is why I suggest it has to be the firmware. Unless there's another level of abstraction between the microcontroller in question and the physical switches, there can be nothing wrong with the keyboard, or the "unshifted" keys would be wrong.

[ab1jx]

Anybody run this hex code through a disassembler?
http://plit.de/asem-51/dis51.html

Well ok, it disassembles to 95 k bytes, too much to post here. Try it. Just a sample:

Code:

L0358: MOV A, #82h ADD A, 37h MOV R0, A MOV A, @R0 MOV R7, A CLR C SUBB A, #90h JC L0359 LJMP L0360 L0359: MOV B, #2h MOV A, R7 MUL AB ADD A, #15h MOV DPL, A MOV A, B ADDC A, #8h MOV DPH, A CLR A MOVC A, @A+DPTR MOV 65h, A MOV B, #2h MOV A, R7 MUL AB ADD A, #16h MOV DPL, A MOV A, B ADDC A, #8h MOV DPH, A CLR A MOVC A, @A+DPTR MOV 64h, A MOV A, 65h JNZ L0361 LJMP L0360 L0361: LCALL L0362 MOV A, 65h CJNE A, #4h, L0363 JNB 0Ah, L0364 SETB 26h SJMP L0363 L0364: CLR 26h L0363: JB 0Ah, L0365 LJMP L0366 L0365: MOV A, 65h CJNE A, #2h, L0419 MOV A, 64h CJNE A, #8h, L0420 MOV R0, #15h MOV @R0, #1h L0420: LJMP L0368 L0419: MOV A, 65h CJNE A, #1h, L0421 LJMP L0422 L0421: MOV A, 65h CJNE A, #3h, L0423 LJMP L0424 L0423: MOV A, 65h CJNE A, #5h, L0425 LJMP L0426 L0425: MOV A, 65h XRL A, #6h JNZ L0427 JNB 26h, L0428 LCALL L0394 MOV DPH, A CLR A MOVC A, @A+DPTR MOV R5, A CJNE A, #0FEh, L0429 JNB 24h, L0430 CLR 24h RET L0430: SETB 24h RET L0429: LJMP L0431 L0428: LCALL L0396 LJMP L0431 L0427: MOV A, 65h XRL A, #7h JZ L0432 LJMP L0433 L0432: JNB 26h, L0447 LCALL L0398 MOV DPH, A CLR A MOVC A, @A+DPTR MOV R5, A LJMP L0431 L0447: MOV R0, #15h MOV A, @R0 JNZ L0448 LJMP L0449 L0448: LCALL L0399 CJNE A, #43h, L0450 MOV R7, #1h SJMP L0451 L0450: MOV R7, #0h L0451: MOV A, R7 JZ L0452 CLR A MOV R0, #14h MOV @R0, A MOV R0, #17h MOV A, @R0 MOV R7, A JNB ACC.0, L0453 LCALL L0454 ANL A, #0FEh MOV @R0, A MOV 12h, #4h SJMP L0455 L0453: LCALL L0467 ORL A, #1h MOV @R0, A MOV 12h, #6h L0455: SETB 0C0h SETB 0C1h LCALL L0456 LCALL L0138 L0452: LCALL L0399 CJNE A, #44h, L0457 MOV R7, #1h SJMP L0458 L0457: MOV R7, #0h L0458: MOV A, R7 JZ L0459 MOV R0, #14h MOV @R0, #1h MOV R0, #17h MOV A, @R0 MOV R7, A JNB ACC.1, L0460 LCALL L0454 ANL A, #0FDh MOV @R0, A MOV 12h, #4h SJMP L0461 L0460: LCALL L0467 ORL A, #2h MOV @R0, A MOV 12h, #6h L0461: SETB 0C0h SETB 0C1h LCALL L0456 LCALL L0138 L0459: LCALL L0399 CJNE A, #45h, L0462 MOV R7, #1h SJMP L0463 L0462: MOV R7, #0h L0463: MOV A, R7 JNZ L0464 LJMP L0360 L0464: MOV R0, #14h MOV @R0, #2h MOV R0, #17h MOV A, @R0 MOV R7, A JNB ACC.2, L0465 LCALL L0454 ANL A, #0FBh MOV @R0, A MOV 12h, #4h SJMP L0466 L0465: LCALL L0467 ORL A, #4h MOV @R0, A MOV 12h, #6h L0466: SETB 0C0h SETB 0C1h LCALL L0136 MOV R5, #1h MOV R7, #0A0h LCALL L0137 MOV R5, #1h CLR A MOV R7, A LCALL L0137 MOV R0, #17h MOV A, @R0 MOV R7, A MOV R5, #1h LCALL L0137 LJMP L0138 L0449: LCALL L0399 MOV R5, A LJMP L0431 L0433: MOV A, 65h XRL A, #0Ah JNZ L0434 JNB 26h, L0435 LCALL L0402 MOV DPH, A CLR A MOVC A, @A+DPTR MOV R5, A LJMP L0431 L0435: MOV A, 64h ADD A, ACC JNB 1Ah, L0436 LCALL L0437 SJMP L0438 L0436: ADD A, #57h MOV DPL, A CLR A ADDC A, #9h L0438: MOV DPH, A CLR A MOVC A, @A+DPTR MOV R5, A LJMP L0431 L0434: MOV A, 65h XRL A, #9h JNZ L0439 JNB 26h, L0440 MOV C, 0Ah LJMP L0441 L0440: SJMP L0422 L0439: MOV A, 65h XRL A, #0Ch JZ L0442 LJMP L0360 L0442: JNB 26h, L0443 L0444: MOV A, 0E4h JNB ACC.3, L0444 MOV A, 0E4h ANL A, #3h JNZ L0444 LCALL L0406 LCALL L0143 L0445: MOV A, 0E4h JNB ACC.3, L0445 MOV A, 0E4h ANL A, #3h JNZ L0445 LCALL L0404 LJMP L0446 L0443: SJMP L0422 L0366: MOV A, 65h CJNE A, #2h, L0367 MOV A, 64h CJNE A, #8h, L0368 CLR A MOV R0, #15h MOV @R0, A L0368: LCALL L0369 LJMP L0370 L0367: MOV A, 65h CJNE A, #1h, L0372 L0422: LCALL L0369 LJMP L0373 L0372: MOV A, 65h CJNE A, #3h, L0383 L0424: LCALL L0369 LJMP L0384 L0383: MOV A, 65h CJNE A, #5h, L0388 L0426: LCALL L0369 LJMP L0389 L0388: MOV A, 65h XRL A, #6h JNZ L0393 LCALL L0394 LCALL L0395 LCALL L0374 LCALL L0396 L0431: MOV C, 0Ah CLR A RLC A MOV R7, A LJMP L0373 L0393: MOV A, 65h XRL A, #7h JNZ L0397 LCALL L0398 LCALL L0395 LCALL L0374 LCALL L0399 LCALL L0400 SJMP L0373 L0397: MOV A, 65h XRL A, #0Ah JNZ L0401 LCALL L0402 LCALL L0395 LCALL L0374 MOV A, 64h ADD A, ACC ADD A, #57h MOV DPL, A CLR A ADDC A, #9h LCALL L0395 SJMP L0373 L0401: MOV A, 65h CJNE A, #9h, L0403 LCALL L0369 LCALL L0374 MOV C, 0Ah CLR A L0441: RLC A MOV R7, A MOV R5, #66h L0373: LJMP L0374 L0403: MOV A, 65h XRL A, #0Ch JNZ L0360 MOV C, 0Ah RLC A MOV R7, A MOV R5, 64h LCALL L0374 LCALL L0404 LCALL L0143 L0405: MOV A, 0E4h JNB ACC.3, L0405 MOV A, 0E4h ANL A, #3h JNZ L0405 LCALL L0406 L0446: LCALL L0143 L0360: RET L0456: LCALL L0136 MOV R5, #1h MOV R7, #0A0h LCALL L0137 MOV R5, #1h CLR A MOV R7, A LCALL L0137 MOV R0, #17h MOV A, @R0 MOV R7, A MOV R5, #1h LCALL L0137 RET L0406: MOV C, 0Ah CLR A RLC A MOV R7, A MOV R5, #8h LCALL L0370 RET L0404: MOV C, 0Ah CLR A RLC A MOV R7, A MOV R5, #13h LCALL L0374 RET

8051 instruction set summary http://ww1.microchip.com/downloads/en/De...oc0509.pdf

[dsimic]

It would take a lot of time to go through that much assembly code, with questionable end results because no datasheet is available for the keyboard controller.

I'll look into the source code of the firmware update utility and see if it's possible to implement an option to read the current firmware and save it to a file.  That would allow a much better insight into the "untouched" and troublesome keyboards.

[ab1jx]

Possibly, about half of it is just DB statements defining constants though.  If you do a grep -v DB there's 47K left.

The sh61f63 datasheet says "instruction set compatible with standard 8051".

It might be possible.  I don't have an untouched one to look at.  I was trying to see if it was possible that it only works with 16 k chips and not 14 k.  But there's a #define MAX_BINLEN (14*1024) in there.  Looked like it read back and checked the touchpad code more than the keyboard code though.

[KC9UDX]

That's a ton of code for a keyboard and touchpad!

I'm wondering, if this is on the main board, how is it proprietary to the keyboard and touchpad? I wish I had time; it shouldn't be terribly difficult to reverse engineer the whole works and write new firmware from scratch. But then, I'd rather not get my head into 8051...

[ab1jx]

The pbp has how many usb busses and hubs?  And only 2 for the user. Try lsusb -v. Somebody said earlier in this thread that it's on the mainboard right next to something.  From dsimic: "According to page 20 of the PineBook Pro schematic, the SH68F83Q IC is located on the main board. The schematic puts it behind the J6 connector (#7 in the picture), which receives the keyboard's ribbon cable."

Sounds like a job for hexcmp.  Windows only I think but it might work under WINE.  https://duckduckgo.com/?q=hexcmp&t=fpas&...&ia=images

I think disassembling both and feeding them into diff would be better, that way the differences are in assembly, not hex.  Diff is used to make source code patch files.