spontaneous menu change

Ned Konz ned at squeakland.org
Sun Nov 28 18:41:09 UTC 2004


On Saturday 27 November 2004 4:21 pm, Doug Way wrote:

> So, log it in Mantis as a bug.  (I guess I'll log it if no one else
> already has.)  The fact that the bug doesn't happen on Windows & Mac OS
> X makes it likely that it's a bug in the Linux VM... perhaps that VM is
> specifically turning Caps Lock into Shift when it shouldn't, or
> something.  At least, I assume that other Linux apps do not treat Caps
> Lock exactly the same as holding down Shift...

I'd say it's a bug too. Using xev, this is what I see coming straight from X:

left-button press
Caps lock Shift state
0 0 0
0 1 1
1 0 2
1 1 3

A key
Caps lock Shift state char
0 0 0 a
0 1 1 A
1 0 2 A
1 1 3 a

1 key
Caps lock Shift state char
0 0 0 1
0 1 1 !
1 0 2 1
1 1 3 !

So we do get a clear distinction between caps lock and shift, and the caps 
lock does indeed only affect letters.

The bug appears to be in platforms/unix/vm-display-X11/sqUnixX11.c where we 
see:

static int x2sqModifier(int state)
{
  int mods= 0;
  if (optMapIndex || cmdMapIndex)
    {
      int shift= 1 & ((state >> ShiftMapIndex) ^ (state >> LockMapIndex));
      int ctrl=  1 & (state >> ControlMapIndex);
      int cmd=   1 & (state >> cmdMapIndex);
      int opt=   1 & (state >> optMapIndex);
      mods= (shift ? ShiftKeyBit   : 0)
 |   (ctrl  ? CtrlKeyBit    : 0)
 |   (cmd   ? CommandKeyBit : 0)
 |   (opt   ? OptionKeyBit  : 0);

etc.

That is, we're always inverting the SHIFT state when we see a Caps Lock.

But then we're calling XLookupString() to process the keystroke events, and it 
handles the Caps Lock correctly.

So I'd argue that we should just look at the Shift and ignore the CapsLock 
altogether.

That is:

      int shift= 1 & (state >> ShiftMapIndex);

Any thoughts on this? Would this cause any problems?

Thanks,
-- 
Ned Konz
http://bike-nomad.com/squeak/



More information about the Squeak-dev mailing list