I've reviewed the code in rsync://updates.laptop.org/build-candidate-801/root/usr/share/sugar/shell/view/keyhandler.py
and I cannot see a way to easily induce the symptom you report even with mistaken changes done in an editor. On Sun, Mar 22, 2009 at 09:58:19AM -0500, Aaron Konstam wrote: > I was running build 801 and I opened keyhandler.py in an editor. I did > not mean to change it but maybe I mistakenly did. Do you have a copy of the file after the change? Which editor was used? Were you doing this change in Terminal, or a text console, or via SSH? Which user were you at the time of the edit ... olpc or root? > Shortly after that the functioning of my XO keyboard slowly > deteriorated. First after typing 2 or 3 characters it would freeze up. Define freeze up? At the time you observed the freeze, what actions were you taking and what was the result, e.g. pressing keys and they were not echoed, or moving finger on touchpad and the cursor did not move, or the lights went out, or an SSH session via the wireless hung? > Or it would type nonsense characters. What made them nonsense? > I installed the previous build 767 > by holding down the O game key at boot but things did not improve. This would have used the alternate keyhandler.py in the other /versions pristine tree. One that you had not edited. Did you confirm after boot that the build number was 767? (Asking this to exclude the possibility that the alternate build was no longer available or the firmware did not capture the O game key from you). Did you attempt a full power down, remove battery and external AC, wait 30 seconds, and restart? (Asking this to exclude certain problems I know of). The slow deterioration you report is hard to relate to accidental edits. You edits would have had to accidentally add some form of data storage about the progression of the deterioration. > The Home, Mesh, etc keys did not function. This implies that the change prevented the module from working. Those keys are handled by this file. Reference: _actions_table. > But at this point I could > synchronize the cursor by holding down the four corner keys. This is handled by the embedded controller (EC) and has nothing to do with the Sugar shell keyhandler. One of the corner keys is the frame. If the frame key did not work in Sugar, but the frame key worked for touchpad recalibration, then this matches the possible cause well. > ctl-u > erased the current line inn the terminal. keyhandler.py does not intercept Control/U, so that's good. Control/U is intended to erase the current line in the Terminal. > esc worked for a while. keyhandler does intercept Alt/Esc for close_window. It is as if the change you mistakenly made hurt the key release function at the end of the file, perhaps. > Returning to 801 did not help and eventually all keys failed to work. With olpc-update again? Or by reboot? > A usb keyboard worked without problem. On plugging it in, this may have changed stored state. Was it plugged in prior to you finding that it worked without problem, or did you plug it in at the time? > A run of the self test showed > that the keys were functional, You mean the OpenFirmware self test? > so it had to be a software problem. If so, then I agree, but I'd also wonder if you tested in the text console (Control/Alt/F2) whether the keyboard worked. Doing so would exclude Sugar and X11 leaving only the kernel and keyboard driver as relevant, and would be a useful bisection. > Finally a usb install that is described as erasing all XO data brought > my XO back to life. Ok. > Now this was a software problem. The only key related file I messed with > was keyhandler.py. That seems to be the culprit and it seems that > installing a new build under normal procedures does not change this > file. You mean with olpc-update? keyhandler.py is unchanged from build 767 to build 801. > Can anyone suggest another reason for my experiences? Yes, a combination of other problems that you have managed to connect imaginatively. (I had considered keyboard matrix lockup, which was a problem with B1 models that was fixed with B2. But the matrix is vertical; if the F1 (zoom_mesh) key did not work, then 2 w s x keys would also not work. You would have likely noticed that. Cleared by full power removal for 30 seconds. Might be induced by static discharge or electromagnetic interference.) -- James Cameron mailto:qu...@us.netrek.org http://quozl.netrek.org/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel