How does linux handle USB mouse?

migg · 04-09-2008, 03:37 PM

Hi, I have bought one these small USB writing pads (see below) in China, and I am trying to get Linux to create a proper /dev/input/event? entry for it. Or I am trying to understand how Linux handles HID devices...

What the device is: It is essentially a small touch sensitive drawing tablet. The purpose is to write Chinese characters on it, and use it together with handwriting recognition software. It has 3 buttons and a touch sensitive area (and a plastic pen..), but as far as I know no pressure sensitivity etc. like fancy drawing tablets. The box says "Qing dynasty", for what it's worth.

My system, before I forget: It's a Thinkpad R50e running Debian testing with kernel 2.6.24 (from kernel.org, no Debian patches).

Now, what works and how, and what I'd like:

When plugging the device in, syslog says:

kernel: usb 2-2: new low speed USB device using uhci_hcd and address 17
kernel: usb 2-2: configuration #1 chosen from 1 choice
kernel: hiddev96hidraw0: USB HID v1.10 Device [PenPower Touchpad PenPower Touchpad] on usb-0000:00:1d.1-2

Then /dev/usb/hiddev0 is created, and it works fine, in the sense that whenever the tablet is touched, /dev/usb/hiddev0 outputs what looks like 6 key/value pairs giving x- and y- coordinates and the status of the buttons. (I can supply details if it is relevant.) I have even written some code that reads /dev/usb/hiddev0 directly and lets you draw on a canvas. But that is obviously not the right way to do it.

And now I have to admit that I do not know a lot about how HID devices are handled. It seems to me that, if the device is recognized as a mouse, then I should get a /dev/input/event? that I could use for configuring X, and access the device through the XInput extension. But /dev/input/event? is not created. Does it mean that the device is not recognized as a mouse, or does it simply not behave as a mouse, or what? From the data I can read from /dev/usb/hiddev0 I would be slightly surprised if there's no way to use an existing driver, but I might be missing something, and any explanation would be appreciated.

That's it, below follows some technical info. Thanks for your time!

Relevant part of output from lsusb -v:

Bus 002 Device 017: ID 04b4:fef3 Cypress Semiconductor Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x04b4 Cypress Semiconductor Corp.
idProduct 0xfef3
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 4
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 63
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0005 1x 5 bytes
bInterval 10

(Note that bInterfaceProtocol says Mouse, does it mean that it should work as a standard USB mouse?)

Relevant part of cat /proc/bus/usb/devices:

T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 17 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=04b4 ProdID=fef3 Rev= 1.00
S: Manufacturer=PenPower Touchpad
S: Product=PenPower Touchpad
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 5 Ivl=10ms

The thing does not appear in /proc/bus/input/devices.

Simon Bridge · 04-10-2008, 08:35 AM

... it's working! Support for the penpower touchpad was added to the kernel in 2.6.24 (October 2007) (http://linux.chapter7.ch/touchkit/)

Quote:

whenever the tablet is touched, /dev/usb/hiddev0 outputs what looks like 6 key/value pairs giving x- and y- coordinates and the status of the buttons. (I can supply details if it is relevant.) I have even written some code that reads /dev/usb/hiddev0 directly and lets you draw on a canvas. But that is obviously not the right way to do it.

Nope, that's pretty much the way to do it. What were you expecting?

The kernel driver catches the touchpad events and sends them in a useable form to the input layer. You need an application to use them.

migg · 04-10-2008, 11:57 AM

Quote:

Originally Posted by Simon Bridge

... it's working! Support for the penpower touchpad was added to the kernel in 2.6.24 (October 2007) (http://linux.chapter7.ch/touchkit/)

Thanks for the link, but I have already tried that driver. I think it is a different device with a similar name. My device has a different id, and isn't really listed among the devices supported by the driver. I even tried adding my id in the source of the driver just to be sure, and it didn't work.

Quote:

Nope, that's pretty much the way to do it. What were you expecting?

The kernel driver catches the touchpad events and sends them in a useable form to the input layer. You need an application to use them.

What I was expecting, or at least hoping, was to be able to set up the device as a second mouse in X with something like

Code:

Section "InputDevice"
    Identifier   "PadThing"
    Driver   "mouse"
    Option "Protocol"   "auto"
    Option "Device"     "/dev/input/event?"
EndSection

Then an application could access the device through the XInput extension or something similar. That would be much more generic than writing applications reading /dev/usb/hiddev0 directly.

I guess that would require that usbmouse instead of hiddev would talk to my device: I have been suspecting that the pad is in fact using a standard mouse protocol, and just isn't recognized as such. But here I'm on thin ice, and perhaps I'm not even making any sense. That was really my question..

Thanks for the suggestions, anyway.

Simon Bridge · 04-10-2008, 01:29 PM

Um - no. Touchpads in hardware sense relative position. Mice sense change in position. You can make one look like the other electronically by adding hardware. That would usually rule out cheap.

From your description, your touchpad is supposed to work with some software for drawing.

You could write an app so when the pad is touched the mouse pointer jumps to the equivalent screen position.

Maybe you could try configuring it like a tablet input for a tablet PC?

Section "InputDevice"
Driver "touchkitusb"
Identifier "stylus"
Option "Device" "/dev/usb/hiddev0"
Option "Type" "stylus"
Option "ForceDevice" "ISDV4" # dunno about this bit.
EndSection

But you'll need to read the driver notes to see what's supported.
Hmmm... anything like this?
http://www.worldlanguage.com/Chinese...nit-104650.htm

migg · 04-16-2008, 04:06 AM

Quote:

Originally Posted by Simon Bridge

Um - no. Touchpads in hardware sense relative position. Mice sense change in position.

Of course, you are right.

Quote:

Originally Posted by Simon Bridge

Hmmm... anything like this?
http://www.worldlanguage.com/Chinese...nit-104650.htm

Yes, something like that, but a different manufacturer. The name "Pen Power" only appears "in hardware" in my device.

Anyway, I had a closer look at usbtouchpad (aka touchkit) in the kernel source, and it was much simpler than I expected. None of the supported devices used a protocol that matched mine exactly, but it was straight forward to add my device to the driver. So now I have a working driver, and a /dev/input/event?, and gimp recognizes my "extended input device".

So, thanks for the input!

Simon Bridge · 04-16-2008, 06:11 AM

Excellent - slightly-off mainstream devices like this can be touch and go.
Have fun.

AnomalyConcept · 04-27-2008, 12:22 AM

Hi, stumbled across this thread when playing around with a similar USB touchpad device.

So far, I've gotten the /dev/usb/hiddev0 to show up and displaying output whenever events happen on the touchpad, but I haven't had any luck decoding the output yet.

Both Simon Bridge and migg both had some luck with this; care to share any insight? =)

Simon Bridge · 04-27-2008, 03:55 AM

Look at the touchkit part of the kernel source.

migg · 05-07-2008, 02:55 PM

Quote:

Originally Posted by AnomalyConcept

Hi, stumbled across this thread when playing around with a similar USB touchpad device.

So far, I've gotten the /dev/usb/hiddev0 to show up and displaying output whenever events happen on the touchpad, but I haven't had any luck decoding the output yet.

Both Simon Bridge and migg both had some luck with this; care to share any insight? =)

Hi, I apologize for the very late response, but I've been horribly busy, tax declaration and whatnot..

Using /dev/usb/hiddev0 directly (in my own code) turned out to be very easy. With a small C program echoing whatever happened on that device, it was easy to establish that, with my device, I got 6 key/value pairs whenever anything happened to the touchpad, each key and value consisting of a 4 bytes word (each). For instance, the first key was 0x10030, and the first value was the x-position, LSB first. And so on. From this knowledge I wrote a small program that used the XTest extension to grab the mouse cursor and simulate mouse events, I'm attaching the code below.

As step two, I had a look at the usbtouchscreen.c in the kernel source (look under drivers/input/touchscreen). The C code here is very "extendible", i.e. it is quite easy to add support for a new device. Have a look yourself. I think, by the way, I had to blacklist hiddev, so that the usbtouchscreen got control over the device instead. Anyway, it seems to me that using the usbtouchscreen driver you can only get position through, and not click events, as I guess the driver is intended for actual touch-sensitive computer screens, and not these pads we are using. With the patched usbtouchscreen driver, I got a /dev/input/eventX device when plugging in my touchpad, and it seems to work together with the evtouch driver in X. But my setup is still not quite at "production" level, the problem now is that I cannot keep the evtouch driver from grabbing the mouse cursor. So in gimp, for instance, I can draw with the touchpad, but the mouse cursor also moves along.. Also, with the usbtouchscreen driver, I got a second mouse device /dev/input/mouse1 (and a collective /dev/input/mice), and I don't quite understand "who" created that. But that should perhaps indicate that I don't need evtouch after all, but can use a mouse driver (if I use /dev/input/mice for my usual core pointer in X, I can move the cursor fine using either the mouse or the pad). Ok, this is perhaps confusing to read, but this is about where I am at the moment. Happy hacking

Here's the code that uses /dev/usb/hiddev0 directly (tailor made for my device only I guess!), in case you need something to get started. When touching the pad, I simulate click-and-drag:

Code:

/* gcc -g -Wall -o xtestmotion xtestmotion.c -L /usr/X11R6/lib/ -lX11 -lXtst */ 

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <X11/extensions/XTest.h> 

int main( int argc, char *argv[] ) { 
        int pad_x = 128, pad_y = 240, pad_width=1184, pad_height=1040;
        int canvas_x = 0, canvas_y = 0, canvas_width=1024, canvas_height=768;
        int x,y;
        Display *dpy;
        int i;
        FILE *hiddev;
        int packet[12];
        int state=0;

        dpy = XOpenDisplay( NULL ); 
        assert(dpy);

        hiddev = fopen("/dev/usb/hiddev0", "r");
        assert(hiddev);

        for(;;)
        {
                for(i=0; i<12; i++) {
                        packet[i] = getc(hiddev);
                        packet[i] += getc(hiddev)*0x100;
                        packet[i] += getc(hiddev)*0x10000;
                        packet[i] += getc(hiddev)*0x1000000;
                        printf("\t%x", packet[i]);
                }
                printf("\n");
                if(packet[1] != 0 && packet[3] != 0) {
                        x = (packet[1]-pad_x)*canvas_width/pad_width + canvas_x;
                        y = (packet[3]-pad_y)*canvas_height/pad_height + canvas_y;
                        XTestFakeMotionEvent(dpy, -1, x, y, CurrentTime);
                        if(state==0) {
                                XTestFakeButtonEvent(dpy, 1, 1, CurrentTime);
                                state=1;
                        }
                }
                else {
                        if(state==1) {
                                XTestFakeButtonEvent(dpy, 1, 0, CurrentTime);
                                state=0;
                        }
                }
                XFlush(dpy);
        }
        return 0;
}

Best,

migg.

bkruggel · 11-05-2009, 08:16 PM

Hello migg,

It seems I have exactly the same input pad (see below).

However, I have searched around for some (5) hours now and I don't really understand how to make it work...
Just as yours, it seems to be recognized by usbhid (I get crazy stuff in the terminal when I type 'cat /dev/usb/hiddev0' and scribble on the pad) - unfortunately, I wouldn't like to blacklist the usbhid driver, since I use a 9-button mouse with imwheel (which needs usbhid).
Is there a way to tell usbhid not to use the tablet?

What exactly are these changes you made to the touchkitusb driver to make the tablet work?

---EDIT---
Okay, after another night searching around I have found this script:
http://matias.archlinux-br.org/archives/153

So input through /dev/usb/hiddev0 is working. Needs just a little adjustments.

I actually just want to use the pad for chinese character input - if it is used as a mouse or not is not important (well, I didn't find any program yet that would use a pad as an input 'other than a mouse').

Migg, would you mind explaining me a little? I'm familiar with modules, packages etc. but when it comes to compiling or catching input like you did, I'm a complete zero. So which changes did you exactly make to the driver?

Has anybody found any program for chinese character input that is specialized for these pads? I'm thinking of something like tegaki (http://www.tegaki.org/) but without a canvas to write on. As soon as one uses the pad, there should be a 'click' at the same time (so that it actually draws the strokes without the need to click the pad's button). Then, tegaki should use a easystroke-like (http://sourceforge.net/apps/trac/easystroke/) input to analyze the stroke order without the need for the user to stay in a certain canvas (he can only work with the pad and doesn't need to look at the screen). This way, one could take a sheet of paper, lay it on the pad and write a good old character directly on the paper and the PC gets the input.
Any idea on this? Would this solution be better through /dev/usb/hiddev0 or through a real input driver?

Thank you very much,
Björn

T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=04b4 ProdID=fef3 Rev= 1.00
S: Manufacturer=PenPower Touchpad
S: Product=PenPower Touchpad
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 5 Ivl=10ms