Dev input event linux

How to debug the input from an input-device (/dev/input/event*)

I have a IR receiver that is using the imon-driver and I would like to get it working with the kernel. Right now half of the keys on the remote (image) works, but an all important think like the numeric keys doesn’t! The weird think is that the kernel keymap module (rc-imon-pad) seems to be correct but it seems that it is not really used since excatly the same keys are working without that module. It seems that the rc-imon-pad module always gets loaded when I load imon, and then I suspect that the keycodes are cached so it doesn’t make a difference if I unload rc-imon-pad Now I am lost, if I do cat /dev/input/event5 or ir-keytable -t there is data no matter what key I press, so the driver registers the buttons but it just seems that they are translated to the wrong keycodes. My kernels is an ubuntu stock kernel from Natty (Linux xbmc 2.6.37-11-generic #25-Ubuntu SMP Tue Dec 21 23:42:56 UTC 2010 x86_64 GNU/Linux)

It seems the problem is that the kernel sends keycodes larger than 255 which X doesn’t register because it is limited to an unsigned 8bit integer. And I’m now recompiling the kernel module with modified keycodes to test this theory.

2 Answers 2

You may find useful xinput list and xinput test .

$ xinput list ⎡ Virtual core pointer [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad [slave pointer (2)] ⎣ Virtual core keyboard [master keyboard (2)] ↳ Virtual core XTEST keyboard [slave keyboard (3)] ↳ Power Button [slave keyboard (3)] ↳ Video Bus [slave keyboard (3)] ↳ Sleep Button [slave keyboard (3)] ↳ Asus Laptop extra buttons [slave keyboard (3)] ↳ AT Translated Set 2 keyboard [slave keyboard (3)]

and I can monitor my keyboard ( xinput test 10 ) or touchpad ( xinput test 11 , or even xinput test «SynPS/2 Synaptics TouchPad» ) for all kinds of input events, and they get pretty printed to console, and parameters get extracted and printed too.

This won’t solve your problem, but at least will help a bit by deciphering the clutter which e.g. cat /dev/input/event1 produces.

Edit (from @alphanum in comments):

I wasn’t really precise in my 10-year old answer. apologies. Enjoy this quick diagram:

┌─────────────────────┐ ┌─────────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ HID events │ │ xinput events │ │ │ │ │ HID/input device ├───────────►│ Device-specific ├──────────────►│ the kernel ├───►│ Userspace (apps) │ │ (e.g. USB keyboard) │ ▲ │ driver │ ▲ │ │ │ │ └─────────────────────┘ │ └─────────────────┘ │ └──────────────┘ └──────────────────┘ │ │ evtest /dev/input/XX xinput test

• The results you get from xinput test are «xinput-unified»; i.e. processed by the device driver. These are more similar to what userspace apps see.
• The results you get from evtest /dev/input/XX are more «raw», not-yet-translated into xinput format. These are more similar to what your HID device will see.

Pertinent to whether you build a physical HID device, or an app, you may choose to use evtest or xinput test for debug. Comparing the 2 may also help troubleshoot device driver issues.

Источник

Определить устройство на /dev/input/event

К компьютеру с Linux на борту подключены несколько устройств ввода (мышь, клавиатура, и touchscreen), так как сенсор в сенсорном дисплее находится в перевернутом положении — нужно инвертировать устройство ввода по оси Y посредством внесения правок в файл evdev.conf но при этом не затронуть работу мыши. Конфигурация устройств ввода производится на основе закрепленного за ними устройства в /dev/input/event, а вот определить кто из них — тачскрин, нам поможет утилита input-utils

sudo apt-get install input-utils

Теперь можно посмотреть список всех event*

$ ls -la /dev/input/event* crw-rw---T 1 root input 13, 64 Jan 1 1970 /dev/input/event0 crw-rw---T 1 root input 13, 65 Jan 1 1970 /dev/input/event1 crw-rw---T 1 root input 13, 66 Jan 1 1970 /dev/input/event2

И собственно смотрим в каждый

$ sudo input-events 0 /dev/input/event0 bustype : BUS_USB vendor : 0x4e7 product : 0x50 version : 256 name : "EloTouchSystems,Inc Elo TouchSys" phys : "usb-bcm2708_usb-1.2/input0" uniq : "50U11950" bits ev : EV_SYN EV_KEY EV_ABS EV_MSC $ sudo input-events 1 /dev/input/event1 bustype : BUS_USB vendor : 0x4f3 product : 0x103 version : 273 name : "HID 04f3:0103" phys : "usb-bcm2708_usb-1.3/input0" uniq : "" bits ev : EV_SYN EV_KEY EV_MSC EV_LED EV_REP $ sudo input-events 2 /dev/input/event2 bustype : BUS_USB vendor : 0x4f3 product : 0x103 version : 273 name : "HID 04f3:0103" phys : "usb-bcm2708_usb-1.3/input1" uniq : "" bits ev : EV_SYN EV_KEY EV_REL EV_ABS EV_MSC

Исходя из этого, мы видим что наш тачскрин это /dev/input/event0

Источник

1. Introduction¶

Input subsystem is a collection of drivers that is designed to support all input devices under Linux. Most of the drivers reside in drivers/input, although quite a few live in drivers/hid and drivers/platform.

The core of the input subsystem is the input module, which must be loaded before any other of the input modules — it serves as a way of communication between two groups of modules:

1.1.1. Device drivers¶

These modules talk to the hardware (for example via USB), and provide events (keystrokes, mouse movements) to the input module.

1.1.2. Event handlers¶

These modules get events from input core and pass them where needed via various interfaces — keystrokes to the kernel, mouse movements via a simulated PS/2 interface to GPM and X, and so on.

1.2. Simple Usage¶

For the most usual configuration, with one USB mouse and one USB keyboard, you’ll have to load the following modules (or have them built in to the kernel):

input mousedev usbcore uhci_hcd or ohci_hcd or ehci_hcd usbhid hid_generic

After this, the USB keyboard will work straight away, and the USB mouse will be available as a character device on major 13, minor 63:

crw-r--r-- 1 root root 13, 63 Mar 28 22:45 mice

This device is usually created automatically by the system. The commands to create it by hand are:

cd /dev mkdir input mknod input/mice c 13 63

After that you have to point GPM (the textmode mouse cut&paste tool) and XFree to this device to use it — GPM should be called like:

Section "Pointer" Protocol "ImPS/2" Device "/dev/input/mice" ZAxisMapping 4 5 EndSection

When you do all of the above, you can use your USB mouse and keyboard.

1.3. Detailed Description¶

1.3.1. Event handlers¶

Event handlers distribute the events from the devices to userspace and in-kernel consumers, as needed.

1.3.1.1. evdev¶

evdev is the generic input event interface. It passes the events generated in the kernel straight to the program, with timestamps. The event codes are the same on all architectures and are hardware independent.

This is the preferred interface for userspace to consume user input, and all clients are encouraged to use it.

The devices are in /dev/input:

crw-r--r-- 1 root root 13, 64 Apr 1 10:49 event0 crw-r--r-- 1 root root 13, 65 Apr 1 10:50 event1 crw-r--r-- 1 root root 13, 66 Apr 1 10:50 event2 crw-r--r-- 1 root root 13, 67 Apr 1 10:50 event3 .

There are two ranges of minors: 64 through 95 is the static legacy range. If there are more than 32 input devices in a system, additional evdev nodes are created with minors starting with 256.

1.3.1.2. keyboard¶

keyboard is in-kernel input handler and is a part of VT code. It consumes keyboard keystrokes and handles user input for VT consoles.

1.3.1.3. mousedev¶

mousedev is a hack to make legacy programs that use mouse input work. It takes events from either mice or digitizers/tablets and makes a PS/2-style (a la /dev/psaux) mouse device available to the userland.

Mousedev devices in /dev/input (as shown above) are:

crw-r--r-- 1 root root 13, 32 Mar 28 22:45 mouse0 crw-r--r-- 1 root root 13, 33 Mar 29 00:41 mouse1 crw-r--r-- 1 root root 13, 34 Mar 29 00:41 mouse2 crw-r--r-- 1 root root 13, 35 Apr 1 10:50 mouse3 . . crw-r--r-- 1 root root 13, 62 Apr 1 10:50 mouse30 crw-r--r-- 1 root root 13, 63 Apr 1 10:50 mice

Each mouse device is assigned to a single mouse or digitizer, except the last one — mice . This single character device is shared by all mice and digitizers, and even if none are connected, the device is present. This is useful for hotplugging USB mice, so that older programs that do not handle hotplug can open the device even when no mice are present.

CONFIG_INPUT_MOUSEDEV_SCREEN_[XY] in the kernel configuration are the size of your screen (in pixels) in XFree86. This is needed if you want to use your digitizer in X, because its movement is sent to X via a virtual PS/2 mouse and thus needs to be scaled accordingly. These values won’t be used if you use a mouse only.

Mousedev will generate either PS/2, ImPS/2 (Microsoft IntelliMouse) or ExplorerPS/2 (IntelliMouse Explorer) protocols, depending on what the program reading the data wishes. You can set GPM and X to any of these. You’ll need ImPS/2 if you want to make use of a wheel on a USB mouse and ExplorerPS/2 if you want to use extra (up to 5) buttons.

1.3.1.4. joydev¶

joydev implements v0.x and v1.x Linux joystick API. See Programming Interface for details.

As soon as any joystick is connected, it can be accessed in /dev/input on:

crw-r--r-- 1 root root 13, 0 Apr 1 10:50 js0 crw-r--r-- 1 root root 13, 1 Apr 1 10:50 js1 crw-r--r-- 1 root root 13, 2 Apr 1 10:50 js2 crw-r--r-- 1 root root 13, 3 Apr 1 10:50 js3 .

And so on up to js31 in legacy range, and additional nodes with minors above 256 if there are more joystick devices.

1.3.2. Device drivers¶

Device drivers are the modules that generate events.

1.3.2.1. hid-generic¶

hid-generic is one of the largest and most complex driver of the whole suite. It handles all HID devices, and because there is a very wide variety of them, and because the USB HID specification isn’t simple, it needs to be this big.

Currently, it handles USB mice, joysticks, gamepads, steering wheels, keyboards, trackballs and digitizers.

However, USB uses HID also for monitor controls, speaker controls, UPSs, LCDs and many other purposes.

The monitor and speaker controls should be easy to add to the hid/input interface, but for the UPSs and LCDs it doesn’t make much sense. For this, the hiddev interface was designed. See Care and feeding of your Human Interface Devices for more information about it.

The usage of the usbhid module is very simple, it takes no parameters, detects everything automatically and when a HID device is inserted, it detects it appropriately.

However, because the devices vary wildly, you might happen to have a device that doesn’t work well. In that case #define DEBUG at the beginning of hid-core.c and send me the syslog traces.

1.3.2.2. usbmouse¶

For embedded systems, for mice with broken HID descriptors and just any other use when the big usbhid wouldn’t be a good choice, there is the usbmouse driver. It handles USB mice only. It uses a simpler HIDBP protocol. This also means the mice must support this simpler protocol. Not all do. If you don’t have any strong reason to use this module, use usbhid instead.

1.3.2.3. usbkbd¶

Much like usbmouse, this module talks to keyboards with a simplified HIDBP protocol. It’s smaller, but doesn’t support any extra special keys. Use usbhid instead if there isn’t any special reason to use this.

1.3.2.4. psmouse¶

This is driver for all flavors of pointing devices using PS/2 protocol, including Synaptics and ALPS touchpads, Intellimouse Explorer devices, Logitech PS/2 mice and so on.

1.3.2.5. atkbd¶

This is driver for PS/2 (AT) keyboards.

1.3.2.6. iforce¶

A driver for I-Force joysticks and wheels, both over USB and RS232. It includes Force Feedback support now, even though Immersion Corp. considers the protocol a trade secret and won’t disclose a word about it.

1.4. Verifying if it works¶

Typing a couple keys on the keyboard should be enough to check that a keyboard works and is correctly connected to the kernel keyboard driver.

Doing a cat /dev/input/mouse0 (c, 13, 32) will verify that a mouse is also emulated; characters should appear if you move it.

You can test the joystick emulation with the jstest utility, available in the joystick package (see Introduction ).

You can test the event devices with the evtest utility.

1.5. Event interface¶

You can use blocking and nonblocking reads, and also select() on the /dev/input/eventX devices, and you’ll always get a whole number of input events on a read. Their layout is:

time is the timestamp, it returns the time at which the event happened. Type is for example EV_REL for relative movement, EV_KEY for a keypress or release. More types are defined in include/uapi/linux/input-event-codes.h.

code is event code, for example REL_X or KEY_BACKSPACE, again a complete list is in include/uapi/linux/input-event-codes.h.

value is the value the event carries. Either a relative change for EV_REL, absolute new value for EV_ABS (joysticks . ), or 0 for EV_KEY for release, 1 for keypress and 2 for autorepeat.

See Input event codes for more information about various even codes.

Источник