devel/evdev: Forward to dev/evdev headers where possible

[arichardson]

Summary

Instead of downloading the linux headers, use the system-provided evdev headers
instead where possible. We don't have a compatible joystick.h, but the other
three headers should be compatible.

Test Plan

Installed headers look correct.

[arichardson]

ping?

[wulf]

It is desirable for ports to have up to date version of input-event-codes.h, so it should be downloaded from upstream rather than bundled with OS.

[adridg]

input-event-codes.h hasn't changedu pstream in 4 years (perhaps "of course" because it's a tagged release) but if wulf@ says that that one should be obtained upstream, then that seems reasonable. There's no meaningful difference between the base-system-provided version and upstream that I can see -- it's all defines of constants. One concern I have is that we stopped using base-system headers at some point -- at least that's how I remember it -- because the dev/evdev/ headers were not meant for user-space consumption. I can't find that in ports commit history, though, so maybe I'm dreaming it.

[arichardson]

In D43498#996756, @adridg wrote:

input-event-codes.h hasn't changedu pstream in 4 years (perhaps "of course" because it's a tagged release) but if wulf@ says that that one should be obtained upstream, then that seems reasonable. There's no meaningful difference between the base-system-provided version and upstream that I can see -- it's all defines of constants. One concern I have is that we stopped using base-system headers at some point -- at least that's how I remember it -- because the dev/evdev/ headers were not meant for user-space consumption. I can't find that in ports commit history, though, so maybe I'm dreaming it.

Considering the macro used in those headers are actually consumed by the kernel and define ioctls, shouldn't we make sure that the value match what the kernel assumes rather than relying on the fact that they probably match the linux values? I'd rather have a compilation failure than a runtime failure because some new ioctl was assumed to be supported?

[arichardson]

For example the linux joystick.h defines a bunch of ioctls that I don't see implemented on FreeBSD, so we really shouldn't claim support for it? Maybe the header should only includes the constants?

[wulf]

In D43498#996835, @arichardson wrote:

For example the linux joystick.h defines a bunch of ioctls that I don't see implemented on FreeBSD, so we really shouldn't claim support for it? Maybe the header should only includes the constants?

Probably joystick support is provided by webcamd