Bug 907221

Hi,

This is not a libhid bug, but a kernel bug. Still I may be able to help :)

Can you please do:
lsusb -v > lsusb.log

And then attach the generated lsusb.log file, and you please also attach your full dmesg output?

Thanks,

Hans

Created attachment 692874 [details]
lsusb.log

Hi,

(In reply to comment #2)
> Created attachment 692874 [details]
> lsusb.log

Hmm, funky device, ie:

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None

Where as a normal keyboard has:

    Interface Descriptor:  
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0   
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard

I was actually expecting something like your device has, but then on a *second* interface, some fancy keyboards present themselves as 2 hid devices 1 standard keyboard, and 1 device only usable through rawhid which gives access to the lcd, etc. And my plan was to then blacklist standard hid probing for the second interface ...

That won't work here though. I believe your best bet for getting this fixes is sending a mail to the linux-input list:
http://vger.kernel.org/vger-lists.html#linux-input

Regards,

Hans

To be clear, as said I expected a rawhid only second interface, but your keyboard has only one interface, so everything needs to be done through that single interface, which means blacklisting it from (non raw) hid probing would be a bad idea.

As this is a laptop keyboard, I believe it has the standard keyboard interface in addition to this second usb interface to control the LEDs.  I am not sure how we can identify this, but I assume that if we disable probing the usb interface, the keyboard should still function.  Is there anyway I could test this on my own?

(In reply to comment #5)
> As this is a laptop keyboard, I believe it has the standard keyboard
> interface in addition to this second usb interface to control the LEDs.  I
> am not sure how we can identify this, but I assume that if we disable
> probing the usb interface, the keyboard should still function.  Is there
> anyway I could test this on my own?

Ah, so your keyboard is using ps/2 for the keypresses, and usb with hid for the backlight funky setup,but we can work with that :)

So to tell the  usbhid driver to skip the reports initialization completely,  add the following to the kernel cmdline: usbhid.quirks=0x1770:0xff00:0x20000000

To add something to the kernel cmdline, edit /etc/grub2.cfg, find the entry for your currently running kernel (usually the first), and add it to the end of the "linux   /boot/vmlinuz-...." line, ie change:

linux   /boot/vmlinuz-3.7.4-204.fc18.x86_64 root=UUID=85b48b3e-e8ba-451b-800a-63609fcb77cb ro rd.md=0 rd.dm=0 rd.lvm=0 FONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYMAP=us quiet rhgb

To:

linux   /boot/vmlinuz-3.7.4-204.fc18.x86_64 root=UUID=85b48b3e-e8ba-451b-800a-63609fcb77cb ro rd.md=0 rd.dm=0 rd.lvm=0 FONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYMAP=us quiet rhgb usbhid.quirks=0x1770:0xff00:0x20000000

Note bugzilla will likely wrap the above examples, but they are a single line!

Then the 10 second timeout should be gone, and you should still see something like this:
[   11.982126] hid-generic 0003:1770:FF00.0004: hiddev0,hidraw2: USB HID v1.10 Device [MSI EPF USB MSI EPF USB] on usb-0000:00:1d.0-1.7/input0

At a minimum we want the hidraw driver to still get attached, so that later on a userspace utility for configuring the backlight of the keyboard can be written.

That worked perfectly! The system now boots without the 10 second delay.  Thank you!

For another data point on this problem, please take a look at RHBZ 806587.

In my case, it seems to be a multi-format card reader rather than a keyboard.  Nevertheless, the above trick seems to work.

Created attachment 710694 [details]
Patch to add quirk

Something like this look OK Hans?

(In reply to comment #9)
> Created attachment 710694 [details]
> Patch to add quirk
> 
> Something like this look OK Hans?

2 remarks:
1) About the commit message it is not the keyboard device it is the keyboard backlight led controller
2) I don't think using direct ids rather then defines will fly upstream, a quick google found me that someone already submitted a patch for this upstream, was asked to add his Signed-off-by, and never followed up :| But his patch does add defines, with what I believe are the proper names for the vendor / device. which I think we should do too:
http://www.spinics.net/lists/linux-usb/msg54756.html
(patch at the end of the very long mail).

With this fixed, it is probably best to submit both patches directly to Jiri Kosina  jkosina-suse-cz, with linux-input.org in the CC.

Thanks for working on this!

OK, I'll rework.  Thanks for finding that thread.

Steve, if you could please test this scratch build after removing usbhid.quirks=0x1770:0xff00:0x20000000 from the command line, it would be greatly appreciated:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5127181

(In reply to comment #12)
> Steve, if you could please test this scratch build after removing
> usbhid.quirks=0x1770:0xff00:0x20000000 from the command line, it would be
> greatly appreciated:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5127181

Steve, ping ?

I apologize for the delay in my response.  I do not know how to go about testing the build.  I thought there would be an .rpm to download or something along those lines.

Steve, I was able to find an RPM for the architecture I use (x86_64) under the "koji" link provided above.  I double-clicked on it, the firefox web browser activated "yumex", I provided the correct password, and everything worked fine after that.  I thought it would pull in some dependencies, but it apparently had all it needed within the RPM.  However, at the moment, it appears like the build has failed, so there's no usable RPM there right now.

Depending on how many test kernels you anticipate, you may want to bump the install-only limit in /etc/yum.conf.  I changed mine from 3 to 5, to postpone the day that this test kernel gets dropped from my available kernel choices.

(In reply to comment #15)
> However, at the moment, it
> appears like the build has failed, so there's no usable RPM there right now.

Oh, you're right!

Josh, can you do a new build for this?

(In reply to comment #16)
> (In reply to comment #15)
> > However, at the moment, it
> > appears like the build has failed, so there's no usable RPM there right now.
> 
> Oh, you're right!
> 
> Josh, can you do a new build for this?

Yeah, later today.  Typo in the patch.

http://koji.fedoraproject.org/koji/taskinfo?taskID=5170528

That one should build now

The issue is resolved with the test build.  After removing usbhid.quirks=0x1770:0xff00:0x20000000 from the command line, the system booted without the usbhid delay.  Thank you.

Thank you for testing.  Added to the Fedora kernel git branches.

kernel-3.8.5-201.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.8.5-201.fc18

Package kernel-3.8.5-201.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.8.5-201.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-4645/kernel-3.8.5-201.fc18
then log in and leave karma (feedback).

kernel-3.8.5-201.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.