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

[bugzilla-daemon at freedesktop.org]

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:32 -------
[ I mailed Ivan Pascal about the change to the xkb files ]

  Hi,

>> As you can see this change breaks among others the metacity window 
>> manager.  I'm not too familiar with XKB, could you suggest a fix for 
>> this?  I was thinking of adding back the line
>> 
>>    modifier_map Mod1   { Alt_L, Alt_R };
>> 
>> in the pc/pc(basic) section, which works for me, but I fear it may break 
>> something else.  Could you comment?


OK.  Let me explain.
It was a fix for some problem arised after addind muti-layout capability.
In such multi-layout you can combine (in differnt XKB groups), say, 'us' keymap
where right Alt key is just Alt and 'cz' keymap where this key is used as
AltGr i.e. for acces to third-fourth symbol of the key.  Or you can put 'ru'
keymap (where right Alt is Alt) above 'de' keymap where this key is AltGr.

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.

The roots of the problems are...
* XKB and core protocol have different approaches to modifiers.  In the core
protocol a modifier bit is attached to a keycode i.e. to a whole key.  Whereas
in XKB a modifier is controlled by a single keysym i.e. the same key can
set/reset different modifiers in dependence on other modifiers state or
the current XKB group (layout).

This differnce itself is not a big problem.  At least XKB approach is more
flexible and it sets modifiers well and an application gets their state
correctly.  But you know a part of modifiers are unnamed and an application
need to know what each Mod* means in each keymap.
And here we face a serious problem...

* All toolkits don't use directly XKB functions and...
* Xlib doesn't provide any public (core protocol) functions to find the mapping
between modifier bits and keysyms (like GetModifier(keysym) or
GetKeysym(modifier)).  If such mapping functions existed they could be replaced
with XKB's ones in Xlib invisibly for an application and the differnce in
approaches would not matter.

Instead Xlib provides a 'raw data' such as core protocol tables of 'modifiers
to keycodes' binding and 'keycodes to keysyms' table (the keymap itself)
and makes a toolkit to guess about Mod's binding in own way.  And the worst
thing is that diferent toolkits make is in different ways.

In the core protocol one-layout maps it was simple.  There was one Mod on
each modifier key and one keysym (at least one _modifier_ keysym) tied to
this key.  An application found modifier-keycode and keycode-modifier_keysym
pairs and made modifier-modifier_keysym mapping.

But in the multi-layout cases I said above we have ambiguity.  The right Alt
key has two Mods bound and at least two keysyms that are modifier ones.
If a toolkit asked XKB about mapping it would get clear answer (two separated
pairs).  But actually it tries to guess about this mapping from core protocol
tables where such mess can't be resolved.

As I said different toolkits in such cases come to differnt conclusions.
Some of them thinks that Alt is active only when both Mods (Mod1 and Mod4)
are set. Some other become crazy and think that Alt modifier is set always
even if none modifier key is pressed.  (You guess in this case you press the
letter key 'F' but an application instead of printing the letter opens 'File'
menu which hotkey is Alt+F).  And in the rest Alt key doesn't work anyhow.

To avoid these problems I removed all modifiers (unnamed Mods) from real keys
and made some 'fake keys'.  I took keycodes (scan-codes) that are never produced
by hardware keyboard and therefore I could use them as I like.
Using these never_can_be_pressed keys I made simple one_keycode-one_modifier
and one_keycode-one_keysym pairs to help application to guess about Mods
meaning (Mod* - keysym relations) even they use dumb core protocol tables.
The problem with "many modifiers and many keysyms on the same key" mess was
solved.

But it led to the problem you talk about.

The thing is that Alt+TAB feature (copied from MS Windows) doesn't fit well
X Window architecture.  In X's a window manager can't get key press/release
events from any key because they are passed to focused window only.
Of course there is GrabKey mechanism but it contrary passes events to the
grabing application but not to the focused window.  There even is a way to
repeat the grabed even for the focused window but it is too comples and need
the grabing application makes UnGrab and grab again for each such event.

Therefore no one WM (AFAIK) grabs modifier keys.  Instead a WM garbs 'TAB with
Alt modifier' combination only (in such case TAB alone or with any other
modifier arrives to the focised window).  But the problem is that when it
gets such grabed event it doesn't know what key had set this Alt modifier.
In the same time it must to know when this _unknown_ key will be released.

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.

To solve (or rather to moderate) this problem I returned Mod1 (and some other
modifiers) to the real key left Alt.  This key usualy has not other meaning
(unless it is Meta key) and it should not cause any conflict between modifiers.
But the right Alt key (as I said) can be used for two (or even more) modifiers
in different layouts and I didn't dare to tie Mod1 to it.

The another one problem is that 'XKB language' doesn't have any 'if-then'
construction and I can't imagine how to make it guess when Mod1 can be put
onto this key (when a single layout is used or all of layouts use right Alt
in the same way) and when is shouldn't be done.

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.

And the second one is to make special XKB option that does only one thing -
maps Mod1 to right Alt key.  In this case all users who want right alt key
works as Alt have to specify this option explicitly in their configs.
I guess they will not be happy to learn such detail but it is most correct
solution I can offer now.

-- Ivan U. Pascal | e-mail: pascal at tsu.ru Administrator of | Tomsk State
University University Network | Tomsk, Russia         
   
   
--         
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.