Különbségek

A kiválasztott változat és az aktuális verzió közötti különbségek a következők.

--- billentyuzet [2018/10/03 13:31] – külső szerkesztés 127.0.0.1
+++ billentyuzet [2021/05/20 20:04] (aktuális) – daevidt
@@ Sor 22: / Sor 22: @@
     ↳ AT Translated Set 2 keyboard            	id=10	[slave  keyboard (3)]
   #xinput test 10
+==== udev ====
+A scankódokat evtest segítségével ki kell nyerni:
+  Event: time 1621536973.327504, -------------- SYN_REPORT ------------
+  Event: time 1621536973.473735, type 4 (EV_MSC), code 4 (MSC_SCAN), value **c00ea**
+  Event: time 1621536973.473735, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value
+Az eszköz azonosítót kideríteni:
+  * lsusb segítségével, ha usb eszközről van szó,
+  * vagy dmesg-ből:
+  [271866.624518] input: VR BOX Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-
+.4:1.0/bluetooth/hci0/hci0:12/0005:1345:7003.0003/input/input21
+  [271866.624820] input: VR BOX Consumer Control as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-
+.4:1.0/bluetooth/hci0/hci0:12/0005:1345:7003.0003/input/input22
+  [271866.625187] hid-generic 0005:1345:7003.0003: input,hidraw0: BLUETOOTH HID v0.01 Keyboard [VR BOX] on 7c:e9:d3:b5:05:06
+.4:1.0/bluetooth/hci0/hci0:12/**0005:1345:7003**.0003/input/input22 --> ez alapján **b0005v1345p7003**
+Elkészíteni a **hwdb** fájlt:
+  * segítség a ''/lib/udev/hwdb.d/60-keyboard.hwdb'' fájlban
+  * létrehozunk egy új fájlt pl ''/etc/udev/hwdb.d/98-custom.hwdb'' néven
+Az új fájl a következő formájú sorokból áll:
+  evdev:input:<eszközazonosító>
+  KEYBOARD_KEY_<scancode>=<keycode>
+A ''keycode'' -ok a ''KEY_VOLUMEDOWN'' formából a ''KEY_'' elhagyásával és kisbetűsítéssel keletkeznek. (pl az ''evtest'' kimenete ad ilyen kódokat.
+<code>
+evdev:input:b0005v1345p7003*
+ KEYBOARD_KEY_c00b3=up       # stick up
+ KEYBOARD_KEY_c00b4=down       # stick down
+ KEYBOARD_KEY_c00b5=right       # stick right
+ KEYBOARD_KEY_c00b6=left       # stick left
+ KEYBOARD_KEY_c00cd=enter       # upper trigger
+ KEYBOARD_KEY_c00e2=esc       # lower trigger
+</code>
+==== evdev ====
+It sits below the process that handles input events, in between the kernel and that process.
+kernel → libevdev → xf86-input-evdev → X server → X client
+For Weston/Wayland, the stack would look like this:
+kernel → libevdev → libinput → Wayland compositor → Wayland client
+Since version 1.16 the xorg-xserver obtained support for libinput:
+kernel → libevdev → libinput → xf86-input-libinput → X server → X client
+====  Linux input ecosystem ====
+October 2010
+from:   https://www.joeshaw.org/linux-input-ecosystem/
+Over the past couple of days, I’ve been trying to figure out how input in Linux works on modern systems. There are lots of small pieces at various levels, and it’s hard to understand how they all interact. Things are not helped by the fact that things have changed quite a bit over the past couple of years as HAL – which I helped write – has been giving way to udev, and existing literature is largely out of date. This is my attempt at understanding how things work today, in the Ubuntu Lucid release.
+=== Kernel ===
+In the Linux kernel’s input system, there are two pieces: the device driver and the event driver. The device driver talks to the hardware, obviously. Today, for most USB devices this is handled by the usbhid driver. The event drivers handle how to expose the events generated by the device driver to userspace. Today this is primarily done through evdev, which creates character devices (typically named /dev/input/eventN) and communicates with them through struct input_event messages. See include/linux/input.h for its definition.
+A great tool to use for getting information about evdev devices and events is evtest.
+A somewhat outdated but still relevant description of the kernel input system can be found in the kernel’s Documentation/input/input.txt file.
+=== udev ===
+When a device is connected, the kernel creates an entry in sysfs for it and generates a hotplug event. That hotplug event is processed by udev, which applies some policy, attaches additional properties to the device, and ultimately creates a device node for you somewhere in /dev.
+For input devices, the rules in /lib/udev/rules.d/60-persistent-input.rules are executed. Among the things it does is run a /lib/udev/input_id tool which queries the capabilities of the device from its sysfs node and sets environment variables like ID_INPUT_KEYBOARD, ID_INPUT_TOUCHPAD, etc. in the udev database.
+For more information on input_id see the original announcement email to the hotplug list.
+=== X ===
+X has a udev config backend which queries udev for the various input devices. It does this at startup and also watches for hotplugged devices. X looks at the different ID_INPUT_* properties to determine whether it’s a keyboard, a mouse, a touchpad, a joystick, or some other device. This information can be used in /usr/lib/X11/xorg.conf.d files in the form of MatchIsPointer, MatchIsTouchpad, MatchIsJoystick, etc. in InputClass sections to see whether to apply configuration to a given device.
+Xorg has a handful of its own drivers to handle input devices, including evdev, synaptics, and joystick. And here is where things start to get confusing.
+Linux has this great generic event interface in evdev, which means that very few drivers are needed to interact with hardware, since they’re not speaking device-specific protocols. Of the few needed on Linux nearly all of them speak evdev, including the three I listed above.
+The evdev driver provides basic keyboard and mouse functionality, speaking – obviously – evdev through the /dev/input/eventN devices. It also handles things like the lid and power switches. This is the basic, generic input driver for Xorg on Linux.
+The synaptics driver is the most confusing of all. It also speaks evdev to the kernel. On Linux it does not talk to the hardware directly, and is in no way Synaptics(tm) hardware-specific. The synaptics driver is simply a separate driver from evdev which adds a lot of features expected of touchpad hardware, for example two-finger scrolling. It should probably be renamed the “touchpad” module, except that on non-Linux OSes it can still speak the Synaptics protocol.
+The joystick driver similarly handles joysticky things, but speaks evdev to the kernel rather than some device-specific protocol.
+X only has concepts of keyboards and pointers, the latter of which includes mice, touchpads, joysticks, wacom tablets, etc. X also has the concept of the core keyboard and pointer, which is how events are most often delivered to applications. By default all devices send core events, but certain setups might want to make devices non-core.
+If you want to receive events for non-core devices, you need to use the XInput or XInput2 extensions for that. XInput exposes core-like events (like DeviceMotionNotify and DeviceButtonPress), so it is not a major difficulty to use, although its setup is annoyingly different than most other X extensions. I have not used XInput2.