[support-gang] the keyhandler.ppy mystery

[quozl at laptop.org]

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:quozl at us.netrek.org     http://quozl.netrek.org/