hid device not claimed but /dev/input/event exists
Tomas Carnecky
usb 1-2.2: new full speed USB device using ehci_hcd and address 6
usb 1-2.2: configuration #1 chosen from 1 choice
HID device claimed by neither input, hiddev nor hidraw
input: Logitech Z-10 USB Speaker as
/devices/pci0000:00/0000:00:02.1/usb1/1-2/1-2.2/1-2.2:1.3/input/input4
input: USB HID v1.10 Device [Logitech Z-10 USB Speaker] on
usb-0000:00:02.1-2.2
Nobody claims the device and yet an evdev device shows up in /dev/input?
That device reports ~8 EV_KEY event codes, which is about right, but
pressing these buttons doesn't generate any events.
The audio part of the device works ok with the alsa-usb-audio driver.
Though sometimes it locks up, when I try to change the volume of the
speaker through the gnome-volume dialog. When that happens, lsusb
becomes _very_ slow and eventually times out (cannot read device status,
Connection timed out (110)), I also see some of these messages in dmesg:
usb 1-2.2: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 255
ret -110 (with different 'len' values). To reset the device I have to
plug it out and in again.
I enabled HID_DEBUG, but no debug messages show up in my dmesg output,
which is strange. Attached is lsusb of the device.
tom
Jiri Kosina
> usb 1-2.2: new full speed USB device using ehci_hcd and address 6
> usb 1-2.2: configuration #1 chosen from 1 choice
> HID device claimed by neither input, hiddev nor hidraw
> input: Logitech Z-10 USB Speaker as
> /devices/pci0000:00/0000:00:02.1/usb1/1-2/1-2.2/1-2.2:1.3/input/input4
> input: USB HID v1.10 Device [Logitech Z-10 USB Speaker] on
> usb-0000:00:02.1-2.2
> Nobody claims the device and yet an evdev device shows up in /dev/input? That
Yes, that looks indeed bogus.
> I enabled HID_DEBUG, but no debug messages show up in my dmesg output,
> which is strange.
You have to modprobe the 'hid' module with 'debug=1' parameter. Please
send me the resulting output.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tomas Carnecky
> On Tue, 19 Feb 2008, Tomas Carnecky wrote:
>
>> usb 1-2.2: new full speed USB device using ehci_hcd and address 6
>> usb 1-2.2: configuration #1 chosen from 1 choice
>> HID device claimed by neither input, hiddev nor hidraw
>> input: Logitech Z-10 USB Speaker as
>> /devices/pci0000:00/0000:00:02.1/usb1/1-2/1-2.2/1-2.2:1.3/input/input4
>> input: USB HID v1.10 Device [Logitech Z-10 USB Speaker] on
>> usb-0000:00:02.1-2.2
>> Nobody claims the device and yet an evdev device shows up in /dev/input? That
>
> Yes, that looks indeed bogus.
>
>> I enabled HID_DEBUG, but no debug messages show up in my dmesg output,
>> which is strange.
>
> You have to modprobe the 'hid' module with 'debug=1' parameter. Please
> send me the resulting output.
>
Attached is the dump from dmesg.
The device apparently has four 'interfaces' - whatever that is, see [1].
It seems like usbhid probes interface 2 (which is the LCD plus a few
buttons, probably the four just under the LCD, as described [1]).
Because usbhid doesn't know how to handle the buttons, it fails. But
then it probes interface 3 which is a 'proper' HID device with
well-defined buttons.
But still nothing shows up if I press the buttons. But something is
strange, neither does when I press buttons on my sidewinder pad. Unless
I 'cat /dev/input/event5' and then press the buttons, then they shows up
in dmesg. But that trick doesn't work with the Z-10 speakers. Maybe the
alsa driver is interfering somehow?
[1]
http://forums.logitech.com/logitech/board/message?board.id=stereo_20&message.id=633#M633
Jiri Kosina
> The device apparently has four 'interfaces' - whatever that is, see [1].
> It seems like usbhid probes interface 2 (which is the LCD plus a few
> buttons, probably the four just under the LCD, as described [1]).
> Because usbhid doesn't know how to handle the buttons, it fails. But
> then it probes interface 3 which is a 'proper' HID device with
> well-defined buttons.
Yes, the dump clearly shows that.
Does anything appear in dmesg when you press those buttons? There should
be messages resembling the one you already have there:
drivers/hid/hid-core.c: report (size 8) (unnumbered)
drivers/hid/hid-core.c: report 0 (size 8) = 00 00 28 00 00 00 00 00
and they should react to keys such as FastForward, Play, Mute, Volume Up,
etc.
Tomas Carnecky
> On Tue, 19 Feb 2008, Tomas Carnecky wrote:
>
>> The device apparently has four 'interfaces' - whatever that is, see [1].
>> It seems like usbhid probes interface 2 (which is the LCD plus a few
>> buttons, probably the four just under the LCD, as described [1]).
>> Because usbhid doesn't know how to handle the buttons, it fails. But
>> then it probes interface 3 which is a 'proper' HID device with
>> well-defined buttons.
>
> Yes, the dump clearly shows that.
>
> Does anything appear in dmesg when you press those buttons? There should
> be messages resembling the one you already have there:
>
> drivers/hid/hid-core.c: report (size 8) (unnumbered)
> drivers/hid/hid-core.c: report 0 (size 8) = 00 00 28 00 00 00 00 00
>
> and they should react to keys such as FastForward, Play, Mute, Volume Up,
> etc.
Nothing. Not even after I removed the alsa-usb-audio driver. All I see
is Keyboard.*, but the events from the speaker should be Key.*, right?
It looks like the speaker goes into a different mode once the USB cable
is plugged in. Without the USB cable, the Z-10 acts as simple/dumb
speaker, the volume up/down buttons change the internal volume, and I
see that on the display, too. The play/next/prev song buttons don't do
anything, which is quite obvious.
But once the USB cable is plugged in, the volume up/down buttons stop
reacting. I assume they are now meant to send events to the computer so
that some software can decide what to do. But features that are not
useful for the computer (bass/treble), can still be controlled using the
buttons on the speaker. The buttons are not dead. I can see that because
the display goes to sleep after a few seconds of inactivity, and when I
press the volume buttons, it wakes up and displays the current volume.
So the speaker is definitely seeing that the buttons are being pressed.
Is there a USB packet inspector/dumper, like libpcap for network?
tom
Tomas Carnecky
> Does anything appear in dmesg when you press those buttons? There should
> be messages resembling the one you already have there:
>
> drivers/hid/hid-core.c: report (size 8) (unnumbered)
> drivers/hid/hid-core.c: report 0 (size 8) = 00 00 28 00 00 00 00 00
>
> and they should react to keys such as FastForward, Play, Mute, Volume Up,
> etc.
This bug is in a completely different place then I thought! The speakers
were plugged into the hub built into my monitor. I plugged it directly
into the mainboard and voila, it works. Even g15daemon, the lcd driver,
can now display a nice clock on the lcd.
Could it be that the hub is defective?
tom
Jiri Kosina
> This bug is in a completely different place then I thought! The speakers
> were plugged into the hub built into my monitor. I plugged it directly
> into the mainboard and voila, it works. Even g15daemon, the lcd driver,
> can now display a nice clock on the lcd. Could it be that the hub is
> defective?
Definitely could be.
Please collect usbmon logs (this is what you asked for previously -- the
USB traffic analyzer -- see Documentation/usb/usbmon.txt) and send them to
the usb-devel mailinglist. This is no longer related to HID code at all.
Thanks for tracking this down,
--
Jiri Kosina
SUSE Labs