xf86-input monitor filedescriptors

[Peter Hutterer]

On Tue, Feb 28, 2012 at 04:15:12PM -0600, Chris Bagwell wrote:
> 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 agree. There are legitimate use-cases for new X input modules, but they
should be a last resort.

Cheers,
  Peter

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