On Tue, Feb 28, 2012 at 04:15:12PM -0600, Chris Bagwell wrote: > On Tue, Feb 28, 2012 at 12:58 PM, David Herrmann > <[email protected]> wrote: > > On Tue, Feb 28, 2012 at 6:55 PM, Chris Bagwell <[email protected]> wrote: > >> On Tue, Feb 28, 2012 at 10:09 AM, David Herrmann > >> <[email protected]> > >>>>> I am writing an input driver for Nintendo Wii Remotes. > >>>>> See: http://github.com/dvdhrm/xf86-input-xwiimote > >>>>> > >> > >>> > >>> 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 > >> > >> Out of the box, does this interface get controlled by xf86-input-evdev? > >> > >> You may still wish to write a xf86-input-wiimote but have you > >> considered alternatives? I think for this device, your mostly > >> interested in remapping the key's. > >> > >> IR Remote's have same basic issue and push a lot of the problem into > >> kernel and the EVIOCSKEYCODE ioctl(). Here is a sample user land > >> application: > >> > >> http://linuxtv.org/downloads/v4l-dvb-apis/Remote_controllers_table_change.html > >> > >> You'll probably have to invent "scancode" concept for your kernel > >> driver for this to work. This old patch from google may be of > >> interest for HID devices and EVIOSKEYCODE. > >> > >> http://www.mail-archive.com/[email protected]/msg48259.html > > > > I am not getting your point here. Do you propose to use EVIOSKEYCODE > > if I want to change the scancode/keycode mapping? > > Yes. > > > I never understood why this API is used. Consider one application > > reads the input device and I change the mapping just to remap the keys > > for X/evdev. The other application now breaks as the kernel sends > > other events (ABI breakage). Or am I getting something wrong here? > > This may work if X is the only user of the device but then I wonder > > why using the kernel API and not implementing it in X anyway. > > I believe intent is only 1 owner of an input at a time so above > wouldn't be a concern then. > > I'll only add here that when a kernel driver supports EVIOSKEYCODE, > using /lib/udev/keymaps and /lib/udev/rules.d/95-keymaps to change > them to more reasonable value is very easy for X and console users. > > > > >>> "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. > >>> > >> > >> I think your current X input driver is taking HAT0X/Y and posting them > >> with little modification on more typical X/Y axis? > > > > It uses all four HAT?X/Y values to compute one absolute value. It's a > > little more complex so rotations are also detected and so on but I > > think that's not important here. > > > >> I've seen a common problem where hid-core combines 2 HID interfaces > >> into 1 and devices first X/Y's are reported as X/Y and second X/Y's as > >> Z/RX. I've also seen people work around this in user land using the > >> "uinput" feature. They would create a program that opens > >> /dev/input/event? of touchscreen and listen for ABS_Z/RX events and > >> then post them to a /dev/uinput as ABS_X/Y values. > > > > As I said earlier, I've already written a daemon which listens for new > > Wii Remotes and opens an uinput device for each of them to emulate the > > desired behavior. It works currently only with buttons but that can be > > extended easily. However, I was concerned about the additional > > round-trips that this introduces as every event is sent back to the > > kernel which then sends it through the uinput interface. > > Oh, sorry. I missed that part. So you already knew about what I was > suggesting. > > > > >> Eventually, these converted events came back to user land as a new > >> /dev/input/event? interface and xf86-input-evdev can then be used > >> unmodified. You could do something similar by converting HAT0X/Y to > >> X/Y axis. > >> > >> I suspect this option is easier to toggle between mouse mode and > >> letting the device be owned by some specific application as well. > >> > >> Google "uinput.h" for examples. Sorry, I couldn't quickly find the > >> touchscreen uinput code I've seen in past. > >> > >> Chris > > > > Thanks for the reply. I am getting the feeling that you both recommend > > solving this problem in a separate process and feeding that input into > > the evdev driver. I never worked on the xserver before so I thought > > the recommended way was writing an xf86-input driver. > > I think we were just trying to get a feel for what you needed to make > sure it wasn't already solved. Its certainly valid to write new > xf86-input drivers for unique input devices.
I agree. There are legitimate use-cases for new X input modules, but they should be a last resort. Cheers, Peter > > I think you can look to joysticks for my main concern. There probably > are some use cases were having xf86-input-joystick makes most sense > but I'm not sure how you would negotiate control of device so > sometimes its mouse-like and owned by X input driver and sometimes its > controlled by a game you launch. At least how to do it so user isn't > editing config files or clicking on things. > > Chris > > > > > But after your responses I might instead consider extending my > > previous approach: A daemon which listens for new devices and for each > > device it emulates the expected behavior via uinput. This would also > > allow to listen for on-line configurations on some bus-system etc. I > > might need some file in xorg.conf.d so Wiimotes get the default Xkb > > keymap applied and no keyboard-catchall Xkb change is applied instead. > > > > Thanks > > David > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
