xf86-input monitor filedescriptors

[Chris Bagwell]

On Tue, Feb 28, 2012 at 12:58 PM, David Herrmann
<dh.herrmann at googlemail.com> wrote:
> 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?

Yes.

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

I believe intent is only 1 owner of an input at a time so above
wouldn't be a concern then.

I'll only add here that when a kernel driver supports EVIOSKEYCODE,
using /lib/udev/keymaps and /lib/udev/rules.d/95-keymaps to change
them to more reasonable value is very easy for X and console users.

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

Oh, sorry.  I missed that part.  So you already knew about what I was
suggesting.

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

I think we were just trying to get a feel for what you needed to make
sure it wasn't already solved.  Its certainly valid to write new
xf86-input drivers for unique input devices.

I think you can look to joysticks for my main concern. There probably
are some use cases were having xf86-input-joystick makes most sense
but I'm not sure how you would negotiate control of device so
sometimes its mouse-like and owned by X input driver and sometimes its
controlled by a game you launch.  At least how to do it so user isn't
editing config files or clicking on things.

Chris

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