xf86-input monitor filedescriptors

[David Herrmann]

On Tue, Feb 28, 2012 at 6:55 PM, Chris Bagwell <chris at cnpbagwell.com> wrote:
> 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

I am not getting your point here. Do you propose to use EVIOSKEYCODE
if I want to change the scancode/keycode mapping?
I never understood why this API is used. Consider one application
reads the input device and I change the mapping just to remap the keys
for X/evdev. The other application now breaks as the kernel sends
other events (ABI breakage). Or am I getting something wrong here?
This may work if X is the only user of the device but then I wonder
why using the kernel API and not implementing it in X anyway.

>> "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?

It uses all four HAT?X/Y values to compute one absolute value. It's a
little more complex so rotations are also detected and so on but I
think that's not important here.

> 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.

As I said earlier, I've already written a daemon which listens for new
Wii Remotes and opens an uinput device for each of them to emulate the
desired behavior. It works currently only with buttons but that can be
extended easily. However, I was concerned about the additional
round-trips that this introduces as every event is sent back to the
kernel which then sends it through the uinput interface.

> 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

Thanks for the reply. I am getting the feeling that you both recommend
solving this problem in a separate process and feeding that input into
the evdev driver. I never worked on the xserver before so I thought
the recommended way was writing an xf86-input driver.

But after your responses I might instead consider extending my
previous approach: A daemon which listens for new devices and for each
device it emulates the expected behavior via uinput. This would also
allow to listen for on-line configurations on some bus-system etc. I
might need some file in xorg.conf.d so Wiimotes get the default Xkb
keymap applied and no keyboard-catchall Xkb change is applied instead.

Thanks
David