Comment 28 for bug 636311

... or for that matter, it also seems to find all other kinds of input types, relative _and_ absolute axes, and scroll wheels, and mouse buttons.

I had another look at the udev output, and indeed the kernel reports strange things in the event mask:

UDEV [1286488972.672211] add /devices/pci0000:00/0000:00:12.0/usb3/3-1/3-1:1.1/input/input3 (input)
[...]
EV==10001f
KEY==837fff 2c3027 bf004444 0 c000000 1 10f84 8b27c007 ffff7bfa d941dfff febeffdf ffefffff ffffffff fffffffe
REL==40
ABS==ffffff01 701ff
MSC==10

In contrast to that, the input device for the "normal" keys looks much more reasonable:

KERNEL[1286488968.583658] add /devices/pci0000:00/0000:00:12.0/usb3/3-1/3-1:1.0/input/input2 (input)
[...]
EV==120013
KEY==10000 7 ff800000 7ff febeffdf f3cfffff ffffffff fffffffe
MSC==10
LED==107

So I assume the evdev driver looks at the event mask, and this is what's causing it to think that this is a mouse, joystick, and all that. I'm not sure how the kernel detects these event masks, whether it's read from the hardware, or set in the driver; in the former case it would be hardware bug, in the latter case a kernel bug.

However, that still leaves the question open why the mouse clicks happen? Even if the input device falsely claims that it can send all these types of events (relative, absolute axes, mouse buttons, etc., as declared in the event masks), that still doesn't mean that it actually does send out these events, and above input-events output shows that it doesn't send out BTN_* events which would represent mouse clicks.