xf86-input monitor filedescriptors

[Peter Hutterer]

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?

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

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

Cheers,
  Peter