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