How can I swap left control with search keys when using the Crouton 'keyboard' target?

darcyparker commented 10 years ago

On a typical modern keyboard (88/101/102 keys) I (like many others) like to map Capslock to CTRL. (I normally don't swap the left CTRL and Capslock because I have no need for Capslock.)

In ChromeOS it is easy to swap the Ctrl and Search keys. And when I ssh into my crouton chroot, I get the desired experience.

But when I am using xfce, (jessie with the Crouton 'keyboard' target included), I am having difficulties figuring out how to swap the CTRL and Search keys.

I read https://github.com/dnschneid/crouton/wiki/Keyboard and man xmodmap and tried things like:

xmodmap -e "keycode 133 = Control_L"
xmodmap -e "keycode 37 = Overlay1_Enable"

but this hasn't work for me.

I'd like to have the 'keyboard' target provided by crouton because I like being able to enter F11 and F12 by pressing "Search" and "-", and "Search" and "+" respectively. But I'd like to swap the Search and Ctrl keys.

I suspect there is something that is non obvious about how the mappings in the keyboard target are stacking up.

Has anyone else figured this out? And if so, can you please share how you did it? Thanks.

dnschneid commented 10 years ago

You probably want to start by modifying /usr/share/x11/xkb/symbols/chromebook to change LWIN to whatever you want for the overlay enable, then xmodmap should work for mapping search to ctrl. You may have to clear out /var/lib/xkb/*.xkm and restart the chroot for the modifications to take affect, after which using xmodmap to change search to ctrl should work. Note that updating your chroot with the crouton installer will overwrite this change.

@drinkcat: perhaps it's worth detecting that specific modification and sustaining it when updating a chroot?

m040601 commented 10 years ago

I too, still haven't been able to " swap left control with search keys when using the Crouton 'keyboard' target"

@drinkcat: perhaps it's worth detecting that specific modification and sustaining it when updating a chroot?

Vote 1 for this. It's more than worth it, it should be mandatory.

After carefully reading:

all the wiki entries on crouton and croagh
all the github questions and issues posted related to keyboard customization
a lot of very usefull resources that i strongly recommend:
- wikipedia pages that I strongly recommend: ‎ https://en.wikipedia.org/wiki/Template:Keyboard_keys https://en.wikipedia.org/wiki/Modifier_key‎ https://en.wikipedia.org/wiki/Meta_key
- arch wiki pages: https://wiki.archlinux.org/index.php/X_KeyBoard_extension https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg https://wiki.archlinux.org/index.php/Extra_Keyboard_Keys https://wiki.archlinux.org/index.php/Extra_Keyboard_Keys_in_Console

I'm convinced that keyboard setup is such a basic and fundamental thing that it should really deserve a special attention in :

Sane defaults and working out of the box
Care in the documentation/wiki
- An effort to persuade people commenting on the issues to update the wiki. Dont let that knowledge there "buried" for ever. Avoid someone else coming up in a couple of weeks with similar questions.
- Pointers to basic knowledge (wikipedia etc), for those unfamiliar with the lingo/basic knowledge. There's no need to repeat oneself, when there's good info elsewhere for the basic questions.
- Avoid assuming prior knowledge from the users. Carefull with the lingo. Dont assume any apriori knowledge specially on keyboard issues even for more experienced users.
- The chroot design decisions on this matter made by the crouton/croagh devs
- Carefull mentioning and attention to relevant exceptions. That is, does this or that hack/customization applies to, ex:
  - editing files: are we talking about inside or outside the chroot ?
  - distro: is it universal ? or does it only apply to ubuntu ? or arch or ...
  - hardware: is it universal ? or does it only apply for the x86 laptops ? or only the arm laptops/models ?

Just think of how much time and effort would be saved dealing with all the isssues with keyboard questions that show up regularly

I dont think that,

You probably want to start by modifying /usr/share/x11/xkb/symbols/chromebook applies to the vast majority of crouton/croagh users, even if they are not linux newbies or familiar with chroot concepts.

I'm not a developer in any way, but I'm fairly confortable customizing my console or X11 environment "by hand" editing config files.

One exception to this is the keyboard infrastructure in linux. All the design, hardware, configuration possibilites and utilites: scancodes, keycodes, xkb, xmodmap, xresources, xcape etc etc. still make my head bang on the wall.

As someone already said, on " Questions about the keyboard overlay · Issue #267" https://github.com/dnschneid/crouton/issues/267

Indeed this stuff looks like unneeded rocket science, with Ariane5 piled upon Shuttle piled upon Saturn piled upon Sputnik etc. :-)

and

Nothing much is obvious with xkb, xmodmap, xkbcomp, xbindkeys, etc. There are 3-4 ways of accomplishing the same stuff, none of them being perfect in all aspects.

And me too, i dont want to mess around with things i still dont quite understand,

I certainly wouldn't want my personal use case messing up something that's clean and working well.

m040601 commented 10 years ago

is xmodmap the only (and right way) to accomplish these kind of things on crouton ? what about using xkbcomp in crouton for customization ?

My question is because on ,

https://wiki.archlinux.org/index.php/X_KeyBoard_extension#xmodmap

While sometimes used in conjunction with preset configuration, xmodmap is not directly related to XKB. This tool uses different (pre-XKB) ideas on how keycodes are processed within X; in particular, xmodmap lacks the notion of groups and types, so trying to set more than one keysym per key is not likely to work.

Generally it is not recommended to use xmodmap, except maybe for the simpliest tasks. XKB-compatible equivalent of xmodmap is xkbcomp; however, xkbcomp lacks -e option, so it is not that simple. Anyway, whenever possible, xkbcomp should be preferred.

darcyparker commented 10 years ago

@dnschneid - thank you for the pointer to /usr/share/x11/xkb/symbols/chromebook. I will give this a try when I get a chance... but it may take me a week or so to find the time to look at it more closely. If/when I find a solution, I will share it here.

@m040601 - I am glad you voted for this.

@drinkcat: I think it would be helpful to have a SwapCtrlSearch target that extends the existing keyboard target, or another keyboard_with_CtrlSearch_Swapped target that is similar to the existing keyboard target. It's such a popular use case that I am sure it will be appreciated by many chroot users.

(As a side comment: I am glad Google eliminated the caps lock key on the chrome books... but I am surprised they put the search key in its place and not Control. Putting the Control key where capslock was is the most common alternative in practice. I speculate it was a hot debate among their designers about where to put the control and search keys. Fortunately they made it possible to swap the keys in ChromeOS. Hopefully it won't be too hard to support this in a crouton chroot.)

drinkcat commented 10 years ago

@darcyparker : Gave it a quick try, and I believe this is the way to go:

xmodmap -e "keycode 133 = Control_L"
xmodmap -e "keycode 37 = Overlay1_Enable"
xmodmap -e "add control = Control_L"
xmodmap -e "remove control = Overlay1_Enable"

I didn't investigate why this did not cause problems with Super_L (I think some WM ignore modifiers and look only at key stroke sequence).

A keyboard layout variant is also a good idea, and it can easily be applied in a startup script (feel free to try.... see below...)

Please update the wiki if that works!

@m040601 :

One exception to this is the keyboard infrastructure in linux. All the design, hardware, configuration possibilites and utilites: scancodes, keycodes, xkb, xmodmap, xresources, xcape etc etc. still make my head bang on the wall.

Which is why I've not been very enthusiastic about this topic ,-) What we currently have is one of many possibilities (other alternatives had bigger problems), but everytime I try to extend it, it keeps falling apart... On the other hand, the solution that we currently have works well for most users I believe.

And I agree that there is a need to summarize outstanding issues (I'll try to do that in the wiki when I have time).

darcyparker commented 10 years ago

@drinkcat - I gave your commands a try and they work! Thank you. I need a little more help though.

I tried adding the following to automate this setting in the following start up scripts:

Note that I put some basic logging to ~/mylog.txt to prove to myself that these are getting executed. The ~/.xsessionrc does not execute unless I put it in the xinitrc

#!/bin/sh
# This file is: ~/.config/xfce4/xinitrc
# Note, /etc/X11/xinit/xinitrc doesn't get executed when I start my chroot 
# with `sudo startxfce4`... I looked into `startxfce4` further and found out 
# that it instead does `exec` on ~/.config/xfce4/xinitc... which did not exist. 
# So I created one based on /etc/X11/xinit/xinitrc.  After doing this, the 
# ~/.xsessionrc below gets sourced.
set -e
echo "`date` Running ~/.config/xfce4/xinitrc" >> ~/mylog.txt
. /etc/X11/Xsession

# This file is: ~/.xsessionrc
# Notes about ~/.xsessionrc:
#   - This file is sourced by Xsession(5), not executed.
#   - See /etc/X11/Xsession script
#       1. It sets $USERXSESSIONRC to "$HOME/.xsessionrc"
#       2. It also sources /etc/X11/Xsession.d/* including
#          "40x11-common_xsessionrc"
#       3. "40x11-common_xsessionrc" sources "$USERXSESSIONRC"
#          (this file)
#   - Also note that /etc/X11/xinit/xinitrc sources /etc/X11/Xsession
#
# Swap Ctrl and Search keys for ChromeOS Crouton chroots
# Note: This works well with the crouton 'keyboard' target
# Credit for this snippet: http://goo.gl/O8zaBR
echo "`date` Running ~/.xsessionrc" >> ~/mylog.txt
xmodmap -e "keycode 133 = Control_L"
xmodmap -e "keycode 37 = Overlay1_Enable"
xmodmap -e "add control = Control_L"
xmodmap -e "remove control = Overlay1_Enable"

The ~/.xsessionrc is running because I get timestampped messages in ~/mylog.txt.... But for some reason the xmodmap commands are not running? or the changes being made by these commands are not sticking.

I do get some errors in ~/.xsession-errors that I don't get when I remove the files above... but I don't see anything obvious in this errors file that would indicate what is wrong with the xmodmap commands.

Xsession: X session started for darcy at Thu May  8 12:24:43 EDT 2014
localuser:darcy being added to access control list
xfce4-session-Message: ssh-agent is already running; starting gpg-agent without ssh support
/usr/bin/xbindkeys_autostart: line 24: CONF: unbound variable

(xfdesktop:13366): GLib-GIO-CRITICAL **: g_file_get_path: assertion 'G_IS_FILE (file)' failed

(xfdesktop:13366): GLib-GIO-CRITICAL **: g_file_get_path: assertion 'G_IS_FILE (file)' failed

(xfdesktop:13366): GLib-GIO-CRITICAL **: g_file_get_path: assertion 'G_IS_FILE (file)' failed

(xfdesktop:13366): GLib-GIO-CRITICAL **: g_file_get_path: assertion 'G_IS_FILE (file)' failed
xscreensaver: 12:28:45: SIGHUP received: restarting...
xscreensaver: 12:28:45: running as darcy/darcy (1000/1000)

xscreensaver: 12:28:46: Can't open display: :1.0
xscreensaver: 12:28:46: running as darcy/darcy (1000/1000)

xscreensaver: 12:28:46: Errors at startup are usually authorization problems.
              But you're not logging in as root (good!) so something
              else must be wrong.  Did you read the manual and the FAQ?

              http://www.jwz.org/xscreensaver/faq.html
              http://www.jwz.org/xscreensaver/man.html

Xsession: X session started for darcy at Thu May  8 12:29:45 EDT 2014
localuser:darcy being added to access control list
xfce4-session-Message: ssh-agent is already running; starting gpg-agent without ssh support
/usr/bin/xbindkeys_autostart: line 24: CONF: unbound variable

(xfdesktop:19665): GLib-GIO-CRITICAL **: g_file_get_path: assertion 'G_IS_FILE (file)' failed

(xfdesktop:19665): GLib-GIO-CRITICAL **: g_file_get_path: assertion 'G_IS_FILE (file)' failed

(xfdesktop:19665): GLib-GIO-CRITICAL **: g_file_get_path: assertion 'G_IS_FILE (file)' failed

(xfdesktop:19665): GLib-GIO-CRITICAL **: g_file_get_path: assertion 'G_IS_FILE (file)' failed
Created new window in existing browser session.
[WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED

Do you have any suggestions about how I should be putting these in my init scripts? (I am not putting these in ~/.bashrc or .profile etc because it seems unnecessary to run these every time I start a shell. They only need to be run once per x windows session. And although I run a terminal/shell frequently, I don't want to have this be a requirement.

Any suggestions or help is appreciated. (I'll update the wiki when I get a fully working solution.)

drinkcat commented 10 years ago

@darcyparker: Have a look at this: https://wiki.archlinux.org/index.php/xfce#Custom_Startup_Applications I'd recommend the first approach: creating a custom shell script and adding it in "Application Autostart".

drinkcat commented 10 years ago

Wiki updated: https://github.com/dnschneid/crouton/wiki/Keyboard , with instructions for Control_L swap, and outstanding issues (@m040601). If you have some time, please have a look, and update if it's not clear.

DennisLfromGA commented 10 years ago

And I agree that there is a need to summarize outstanding issues (I'll try to do that in the wiki when I have time)

@drinkcat, So sorry, that task had been assigned to me and I've made absolutely no progress on it. You even tried to get me started in https://github.com/dnschneid/crouton/issues/627#issuecomment-35473272 :-)

willardthor commented 10 years ago

@drinkcat and @darcyparker : Have none of you experienced strange behavior from the keys after the swap? On my machine (Samsung Chromebook 2 13 inch), when I press the left control key, xev reports both an Overlay1_Enable and a control KeyPress / KeyRelease event. A similar problem arises when I simply try to make Control_R stop being a control modifier; see my post on this on the Arch Linux forums for details: https://bbs.archlinux.org/viewtopic.php?id=187052

darcyparker commented 10 years ago

@willardthor - Sorry, I am not experiencing the problems you describe. (I have an asus 720p chromebook and I am running jessie (debian) using crouton.) And I am simply using the 4 xmodmap @drinkcat suggested above. They seem to work well for me. (I use vim, tmux, and tig and other tools regularly and don't have problems with the swapped ctrl and search keys on my chromebook in jessie crouton.)

I had a quick look at your post in the arch linux forum. Do be honest, I didn't have time to really look at it in detail and I am not at my chromebook right now... but I will try the xev tests you outlined and let you know what I find.

willardthor commented 10 years ago

@darcyparker : I would appreciate that; here is a simpler test you can make: xmodmap -e "remove Control = Control_R", and see which events xev reports upon pressing Control_R. On my machine, pressing Control_R will generate events for 2 different keys (I tried this without the search and Control_L keys swapped).

(My current workaround for this problem is to make the search key, Control_L and Control_R all be control modifiers; this makes Control_R stop behaving erratically. But having a Super_L key and/or a Overlay1_Enable key would make using my Chromebook function keys, and controlling dwm, much easier).

dme commented 10 years ago

There are significant differences between how this works depending on whether you have xorg or xephyr (typically Intel Chromebooks are using Xorg and ARM Chromebooks are using Xephyr). It would help if people reporting both problems and solutions could indicate whether they are using Xorg or Xephyr.

darcyparker commented 10 years ago

@willardthor - sorry for the long delay. I tried xmodmap -e "remove Control = Control_R" without swapping the keys first... so I was using just the out of the box keyboard settings before I entered the xmodmap command.) Both before and after the xev showed a KeyPress and keyRelease event for the Control_R key. (I am not sure why the behavior did not change after the command...)

With the commands suggested by @drinkcat above, I haven't had any problems... I use tmux/vim all the time and I can toggle the xfce terminal's full screen using F11. (Actually the old ctrl key and dash - key to get F11...) And other function keys seem to work as expected...

Sorry you are having problems... (I don't fully understand everything you have tried... but hopefully my description above will be clear so you can get a sense if I am testing the same thing.)

@dme - I am on an Acer C720p model ZHN mfg date 2013/09/26. How can I tell if I am using Xorg or Xephyr?)

darcyparker commented 10 years ago

@dme - I figured out how to tell if I am using Xorg or Xephyr... See https://github.com/dnschneid/crouton/blob/master/targets/core#L12-L16 where $ARCH is set and https://github.com/dnschneid/crouton/blob/master/targets/x11 for logic based on $ARCH that determines whether Xorg or Xephyr is used. If I do croutonversion -a inside the chroot, I get amd64. So I am using Xorg....

willardthor commented 10 years ago

@darcyparker : Thank you very much for testing the command. The result you describe seems to indicate that your right control key is behaving as intended (whereas mine is not). The reason xev is reporting Control_R when you press your right control key is because the keycode tied to that button is still mapped to the keysym Control_R (which was a Control modifier before you executed xmodmap -e "remove Control = Control_R", and stopped being a Control modifier after; check the expression grammar in the xmodmap man page for an explanation of this jargon).

The output of croutonversion -a on my machine is armv7h. Which makes sense since my Chromebook has an ARM processor. So my Crouton is using Xephyr. To sanity check, I performed the following interaction in a shell in Chrome OS, while Crouton (chroagh) is running:

chronos@localhost / $ ps -e | grep [Xx]ephyr
18702 ?        00:00:05 Xephyr
chronos@localhost / $ ps -e | grep [Xx]org
chronos@localhost / $

@dme : Which command(s)/config(s) do I use/modify to swap keys sanely in Xephyr?

dme commented 10 years ago

On Fri, Oct 10 2014, willardthor wrote:

@dme : Which command(s) or config(s) do I use/modify to swap keys sanely in Xephyr?

Sorry for the long delay. I'm back working at trying to figure this out.

In the Xorg case things should be relatively straightforward - the X server is reading the keyboard scancodes directly, so it can apply whatever transforms you like in a manner similar to that used on any x86 desktop system.

With Xephyr in the mix it seems that things get complicated. It may be that it's just not possible to make the relevant changes without changing the mappings of the underlying (ChromeOS) X server.

dme commented 10 years ago

On Tue, Nov 11 2014, David Edmondson wrote:

Sorry for the long delay. I'm back working at trying to figure this out.

Firstly, I should be clear that I don't have the 'keyboard' target installed. This runs contrary to the title of this issue, so perhaps the approach described here won't help in that case. I may play with that later.

Second, this only applies to systems using Xephyr (all ARM based Chromebooks, I believe). Systems using Xorg should be simpler to solve.

I have the jessie variant of the x11 target installed, and have then added only i3. So no xfce, etc.

If I change the modifier mappings of the host X server (Xorg :0, the one that is running Chrome) before starting the crouton X server (Xephyr :1, the one that is running in the chroot), then the remapping works. xmodmap for Xephyr doesn't show the correct information, but the right things happen when I hit the control and search keys (that is, they act as mod4 and control respectively).

So the sequence of operations is: 1) boot ChromeOS, 2) start a shell (ctrl-shift-t), 3) enter the chroot ("sudo enter_chroot"), 4) fix the modifier mappings (see below), 5) start Xephyr ("xinit").

If you are using xfce or something else, perhaps step 5 will look different for you.

For step 4, I have a small shell script:

#!/bin/bash
export XAUTHORITY=/var/host/Xauthority
export DISPLAY=:0
xmodmap -e "remove control = Control_L"
xmodmap -e "remove control = Control_R"
xmodmap -e "remove mod4 = Super_L"
xmodmap -e "remove mod4 = Super_L"
xmodmap -e "add control = Super_L"
xmodmap -e "add mod4 = Control_L"
xmodmap -e "add mod4 = Control_R"

Note that this will change the behaviour of the ChromeOS X server, so it will affect applications running there as well!

DennisLfromGA commented 10 years ago

On Tue, Nov 11, 2014 at 10:17 AM, David Edmondson notifications@github.com wrote:

So the sequence of operations is:

Maybe you could put the 'modifier mappings' in /etc/rc.local and, in in step 3., go straight into your DE avoiding steps 4. & 5.

DennyL@GMail

dme commented 10 years ago

On Tue, Nov 11 2014, DennisL wrote:

Maybe you could put the 'modifier mappings' in /etc/rc.local and, in in step 3., go straight into your DE avoiding steps 4. & 5.

That should work, yes. Let's be sure that we're getting the desired behaviour first.

morsedl commented 9 years ago

BACKGROUND

It's taken quite some effort, but I finally have a solution that does as I desire on my new Asus c300 Chromebook (crouton, with the "keyboard" target added post-install, Ubuntu 12.04 LTS aka "precise"). There were several pitfalls and false starts along the way. Two in particular were quite troublesome, so I mention them here as well, in case doing so benefits others.

My desired setup is as follows:

I very much needed the overlay key, not so much for brightness and volume (although those do work in my setup), but because certain applications are notably more difficult to use without PgUp / PgDn / Home / End / Insert / Delete keys. I opted for the Control_R key.
I use the Ctrl key all the time, and on all my other systems I map BOTH CapsLock and Control_L as control key modifiers. Thus, for my Chromebook, I wanted both Search and Control_L to act as control keys.
I use Unity, not XFCE, so I need an equivalent of the "WIN" key to access many Unity functions. I opted to make this key the Alt_R key.

Put more simply, I had the following Goals:

Control_R = Overlay1_Enable (modifier)
Search = Ctrl (modifier)
Control_L = Ctrl (modifier)
Alt_R = WIN / "Unity" key

Before describing the procedure, I should note the particular keycodes in use on the Asus c300, as they may not match the default keycodes on other systems. Thus, if you try this procedure on another system and it does not work, then you may need to use different keycodes. The Asus c300 seems to use the keycodes from /usr/share/X11/xkb/keycodes/evdev by default, which is where I obtained these values (or by using xmodmap -pke, before making any modifications). Different systems may have different values in this file (or in an different file in the same directory; which file is used on your system is something you will have to figure out). Here are my keycodes:

keycode	physical key
133	Search
37	Ctrl (Left)
105	Ctrl (Right)
108	Alt (Right)

In the procedure that follows, I only use keycodes 133 and 108, but I listed the keycodes for all the keys involved (for completeness).

THE PROCEDURE (AND PITFALLS)

As for the procedure itself, first I modified /usr/share/X11/xkb/symbols/chromebook, as described by dnschneid (comment no. 2, above), changing line 4 from:

    key <LWIN> { [ Overlay1_Enable ], overlay1=<LWIN> };

to:

    key <RCTL> { [ Overlay1_Enable ], overlay1=<RCTL> };

to achieve Goal 1. Obviously, you must "sudo " or "gksu " to start your editor (e.g., vim, emacs, etc.), as you are editing a system file.

Also, for this to work, you must next do as dnschneid suggests, remove the cache files:

sudo rm -f /var/lib/xkb/*.xkm

and then reboot crouton (it is not necessary to restart the hosting ChromeOS). Do this before proceeding.

Next, to make the Search key act as a Ctrl key (Goal 2), I ran:

xmodmap -e 'remove mod4 = Super_L'
xmodmap -e 'keycode 133 = Control_L'
xmodmap -e 'add control = Control_L'

PITFALL: It took quite some time before I realized I needed the third line to get this to work. Apparently, with xmodmap, even if you update the symbol associated with a keycode, doing so does NOT update the modifiers map (table; i.e., the output of running 'xmodmap' without any arguments). So, even though I assigned keycode 133 (the Search key) to Control_L, it still did not act as a Control key. Thus, I had to run "xmodmap -e 'add control = Control_L'", even though Control_L was already associated with the "control" modifier. After running it, you should see Control_L listed twice in the output of xmodmap (with different key identifiers, that is, different hexadecimal codes in parentheses):

$ xmodmap
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_L (0x85)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x6c),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

No actions were needed to make the left Ctrl key act as a control key (Goal 3), as this the default setting.

Finally, to make the right Alt key to act as the Unity / WIN key (Goal 4), I ran:

xmodmap -e 'remove mod1 = Alt_R'
xmodmap -e 'keycode 108 = Super_L'
xmodmap -e 'add mod4 = Super_L'

PITFALL: Running the following does NOT work, and had me stumped for quite a while:

xmodmap -e 'remove mod1 = Alt_R'
xmodmap -e 'add mod4 = Alt_R'

I'm not sure why, these two commands using Alt_R should have worked. They did, sort of, and hence the frustration and being stumped for a while. If you run these two commands, the right Alt key (Alt_R) will bring up the Unity sidebar and keyboard help, but then you cannot get them to disappear. In addition, pressing the right Alt key in combination with other keys does nothing (i.e., none of the Unity functions work, e.g., Alt+1 does not switch to the first application in the Unity launcher, etc.).

Moreover, for some reason, the second of these two commands causes BOTH Alt keys to stop working at the operating system level. For example, using Ctrl-Alt- stops working to shift between viewports. Alt-Space stops working to bring up a window's system menu. But the Alt keys do continue to work as expected within applications such as Gvim, Firefox, and Thunderbird. Very odd indeed, and hence the need to assign keycode 108 to Super_L and add (or update) Super_L as a mod4 modifier, instead of letting keycode 108 remain assigned to Alt_R.

AUTOMATING

The steps for Goal 1 -- modifying the "chromebook" file, removing the cache files, and rebooting -- only need to be performed once. They also will need to be performed after every update to crouton, as crouton updates will likely often overwrite this file (and hence lose your changes).

The steps for Goals 2-4 need to be run everytime you start your crouton environment. I simply have a bash shell script called "unity-startup.sh" in my $HOME/bin directory (which I have in my path by default) that runs all the above xmodmap commands, in the appropriate order. Then I just add this script to the startup applications, found under "System Menu -> Startup Applications..." to ensure these commands run every time I log in.

FINAL REMARKS

I hope this is helpful to others. It sure took quite some doing to get this worked out. The different keycodes used by evdev and xmodmap are certainly a source of confusion and frustration. Perhaps they are the same values, with evdev just using hexadecimal encoding and xmodmap using decimal encoding, or not -- I haven't checked -- but either way it sure would be nice if we had a consistent, universal, and contextualized scheme for defining keys across distributions, applications, and even operating systems. One can dream. I won't be holding my breath, though. :)

Lastly, my gratitude to everyone posting here. The comments here were invaluable in figuring out a procedure that actually worked for me.

dnschneid commented 9 years ago

Wow! Thanks for the detailed writeup. That's sure to help a lot of people.

If you want to automate the root stuff, try adding this to /etc/rc.local:

sed -i 's|key <LWIN> { [ Overlay1_Enable ], overlay1=<LWIN> };|key <RCTL> { [ Overlay1_Enable ], overlay1=<RCTL> };|' /usr/share/X11/xkb/symbols/chromebook
rm -f /var/lib/xkb/*.xkm || true

Then create ~/.xmodmaprc in your home directory with the xmodmap edits:

remove mod4 = Super_L
keycode 133 = Control_L
add control = Control_L
remove mod1 = Alt_R
keycode 108 = Super_L
add mod4 = Super_L

If your DE doesn't auto-apply the .xmodmaprc on start, you'll need to add to your startup applications an entry xmodmap /home/USER/.xmodmaprc (replace USER with your username).

morsedl commented 9 years ago

@dnschneid Sure thing, and thanks for the enhancements for automating. Very elegant! sed & awk are our friends, it's nice to see someone else turning to them as well. :) Also, I do believe Unity (Gnome) runs xmodmap automatically during startup, but the man page says (and my prior use always has been) the file name is ".xmodmaprc" instead of ".Xmodmaprc". I imagine both might work, but I can confirm the lower-case version does and does run automatically on a "stock" Ubunutu 12.04 install.

morsedl commented 9 years ago

This information is available elsewhere, but for completelness I'm including it here as well. Below are the key combinations for the most commonly used keys enabled by the Overlay1_Enable key. There are certainly many more -- see dnschneid's file /usr/share/X11/xkb/chromebook for a complete listing.

Again, in my setup on my Asus c300, the right Ctrl key (Control_R) has been mapped the Overlay1_Enable key, which I refer to as OVERLAY below.

Key	Standard Key or Function
OVERLAY+UpArrow	Page up
OVERLAY+DownArrow	Page down
OVERLAY+LeftArrow	Home
OVERLAY+RightArrow	End
OVERLAY+Period	Insert
OVERLAY+Backspace	Del
OVERLAY+BrightnessDown (F6)	Reduce display brightness
OVERLAY+BrightnessUp (F7)	Increase display brightness
OVERLAY+VolumeMute (F8)	Mute volume
OVERLAY+BrightnessDown (F9)	Reduce volume
OVERLAY+BrightnessUp (F10)	Increase volume

dnschneid commented 9 years ago

Thanks! Updated my comment to avoid disinformation...

DennisLfromGA commented 9 years ago

This could be helpful on the keyboard wiki page I think - https://github.com/dnschneid/crouton/wiki/Keyboard

On Sun, Dec 7, 2014 at 3:14 AM, David Schneider notifications@github.com wrote:

Thanks! Updated my comment to avoid disinformation...

— Reply to this email directly or view it on GitHub https://github.com/dnschneid/crouton/issues/811#issuecomment-65930204.

DennyL@GMail

dnschneid commented 9 years ago

@morsedl, would you like to summarize and add to the keyboard wiki page Dennis linked to?

morsedl commented 9 years ago

Sure! I can probably get to doing so by either mid-January or hopefully by end of January (I'm in the throws of preparing a written and oral defense for my dissertation proposal). I've added a reminder to my to-do system to ensure I get it done.

Are there particular things, over and above what I've already written --- revised, better integrated, and re-contextualized for a more general audience, of course --- that you or he are wanting me to include or cover?

On 12/28/2014 05:02 PM, David Schneider wrote:

@morsedl https://github.com/morsedl, would you like to summarize and add to the keyboard wiki page Dennis linked to?

dnschneid commented 9 years ago

Thanks! Use your best judgement; you're far deeper into keyboard customization than I've ever gone.

tonyxue commented 9 years ago

@drinkcat 's solution, which is written in the wiki already:

@darcyparker : Gave it a quick try, and I believe this is the way to go:
xmodmap -e "keycode 133 = Control_L"
xmodmap -e "keycode 37 = Overlay1_Enable"
xmodmap -e "add control = Control_L"
xmodmap -e "remove control = Overlay1_Enable"

caused an error in my ubuntu 14.04 w/ xfce chroot:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  118 (X_SetModifierMapping)
  Value in failed request:  0x17
  Serial number of failed request:  11
  Current serial number in output stream:  11

after running xmodmap -e "add control = Control_L"

After checking `xmodmap` at every step, I discovered:

After running xmodmap -e 'keycode 133 = Control_L' the Control_L is somehow automatically mapped to mod4, which is causing the error above. So here an extra xmodmap -e 'remove mod4 = Control_L' should be added to correct it.

I intended to change the wiki but I am not sure what exactly the reason is and I am not 100% sure what I have done is the best or the most appropriate to solve the error. So posting it here for discussion.

DennisLfromGA commented 8 years ago

Please re-open if this issue is still a concern.

dnschneid / crouton