Keyboard remapping on Linux

[ctm]

Gradually I realize it's not very realistic to flash in custom firmware for every keyboard and sometimes software remapping is just easier to do. I would like to add a few fn combinations to my keyboard. Any recommendation on remapping keys in Linux? I am running Ubuntu 14.04 with Unity.

[pr0ximity]

It's been a while since I've wanted to do anything more complicated than swap Caps and Esc, but xmodmap is pretty flexible.

[ttzhou]

deprecated, but worth a shot.

http://www.jwz.org/xkeycaps/

gui frontend to xmodmap. i avoid gui when I can but this is actually kinda neat and saves the hassle of keysym finding.

[henz]

It's been a while since I've wanted to do anything more complicated than swap Caps and Esc, but xmodmap is pretty flexible.

+1

works nicely

[jotillo]

xmodmap
"xmodmap is a utility for modifying keymaps and pointer button mappings in Xorg."

https://wiki.archlinux.org/index.php/Xmodmap
http://deskthority.net/wiki/Xmodmap

autokey
"AutoKey is a desktop automation utility for Linux and X11. It allows you to manage collection of scripts and phrases, and assign abbreviations and hotkeys to these."

https://apps.ubuntu.com/cat/applications/precise/autokey-gtk/
https://code.google.com/p/autokey/

[keyhopper]

In Linux, one can create or customize a layout by messing with these files:

        /usr/share/X11/xkb/symbols/us
        /usr/share/X11/xkb/types/pc

To have changes take effect, one must delete the cached form of those files:

        cd /var/lib/xkb/
        rm server-*

and either reboot or run:

        setxkbmap -layout 'us'
or
        setxkbmap -layout 'us(dvorak-alt-intl)'
(according to your layout).


For instance, this makes the MENU key behave as an additional WINDOWS key, unless SHIFT+MENU is pressed:

            key <MENU> { [ Super_R, Menu ] };

This maps CapsLock as an additional Escape in the layout level:

            key <CAPS> { [ Escape ] };

A lot of interesting things can be done, because one has access to the ALTGR layer here.

Cheers!

[spiceBar]

Linux offers plenty of keyboard customization that is not even able to do some simple, obvious things. That is, you can do simple things in several ways, by touching this or that obscure system file, but the kind of remapping we really want to do is not possible.

Linux lovers, flame me. I have been using linux since 2003 and I'm not bashing this system I love, I'm just saying it like it is.

There is nothing for linux like Karabiner for Mac OS or AutoHotKey for Windows.

You want to create an Fn key, so Fn + some_key will do some_other_key or even some_other_keys_combination.

This is a problem that has no simple solution under linux, at this time.

Examples:

- Change the behaviour of Ctrl+Left to do Home (instead of previous word), systemwide or at least for all X programs: not possible.

- Change Alt+Left to do Ctrl+Left systemwide: not possible.

- Change the behaviour of Fn+Left to do Home: not possible either (the Fn key could be the left Windows key or CapsLock for example).

- Change Space+Left to do Home: don't even think about it.

- Change Shift so a single press on Shift does "persistent Shift", like on a mobile phone, to capitalize only the next letter: GTFO.

When I say "not possible", I mean "not possible unless you want to spend weeks working on this". Because, after all, anything can be done with enough time and energy.

I'm currently in the process of writing a utility (a daemon actually) that will allow some of the above, using the XRecord extension. I did not intend to publish it, however, because I don't have much time to dedicate to this project.

[Pro XKB]

- Change the behaviour of Ctrl+Left to do Home (instead of previous word), systemwide or at least for all X programs: not possible.

- Change Alt+Left to do Ctrl+Left systemwide: not possible.

Possible and not too difficult with XKB, the standard X11 keyboard layout mechanism.  You just need an apropriate key "type", and a "Redirect action"

- Change the behaviour of Fn+Left to do Home: not possible either (the Fn key could be the left Windows key or CapsLock for example).

Something like this already part of the Neo 2 and AdNW layout that ship with the standard layouts (just that Home is on Fn+A, and Fn is called ISO_Level5_Shift).  It would work more robustly with a Redirect action in additon.

- Change Space+Left to do Home: don't even think about it.

Right, this one is not easy, I would do with XRecord and XTest.  I actually did something similar, a simple variant of your SpaceFn scheme.

- Change Shift so a single press on Shift does "persistent Shift", like on a mobile phone, to capitalize only the next letter: GTFO.

It's called "Latch" in XKB.  Simple.

[davkol]

XKB, xmodmap, Pystromo, a ton of X.Org utilities (e.g., xdotool), AutoKey,… It really depends what you want to do. The X is a pile of manure inside though.

BTW even KDE System Settings have a KCM that allows idiot-friendly macro/gesture configuration.

[spiceBar]

- Change the behaviour of Ctrl+Left to do Home (instead of previous word), systemwide or at least for all X programs: not possible.

- Change Alt+Left to do Ctrl+Left systemwide: not possible.

Possible and not too difficult with XKB, the standard X11 keyboard layout mechanism.  You just need an apropriate key "type", and a "Redirect action"

As it's not too difficult, you can probably show us how to do that?

- Change the behaviour of Fn+Left to do Home: not possible either (the Fn key could be the left Windows key or CapsLock for example).

Something like this already part of the Neo 2 and AdNW layout that ship with the standard layouts (just that Home is on Fn+A, and Fn is called ISO_Level5_Shift).  It would work more robustly with a Redirect action in additon.

Can show us how to do that?

- Change Space+Left to do Home: don't even think about it.

Right, this one is not easy, I would do with XRecord and XTest.  I actually did something similar, a simple variant of your SpaceFn scheme.

There are problems with XRecord/XTest that make it almost unsuitable for the task. After several attempts I started to believe it was simply impossible. But I finally figured out a way to do it. I guess you did, too, if you have implemented a variant of SpaceFN.

The main problem is that XRecord/XTest won't let you remove key events from the queue. You need to work around this if you want to implement something like SpaceFN, or anything that maps a character or function into another.

The only way that I have found is to map (for example with xmodmap) the keys I want to "own" to unused keycodes. Then I intercept the standard keycodes and generate, if needed, one of the new keycodes I have declared. I know this is not clear, so here is an example:

- You tell xmodmap that keycode 255 = space (keycode 255 cannot, apparently, be generated by any keyboard, so we use it as a "virtual" keycode).
  From now on, the clients will think that space has been pressed if you generated a keypress for keycode 255.
- You tell xmodmap that the standard keycode for space has no function at all.
  From now on the clients will not react to a physical press on the space key.

Then with the XRecord extension you intercept input events, and when you see the standard keycode for space coming, you can:
- either send space by generating a keycode 255 event
- or swallow the space and do something else (for example generate a keycode for an arrow in the case of SpaceFN)

In both cases the clients will see the usual physical keycode for space, but as they have been told that this keycode does nothing, they will not react to it (unless they have it hard-coded, which would be bad practice).

Something else to take into account is that when you generate a keypress event, you will receive it back in echo. So you must implement some mechanism to ignore the events you have generated. Not a big deal, but it definitely has to be taken into account and can have an impact on design decisions. In particular it can force you to use even more "virtual" keycodes to avoid the problem of telling apart the codes that have been generated by the user and the ones you have generated.

Another irritating point is that you can actually end up screwing the X server. For example you cannot remap the Control and Alt keys by using the trick above (mapping them to "virtual" keycodes), because if you do you will not be able to switch to a console with Ctrl-Alt-Fx or to kill the X server with Ctrl-Alt-Backspace. Apparently the X server tests for these combinations before the XRecord extension has a chance to see them. This prevents for example turning Alt-Arrow into Ctrl-Arrow, because you cannot "own" Ctrl or Alt.

As usual, the devil is in the details.

- Change Shift so a single press on Shift does "persistent Shift", like on a mobile phone, to capitalize only the next letter: GTFO.

It's called "Latch" in XKB.  Simple.

Can you tell me how to activate it?

[Pro XKB]

- Change the behaviour of Ctrl+Left to do Home (instead of previous word), systemwide or at least for all X programs: not possible.

- Change Alt+Left to do Ctrl+Left systemwide: not possible.

Possible and not too difficult with XKB, the standard X11 keyboard layout mechanism.  You just need an apropriate key "type", and a "Redirect action"

As it's not too difficult, you can probably show us how to do that?

- Change the behaviour of Fn+Left to do Home: not possible either (the Fn key could be the left Windows key or CapsLock for example).

Something like this already part of the Neo 2 and AdNW layout that ship with the standard layouts (just that Home is on Fn+A, and Fn is called ISO_Level5_Shift).  It would work more robustly with a Redirect action in additon.

Can show us how to do that?

For Redirect actions and types, see an example in the following post:

https://geekhack.org/index.php?topic=53137.msg1184091#msg1184091

For a "Fn" key, see the neo layout in symbols/de of your local xkeyboard-config installation.  For combining this with Redirect actions for better robustness, see the modified xkeyboard-config here:

http://adnw.de/uploads/Main/Downloads/AdNW-xkc.tar.gz

Here, have a look at the file compat/misc for definitions of keysyms that do a redirection, and at symbols/de and symbols/adnw for their use.

The main problem is that XRecord/XTest won't let you remove key events from the queue.

I agree, and I handle this in the same way as you do.  There might be an alternative to XRecord, described here:

http://lists.freedesktop.org/archives/xorg/2010-September/051098.html

But it is complicated and unproven.

- Change Shift so a single press on Shift does "persistent Shift", like on a mobile phone, to capitalize only the next letter: GTFO.

It's called "Latch" in XKB.  Simple.

Can you tell me how to activate it?

There is a keysym called 'ISO_Level2_Latch'.  You map it like you would map a shift key. In xmodmap syntax:

keycode 62 = ISO_Level2_Latch
add shift = ISO_Level2_Latch

(Note I cannot test this, as my xkeyboard-config is too much customized to make this meaningful).  You can also latch modifiers other than shift, even multiple modifiers at the same time.  There are predefined ISO_Level3_Latch and ISO_Level5_Latch keysyms, for other stuff you have go a bit deeper.  To see a predefined layout using latches, see the T3 layout in symbols/de of xkeyboard-config.

[spiceBar]

Thank you. I'll try your solutions and report back here.

[spiceBar]

- Change the behaviour of Ctrl+Left to do Home (instead of previous word), systemwide or at least for all X programs: not possible.

- Change Alt+Left to do Ctrl+Left systemwide: not possible.

Possible and not too difficult with XKB, the standard X11 keyboard layout mechanism.  You just need an apropriate key "type", and a "Redirect action"

As it's not too difficult, you can probably show us how to do that?

- Change the behaviour of Fn+Left to do Home: not possible either (the Fn key could be the left Windows key or CapsLock for example).

Something like this already part of the Neo 2 and AdNW layout that ship with the standard layouts (just that Home is on Fn+A, and Fn is called ISO_Level5_Shift).  It would work more robustly with a Redirect action in additon.

Can show us how to do that?

For Redirect actions and types, see an example in the following post:

https://geekhack.org/index.php?topic=53137.msg1184091#msg1184091

For a "Fn" key, see the neo layout in symbols/de of your local xkeyboard-config installation.  For combining this with Redirect actions for better robustness, see the modified xkeyboard-config here:

http://adnw.de/uploads/Main/Downloads/AdNW-xkc.tar.gz

Here, have a look at the file compat/misc for definitions of keysyms that do a redirection, and at symbols/de and symbols/adnw for their use.

I have tried what you have suggested in the GeekHack post you have linked to above, and I'm running into problems.

My first step has been to remap Control+arrow to Home, End, PgUp and PgDn.

For example, Ctrl+Up is supposed to do PgUp.

In my ".xkb" file, created from my default configuration with "xkbcomp :0 my.xkb", I have found that I already have a "type" for Control, which is called "PC_CONTROL_LEVEL2".

Here it is:
    type "PC_CONTROL_LEVEL2" {
        modifiers= Control;
        map[Control]= Level2;
        level_name[Level1]= "Base";
        level_name[Level2]= "Control";
    };

So I just use this "type" to remap the UP key, exactly as you suggested:
    key   <UP> {
      type="PC_CONTROL_LEVEL2",
      symbols[Group1] = [ Up, NoSymbol ],
      actions[Group1] = [ NoAction(), RedirectKey(key=<PGUP>,clearMods=Control) ]
    };

I then feed xkbcomp with "my.xkb":
  xkbcomp my.xkb :0

This worked fine in Firefox and OpenOffice. I thought it was great.

Then I discovered that the remapping did not work in some other programs. For example, it does not work in gedit.

What happens in these programs is that when I press Ctrl-Up they believe that Ctrl-PgUp has been pressed. The "clearMods" stuff is not working.

I'm using Ubuntu 12.04, but it appears to be a known problem in others versions of Ubuntu, and probably other versions of Linux:
  https://bugs.freedesktop.org/show_bug.cgi?format=multiple&id=78661

Apparently, client programs are free to ignore the "clearMods" thing, which means that remapping is actually not transparent. It is somehow exposed to the client programs, which defeats the purpose of remapping and leaves open the possibility of programs not behaving according to the remapping.

The other way to remap, with:
    key   <UP> {
      type="PC_CONTROL_LEVEL2",
      symbols[Group1] = [ Up, Prior ]
    };

...exhibits exactly the same problem, but in reverse. It works in gedit but does not in Firefox or OpenOffice.

This version does not work either:
    key   <UP> {
      type="PC_CONTROL_LEVEL2",
      symbols[Group1] = [ Up, Prior ],
      actions[Group1] = [ NoAction(), RedirectKey(key=<PGUP>,clearMods=Control) ]
    };

I have tried a few others without success: clearMods=Control+LControl+RControl, clearMods=all...

Do you have a solution for this? Did I do something wrong?

I'm actually wondering if you are yourself using (or tried) remapping the way you have described it, and if so why you are not affected by this problem.

The main problem is that XRecord/XTest won't let you remove key events from the queue.

I agree, and I handle this in the same way as you do.  There might be an alternative to XRecord, described here:

http://lists.freedesktop.org/archives/xorg/2010-September/051098.html

But it is complicated and unproven.

It looks like they are doing it in a similar way as we do it: to "own" Control you are going to associate it with an unused keycode.

This will suffer from the problem I have described: this will prevent Ctrl-Alt-Backspace and Ctrl-Alt-Fx to work as they should.

- Change Shift so a single press on Shift does "persistent Shift", like on a mobile phone, to capitalize only the next letter: GTFO.

It's called "Latch" in XKB.  Simple.

Can you tell me how to activate it?

There is a keysym called 'ISO_Level2_Latch'.  You map it like you would map a shift key. In xmodmap syntax:

keycode 62 = ISO_Level2_Latch
add shift = ISO_Level2_Latch

(Note I cannot test this, as my xkeyboard-config is too much customized to make this meaningful).  You can also latch modifiers other than shift, even multiple modifiers at the same time.  There are predefined ISO_Level3_Latch and ISO_Level5_Latch keysyms, for other stuff you have go a bit deeper.  To see a predefined layout using latches, see the T3 layout in symbols/de of xkeyboard-config.

Thank you, this works.

[Pro XKB]

I'm using Ubuntu 12.04, but it appears to be a known problem in others versions of Ubuntu, and probably other versions of Linux:

There was a bug in the X-server that was fixed for version 1.13 (that is, about three years ago), which affected Redirect actions for GTK 3 applications (or more precisely, applications using the Xinput extension, which GTK 3 does) . According to distrowatch.com, Ubuntu 12.04 uses X-server 1.11.4 and GTK 3.4.1, so that would fit what you see.

I'm actually wondering if you are yourself using (or tried) remapping the way you have described it, and if so why you are not affected by this problem.

Of course I am using Redirect actions, and much more extensively than you might imagine.  Nearly each keystroke I make is redirected.  However, the systems I use at work at work still use GTK 2, and my system at home has an X-server version where the problem noted above is fixed.

[keyhopper]

[..]

This worked fine in Firefox and OpenOffice. I thought it was great.

Then I discovered that the remapping did not work in some other programs. For example, it does not work in gedit.
[...]

spiceBar: have you tried with UIM?

In the past I had a problem with GTK apps, they weren't affected by the /home/<user>/.XCompose file and I needed to put some customizations there.
I solved it by using the UIM input method.
In Ubuntu/Debian do:

        sudo apt-get install uim

        sudo im-config -n uim

But UIM brings an annoying tray icon "toolbar" that can be disabled by doing this:
Edit
        /usr/share/im-config/data/24-uim.rc
and comment out this block of lines:
        # Starting GUI
        #if [ -x /usr/bin/uim-toolbar-gtk3-systray ]; then
        # [...]
        #fi

Cheers!!
.KeyHopper.

[spiceBar]

I'm using Ubuntu 12.04, but it appears to be a known problem in others versions of Ubuntu, and probably other versions of Linux:

There was a bug in the X-server that was fixed for version 1.13 (that is, about three years ago), which affected Redirect actions for GTK 3 applications (or more precisely, applications using the Xinput extension, which GTK 3 does) . According to distrowatch.com, Ubuntu 12.04 uses X-server 1.11.4 and GTK 3.4.1, so that would fit what you see.

Unfortunately it's not a bug that has been affecting only some systems for a just short period of time.

If you follow the link I have already posted, you will see that a guy reports exactly the same problem in Ubuntu 14.04 (xorg-server 1.15.1). The bug report has been made approximately one year ago.

From this report, I cannot tell if the problem with clearMods not working has been fixed or not.

What I know:
- The xkbcomp solution does not work under Ubuntu 12.04, which has an end of life in 2017.
- In may of last year, the bug still existed in Ubuntu 14.04, which has an end of life in 2019.
- We don't know if the bug has been fixed in 14.04 or in 14.10.

The bug probably affects a significant percentage of Linux systems currently in use, to this day. It is possible that it affects a majority of Ubuntu systems in production today, and some other variants as well, derived or not from Ubuntu.

I'm actually wondering if you are yourself using (or tried) remapping the way you have described it, and if so why you are not affected by this problem.

Of course I am using Redirect actions, and much more extensively than you might imagine.  Nearly each keystroke I make is redirected.  However, the systems I use at work at work still use GTK 2, and my system at home has an X-server version where the problem noted above is fixed.

OK, but the solution you suggest, which as far as I can tell would be the best one, is broken at this time. Not for you, but for me, and probably a vast number of other users.

It could happen to you as well if you have to work on a new Linux system.

There is another weakness, which is that for this solution to work, some cooperation is required from the client side. The xkbcomp solution remaps in a way that is not completely transparent to the clients, which opens the possibility that some programs will not respond correctly. I think that's exactly what is happening here, because even the solution that does not involve clearMods works on some programs, and not on others.

Is it remapping, when some programs, without even trying, can just ignore it?

Finally, for this problem to go unnoticed in xorg-server or GTK, it shows that remapping with xkbcomp is not even part of their regression tests.

[spiceBar]

[..]

This worked fine in Firefox and OpenOffice. I thought it was great.

Then I discovered that the remapping did not work in some other programs. For example, it does not work in gedit.
[...]

spiceBar: have you tried with UIM?

In the past I had a problem with GTK apps, they weren't affected by the /home/<user>/.XCompose file and I needed to put some customizations there.
I solved it by using the UIM input method.
In Ubuntu/Debian do:

        sudo apt-get install uim

        sudo im-config -n uim

But UIM brings an annoying tray icon "toolbar" that can be disabled by doing this:
Edit
        /usr/share/im-config/data/24-uim.rc
and comment out this block of lines:
        # Starting GUI
        #if [ -x /usr/bin/uim-toolbar-gtk3-systray ]; then
        # [...]
        #fi

Cheers!!
.KeyHopper.

Thank you for your suggestion.

I have just tried it, and it does not work, even after rebooting (the uim menu icon is there, so I guess the installation worked). It makes no difference whatsoever for the xkbcomp problem.

[Pro XKB]

In the past I had a problem with GTK apps, they weren't affected by the /home/<user>/.XCompose file and I needed to put some customizations there.

The compose mechanism kicks in later in the handling of input, and is unrelated to what spiceBar observes.  By the way the usual way people handle your issue is setting the environment variable GTK_IM_MODULE to xim (and, for Qt applications, QT_IM_MODULE as well).  Installing uim is not necessary.

If you follow the link I have already posted, you will see that a guy reports exactly the same problem in Ubuntu 14.04 (xorg-server 1.15.1). The bug report has been made approximately one year ago.

I followed the link and, moreover, read what is written there.  Basically, it says there is a bug with repeat handling.  Comment 6 mentions issues with consumed modifiers.  This is what you see in Firefox and OpenOffice when you NOT use RedirectKey, and is an application bug.

From this report, I cannot tell if the problem with clearMods not working has been fixed or not.

Sure you cannot tell, as bug 78661 is unrelated the RedirectKey problem. Here is the one I had in mind:

  https://bugs.freedesktop.org/show_bug.cgi?id=48224

It is marked as fixed since three years.

OK, but the solution you suggest, which as far as I can tell would be the best one, is broken at this time. Not for you, but for me, and probably a vast number of other users.

Even conservative distributions such as Redhat 6 and 7  use X-servers where the bug is already fixed.  For Ubuntu 12.04 LTS, it seems easy to get a sufficiently recent X-server:

  https://wiki.ubuntu.com/Kernel/LTSEnablementStack

There is another weakness, which is that for this solution to work, some cooperation is required from the client side.

RedirectKey does not require cooperation from the client, and that's one of the reason why it is so useful.  It tells the server to set up the key event as we want it, and that is what the client sees.

I think that's exactly what is happening here, because even the solution that does not involve clearMods works on some programs, and not on others.

I as already wrote, it is a bug in the X-server, which affects applications using the Xinput extension, which practically means GTK 3 applications.

Finally, for this problem to go unnoticed in xorg-server or GTK, it shows that remapping with xkbcomp is not even part of their regression tests.

Once more, it is a bug in the X-server.  GTK is not to blame.  Regarding testing, I do not know if there are regression tests at all.  However, whenever you start an X-server, it runs xkbcomp to map the keyboard.  Therefore, bugs in commonly used features should get noticed quickly.  RedirectKey is not very common (no layout in xkeyboard-config uses it), and most applications do not use the Xinput extension, so bugs combining both can hide for some longer time.

[spiceBar]

@Pro XKB:

Thank you for your suggestions.

I have tried to update both the kernel and the xserver on my Ubuntu 12.04, but I'm now in dependency hell. apt-get refuses to install the new packages for reasons I have yet to determine.

I'll post back when I find the time to work on this.

[spiceBar]

Unfortunately, I can't upgrade my Ubuntu 12.04 system to use the 14.04 linux kernel and X server.

apt-get informs me that there are conflicts when trying to execute the official update command.

I have researched the possible solutions and tried some of them without success. There are still a few solutions to try, but they have a good chance, from what I read, to bork my system.

You can read about the known problem with upgrading the kernel+Xserver on these pages (but there are dozens more):
  http://askubuntu.com/questions/336138/dependency-issues-while-trying-to-upgrade-12-04-2-to-the-12-04-3-hwe-stack
  http://ubuntuforums.org/showthread.php?t=2203488&page=3
  http://ubuntuforums.org/showthread.php?t=2235906
  http://ubuntuforums.org/showthread.php?t=2234815
  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1095686

I have already spent days trying to remap keys on linux and I'm fed up with this. Every possible solution leads into more problems. The prospect of rendering my system unusable and having to rebuild it is the last drop. Spending days and days just to achieve this simple thing, remapping keys, is just insane. I also have other important things to do...

I know linux is supposed to offer tools to remap keys. But this is not the whole story.

The whole story is that in real life you run into problems.

Guys, when you recommend a tool or just say that linux can do this or that easily, please remember to try it first.

Thank you for those who have tried to help. @Pro XKB: I appreciate the help you have provided. Your solution is the one I'll use, when it works.

[Pro XKB]

One pure XKB thing one might try out is:

key <UP> {
      type="PC_CONTROL_LEVEL2",
      symbols[Group1] = [ Up, NoSymbol ],
      actions[Group1] = [ NoAction(), RedirectKey(key=<FK13>,clearMods=Control) ]
};

key <FK13> {
      type="PC_CONTROL_LEVEL2",
      symbols[Group1] = [ Prior, Prior ]
};

using key FK13, assuming you do not need it otherwise.  You could also use PGUP instead, if you never want to enter Control+Prior and have it treated different from Prior alone.

The idea is that applications that do not use the XInput extensions get the Control cleared by the RedirectKey, and applications that do use XInput handle consumed modifiers properly.  GTK applications tend to be quite good in this respect, in my experience.

Of course, even if this works, setting a modifier rather than clearing one cannot be done in a similar manner.

[Skechup]

http://www.jwz.org/xkeycaps/

This is a good program as they have GUI and personally, I like anything better if it has GUI.

[spiceBar]

http://www.jwz.org/xkeycaps/

This is a good program as they have GUI and personally, I like anything better if it has GUI.

It's just a deprecated and unsupported frontend to xmodmap which has already been suggested earlier in the thread.

If you can't edit an xmodmap file it may help you, but it does not address the issue of, for example, remapping Ctrl-Arrow to Home/End/PgUp/PgDn.

[spiceBar]

One pure XKB thing one might try out is:

key <UP> {
      type="PC_CONTROL_LEVEL2",
      symbols[Group1] = [ Up, NoSymbol ],
      actions[Group1] = [ NoAction(), RedirectKey(key=<FK13>,clearMods=Control) ]
};

key <FK13> {
      type="PC_CONTROL_LEVEL2",
      symbols[Group1] = [ Prior, Prior ]
};

using key FK13, assuming you do not need it otherwise.  You could also use PGUP instead, if you never want to enter Control+Prior and have it treated different from Prior alone.

The idea is that applications that do not use the XInput extensions get the Control cleared by the RedirectKey, and applications that do use XInput handle consumed modifiers properly.  GTK applications tend to be quite good in this respect, in my experience.

Of course, even if this works, setting a modifier rather than clearing one cannot be done in a similar manner.

Well... I works!!!

At first it didn't, because I have tried using FK20 instead of FK13.

It turns out that, on my system at least, you can remap FK13 to FK24 except FK20 to FK23. 

It took me a while to figure this out, but now it works.

Thank you for the trick, it's a nice workaround for the Xserver bug.

So what I understand from this is that bouncing to another key using RedirectKey allows the clearMods to work.

Now I'm trying to remap keys in combination with Alt, and I'm hitting a wall again.

I'm doing this:
    key   <UP> {
      type="PC_ALT_LEVEL2",
      symbols = [ Up, NoSymbol ],
      actions = [ NoAction(), NoAction() ]
    };

PC_ALT_LEVEL2 is predefined as:
    type "PC_ALT_LEVEL2" {
        modifiers= Alt;
        map[Alt]= Level2;
        level_name[Level1]= "Base";
        level_name[Level2]= "Alt";
    };

Now when I hit the UP key, it generates Alt+UP, always. I don't understant why.

[Pro XKB]

It turns out that, on my system at least, you can remap FK13 to FK24 except FK20 to FK23.

In my experience, remapping keys that had some function mapped to them before sometimes causes trouble, when some program running in the background "grabs" these keys and fails to notice when you remap them.  If you remap the keys before those background programs start running, you should be fine.

So what I understand from this is that bouncing to another key using RedirectKey allows the clearMods to work.

For the programs for which clearMods did not work, it still does not work.  However, now we redirect to a key that uses Control for level selection.  Consequently, Control is "consumed", that is, not accounted for except for level selection.

Now when I hit the UP key, it generates Alt+UP, always. I don't understant why.

I tried you redefinition of UP, and in xev, it looks fine: UP along gives Up, Alt+UP gives NoSymbol with the Mod1 modifier set.  In emacs, UP is up (ok) and Alt+UP is Alt+Up, which is not ok.  I would not worry about that, what you do is correct so far.  Just add the RedirectKey to what you already have.

[spiceBar]

It turns out that, on my system at least, you can remap FK13 to FK24 except FK20 to FK23.

In my experience, remapping keys that had some function mapped to them before sometimes causes trouble, when some program running in the background "grabs" these keys and fails to notice when you remap them.  If you remap the keys before those background programs start running, you should be fine.

So what I understand from this is that bouncing to another key using RedirectKey allows the clearMods to work.

For the programs for which clearMods did not work, it still does not work.  However, now we redirect to a key that uses Control for level selection.  Consequently, Control is "consumed", that is, not accounted for except for level selection.

Now when I hit the UP key, it generates Alt+UP, always. I don't understant why.

I tried you redefinition of UP, and in xev, it looks fine: UP along gives Up, Alt+UP gives NoSymbol with the Mod1 modifier set.  In emacs, UP is up (ok) and Alt+UP is Alt+Up, which is not ok.  I would not worry about that, what you do is correct so far.  Just add the RedirectKey to what you already have.

Actually I had the RedirectKey already, but it did not work correctly, so I tried to simplify. It turns out the simplest form of using the PC_ALT_LEVEL2 type, the bit of code I have posted, behaves strangely.

What is happening is that I just press the UP key, without any modifier, and I receive Alt-UP. It does not make any sense to me.

For example in gedit, when I press UP it now exchanges the current line with the line above it (this is the default behavior for Alt-UP in gedit). In some other programs, pressing the UP key is ignored, because the program receives Alt-UP, which does nothing.

I have also tried to create a "type" myself, because I wanted to be able to distinguish between Alt and Ctrl+Alt. This new type exhibits the same problem. UP always becomes Alt-UP.

After having remapped Ctrl+arrow to do Home/End/PgUp/PgDn, the next step for me was to remap Alt+Left to Ctrl+Left (previous word) and Alt+Right to Ctrl+Right (next word).

I know that it will probably not be possible to do it because of the clearMods bug in my version of Xserver, but what I wanted to try is a workaround: to remap Ctrl+Alt+Left to Ctrl+Left, which involves removing only the Alt modifier. I thought that it would maybe be possible with the trick you have shown.

I'm sorry to be such a pain, but the linux keyboard system seems to have something against me, specifically.

[Pro XKB]

What is happening is that I just press the UP key, without any modifier, and I receive Alt-UP. It does not make any sense to me.

That is strange, indeed.  Maybe it can be understood like this: The key type consumes the Alt modifier, that is, the Alt modifier must not be considered in determining the key's function, other than determining the level.  So the application determines the level, and finds an Up keysym there.  It has one function bound to Up alone, and another one bound to Alt+Up.  But it must not consider the the Alt modifier anymore; so it cannot decide whether the to match to Up or to Alt+Up, and decides the conflict in a quasi-random fashion.  If it works like this, with the Control stuff, we just were lucky.

Now that we apparently cannot get rid of the Alt modifier, me can try to prevent it getting set in the first place.  We can do so by making Alt a key with two levels switched by Control, with the first level a plain Alt and the second level a level three shift:

    key <LALT> {
        type= "PC_CONTROL_LEVEL2",
        repeat= No,
        symbols[Group1]= [           Alt_L,          Meta_L ],
        actions[Group1]= [ SetMods(modifiers=Mod1), SetMods(modifiers=Mod5) ]
    };

(you probably can use LevelThree instead of Mod5 and Alt instead of Mod1. I prefer real modifiers for simplicity).  We introduce a new key type to select levels based on Control and the modifier for level three:

    type "CONTROL_LEVEL3" {
        modifiers= Control+Mod5;
        map[Control]= Level2;
        preserve[Control]= Control;
        map[Mod5]= Level3;
        map[Control+Mod5]= Level4;
        preserve[Control+Mod5]= Control;
        level_name[Level1]= "Base";
        level_name[Level2]= "Control";
        level_name[Level3]= "Level three";
        level_name[Level2]= "Control+Level three";
    };

and then we use it:

    key   <UP> {
      type="CONTROL_LEVEL3",
      symbols = [ Up, Up, Up, Prior ]
    };

You might have to add redirect actions to UP for robustness, but you can just redirect to one level keys, and you should not need any clearMods.

And, of course, you must press Control before Alt.  The other way round still gives you Control+Alt modifiers.

[spiceBar]

What is happening is that I just press the UP key, without any modifier, and I receive Alt-UP. It does not make any sense to me.

That is strange, indeed.  Maybe it can be understood like this: The key type consumes the Alt modifier, that is, the Alt modifier must not be considered in determining the key's function, other than determining the level.  So the application determines the level, and finds an Up keysym there.  It has one function bound to Up alone, and another one bound to Alt+Up.  But it must not consider the the Alt modifier anymore; so it cannot decide whether the to match to Up or to Alt+Up, and decides the conflict in a quasi-random fashion.  If it works like this, with the Control stuff, we just were lucky.

Now that we apparently cannot get rid of the Alt modifier, me can try to prevent it getting set in the first place.  We can do so by making Alt a key with two levels switched by Control, with the first level a plain Alt and the second level a level three shift:

    key <LALT> {
        type= "PC_CONTROL_LEVEL2",
        repeat= No,
        symbols[Group1]= [           Alt_L,          Meta_L ],
        actions[Group1]= [ SetMods(modifiers=Mod1), SetMods(modifiers=Mod5) ]
    };

(you probably can use LevelThree instead of Mod5 and Alt instead of Mod1. I prefer real modifiers for simplicity).  We introduce a new key type to select levels based on Control and the modifier for level three:

    type "CONTROL_LEVEL3" {
        modifiers= Control+Mod5;
        map[Control]= Level2;
        preserve[Control]= Control;
        map[Mod5]= Level3;
        map[Control+Mod5]= Level4;
        preserve[Control+Mod5]= Control;
        level_name[Level1]= "Base";
        level_name[Level2]= "Control";
        level_name[Level3]= "Level three";
        level_name[Level2]= "Control+Level three";
    };

and then we use it:

    key   <UP> {
      type="CONTROL_LEVEL3",
      symbols = [ Up, Up, Up, Prior ]
    };

You might have to add redirect actions to UP for robustness, but you can just redirect to one level keys, and you should not need any clearMods.

And, of course, you must press Control before Alt.  The other way round still gives you Control+Alt modifiers.

Thank you for sharing this.

I cannot test it at this time, as my Ubuntu 12.04 linux box is currently working on video conversion (and it's going to take ages).

I'm going to save this for later.

Honestly, I may actually end up giving up on remapping Ctrl-arrow for Home/End/PgUp/PgDn and Alt-arrow to previous/next word.

It's probably simpler to remap Super-arrow to Home/End/PgUp/PgDn and leave Ctrl and Alt alone. This would turn Super into a kind of Fn key similar to what we find today on some keyboards (my FC660C and FC660M can have the Fn key in place of the left Super for example). It's not important to lose the primary function of Super-arrow in Ubuntu, as I have already disabled it anyway (I think it allowed to select another virtual desktop).

I should be able to do that either with xkbcomp (preferred method if it works) or with the daemon I have already written: as long as I don't try to remap Ctrl and Alt with my daemon, I don't lose some of the functionality of the X server, like access to the virtual consoles and terminate server. So using Super should certainly be made to work.

I can easily configure my Macs to work similarly. Actually I have already written the script in Karabiner, I just have to enable this feature so my linux boxes and my Macs will react (almost) the same way to keyboard input.

Then I'll have to adapt to this, which may be less difficult than trying to work around all the problems with remapping Ctrl and Alt.

Thank you anyway for your continued support. This forum needs someone like you, someone with a deep knowledge of the linux keyboard system.