Hi David,
I have this problem too. Thanks for the explanation.
I use win4lin 1.0 upd 4 and a german keyboard where the @-sign is normaly
generated by pressing AltGr + q but this gets me a simple q.
My workaround is to press Alt + AltGr + q and this gets me the desired @.
I hope this can help in the meantime.
Daniel Hollon
--
Canzler Ingenieure GmbH
Viehgasse 10
D-45481 M�lheim an der Ruhr
Tel: +49 (0)208 4699-0
Fax: +49 (0)208 4699-100
David Peet <[EMAIL PROTECTED]>
Gesendet von: [EMAIL PROTECTED]
12.10.00 18:27
Bitte antworten an win4lin-users
An: win4lin-beta <[EMAIL PROTECTED]>, win4lin-users
<[EMAIL PROTECTED]>
Kopie:
Thema: [Win4Lin-users] AltGr problem located, but no fix yet
Here is what seems to be the problem with AltGr keys on some
European XFree86 setups. The state bit for that key seems to
be inconsistent, which results in xcrt canceling the AltGr key.
When you run xev to look at the events generated from the press
and release of the AltGr key you see:
KeyPress event, serial 24, synthetic NO, window 0x3800001,
root 0x26, subw 0x0, time 341263808, (168,-9), root:(764,15),
state 0x0, keycode 113 (keysym 0xff7e, Mode_switch), same_screen YES,
XLookupString gives 0 characters: ""
KeyRelease event, serial 24, synthetic NO, window 0x3800001,
root 0x26, subw 0x0, time 341263849, (168,-9), root:(764,15),
state 0x2000, keycode 113 (keysym 0xff7e, Mode_switch), same_screen
YES,
XLookupString gives 0 characters: ""
Note the state value "0x2000". The problem is that when the xcrt program
queries the X server about what the state bits mean, and it gets
the value 0x20 instead.
Here is a bit from xcrt where it finds out what the state bit (aka mod
bit)
is for each of the shift type keys.
XModifierKeymap *xmkm;
int ii,jj;
KeyCode *kc;
unsigned short keynum;
unsigned int modbit;
xmkm = XGetModifierMapping(display);
kc = xmkm->modifiermap;
modbit = 1;
for (ii=0; ii < 8; ii++) {
for (jj=0; jj < xmkm->max_keypermod; jj++) {
if (dbgEnable & 1) {
fprintf(logFile, "i=%d j=%d modbit=%xh kc=%d (%xh)",
ii, jj, modbit, *kc, *kc);
if (*kc) fprintf(logFile, " kn=%d(%xh) ",
key_xlate[*kc], key_xlate[*kc]);
kc++;
[ stuff deleted ]
fprintf(logFile,"\n");
}
modbit <<= 1;
}
XFreeModifiermap(xmkm);
Here is a part of the xcrt log file:
i=0 j=0 modbit=1h kc=50(32h) kn=44(2ch)
i=0 j=1 modbit=1h kc=62(3eh) kn=57(39h)
i=1 j=0 modbit=2h kc=66(42h) kn=30(1eh)
i=1 j=1 modbit=2h kc=0
i=2 j=0 modbit=4h kc=37(25h) kn=58(3ah)
i=2 j=1 modbit=4h kc=109(6dh) kn=64(40h)
i=3 j=0 modbit=8h kc=64(40h) kn=60(3ch)
i=3 j=1 modbit=8h kc=0
i=4 j=0 modbit=10h kc=77(4dh) kn=90(5ah)
i=4 j=1 modbit=10h kc=0
i=5 j=0 modbit=20h kc=113(71h) kn=62(3eh)
i=5 j=1 modbit=20h kc=0
i=6 j=0 modbit=40h kc=115(73h) kn=66(42h)
i=6 j=1 modbit=40h kc=0
i=7 j=0 modbit=80h kc=78(4eh) kn=125(7dh)
i=7 j=1 modbit=80h kc=0
This shows that the AltGr key (key code 113) has the modbit 0x20.
So xcrt is confused because when the AltGr key is used it expects
that the modbit will be 0x20, and when it sees 0x2000 it automatically
unshifts the AltGr key because the state seems to indicate that the
AltGr key is not pressed anymore. Now perhaps there is a good reason
why the one way indicates that the state bit is 0x20 but while
in use it really uses 0x2000. Does anyone out there know why
it is acting this way. I do not have an X server acting like
this, all of the above is from log files people have sent me.
-Thanks
-David
_______________________________________________
Win4Lin-users mailing list
[EMAIL PROTECTED]
http://lists.trelos.com/mailman/listinfo/win4lin-users
_______________________________________________
Win4Lin-users mailing list
[EMAIL PROTECTED]
http://lists.trelos.com/mailman/listinfo/win4lin-users
