This sounds like a problem someone else had with a US layout. Unless you have any ALT key mappings in the actual Tarmak layout it shouldn't cause a problem for you – if you've defined it right. Check your includes if you have any!

Did you see how I did this in my xkb files (see my topic sig)? Notably the symbols/colemak and symbols/us files – search for 'tarmak' there. I modularized the layouts but you don't really have to do that. More importantly, you start by including one layout and then you can redefine only what you have to which in the case of Tarmak isn't many keys. (It'll give some complaints about multiple definitions if you watch the setxkbmap output, but it'll work!) If you don't mind lv3-4 mappings then just copy/paste my solution into the uk symbols file and update the rules files accordingly!

You include gb(basic) and then level3(ralt_switch_multikey) which was already included in gb(basic). That's probably what messes up your Alt key for you (although it shouldn't do anything to the LAlt...)? RAlt plus Ctrl equals AltGr which is used as a switch to type lv3-4 symbols (like 'eng/ENG' on 'g/G').

If you don't want this functionality, you can't include gb(basic) directly but have to include "latin" and change the few symbol mappings in gb(basic) in your own layout. Sorry, but the layouts tend to mess with modifier settings which they arguably shouldn't do directly but on a higher level like my modular layouts do. The lv3 switch is very basic though, as just about any layout with lv3-4 mappings tends to use the RAlt key as an AltGr.

Keep in mind that on most Linux systems you can set the behavior of modifier keys in Options as well! So check your keyboard options for any interesting settings that may affect your Alt keys. Try a 'setxkbmap -v 9' to see what your active configuration is.

One little typo in your script: '    name[Group1]="English (UK, Tarmak-1)";' – 'Tarmak-1' should've been 'Tarmak-2'.

Tip: Using [] tags with 'code' and '/code' in your forum posts helps readability. ;)

Logging out and back is necessary but not sufficient (unless you know how to restart the xkb server manually) as it doesn't refresh anything if there's already a server file present. My instdiff script therefore clears out the old temporary server files in /var/lib/xkb/server*.xkm which you should do too.

My patch script works from an unmodified XKB install. If you've made changes to files you'll have to merge patches manually. Reinstalling xkb defaults is as simple as putting back the backups for the files you messed with. You *did* back up those files, right? ;)

Actually, if you look in my "modified files" download for Ub13.04 the original files are there – only the ones I've made changes to but those include the ones you changed.

If the "offending lines" haven't made any difference then your problem shouldn't be about Tarmak at all. My prediction is that the default UK layout will exhibit the same behavior for you and the problem sits in one of the Options settings. Try the verbose setxkbmap I mentioned above.

great - i'll take a look later and hopefully get it fixed

xev

I can't remember if this caused any side-effects (back before I started swapping via evdev, due to wanting caps -> esc -> ctrl -> caps).

I wish I could help more, but when it comes to xkb, I'm little more than an amateur hack. (The messy hack solution, by the way, would be to, starting from scratch, simply edit a preexisting qwerty layout in /usr/share/X11/xkb/symbols/us, everytime you wanted to switch tarmaks.  It's only 4-5 keys at a time, and it's not like you'll go back to the previous tarmak.  Terrible and lazy solution, I know..)

heres what xev is telling me (for tarmak-2):

press left alt (M):

KeyPress event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2182112, (84,-58), root:(1537,457),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2182472, (84,-58), root:(1537,457),
    state 0x4018, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

press j (qwerty g):

KeyPress event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2544853, (106,-13), root:(1559,502),
    state 0x4010, keycode 42 (keysym 0x6a, j), same_screen YES,
    XKeysymToKeycode returns keycode: 44
    XLookupString gives 1 bytes: (6a) "j"
    XmbLookupString gives 1 bytes: (6a) "j"
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2545013, (106,-13), root:(1559,502),
    state 0x4010, keycode 42 (keysym 0x6a, j), same_screen YES,
    XKeysymToKeycode returns keycode: 44
    XLookupString gives 1 bytes: (6a) "j"
    XFilterEvent returns: False

press g (qwerty t):

KeyPress event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2224592, (0,-82), root:(1453,433),
    state 0x4010, keycode 28 (keysym 0x67, g), same_screen YES,
    XKeysymToKeycode returns keycode: 42
    XLookupString gives 1 bytes: (67) "g"
    XmbLookupString gives 1 bytes: (67) "g"
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2224872, (0,-82), root:(1453,433),
    state 0x4010, keycode 28 (keysym 0x67, g), same_screen YES,
    XKeysymToKeycode returns keycode: 42
    XLookupString gives 1 bytes: (67) "g"
    XFilterEvent returns: False

press M-g (qwerty M-t):

KeyPress event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2038881, (85,-172), root:(1538,343),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 41, synthetic NO, window 0x3a00001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 41, synthetic NO, window 0x3a00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 41, synthetic NO, window 0x0,
    keys:  4294967212 0   0   16  0   0   0   0   1   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

KeyPress event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2039121, (85,-172), root:(1538,343),
    state 0x18, keycode 28 (keysym 0x74, t), same_screen YES,
    XLookupString gives 1 bytes: (74) "t"
    XmbLookupString gives 1 bytes: (74) "t"
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2039337, (85,-172), root:(1538,343),
    state 0x4018, keycode 28 (keysym 0x67, g), same_screen YES,
    XKeysymToKeycode returns keycode: 42
    XLookupString gives 1 bytes: (67) "g"
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x3a00001,
    root 0xa5, subw 0x0, time 2039673, (85,-172), root:(1538,343),
    state 0x4018, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

note the weirdness going on with the keypress and keyrelease for 'g' (in the M-g) being different; on press it is 't' and on release it is 'g' - could this be the root of the problem?

I notice also that:

XKeysymToKeycode returns keycode: 42

is missing from the 'g' key press for 'M-g' as opposed to the xev output for just pressing 'g'

This would tally with the behaviour in emacs, i.e. M-g-g is doing a double 'transpose' rather than 'goto-line', i.e emacs is executing M-t twice

Like lalop (and I) said a couple of times, you need to check if this is a Colemak or general issue (sure seems like the latter by now)! Check the preinstalled Dvorak layout for instance.

And yeah, make sure the layout you test is the first one in the list. Some silly programs can't get it right otherwise.

Yeah, sorry I forgot to mention that. It's a known bug, not only affecting Colemakers – but it doesn't seem to get fixed...

I've added a mention of this problem in my Big Bag topic.