build error AM_CONFIG_HEADER -> AC_CONFIG_HEADERS

[mmonaco]

If you get around to fixing this, would you mind tagging .3?

[dvdhrm]

Fixed and 0.3 is also tagged.

Please note that I am not working on this driver, anymore. I will gladly do bugfixes but I won't push this into distributions or extend it.
In my opinion applications should instead directly access Wii Remotes via the /dev/input/eventX character devices or via libxwiimote. I don't see a reason to do this via xf86-input drivers.

Thanks
David

[mmonaco]

You had comments that say the ev devs shouldn't be used directly, and only make sense with libxwiimote. But you can't expect every application to support that? I mean, you don't expect applications to interpret mouse or keyboard events directly from evdev, the use X.

[dvdhrm]

IIRC I said that I don't "recommend" using evdev directly. But the evdev interface is stable and everyone is welcome to use it. It's just messy and using libxwiimote is much easier.

But apart from that the issue with xf86-input-xwiimote that I see is that it is highly dependent on X. That is, if I spent time writing it, I will never be able to use it with other applications like Wayland or kmscon or raw XBMC. This really bothers me.
Furthermore, I don't know a good way to present Wii Remotes to applications that are not aware that it's a Wii Remote. Should I interpret IR data as Motion data? Or Accelerometer Data as motion data?
That's why this driver only supports buttons, yet. This is the only data that I can easily forward without any explicit semantics.

Feedback is always welcome. But I have a lot of other fun projects that I like to work on, sorry. I am still maintaining the kernel WiiRemote driver, but for the user-space part, I'd like to reduce my work to libxwiimote and let others do the application integration if they want.

Regards
David