xf86-input monitor filedescriptors

[David Herrmann]

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

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

Cheers
David

> Cheers,
>  Peter
>
>
>> Furthermore, setting pInfo->fd to an epoll-fd gives me weird behavior.
>> My callback gets called correctly but the call is delayed until
>> another input-device has also input available.
>>
>> Regards
>> David
>> _______________________________________________
>> xorg-devel at lists.x.org: X.Org development
>> Archives: http://lists.x.org/archives/xorg-devel
>> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>>