576f2ed2a7
This is a tool that does effectively the same job as evemu-record. evemu has two disadvantages: its API is clunky and hard to extend even for simple features. And it has a custom file format that requires special processing but is difficult to extend and hard to write manually. e.g. the bitmasks require keeping a line number state to know which bit an entry refers to. libinput-record records the same data but the output is YAML. That can be processed easier and extended in the future without breaking the parsing. We can (in the future) also interleave the evemu output with libinput's debug output, thus having a single file where the events can be compared and analysed without the need for replaying. Likewise, we can easily annotate the file with parsable bits of information without having to shove all that into a comment (like version numbers of libinput, kernel, etc). User-visible differences to evemu-record: * the output file requires an explicit -o or --output-file argument * no evemu-describe equivalent, if you just want the description simply cancel before any events are sent * to see key codes, a --show-keycodes flag must be supplied, otherwise all 'normal' keys end up as KEY_A. This protects against inadvertent information leakage * supports a --multiple option to record multiple devices simultaneously. All recordings have the same time offset, it is thus possible to reproduce bugs that depend on the interaction of more than one device. And to answer the question of: why a printf-approach to writing out yaml instead of a library, it's simply that we want to be able to have real-time output of the recording. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> |
||
|---|---|---|
| doc | ||
| include/linux | ||
| src | ||
| test | ||
| tools | ||
| udev | ||
| .dir-locals.el | ||
| .gitignore | ||
| .vimdir | ||
| circle.yml | ||
| CODING_STYLE | ||
| COPYING | ||
| meson.build | ||
| meson_options.txt | ||
| README.md | ||
libinput
libinput is a library that handles input devices for display servers and other applications that need to directly deal with input devices.
It provides device detection, device handling, input device event processing and abstraction so minimize the amount of custom input code the user of libinput need to provide the common set of functionality that users expect. Input event processing includes scaling touch coordinates, generating pointer events from touchpads, pointer acceleration, etc.
libinput originates from weston, the Wayland reference compositor.
Architecture
libinput is not used directly by applications, rather it is used by the xf86-input-libinput X.Org driver or wayland compositors. The typical software stack for a system running Wayland is:
@dotfile libinput-stack-wayland.gv
Where the Wayland compositor may be Weston, mutter, KWin, etc. Note that Wayland encourages the use of toolkits, so the Wayland client (your application) does not usually talk directly to the compositor but rather employs a toolkit (e.g. GTK) to do so.
The simplified software stack for a system running X.Org is:
@dotfile libinput-stack-xorg.gv
Again, on a modern system the application does not usually talk directly to the X server using Xlib but rather employs a toolkit to do so.
Source code
The source code of libinput can be found at: http://cgit.freedesktop.org/wayland/libinput
For a list of current and past releases visit: http://www.freedesktop.org/wiki/Software/libinput/
Build instructions: http://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html
Reporting Bugs
Bugs can be filed in the libinput component of Wayland: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=libinput
Where possible, please provide an evemu recording of the input device and/or the event sequence in question.
See @ref reporting_bugs for more info.
Documentation
- Developer API documentation: http://wayland.freedesktop.org/libinput/doc/latest/modules.html
- High-level documentation about libinput's features: http://wayland.freedesktop.org/libinput/doc/latest/pages.html
- Build instructions: http://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html
- Documentation for previous versions of libinput: https://wayland.freedesktop.org/libinput/doc/
Examples of how to use libinput are the debugging tools in the libinput repository. Developers are encouraged to look at those tools for a real-world (yet simple) example on how to use libinput.
- A commandline debugging tool: https://cgit.freedesktop.org/wayland/libinput/tree/tools/libinput-debug-events.c
- A GTK application that draws cursor/touch/tablet positions: https://cgit.freedesktop.org/wayland/libinput/tree/tools/libinput-debug-gui.c
License
libinput is licensed under the MIT license.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: [...]
See the COPYING file for the full license information.