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 > <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
