|
From: Milan Z. <mil...@sy...> - 2004-11-29 02:40:18
|
Ned,
Thanks. It sounds like what you are saying is this: "Caps Lock on" should=20
modify ONLY Keyboard events from keys A-Z. (not 123 Keyboard events.., not=
=20
mouse events).
=46WIW I agree, I confirmed this is the behaviour of following applications:
Windows: Pbrush, Notepad
Linux: Gimp, KWrite, others
=46rom the little I can understand, it seems your suggested change would ma=
ke=20
Linux Squeak VM behave in a way consistent with the above apps.
Milan
On November 28, 2004 01:41 pm, Ned Konz wrote:
> 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=3D 0;
> if (optMapIndex || cmdMapIndex)
> {
> int shift=3D 1 & ((state >> ShiftMapIndex) ^ (state >> LockMapIndex=
));
> int ctrl=3D 1 & (state >> ControlMapIndex);
> int cmd=3D 1 & (state >> cmdMapIndex);
> int opt=3D 1 & (state >> optMapIndex);
> mods=3D (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, a=
nd
> 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=3D 1 & (state >> ShiftMapIndex);
>
> Any thoughts on this? Would this cause any problems?
>
> Thanks,
|