Red Hat Bugzilla – Bug 147479
The usbhid driver is incorrectly claiming the USB Wireless Security Lock as a mouse.
Last modified: 2015-01-04 17:16:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
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:
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
system hal.hotplug: 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.
bDeviceClass 0 (Defined at Interface level)
idVendor 0x04b4 Cypress Semiconductor Corp.
iManufacturer 1 Cypress Semi.
iProduct 2 Cypress Ultra Mouse
iConfiguration 4 HID-Compliant??^A
bInterfaceClass 3 Human Interface Devices
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
HID Device Descriptor:
bCountryCode 0 Not supported
bDescriptorType 34 Report
cannot get report descriptor
bEndpointAddress 0x81 EP 1 IN
Transfer Type Interrupt
Synch Type none
Usage Type Data
wMaxPacketSize 0x0004 bytes 4 once
Language IDs: (length=4)
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.
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):
Steps to Reproduce:
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
Expected Results: The hid core should leave the device alone for a
real driver to be able to take over.
i don't see much interest here. is there anywhere else i can report
this bug and get it fixed?
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
I've changed the version field to 'fc4'.
Created attachment 117110 [details]
Patch for USB Wireless Security Lock device
This patch fixes the USB Wireless Security Lock device bug, which incorrectly
detects the device as a mouse.
fixed in cvs.
Thank you, much appriciated. We'll be waiting for the next kernel release for FC4.
Just installed the latest kernel (2.6.12-1.1447_FC4).
Unfortunately, the device isn't assigned a /dev/ entry, instead i get this error:
Aug 30 15:43:46 thinkpad kernel: usb 2-2: new low speed USB device using
uhci_hcd and address 2
Aug 30 15:43:46 thinkpad kernel: usbhid: probe of 2-2:1.0 failed with error -5
Any suggestions please?
There is a possibility that the above error is normal. Once i execute a client
application (http://www.schau.com/l/wsl/) which gets hold of the device, i
Sep 2 19:08:10 thinkpad kernel: usb 2-2: usbfs: interface 0 claimed while
'wslxsctl' sets config #1
Probably because usbfs is still holding the device for some reason.
I'll investigate further.
Created attachment 118394 [details]
Patch for 2.6.13-rc4 kernel and above
Same patch but for newer version of kernel.
Apparently the error is normal. Maybe a little bit misleading, but normal.
We can leave this bug as CLOSED. Sorry for the disturbance.