On Mon, Aug 04, 2014 at 11:13:39AM +0900, Carsten Haitzler wrote: > xmodmap creates a conflict of modifier maps with your setup. phab ticket has > an > explanation - as does the git commit log.
I re-read it an I think I understand it better now. Basically it seems that you cannot assign mode_switch to right alt anymore, at least not in a way that upsets efl (somehow every other program I've used doesn't see or doesn't care about the alt/altgr conflict you explained). I think you said you never could, but I have for a very long time without issues and I'm seeing a different modifier for both alt keys (see below). So putting it another way, just setting xmodmap -e "keycode 108 = Mode_switch" will upset efl and cause the workaround you coded up to kick in, while somehow working with other apps just fine (not sure how or why) Now, the part where I'm confused is that with your patch I can type é in enlightenment itself, but I just can't type it in terminology, which is what started this thread. Somehow it works for John, but not for me. > you have altgr create a modifer mask of 0x8 (bit # 4 set). alt ALSO produces > this bitmask as well. (i don't remember the exact bit bit they both had the > SAME mask). since we detect modifiers by the bitmask - it's now ambiguous. > > try it. hit alt+x then altgr+x - in xev. look at state value. that is the > modifier/lock states. notice it has the same value with either key. note that > with bindings you dont see the modifier key press. you only see the "x" or > "f1" > or whatever along with the current state, so we can't go tracking the modifier > keys themselves. Sorry, let's be more clear. I don't have an altgr key on a US keyboard, by altgr, you mean right alt, aka keycode 108? I have a left alt and right alt. They return different things with xev. left alt: state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, right alt: state 0x0, keycode 108 (keysym 0xff7e, Mode_switch), same_screen YES, left alt+e: state 0x8, keycode 26 (keysym 0x65, e) right alt+e: state 0x2000, keycode 26 (keysym 0xe9, eacute) Clearly state 0x8 and state 0x2000 are not the same, which is why that seems to work fine everywhere, except terminology. I do understand that both keys return 0x8 before I remap right alt, and apparently that's what you've been trying to tell me (and explain in https://phab.enlightenment.org/T1273 ), so I think you're saying that efl gets upset because a key that used to be the same as left alt is now a different modifier. > it's not broken because no one allowed altgr as a modifier. like alt, ctrl, > shift. we do that. this creates a conflict. I understand why you're saying this, but I'm not seeing it with xev :) Sorry for being french and using weird 8 bit characters ;) But more seriously, I'm very perplexed as to why this now works in enlightenment, everywhere else, but not in terminology. terminology just displays 'e' instead of 'é' when I use right alt+e, although it can write é if I use right ctrl (Multi) + ' + e, so it's not a display problem, just an input problem (we kind of knew that, but just confirming). Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
