xf86-input monitor filedescriptors

[Chris Bagwell]

On Tue, Feb 28, 2012 at 10:09 AM, David Herrmann <dh.herrmann at googlemail.com>
>>> I am writing an input driver for Nintendo Wii Remotes.
>>> See: http://github.com/dvdhrm/xf86-input-xwiimote
>>>

>
> The devices created for every WiiRemote include:
>
> "Nintendo Wii Remote" (core device)
> EV_KEY:
>>-------KEY_LEFT,>------/* WIIPROTO_KEY_LEFT */
>>-------KEY_RIGHT,>-----/* WIIPROTO_KEY_RIGHT */
>>-------KEY_UP,>>-------/* WIIPROTO_KEY_UP */
>>-------KEY_DOWN,>------/* WIIPROTO_KEY_DOWN */
>>-------KEY_NEXT,>------/* WIIPROTO_KEY_PLUS */
>>-------KEY_PREVIOUS,>--/* WIIPROTO_KEY_MINUS */
>>-------BTN_1,>->-------/* WIIPROTO_KEY_ONE */
>>-------BTN_2,>->-------/* WIIPROTO_KEY_TWO */
>>-------BTN_A,>->-------/* WIIPROTO_KEY_A */
>>-------BTN_B,>->-------/* WIIPROTO_KEY_B */
>>-------BTN_MODE,>------/* WIIPROTO_KEY_HOME */
> Force-Feedback:
>>-------FF_RUMBLE

Out of the box, does this interface get controlled by xf86-input-evdev?

You may still wish to write a xf86-input-wiimote but have you
considered alternatives?  I think for this device, your mostly
interested in remapping the key's.

IR Remote's have same basic issue and push a lot of the problem into
kernel and the EVIOCSKEYCODE ioctl().  Here is a sample user land
application:

http://linuxtv.org/downloads/v4l-dvb-apis/Remote_controllers_table_change.html

You'll probably have to invent "scancode" concept for your  kernel
driver for this to work.  This old patch from google may be of
interest for HID devices and EVIOSKEYCODE.

http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg48259.html

> "Nintendo Wii Remote IR" (IR device)
> If no user-space process has this device opened, the kernel disables
> the IR-cam on the device to save energy.
> EV_ABS:
>>-------ABS_HAT0X
>>-------ABS_HAT0Y
>>-------ABS_HAT1X
>>-------ABS_HAT1Y
>>-------ABS_HAT2X
>>-------ABS_HAT2Y
>>-------ABS_HAT3X
>>-------ABS_HAT3Y
> This tracks up to 4 IR-sources with the IR-cam reported as 2D absolute data.
>

I think your current X input driver is taking HAT0X/Y and posting them
with little modification on more typical X/Y axis?

I've seen a common problem where hid-core combines 2 HID interfaces
into 1 and devices first X/Y's are reported as X/Y and second X/Y's as
Z/RX.  I've also seen people work around this in user land using the
"uinput" feature.  They would create a program that opens
/dev/input/event? of touchscreen and listen for ABS_Z/RX events and
then post them to a /dev/uinput as ABS_X/Y values.

Eventually, these converted events came back to user land as a new
/dev/input/event? interface and xf86-input-evdev can then be used
unmodified.  You could do something similar by converting HAT0X/Y to
X/Y axis.

I suspect this option is easier to toggle between mouse mode and
letting the device be owned by some specific application as well.

Google "uinput.h" for examples.  Sorry, I couldn't quickly find the
touchscreen uinput code I've seen in past.

Chris