[xorg-bugzilla-noise] [Bug 926] Alt_R not added to Mod1 group

Tue Aug 3 06:37:15 PDT 2004

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   

https://freedesktop.org/bugzilla/show_bug.cgi?id=926        

------- Additional Comments From krh at bitplanet.net  2004-08-03 06:37 -------
[ More explanation from Ivan ]

   Hi,

>> Is it okay if I add your explanation to the Xorg bugzilla report?

Yes, of course.
But I forget one note about "WMs that provide Alt+TAB feature".

XKB could help them in this task.  Using XKB you can order a notification
about any modifier state changes.  Therefore if such WM used XKB features
it could just request special notification "Mod1 state is changed" and wait
this event instead of unreliable guessing what physical key controls this
modifier.

>>> > But AltGr and Alt control differnt modifiers (Mod4 and Mod1 respectively) and
>>> > it means that such combination puts two differnt modifiers on the same key.
>
>> 
>> And is this not possible? How did it work/not work before?

Before the mult-layout support all keymaps were staticaly composed and every
modifier key in them has only one modifier attached and one keysym that can
be treated as modifier keysym.  E.g. the right Alt key had Alt_R keysym and
Mod1 modifier or Mode_switch and Mod3 modifier but there was no one keymap
where this key has both keysyms or both modifiers.

>> Would it be possible for the application to test if XKB is in use and in 
>> that case use the XKB functions for mapping modifiers to keysyms, and if 
>> not, just look it up in the core modifier map?  Is this a 'good' solution?

I think so.  But most of tookits don't rely on XKB.  If we take it as
a solution we need to fix all toolkits.

>> How does this actually work? What modifier state is set when you press a 
>> key that generates a keysym which has two modifiers bound?

No, keysym never has two modifiers bound.  (Strictly speaking it CAN control
more than one modifier but nobody use it.  And it is reasonable.  There are
too few modifiers and the attaching two modifiers to one keysym just redices
the number of differen modifier we can use for different purposes).

OK.  I'll try to explain it with more details.
In the core protocol a modifier bit is attached to keycode (scan code).
Even if this physical key has no one keysym (symbol) assigned anyway when you
press this key the xserver sets this modifier in the 'keyboard state' and
reports this state in every key press/release event.  I.e. keysyms are not
needed to set/reset a modifier bit.  You can leave Shift keys without any
keysym but attach Shift modifier to them.  For usual text input it is enough.

But since most of modifiers (except Caps, Shift and Control) are unnamed,
an application needs somehow know what modifier means what.  If you attach,
say, Mod3 to left Windows key but don't assign any keysym to it the modifier
will be set at this key press but the application will not guess does it
mean Alt, Meta or any other modifier.  (I don't take Mod1/Alt modifier because
some toolkits have hardcoded relation "Mod1 means Alt"  :) .

The core protocol provides two tables:
* the keymap itself where each row match one keycode (scan code) and has
  two-four (actually up to 256) columns and each column can be filled with
  some keysym (symbol).  You can see this table using 'xmodmap -pk'.
* the modifier map where each row match one modifier and columns conatins
  keycodes of keys the modifier is attached to.  It has more then one column
  because the same modifier can be attached to two (or more) keys.  E.g.
  the Shift modifier usualy is attached to Left Shift and Right Shift keys.
  You can get this table running xmodmap without arguments.

When an application wants to know what unnamed modifier means Alt it ...
* searches Alt_L and Alt_R keysyms in the first table and gets the row number
  (that is keycode) where the keysym is found, and then ...
* searches this keycode in the second table and gets the row number that there
  means the modifier bit number.

The differences among differnt toolkits are that ...
some toolkits searches only first occurence of the interesting keysyms but
other searches all, some toolkits sums (with bitwise OR) all found modifiers
but others use the first or the last modifier found.

XKB uses another approach.  In XKB each keysym can have 'an action' bound
to it and this action is being performed in the server.  Actions can change
the 'keyboard state' (modifiers set, current layout and other 'control flags'),
emulate mouse events, emit some special XKB events and so on.

One of such actions is 'SetModifier(modifier)' that sets (and resets) the
specified modifier in the 'keyboard state'.  As I said an action is tied
to keysym, i.e. to a separate symbol.  In opposite to core protocol XKB doesn't
need a modifier bit be attach to something (keycode or keysym).  The modifier
that should be set with some keysym is explicitly specified in the SetModifier
action arguments.  (Strictly speaking XKB uses own internal modifiers with
clear names like Alt, Meta, LevelThree, etc.  But for reporting them to an
application in key events, XKB needs additional mapping of these internal
'virtual' modifiers to 'real' core protocols modifiers.  And for this mapping
XKB uses procedure like core protocols modifier attaching.  But it makes things
more complicated.  Therefore lets think that usual modifiers are specified
directly in the SetModifier arguments).

Thus with XKB we can put two such keysms on the same key, for example
Right Alt key   
keycode    first column         ...    third column
113        Alt_R                       ISO_Level3_Shift
           action= SetMod(Mod1)        action=SetMod(Mod4)
... and none Mods is attached anywhere.

If the current layout (XKB group) is 1 and I press this key the Alt_R keysym
is choosen and its action sets Mod1.  If the current layout is 2 (and points 
to third-fourth columns) the same key press chooses ISO_Level3_Shift and its
action sets Mod4.

But if an application using core protocols procedure (described above) tries
to find what Mod* means Alt, it finds nothing if we don't attach Mod1 to
this (or at least left Alt) key or will be confused if we attach both modifiers
(Mod1 and Mod4) to this Right Alt key.

>>  In other words, when does Alt_R set the Mod1 state and when does it set
>> the Mod4 state?

See above.  If you mean keysym Alt_R it is wrong.  Alt_R keysym always sets
Mod1 only.  But right Alt key (whole key) can have two or more keysyms that
are able to set own modifiers.  And what modifier will be set depends on
what keysym will be chosen (in dependence of the state of other modifiers
and the current layout).

>>> > For it the WM searches all (some WMs even search the first one they can find)
>>> > keys (keycodes !) that have Mod1 modifier bound, grab them all and wait
>>> > some release event.  It need not to say that if modifiers are bound to
>>> > fake keys only the WM will never get such release event.
>
>> 
>> So this is the core of the problem; there is no way to map from a 
>> modifier to the keysyms that it is bound to.

I would say that here we have another problem.
As I said it is possible to make clear one-to-one mapping between modifier
keysyms and modifier bits.  And give this mapping to an application in
traditional core protocol tables.

But for "Alt+TAB feature" an WM needs to know not this mapping only.
It needs to know exactly the key (because it can grab namely key not a keysym)
that had set this modifier.  But actually there is not such information.
And the WM does a trick.  It thinks that it is the key needed modifier is
bound to.  This binding is not needed for all other features (simple text
input or hot-keys catching).  And all other features don't need the modifier
be bound to all keys that sets this modifier (as I said XKB can set any
modifier without such Mod_to_keycode binding).

>>> > I see two ways only.  The first one is to return Mod1 to right Alt key but
>>> > don't put any other modifiers there.  But in this case in some multi layout
>>> > combinations this key will have one modifier but a few modifier keysyms.
>>> > Thus we can do it and ... wait new complains that something in some toolkits
>>> > doesn't work as expected.
>
>> 
>> What kind of problems would this give, more specifically?

Farnkly speaking - don't know.  But I didn't think that two modifiers on the
same key can cause problems (that appear differently in differnt toolkits)
until got reports about such problems.  And now I just fear to make such mix.
I know that it is ambiguity for applications and I think it _can cause_
a problem in some cases in some toolkits.

>> Yeah, we shouldn't have to burden the user with these details.  In GNOME 
>> there is a keyboard config tool to setup XKB, what if this tool could be 
>> extended to figure out from the layouts the user chooses how to 
>> configure Alt_R?  If there are no conflicts in the chosen maps, it would 
>> add and Alt_R option that would make Alt_R work correctly.

Yes.  I forget to mention that there is one more solution - to 'clean' a keymap
with some 'side software'.  But of course I don't like the solution that
solve the problem for Gnome users only ( and in Gnome versions later than xx).

--         
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email       

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.