Building USB HID modules for 2.4.19-rmk7

[hudson]

EDIT: evkb-0.2 Application You can use your USB keyboard with your iLiad with this application!


I've downloaded the linux-2.4.19-rmk7-pxz2-irex1 kernel sources and patches from the iRex website. The kernel sources appear to have the patch already installed, so it is not necessary to reapply it. There is no .config file included in the tar file (and 2.4 doesn't support /proc/config.gz), so I made some guesses and built input, hid, evdev and keybdev as modules (abbreviated .config):

CONFIG_ARM=y
CONFIG_ARCH_PXA=y
CONFIG_MACH_PXA_IREX_ER0100=y
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=768
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_USB_HIDDEV=y
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
CONFIG_USB_WACOM=m


I'm able to load them and it detects the USB keyboard/mouse on the port and I can disconnect/reconnect them without problems, but once I hit a single key it hangs the device hard. If I do not load keybdev, I can try to read /dev/input/mouse0 or /dev/input/event[01], but I never see any events in any of them. If I load the old BP usb keyboard/mouse modules (usbkbd.o) I do not see any results, either, but at least it doesn't hang.

dmesg output, although I don't have any after the hang:

usb.c: registered new driver hiddev
usb.c: registered new driver hid
input0: USB HID v1.00 Keyboard [0d3d:0001] on usb1:2.0
input1: USB HID v1.00 Mouse [0d3d:0001] on usb1:2.1
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers

[hudson]

Following up on my own query, I realized that cat was line buffering the output from the event device file, so I instead I wrote an event decoder that generates synthetic X events via the Xtest extension (attached). You should be able to drop this into /mnt/free/documents or wherever and have an icon to launch the USB keyboard interface. Plug in the keyboard before running so that /dev/input/event0 is already allocated. It may be possible to rebuild the kdrive tinyX server to use the evdev interface (or it may already be enabled). Either of those would allow the use of a USB keyboard without any problems.

The keyboard appears to be correct when I use the usbkbd.c modules, but the mouse is as if the data[] array in the usb_mouse.c usb_mouse_irq() function is shifted by one array position. That doesn't explain the crash with the full HID driver, but I'm less inclined to hunt it down now that I have it working.

In the tarfile is the full source, as well as a pre-compiled version with the pre-compiled kernel modules for the 2.4.19-rmk7 kernel used in the iRex 2.9.1 firmware. No guarantees that it will work for you, but it works great for me with the mrxvt application.

[Antartica]

Originally Posted by hudson

No guarantees that it will work for you, but it works great for me with the mrxvt application.

So, is it working using the module and your evdev-XTEST conversion app?

If so, those are great news :-))).

[henkvdg]

Hudson, it works for me too!

Thank you very much!

[hudson]

So, is it working using the module and your evdev-XTEST conversion app?

It is working with the keyboard and fairly useful. I can run vi in the mrxvt application and use the iLiad as a very interesting text editor. I suspect that emacs could be compiled as well with little difficulty other than memory usage and the lack of any swap device.

The mouse device is still hosed. The data reaching the usb device driver just doesn't make sense. Here is the interrupt routine from 2.4.19:

static void usb_mouse_irq(struct urb *urb)
{
struct usb_mouse *mouse = urb->context;
signed char *data = mouse->data;
struct input_dev *dev = &mouse->dev;

if (urb->status) return;

input_report_key(dev, BTN_LEFT, data[0] & 0x01);
input_report_key(dev, BTN_RIGHT, data[0] & 0x02);
input_report_key(dev, BTN_MIDDLE, data[0] & 0x04);
input_report_key(dev, BTN_SIDE, data[0] & 0x08);
input_report_key(dev, BTN_EXTRA, data[0] & 0x10);

input_report_rel(dev, REL_X, data[1]);
input_report_rel(dev, REL_Y, data[2]);
input_report_rel(dev, REL_WHEEL, data[3]);
}

The data[] array should contain the button bitmap, the relative X, relative Y and relative wheel data (in that order). What I see is that data[0] is always 1, data[1] is the bitmap, data[2] is the X motion and data[3] is the Y motion. If I hack the routine to use 'data = mouse->data + 1' everything looks good, including the wheel and buttons.

It wouldn't be too much work to add mouse support to the evkb program. Does the window manager support displaying a mouse cursor?

[Robert Marquard]

Is that a standard mouse or a mouse-keyboard combo? It could be the ReportID then.

[hudson]

Originally Posted by Robert Marquard

Is that a standard mouse or a mouse-keyboard combo? It could be the ReportID then.

It's through a combined PS/2 keyboard/mouse to USB converter with my trusty 1991 Model-M and a random mouse from some other system. I don't have a true USB mouse to test with.

Looking into the future, 2.6.19 uses the same logic for parsing the mouse->data[] in drivers/usb/input/usbmouse.c:usb_mouse_irq(), so the problem may be with the USB converter. I'll see if I can find a real mouse to test with, as well as a folding USB keyboard for travel.

[Robert Marquard]

So the device uses PS/2 devices (mouse and keyboard) as input devices and represents a mouse/keyboard composite HID device to the OS. It is definitely possible to have such a device use ReportIDs. USB on Linux is still immature even for 2.6. I would suspect either a bug in the 2.4 kernel or a bug in the device. ReportID 1 for the mouse data is suspicious. I would have expected 2.

[Matthijs]

For configs: see arch/arm/def-configs/irex*

so, to compile use:
make irex_config
make oldconfig
make dep
make zImage

Edit: so "make irex_config" installs the iRex .config file, which you can then edit.

[hudson]

Originally Posted by Matthijs

For configs: see arch/arm/def-configs/irex*

That's very useful, thanks!

For anyone else who wants to build their own USB HID kernel modules, here is a diff between the official .config and my .config. Mostly I've just added the input core and USB HID modules, as well as a few other little things to make my life easier (like the NFS client and loopback filesystems).

[Adam B.]

Great work! With a full keyboard, the iLiad could really be a great platform for always-available productivity applications. It has the potential to be so much more than just a document reader.

[Matthijs]

Not to spoil the fun, but:
The problem with this will probably be that even though you have HID modules, you cannot modprobe them and make it work without reflashing a kernel (which you cannot do at this point, since you're not on 2.9.5)...
See also Scotty's efforts to get a keyboard working.

[hudson]

Originally Posted by Matthijs

Not to spoil the fun, but:
The problem with this will probably be that even though you have HID modules, you cannot modprobe them and make it work without reflashing a kernel

I'm not sure what the problem is -- it works great for me. I've been able to use insmod to load the HID modules and route the events to the X server via the Xtest extension. The application that I posted sets up everything with the kernel modules and runs the event redirector in the background.

[Matthijs]

Ah, ok. In that case: ignore my message. From when Scotty tried it, I though I recalled that a new kernel would be needed. Apparently not.
(And I didn't read you first two posts well enough )

Nice job!

[henkvdg]

Originally Posted by hudson

I'm not sure what the problem is -- it works great for me. I've been able to use insmod to load the HID modules and route the events to the X server via the Xtest extension. The application that I posted sets up everything with the kernel modules and runs the event redirector in the background.

As I found out, the keyboard works if it is fist connected before the application is started. When removed and reconnected, the application has to be started again to use the keyboard. Not every key of my keyboard is recognized correctly, so it seems the right keyboard description file has to be used.

I could use the keyboard for the terminal program, but not for changing the name or comments with a file, by using the label icon.

So at least a little bit extra will be needed to use this possibility tot the max.