I frequently work on pairing stations where there are multiple keyboards installed. I can use setxkbmap with -device <ID> to set the layout for a specific keyboard (using an ID from xinput), but often it's not obvious which keyboard I'm at. It would be better to avoid the back-and-forth of trying both keyboards, so I'd like to write a quick tool to get this information for setxkbmap. I'd expect a typical use case like the following:

$ setxkbmap -device "$(get-keyboard-id)" -layout gb
Press Enter to detect keyboard ID

Which interface provides this information on Linux? Ideally it should work without X, but that's not a requirement (there doesn't seem to be many tools which support this without X).

Findings so far:

  • Linux must know which keyboard I'm typing on to support different layouts for multiple keyboards simultaneously.
  • xinput → list.c → list_xi2XIQueryDevice provides device IDs usable by setxkbmap.
  • showkey and xev don't print keyboard IDs.
  • xinput list-props $ID shows where keyboard events are sent. However, using code from another answer it seems this device doesn't print anything to identify the keyboard.
  • One almost possible solution is to run xinput --test <ID> & for each keyboard ID and see which one returns something first. The problem with that is figuring out which "keyboards" are actually keyboards:

    $ xinput | grep keyboard
    ⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
        ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
        ↳ Power Button                              id=6    [slave  keyboard (3)]
        ↳ Video Bus                                 id=7    [slave  keyboard (3)]
        ↳ Power Button                              id=8    [slave  keyboard (3)]
        ↳ Sleep Button                              id=9    [slave  keyboard (3)]
        ↳ WebCam SC-13HDL10931N                     id=10   [slave  keyboard (3)]
        ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]
  • 1
    Perhaps you're looking for MPX. Sep 5, 2013 at 14:28
  • @IgnacioVazquez-Abrams Isn't that a massively more complicated solution?
    – l0b0
    Sep 7, 2013 at 8:54
  • That depends on what the problem is. Sep 7, 2013 at 12:30
  • "it seems this device doesn't print anything to identify the keyboard": what do you mean? If you less -f /dev/input/eventX and hit a key on the corresponding keyboard, you should see "garbage" showing up, so your keypresses are indeed directed into one dev file and not the others.
    – L. Levrel
    May 10, 2016 at 20:38
  • Have you tried this (referenced in another answer of that other question you cite)?
    – L. Levrel
    May 10, 2016 at 20:42

3 Answers 3


Disable device

Here's one idea towards identifying which keyboard is which. You can use the command xinput to enable and disable devices.


$ xinput list
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=12   [slave  pointer  (2)]
⎜   ↳ TPPS/2 IBM TrackPoint                     id=13   [slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver                     id=9    [slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver                     id=10   [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Sleep Button                              id=8    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]
    ↳ ThinkPad Extra Buttons                    id=14   [slave  keyboard (3)]

The above output shows the various devices that I have on my Thinkpad laptop. I only have 1 keyboard attached, this one:

    ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]

Now take a look at the properties available through this device:

$ xinput list-props "AT Translated Set 2 keyboard"
Device 'AT Translated Set 2 keyboard':
    Device Enabled (124):   1
    Coordinate Transformation Matrix (126): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.

From the above you can see that it's enabled, so let's disable it:

$ xinput set-prop "AT Translated Set 2 keyboard" "Device Enabled" 0

To enable it:

$ xinput set-prop "AT Translated Set 2 keyboard" "Device Enabled" 1

The idea?

You could enable disable one of the keyboards using this command to determine which one you're on.


  • Isn't that even more work? My approach involves at minimum one command, at most three. This approach always involves three commands - disable, enable, then set layout (plus possibly a keyboard switch).
    – l0b0
    Sep 6, 2013 at 9:29
  • @l0b0 - yeah I'm not thrilled with this approach either. I'm continuing to look but was putting this method here as "1 way". Not the ideal one though, I agree.
    – slm
    Sep 6, 2013 at 11:15
  • @lobo - This answer isn't going to get the bounty so don't worry about it, it had the votes before you started the bounty. stackoverflow.com/help/bounty. Also what is your anger towards me trying to help you here? I gave you not an ideal solution, but 1 way to accomplish your task. I provided this over 2+ years ago and this Q has sat here w/ 0 alternatives. I think you need to ask yourself if it's perhaps the question/approach that's the problem. Obviously just my $0.02 but it's enough already.
    – slm
    May 11, 2016 at 2:30
  • My bad x 2: I didn't notice the bit about "created after the bounty started", and I appreciate that you wrote a very well formulated answer. But I can't upvote a solution which is more complicated than the original one, and I don't understand why others do.
    – l0b0
    May 11, 2016 at 7:43
  • 1
    @l0b0 My reason for upvoting: It's a single command that I can use to quickly and easily confirm my suspicion which keyboard it was, instead of needing to read an entire script to make sure it doesn't wipe my hard drive, then save and execute it. Or, in the case of the highest voted answer so far, compile C code. Also, creative ideas like this one deserve upvotes. Oct 24, 2019 at 20:11

More digging revealed another solution using plain Bash and a normal user account. Script:

#!/usr/bin/env bash

set -o errexit -o nounset -o noclobber -o pipefail

# Remove leftover files and processes on exit
trap 'rm --recursive -- "$dir"; kill -- -$$' EXIT
dir="$(mktemp --directory)"
cd "$dir"

# Log key presses to file
xinput --list --id-only | while read id
    # Only check devices linked to an event source
    if xinput --list-props "$id" | grep --quiet --extended-regexp '^\s+Device Node.*/dev/input/event'
        xinput test "$id" > "$id" &

# Check for key presses
while sleep 0.1
    for file in *
        if [[ -s "$file" ]]
            echo "$file"

The question sounds a bit contradictory since you're citing X tools but ask for a solution that "ideally should work without X".

About your 4th finding: xinput will give you the correspondence

$ xinput list-props 11
Device 'AT Translated Set 2 keyboard':
    Device Enabled (145):   1
    Coordinate Transformation Matrix (147): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
    Device Product ID (266):    1, 1
    Device Node (267):  "/dev/input/event0"

at least with the following version

$ xinput --version
xinput version 1.6.1
XI version on server: 2.3

First step: detecting the keyboard event device in C ---
#include <stdio.h>
//#include <unistd.h>
#include <fcntl.h>
#include <linux/input.h>

// typical use : sudo ./a.out /dev/input/event*
int main (int argc, char *argv[])
  struct input_event ev[64];
  int fd[argc],rd,idev,value, size = sizeof (struct input_event);
  char name[256] = "Unknown";

  if(argc==1) return -1;

  int ndev=1;
  while(ndev<argc && (fd[ndev] = open (argv[ndev], O_RDONLY|O_NONBLOCK)) != -1){
  fprintf (stderr,"Found %i devices.\n", ndev);
  if(ndev==1) return -1;

  while (1){
    for(idev=1; idev<argc; idev++){
      if( (rd=read (fd[idev], ev, size * 64)) >= size){
      value = ev[0].value;
      if (value != ' ' && ev[1].value == 1 && ev[1].type == 1){
        ioctl (fd[idev], EVIOCGNAME (sizeof (name)), name);
        printf ("%s\n", name);
        return idev;
//    sleep(1);
  return -1;

Many thanks to this page. I've stripped most safety checks from the code I borrowed there, for clarity, in real code you probably want them.

Note that key presses are echoed, so you may indeed want to kindly ask the user to hit a modifier key (Shift, Control...) rather than any key.

Second step: use xinput to get the X ID from the device name

Compile the above C source and use this way:

xinput list --id-only "keyboard:$(sudo ./a.out /dev/input/event*)"

  • There's also /dev/input/by-id
    – jthill
    May 10, 2016 at 15:59
  • Thanks for the tip. I've cited X tools only because most tools seem to require X. I do not know how to work with /dev/input/event* - I tried tailting but to no avail.
    – l0b0
    May 10, 2016 at 18:54
  • by-id gives symlinks mapping device name to event queue, without requiring X.
    – jthill
    May 10, 2016 at 19:18
  • @jthill On the machine I'm currently on, this dir only has links for the mouse.
    – L. Levrel
    May 10, 2016 at 20:08
  • 1
    It appears the reference site got taken over by a lifestyle blogger (or bot) in 2019, here's the Wayback link with the full post. web.archive.org/web/20181215175035/http://www.thelinuxdaily.com/…
    – dragon788
    Oct 14, 2021 at 21:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .