From 3744281b9ae8aa0ab86ceaee1afe8a603e3aeb2c Mon Sep 17 00:00:00 2001 From: marha Date: Mon, 19 Nov 2012 10:16:38 +0100 Subject: dos -> unix --- xorg-server/xkeyboard-config/compat/README | 66 +++++++++++++++--------------- 1 file changed, 33 insertions(+), 33 deletions(-) (limited to 'xorg-server/xkeyboard-config/compat/README') diff --git a/xorg-server/xkeyboard-config/compat/README b/xorg-server/xkeyboard-config/compat/README index ea8750fac..00d591e7b 100644 --- a/xorg-server/xkeyboard-config/compat/README +++ b/xorg-server/xkeyboard-config/compat/README @@ -1,33 +1,33 @@ -The core protocol interpretation of keyboard modifiers does not include direct -support for multiple keyboard groups, so XKB reports the effective keyboard -group to XKB-aware clients using some of reserved bits in the state field of -some core protocol events. This modified state field would not be interpreted -correctly by XKB-unaware clients, so XKB provides a group compatibility mapping -which remaps the keyboard group into a core modifier mask that has similar -effects, when possible. - -XKB maintains three compatibility state components that are used to make -XKB-unaware clients(*) work as well as possible: -- The compatibility state which corresponds to the effective modifier and - effective group state. -- The compatibility lookup state which is the core-protocol equivalent of the - lookup state. -- The compatibility grab state which is the nearest core-protocol equivalent - of the grab state. - -Compatibility state are essentially the corresponding XKB states, but with -keyboard group possibly encoded as one or more modifiers. - -Modifiers that correspond to each keyboard group are described in this -group compatibility map. - - ----- -(*) The implementation of XKB invisibly extends the X library to use the -keyboard extension if it is present. That means, clients that use library or -toolkit routines to interpret keyboard events automatically use all of XKB -features; clients that directly interpret the state field of core protocol -events or the keymap direcly may be affected by some of the XKB differences. -Thus most clients can take all advantages without modification but it also -means that XKB state can be reported to clients that have not explicitly -requested the keyboard extension. +The core protocol interpretation of keyboard modifiers does not include direct +support for multiple keyboard groups, so XKB reports the effective keyboard +group to XKB-aware clients using some of reserved bits in the state field of +some core protocol events. This modified state field would not be interpreted +correctly by XKB-unaware clients, so XKB provides a group compatibility mapping +which remaps the keyboard group into a core modifier mask that has similar +effects, when possible. + +XKB maintains three compatibility state components that are used to make +XKB-unaware clients(*) work as well as possible: +- The compatibility state which corresponds to the effective modifier and + effective group state. +- The compatibility lookup state which is the core-protocol equivalent of the + lookup state. +- The compatibility grab state which is the nearest core-protocol equivalent + of the grab state. + +Compatibility state are essentially the corresponding XKB states, but with +keyboard group possibly encoded as one or more modifiers. + +Modifiers that correspond to each keyboard group are described in this +group compatibility map. + + +---- +(*) The implementation of XKB invisibly extends the X library to use the +keyboard extension if it is present. That means, clients that use library or +toolkit routines to interpret keyboard events automatically use all of XKB +features; clients that directly interpret the state field of core protocol +events or the keymap direcly may be affected by some of the XKB differences. +Thus most clients can take all advantages without modification but it also +means that XKB state can be reported to clients that have not explicitly +requested the keyboard extension. -- cgit v1.2.3