[iPAQ] Control got stuck

From: Carl Worth <cworth.a.t.east.isi.edu>
Date: Thu Oct 12 2000 - 11:23:27 EDT

This morning I was sitting on the metro playing GFingerPoken[1] on the
metro when suddenly Control seems to have gotten stuck. That is, in
most ways, it seems as if the Control modifier is "stuck on". Here's a
summary of what I see:

        1) twm responds to stylus clicks as if I were holding down
           Control, (I had been experimenting with ways to bring up
           menus even if the root screen were obscured [2].)

        2) I ran xev on my desktop with display set to the iPAQ. I
           used x2x to type into xev with my keyboard. Here, all
           results from XLookupString are consistent with Control
           being stuck, (pressing 'G' causes a beep, 'J' emits a
           newline, 'M' emits a carriage-return, etc.).

        3) I can't get xscribble to send anything to other programs. I
           thought I might be able to clear my rxvt by using the 'L'
           stroke but nothing happened. This seems a little strange
           since it is not consistent with #1 and #2. For example,
           under normal circumstances I _can_ hold down the Control
           button on the iPAQ and use an 'L' stroke to clear my rxvt.

When the stuck Control behavior started I had not hit any physical
buttons on the iPAQ. (If I remember correctly the last thing I had
done was click a gtk-button in gfpoken). I had also not been using
xscribble.

Anyone have any ideas what might have caused this behavior? I still
have my iPAQ in this strange state so I can perform any tests you
might recommend. (I can still use things just fine with rsh from my
desktop).

-Carl

[1] I've posted gfpoken at http://www.east.isi.edu/~cworth/ipaq.html

[2] It's annoying to have to leave the root window visible in order to
    use the iPAQ. I'm always nervous when using it away from a serial
    cable/network that a larger-than-life dialog window will appear
    with both OK and CANCEL outside the visible screen. If the only
    access to the window-manager's move command is through the root
    window and the root window is obscured then I'm hosed until I
    reboot or can connect to another machine.

    I've been experimenting with making twm bindings to pop-up
    menus. For example, I made Control-modified mouse clicks popup
    "Window Ops". The funny thing is, this doesn't solve the
    problem. What can happen is that if you select "Move" from "Window
    Ops" while a window is focused and active, then twm expects you to
    move the mouse to position that window and click once when it is
    in place, (rather than clicking once to select the window of
    interest, then releasing to complete the move). Since the stylus
    can not perform a pointer move operation without also clicking, it
    is impossible to move the window!

    I don't know if I don't know if I'll bother tweaking twm to fix
    this as I am perhaps more interested in using aewm or flwm. But,
    this is a general problem that may affect other programs beyond
    window managers. Any program that relies on mouse-moves without
    the button pressed will have to be rewritten. Just something to
    keep your eye out for while you are getting rid of the dependence
    on middle and right mouse button presses...
Received on Thu Oct 12 08:18:23 2000

This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 09:43:44 EDT