From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
The usbhid driver is incorrectly claiming the USB Wireless Security
Lock as a mouse.

This device is a wireless dongle and a receiver. Once the dongle is
far from the computer then the PC will lock (via screensaver or other
way). You can take a look at the device here:
http://www.thinkgeek.com/gadgets/security/698d/

Once the USB Security Lock is inserted, the kernel detects the device
as a mouse, thus it creates /dev/input/mouse* entries.

Here is what i get in the /var/log/messages:

system kernel: usb 3-2.3: new low speed USB device using uhci_hcd and
address 5
system hal.hotplug[5846]: DEVPATH is not set
system kernel: input: USB HID v1.10 Joystick [Cypress Semi. Cypress
Ultra Mouse] on usb-0000:00:10.1-2.3

The problem is with the device itself. Since the internal 'engine' of
the device is really a wireless mouse. The manufacturer did not change
the USB identification marks, thus it still identifies it self as a mouse.

Here is what "lsusb -vv" says:

Bus 003 Device 005: ID 04b4:7417 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          0x7417
  bcdDevice            0.01
  iManufacturer           1 Cypress Semi.
  iProduct                2 Cypress Ultra Mouse
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 HID-Compliant??^A
    bmAttributes         0xa0
      Remote Wakeup
    MaxPower               26mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Devices
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      72
cannot get report descriptor
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               none
          Usage Type               Data
        wMaxPacketSize     0x0004  bytes 4 once
        bInterval              10
  Language IDs: (length=4)
     0409 English(US)


As you can see, the device says its an InterfaceClass "3",
InterfaceSubClass "1" and InterfaceProtocol "2" (mouse).

The device ID should be added in the hid core blacklist instead, thus
a proper device driver will be able to take over the device. There are
two device drivers already written, though they conflict with the hid
core that takes over and loads the device as a mouse.

The device ID is:

 idVendor           0x04b4 Cypress Semiconductor Corp.
 idProduct          0x7417

Also, the product id (7417) should be added in the hwdata id string
database for usb devices with the name "USB Wireless Security Lock",
though i guess that is another bug entry :)



Version-Release number of selected component (if applicable):
kernel-2.6.10-1.741_FC3

How reproducible:
Always

Steps to Reproduce:
1. boot
2. insert USB security device in USB port
3. enable dongle and watch mouse jump around :(
    

Actual Results:  The HID core takes over and attaches the device as a
mouse.

Expected Results:  The hid core should leave the device alone for a
real driver to be able to take over.

Additional info:

none.