Spontaneous numlock

[dsimic]

There's a very good note in the Reddit thread you've linked above...  The keyboard updater attempts to write the firmware multiple times, five times to be precise, for both the "helper" and the final keyboard firmware.  Thus, it's possible to reach the write limit even without writing the final keyboard firmware successfully!

I'll submit a patch for the updater, to correct this behavior.

[ab1jx]

There's a very good note in the Reddit thread you've linked above...  The keyboard updater attempts to write the firmware multiple times, five times to be precise, for both the "helper" and the final keyboard firmware.  Thus, it's possible to reach the write limit even without writing the final keyboard firmware successfully!

I'll submit a patch for the updater, to correct this behavior.

I saw that but for some reason I think it doesn't affect the chip's count of writes unless it gets through.  Like the retry is for if the USB communications fail.   There's one of those loops on read too.  And they allow 20 tries for opening in boot mode above that.  Looks like there are 3 write processes:

flash_tp_upate  in step 1 (ansi and iso are the same)
flash_tp in step 2 (both the same again)
flash_kb_ansi or flash_kb_iso at the end of step 2

What if there's some mixup of versions?  Like you flash an iso with ansi or vice-versa.  It would probably be worse than it is now.

So the keyboards about to leave the factory work perfectly?  Wonder what they have loaded.  It wouldn't be that hard to disable the write part and just read back to write to a file I think.  Leave all the overhead intact and just comment out the actual writes.  All 3 of them.  That shouldn't trip the limit.  Since the write-limited chip mentions the limit in its datasheet I think that's probably where the limit is.

[dsimic]

I saw that but for some reason I think it doesn't affect the chip's count of writes unless it gets through.  Like the retry is for if the USB communications fail.   There's one of those loops on read too.  And they allow 20 tries for opening in boot mode above that.  

Who knows does a failed write actually affect the write count on the keyboard controller?  It shoud be better to stay on the safe side, if possible; also, we'll see what the author of the forked firmware updater will say on that.

Looks like there are 3 write processes:

flash_tp_upate  in step 1 (ansi and iso are the same)
flash_tp in step 2 (both the same again)
flash_kb_ansi or flash_kb_iso at the end of step 2

This is exactly what I've already described at least a couple of times.   See my description of the "helper" firmware.

What if there's some mixup of versions?  Like you flash an iso with ansi or vice-versa.  It would probably be worse than it is now.

Probably nothing good would happen.   The most weird thing is that the ISO variant is supposed to keep working after the "helper" firmware is flashed to the keyboard controller, while the ANSI variant stops working at that point.  I wonder why?

So the keyboards about to leave the factory work perfectly?  Wonder what they have loaded.  It wouldn't be that hard to disable the write part and just read back to write to a file I think.  Leave all the overhead intact and just comment out the actual writes.  All 3 of them.  That shouldn't trip the limit.  Since the write-limited chip mentions the limit in its datasheet I think that's probably where the limit is.

I've already explored the way for reading the current keyboard firmware into a file, but I'm not sure if reading the current firmware is possible without writing something first, or if everything is going to "explode" that way, rendering the keyboard unusable.  I'll make the required changes to the source code of the updater, but would you be willing to test that out?

[KC9UDX]

Sooner or later I have to replace my keyboard. I spillt RC Cola on it and the keys action is driving me up a wall.

I'm pretty sure that replacing your keyboard isn't going to solve your problem, unless you mean fitting it with a different USB keyboard. In that case, get one with a Trackpoint and ditch the touchpad.

[ab1jx]

Sooner or later I have to replace my keyboard.  I spillt RC Cola on it and the keys action is driving me up a wall.

I'm pretty sure that replacing your keyboard isn't going to solve your problem, unless you mean fitting it with a different USB keyboard.  In that case, get one with a Trackpoint and ditch the touchpad.

How long ago?  To some degree they get better with use.  I don't think I've ever done it but I've inherited keyboards like that.  Sometimes you can take them apart and clean them.  I seem to have more trouble with crumbs, a couple days ago my left touchpad switch almost didn't work but I kept using it and now it's recovered.

[KC9UDX]

Three weeks ago, I think. Someone at the door, three little ones running round, me wearing a guitar and reaching over my accordion on a desk for something. Probably the phone was ringing. It could've been much worse. The 32oz cup could've spillt on the accordion. That is much more painful to replace than a PBP.

I don't think I've ever had a computer keyboard in this state, but it is reminiscent of industrial keypads glued with coolant. I suppose I could pull the keyboard out and put it in the dishwasher. I'm mostly glad that the keyboard seems to have kept the cola off the electronics. Else I expect it would have worse issues.

[ab1jx]

The dishwasher's not a bad idea if you can get it apart to be sure no pockets of water with sediment are left when it dries.  A chemist once told me the best way to clean something like that was to flush/soak it with distilled water and let it air dry.  The soda will leave behind a syrup which won't go away by itself, you need to flush it out.  It may conduct electricity or not, pure water won't.

I didn't get far, still trying to figure out what happened.  I blame it on git.  I was determined to write out what was in flash, so I carefully commented out all the writes in the updater that might endanger its 8-write life.  Added a routine to dump that memory out to a file.  Got it compiled and running.  I didn't fuss with trying to put the USB back to the correct state.  So when I ran it I couldn't type anything afterwards, so I sshed in and shut it down,  Booted it back up and my program was competely gone.  No output file, just a log I made by redirecting stdout through tee while it was running.  I had done a git clone and then started modifying what I had downloaded,  In the same directory under git's control.  When I booted back up git had restored everything to the way it was at the end of the download.  I  think, I couldn't find my changes anywhere, I even checked to see if the immutable flag had gotten set but it hadn't.

[dsimic]

I had done a git clone and then started modifying what I had downloaded,  In the same directory under git's control.  When I booted back up git had restored everything to the way it was at the end of the download.  I  think, I couldn't find my changes anywhere, I even checked to see if the immutable flag had gotten set but it hadn't.

This is strange. There's nothing special inside a local git repository that would cause a spontaneous revert.

[ab1jx]

I had done a git clone and then started modifying what I had downloaded,  In the same directory under git's control.  When I booted back up git had restored everything to the way it was at the end of the download.  I  think, I couldn't find my changes anywhere, I even checked to see if the immutable flag had gotten set but it hadn't.

This is strange.  There's nothing special inside a local git repository that would cause a spontaneous revert.

I didn't know, I'm not a git fan.  I use git clone and sometimes git pull, that's about it.  hg bundles or torrents, maybe rsync are more useful.  It expects a perfect network.  It has this little .git subdir so that was the only explanation I could think of.