add a second keyboard with a different mapping

[Peter Hutterer]

On Tue, Jul 21, 2009 at 05:31:17PM +1000, Timothy S. Nelson wrote:
>> evdev instead (there are be plenty of links on google to explain how to use
>> evdev). use a device file of /dev/input/by-id/<keyboard name>-event and
>> assign it the desired Option "XkbLayout", etc. in the config.
>> It is also possible to set up two keyboards, one with the kbd driver and one
>> with evdev (grabs must be enabled in evdev, evdev 2.1 and later requires
>> Option "GrabDevice" "on").
>>
>> Note that depending on your desktop enviroment, the layout set in the config
>> may get overwritten so you may need to apply the layout at runtime anyway.
>> This can be done with "setxkbmap -device <deviceid> -layout <whatever>" etc.
>
> 	I'm running something a little like what you are wanting, so I thought  
> maybe I should document my experience so that you could see what I get.  
> I did most of this setup a month or two ago, so some details may be 
> vague.  I'm also mentioning a few problems along the way in hopes that 
> someone (Peter? :) ) might be able to suggest something.
>
> 	The first thing was to get the multiple keyboards working.  I have it  
> configured to use the "kbd" driver, but looking at the startup log, it 
> seems to be ignoring what I told it and using evdev anyway, which is fine 
> by me.

the device file the kbd driver hooks onto is a "catchall device", similar to
/dev/input/mice. So while it is possible to use it for separate keyboards
it's more straightforward with evdev.

> 	The next thing was to test running the keyboards with different maps.  
> Now that configuration I'm after is like this:
>
> Keyboard 1: Standard us+pc105+inet setup
> Keyboard 2: 4 layouts; us-intl, el (Greek), il (Hebrew), and a custom layout
> 	that lets me type various mathematical symbols
>
> 	So, the configuration of keyboard 1 is automatically the way I want it, 
> so I don't have to do anything to it except ensure that I don't mess it  
> up.  For keyboard 2, I have a script that gets run when I log in to 
> XWindows that runs this command:
>
> setxkbmap -device <deviceid> '<layouts>'

nipick: not XWindows, its your desktop environment. gnome-settings-daemon
will set the configuration earlier chosen but apply it to all devices and
hence overwrite your xorg.conf/HAL configuration.
KDE doesn't overwrite the keyboard config by default, so this is less of an
issue.

> 	A real-life example might look something like this:
>
> setxkbmap -device 3 'us,el,il,custom' -option 'grp:switch,grp:scroll_toggle,grp_led:scroll,lv3:ralt_switch'
>
> 	...or something like that (and all on one line).  Please note that the  
> use of scroll lock and the scroll led were things that I had to put in to 
> the keyboard configuration in /usr/share/X11/xkb/ (this is a Fedora box). 
>  Note also that the device ID can be gotten by running the command 
> "xinput list". My script that runs on login parses the output of "xinput 
> list" to get the appropriate device ID, since it's different different 
> times.

it would be good for setxkbmap to support device names too. If you find the
time to write this up please feel free to do so, it's not that hard to do
(and you could probably just copy/paste from xinput anyway).

> 	Unfortunately, my USB keyboard drops out every once in a while, and,  
> while it comes back online immediately, it has unfortunately lost its  
> configuration, and the setxkbmap script needs to be run manually at that  
> point.  I'd like to be able to have the new USB keyboard trigger the 
> script, but that doesn't seem to be what happens.

you can write a simple daemon listening for DevicePresence events, it'd only
be a few lines of code in C.

> 	Another problem is that, if I have Keyboard 2 set to Greek (layout 2),  
> if I type on keyboard 1, then Keyboard 2 switches back to layout 1.  If I 
> recall correctly, Peter implied that either:
> 1.	It's been fixed in a newer version than what I'm using
> 2.	He fixed it when I described the problem, or
> 3.	He hoped he'd have time to fix it sometime

IIRC this worked in git. This is a fairly narrow use-case and there's too
many use-cases to test already so it is quite possible that it got broken
again. Especially for use-cases that are out of the ordinary I need someone
to watch my commits and tell me when things break.

There's ways to automate tests for these changes, but they are quite
time-consuming to develop and certainly exceed the time I have available to
me right now. If you are interested in helping developing such tests please
contact me off-list.

> 	Hopefully this has helped in some way.  The only thing I haven't  
> answered is how to remap keys.  I'm afraid I don't know the answer; I 
> know how to remap single keys to single keys, but not a single key to 
> multiple keys. The reason I don't know is because I have an Avant 
> Stellar, and my keyboard will remap any key I want to any other key 
> (except Right Ctrl), before it sends it down the keyboard cable.  But I 
> realise that not everyone wants to buy an Avant Stellar.
>
> 	I'm also hoping that someone will build some cool keyboard macroing  
> into the Linux kernel (ie. one keystroke to multiple keystrokes).  But it 
> probably won't happen.

you can solve parts of this using the XTest extension combined with an input
daemon. A program that grabs certain keys and then generates multiple
keycodes through XTest should get close to the same result.

Cheers,
  Peter