So you have a, simple if possible, way to test the above changes?

And how much of the changes in this review depend on the evdev kernel patch? Can it work without that patch?

In D7588#157689, @kwm wrote:

So you have a, simple if possible, way to test the above changes?

devel/libevdev - run internal regression tests. They depend on uinput so evdev kernel support is a must. Currently it cannot pass all tests due to lack of kernel support for some features so I commented out test section in port`s Makefile. I see no regressions as compared with previous version
devel/py-evdev 0.5.0 -> 0.6.1 - this wrapper is only compile tested
multimedia/webcamd 4.2.0.9 -> 4.8.0.2 (kernel evdev interface compatible version) - there is a link for ongoing testing. At least it works with my touchscreen
x11-drivers/xf86-input-evdev 2.9.2 -> 2.10.3 - works with all my hardware. No unit tests available
x11-drivers/xf86-input-synaptics 1.8.2 -> 1.8.99.1 - works with my touchpad (Elantech) in evdev mode. Not tested in psm mode and with synaptics touchpads
devel/libevdev-headers - webcamd is up to date since 4.8.0.2
devel/evemu - passes internal regression tests. just run make test on port`s Makefile. Not sure if it requires uinput
x11-servers/xorg-servers - that is most invasive change. This patch works for me and previous versions works for some other testers. See PR/196678

And how much of the changes in this review depend on the evdev kernel patch?

Not many. Only some optional (and currently not used) sed scripts for patching of headers paths. Most changes can be used with webcamd too.

Can it work without that patch?

Basically it can. But this patch fixes obvious bugs in ports supplied userland evdev headers so devel/libevdev-headers part is a must for both kernel and webcamd event device implementations. Some other changes like enabling of support for event interface for x11-drivers/xf86-input-synaptics and x11-servers/xorg-servers are not strictly necessary but nice to have

In D7588#157689, @kwm wrote:

So you have a, simple if possible, way to test the above changes?

If you want to test above changes "in hardware" I can try to make webcamd patch to workaround "missing usb serial number" issue so it will be possible to attach webcamd to usb keyboards and mouses. Webcamd interface should exactly match its in-kernel counterpart since v.4.8.0.2

In D7588#157689, @kwm wrote:

So you have a, simple if possible, way to test the above changes?

TEST PLAN field updated to reflect simple way of testing

Ping - any updates here?

PR/217248 - devel/libevdev: update to 1.5.6, fix outdated and broken evdev headers (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217248) has been created

Hi,

What tests have you done?

Patches looks good to me.

--HPS

In D7588#200149, @hselasky wrote:

Hi,

What tests have you done?

Libevdev passes 100% of internal regression tests after I #ifdef-ed out unsupported ForceFeedback test. I updated PR`s patch to support tests
xf86-input-evdev, xf86-input-libinput and xf86-input-synaptics are working for a long (~1.5 year) time for me with 1.5 version of libevdev and various versions of this review.
Both in-kernel and webcamd 4.8 event devices were tested.
Other ports are only compile-tested.
I'm not completely sure that I catched all evdev clients in a port tree but I have no technical ability to analyze and compile every port. This list of ports was obtained by grepping Makefile for v4l_compat strings with following grepping of sources for input.h

These headers are not library interface, but a kernel one. I extract them from libevdev not from linux kernel because libevdev is main consumer, always contains updated version and have relatively small filesize.
FreeBSD have native versions of these headers located in /usr/include/dev/evdev/ but as evdev interface evolves faster than our release cycle, they have limited usage in ports system.

I suggest to change headers ports name from libevdev-headers to just evdev-headers to clear this confusion

But, mmm, if those are a kernel interface, surely our base system's kernel provides them, no ?

We do not provide some of ioctls (EVIOCGMASK & EVIOCSMASK) in kernel but

1. There is userspace evdev implementation in ports tree (multimedia/webcamd) that handles them
2. libevdev has some built in runtime features checks, e.g. it can query uinput protocol version (4 or 5) at runtime and choose appropriate ioctls. It currently do not have checks for EVIOC*MASK as do not wrap these services yet.
3. libevdev usually wants recent headers to compile and tries to do #2 to work on older kernels
4. Newer versions of headers contains newer event codes definitions that can be used with older kernels.
5. If some software does want check supported ioctls at compile time it always possible to replace #include <linux/input.h> with #include <dev/evdev/input.h> in sources