# libevdev (vendored)

The Linux gamepad backend (`implementations/Crafter.Graphics-Gamepad.cpp`) parses evdev events with
[libevdev](https://gitlab.freedesktop.org/libevdev/libevdev). It is compiled into Crafter.Graphics from
this directory instead of being linked from the system. The Flatpak SDK that crafter-build runs in has no
libevdev headers, and a vendored copy builds the same way for every target, including cross sysroots.

- Upstream: `https://gitlab.freedesktop.org/libevdev/libevdev.git`, tag `libevdev-1.14.0`
  (commit `d9af2e4580297e9c14715fef06621dd39d9d8a3a`). MIT, see `COPYING`.
- `libevdev/`: the core library sources, unchanged. The uinput half isn't used and isn't included.
- `libevdev/event-names.h`: generated, the way libevdev's meson build does it, from the kernel headers
  below.
- `libevdev/config.h`: what libevdev's meson build writes on Linux (`_GNU_SOURCE`).
- `kernel-headers/linux/`: the kernel uapi `input.h` and `input-event-codes.h` that ship with that
  libevdev release. libevdev compiles against its own copy (its meson build puts them first on the path),
  because `event-names.h` names every code by its macro and has to see the same set of codes. Only the
  libevdev library sees them, and the directory isn't called `include`, because Crafter.Build puts every
  `include` directory of a dependency on its consumers' include path.

`project.cpp` builds these sources once, as their own static library, which Crafter.Graphics depends on.

## Updating

Copy `COPYING`, the files under `libevdev/` and upstream's `include/linux/linux/{input.h,input-event-codes.h}`
(into `kernel-headers/linux/`) from the new release, keep `config.h`, then regenerate the name table:

```sh
python3 libevdev/make-event-names.py kernel-headers/linux/input.h kernel-headers/linux/input-event-codes.h \
    > libevdev/event-names.h
```