Broader handling of architectures; WITH-EVENT-DEVICES macro

[varjagg]

Please consider the following changes:

• Add trivial-features dependency to determine the word size across architectures/compilers
• WITH-EVDEV-DEVICES allowing handling of several input event devices as the same blocking operation

[jtgans]

I'd prefer to not merge this as-is. We need to solve the nonblocking problem in a better way.

Also, I'd like to see the int size problem solved in a better way. Can you split these two things into two different PRs?

[jtgans]

This has always stuck in my craw, and while using these flags seem to work okay, I worry it's the wrong approach.

The more I think about it, the more I think the host CL compiler is the wrong place to put this: it's possible this library could be running in a 32-bit compiler with a 64-bit host kernel, which means these values are entirely wrong for the evdev interface.

We really need a way to identify what the host kernel's word size is, rather than the host compiler's architecture.

[jtgans]

It's also worth noting here that the event orders may be out of order, kernel depending, since you're only using a read syscall here instead of poll or otherwise. It's possible that the other devices may be ready, but you're blocked on one earlier in the list.

read-raw-event should probably at the very least be made to work in nonblocking mode for this to work correctly, or these file descriptors should be passed out in a threaded manner, or otherwise poll/select should be setup to do this, otherwise, this function isn't really what you want. I know I'm speaking C here, but that's the underlying interface we have to think about in this case.

When I designed this library, the concept was to keep it focused on doing one thing well (parse out evdev data into something useful for CL), ideally in a reentrant way. That's why I never put in anything relating to nonblocking, threading or anything else.

This meant that I was actually letting threading and nonblocking behavior exist outside of this library in the outer silica project's inputmanager handler, which felt more appropriate. In there, I was using chanl as a means to dispatch events from multiple threads into a producer/consumer setup to solve the blocking problem in a more managed way. See also handler.lisp in cl-event-handler. Effectively, while the code is currently written to only handle one evdev device, the manager could be altered to manage events from multiple handler instances, each running their own with-evdev-device loop.