xf86-input monitor filedescriptors

[Peter Hutterer]

On Tue, Feb 28, 2012 at 05:09:20PM +0100, David Herrmann wrote:
> On Tue, Feb 28, 2012 at 2:07 AM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > On Mon, Feb 27, 2012 at 12:45:43PM +0100, David Herrmann wrote:
> >> Hi Peter
> >>
> >> On Sun, Feb 26, 2012 at 11:44 PM, Peter Hutterer
> >> <peter.hutterer at who-t.net> wrote:
> >> > On Fri, Feb 24, 2012 at 03:09:05PM +0100, David Herrmann wrote:
> >> >> Hi
> >> >>
> >> >> I am working on an input-driver for xorg and I was wondering how I can
> >> >> add multiple FDs to be monitored for events? I can set pInfo->fd and
> >> >> then call xf86AddEnabledDevice() but I need to watch multiple FDs for
> >> >> my driver. Is there a simple way to do this?
> >> >
> >> > xf86AddEnabledDevice doesn't really care about the pInfo struct other than
> >> > to get the fd and use it as *closure pointer in your callback so the
> >> > following should work.
> >> >
> >> > foreach fd:
> >> >   pInfo->fd = fd;
> >> >   xf86AddEnabledDevice(pInfo);
> >> >
> >> > of course, since the ReadInput hook doesn't give you the fd that had data
> >> > available you'll need to work around that bit.
> >>
> >> Thanks. I have now also looked at xf86Event.c and found the
> >> xf86AddInputHandler() function. This function also works with
> >> epoll-fds (in contrast to xf86AddEnabledDevice() which behaves weird
> >> with epoll-fds as it uses O_SETSIG/O_ASYNC).
> >>
> >> > the bigger question however is: why do you need multiple fd's, why you do
> >> > you need a new input driver and is there some better way to fix this? some
> >> > more information would help answering the last question.
> >>
> >> I am writing an input driver for Nintendo Wii Remotes.
> >> See: http://github.com/dvdhrm/xf86-input-xwiimote
> >>
> >> linux-3.1 has an hid-wiimote input driver which returns the raw events
> >> of the Wii Remote. It uses multiple event interfaces, though. One for
> >> core events, one for accelerometer events and one for IR events (it
> >> cannot report all in one event interface as this would prevent proper
> >> power management. See linux-input ML for reasons behind this).
> >
> > so the device provides three kernel devices to the driver, correct?
> > Can you provide me with the evtest description of each device so I get a bit
> > of a handle on it?
> 
> I am not at home right now so I cannot pair the device. However, I
> appended the important bits from the source so they should give you
> the same information as evtest.
> 
> >> The Wii Remote can be used in multiple different ways as input device.
> >> Here some examples how to emulate a mouse with it:
> >>  - Use the D-Pad buttons to move the mouse
> >>  - Use the accelerometer to compute current tilt and use this as
> >> absolute pointer input
> >
> > fwiw, I've tried this years ago and it's not the most accurate way to
> > control the cursor :)
> 
> Yeah, I noticed that, too. Maybe I will drop this ;)
> 
> >>  - Use the IR cam to track IR-leds which are positioned underneath the monitor
> >>  - Use IR cam to track an IR-pen which can be used to write on a table/desk
> >> And there are a lot more ideas. Some of them have already been
> >> implemented by injecting events with the XTest API. But this seems
> >> wrong.
> >>
> >> Now there are several different ways to implement these ideas:
> >>
> >> Mouse emulation in kernel driver:
> >> Well, this is possible but I cannot see any reason why such stuff
> >> belongs into the kernel. It would mean I have to write one kernel
> >> module for every possible way how to emulate a mouse with the Wii
> >> Remote.
> >>
> >> Mouse emulation via uinput:
> >> I did this to test several things. It works well but the round-trips
> >> kernel->emulator->uinput/kernel->xorg/evdev->X-client are quite slow.
> >>
> >> Both have the advantage that they are independent of X but have
> >> several disadvantages. Therefore, I decided to implement a user-space
> >> library (libxwiimote) which now can be used to provide Wii Remote
> >> input to any application. So I decided to write an input driver for
> >> xorg which really only copies the data from libxwiimote into the
> >> xserver (as you can see in the source code).
> >>
> >>
> >> The main problem is that there are many different ways how to use the
> >> Wii Remote as input device (I only listed mouse-emulation here). This
> >> requires user-configuration of the device. I thought writing an xinput
> >> driver is the best way to do this.
> >
> > One of the main questions of course is whether you want the wiimote to
> > really be a standard input device in X. I think it's special enough that
> > you're likely to need client-side support anyway for anything beyond moving
> > the pointer. So maybe just leaving the three separate devices as separate
> > X devices may be best approach here.
> 
> Well, I already finished writing the driver base. Everything further
> is just copying more data from the libxwiimote into the xserver,
> nothing special. Maybe you're right and this isn't needed, but having
> it around doesn't hurt.
> Anyway, I want at least one standard way to emulate a mouse. This
> requires at least opening the IR-cam plus Core device for buttons.

Have a look at the Wacom Bamboo tablet series, they open two kernel devices,
one for the stylus and one for the touch. They then show up as two separate
devices in X as well.

What I was suggesting above was that you may want the three separate
devices:
  "Nintendo Wii Remote", 
  "Nintendo Wii Remote Accelerometer"
  "Nintendo Wii Remote IR"

In your driver, you could map x/y to dead axes for the first two (unless
some toggle on the "remote" is set to control the cursor through the pad.
Then you can assign different xinput types to them for applications to
detect them easier (wacom assigns "ERASER", "STYLUS", etc as types for the
tools).

for the IR device, you could default to cursor control (internal in the
driver) and again depending on some options on the driver even fork off
multiple devices so that you get 4 devices, one for each IR resource.

In short, I think you have a valid use-case for a new driver. I still
think that splitting it up into several X devices is better than presenting
everything as one device. It would make implementation easier too since you
don't have to juggle multiple fds per device.

Cheers,
  Peter
> 
> > Cheers,
> >  Peter
> 
> 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
> 
> "Nintendo Wii Remote Accelerometer" (accelerometer device)
> If no user-space process has this device opened, the kernel disables
> the Accelerometer on the device to save energy.
> EV_ABS:
> >-------ABS_RX
> >-------ABS_RY
> >-------ABS_RZ
> 
> "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.
> 
> Two additional devices are provided if extension-support is enabled.
> One for first-level extensions and one for second-level extensions.
> Again for power-management reasons.
> 
> The user-space library (libxwiimote) works well. It uses udev to open
> the core-device plus all related devices and can also monitor the
> system for new connecting devices.
> 
> Regards
> David
>