On PC keyboards, XFree86 generates different key _codes_
for:
PrintScreen and Alt+PrintScreen == SysRq
and for:
Pause and Control+Pause == Break
This is an inheritance of a PC keyboard oddity -- different
key codes are actually generated. But XFree86 should cover up
for this oddity,rather than propagating it.
Reasons:
A) If you remap Alt or Control, then the keycodes don't
follow along. On my keyboard, I map both Control and
Caps Lock to Control_L, but:
Pause gives keycode 110 == Pause
Caps Lock + Pause gives control + keycode 110 == Break
Control + Pause gives control + keycode 114 == NoSymbol
B) Multiple keycodes per phyical key don't correspond to
the Core X or XKB model of how keyboards work.
C) XKeysymToKeycode() and XKeycodeToKeysym() don't work.
As an excerpt from the standard XFree86 XKB mapping:
key <PRSC> {
type= "PC_SYSRQ",
symbols[Group1]= [ Print, Sys_Req ]
};
key <SYRQ> {
type= "PC_SYSRQ",
symbols[Group1]= [ Print, Sys_Req ]
};
You get:
XKeysymToKeycode (XKeycodeToKeysym (SYRQ)) == Print
(Or, depending on ordering, it might be:
XKeysymToKeycode (XKeycodeToKeysym (PRSC)) == SYRQW)
This means it's very hard to XGrabKey() on PrintScreen
correctly.
Unless anybody objects to the above reasoning, I'm going to
submit a patch that:
* Changes xf86PostKbdEvent() to force convert keycodes
KEY_SysReqest => KEY_Print and KEY_Break => KEY_Pause
* Changes the supplied xkb maps to remove the mappings
for the SYRQ and BRK keycodes.
(This should cause no compatibility problems for applications,
since applications should never be hardcoding keycodes.
It might cause some small compatibility problems for people's
custom keymaps if they are hardcoding keycodes, but the current
situation is broken enough that I think it's worth that
incompatibility.)
Regards,
Owen
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
