#evdev

evdev-rs

Bindings to libevdev for interacting with evdev devices. It moves the common tasks when dealing with evdev devices into a library and provides a library interface to the callers, thus avoiding erroneous ioctls, etc.

9 releases (breaking)

0.6.1 Oct 22, 2022
0.6.0 Jul 24, 2022
0.5.0 Apr 5, 2021
0.4.0 Apr 26, 2020
0.0.1 Sep 2, 2017

#109 in Hardware support

Download history 1170/week @ 2023-11-05 782/week @ 2023-11-12 803/week @ 2023-11-19 892/week @ 2023-11-26 759/week @ 2023-12-03 881/week @ 2023-12-10 628/week @ 2023-12-17 534/week @ 2023-12-24 492/week @ 2023-12-31 609/week @ 2024-01-07 938/week @ 2024-01-14 756/week @ 2024-01-21 789/week @ 2024-01-28 935/week @ 2024-02-04 852/week @ 2024-02-11 899/week @ 2024-02-18

3,558 downloads per month
Used in 12 crates

MIT/Apache

495KB
13K SLoC

C 8K SLoC // 0.0% comments Rust 4K SLoC // 0.0% comments Python 486 SLoC // 0.0% comments Automake 195 SLoC M4 191 SLoC // 0.2% comments Shell 110 SLoC // 0.2% comments JavaScript 64 SLoC // 0.3% comments

evdev-rs

Build Status Latest Version Documentation

Documentation

A Rust wrapper for libevdev

# Cargo.toml
[dependencies]
evdev-rs = "0.6.1"

to enable serialization support, enable the feature "serde"

# Cargo.toml
[dependencies]
evdev-rs = { version = "0.6.1", features = ["serde"] }

With a newer libevdev version (>= 1.10) enable the feature `libevdev-1-10` to
allow disabling a property. It also extends the `Enable` trait to `InputProp`,
enabling the use of `enable()`, `disable()` and `has()` for `InputProp` as well.

Why a libevdev wrapper?

The evdev protocol is simple, but quirky, with a couple of behaviors that are non-obvious. libevdev transparently handles some of those quirks.

The evdev crate is an implementation of libevdev in Rust which provides most of the same features.

evdev-rs crate closely follows libevdev and hence enjoys all the complex handling that libevdev does. Some of the things that libevdev handles transparently, which may or may not be in evdev crate:

  • handling of fake multitouch devices
  • synching of slots and per-slot state
  • transparent generation of missing tracking ids after SYN_DROPPED
  • various boundary checks with defined error codes if you request invalid data (e.g. event codes that don't exist on the device)
  • fd swapping on the same context
  • disabling/enabling events on a per-context basis, so you can disable/enable ABS_FOO and then not care about quirks in the client-side code.

Development

src/enums.rs can be generated by running ./tools/make-enums.sh.

Dependencies

~93–560KB
~12K SLoC