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