Hi Peter On Sun, Feb 26, 2012 at 11:44 PM, Peter Hutterer <peter.hutte...@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@lists.x.org: X.Org development >> Archives: http://lists.x.org/archives/xorg-devel >> Info: http://lists.x.org/mailman/listinfo/xorg-devel >> _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel