USB suspend and Logitech Iilluminated Keyboard

USB suspend and Logitech Iilluminated Keyboard

[Roland Ramthun]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

Hello list,

I recently bought a Logitech Illuminated Keyboard, which has, as the name suggests, a background illumination.

After activating USB suspend (USB_SUSPEND) in the kernel, the keyboard is rendered unusable:
*) It starts to flash (suspend -> immediate wakeup, even without a key pressed -> suspend -> ...)
*) While starting up the illumination after every suspend, key presses are not recognized for fractions of a second

I wrote an udev rule to disable USB suspend for this specific model, which solves the described problems. You'll find it attached.

Is there another way to circumvent this problem?
If not, please consider to include this rule into the official udev release.

Kind regards,
Roland

[-- Attachment #2: 99-logitech-illuminated-keyboard.rules --]
[-- Type: application/octet-stream, Size: 242 bytes --]

#Disable USB power suspend on Logitech Illuminated Keyboard, which leads to flashing background illumination and short episodes of non responsiveness
SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="c318", ATTR{power/control}="on"

Re: USB suspend and Logitech Iilluminated Keyboard

[Kay Sievers]

On Sun, Oct 31, 2010 at 18:38, Roland Ramthun <mail@roland-ramthun.de> wrote:
> I recently bought a Logitech Illuminated Keyboard, which has, as the name suggests, a background illumination.
>
> After activating USB suspend (USB_SUSPEND) in the kernel, the keyboard is rendered unusable:
> *) It starts to flash (suspend -> immediate wakeup, even without a key pressed -> suspend -> ...)
> *) While starting up the illumination after every suspend, key presses are not recognized for fractions of a second
>
> I wrote an udev rule to disable USB suspend for this specific model, which solves the described problems. You'll find it attached.
>
> Is there another way to circumvent this problem?

I think usb-auto-suspend is usually off by default and needs to be
enabled per device. The idea is/was to have whitelist of devices and
enable devices which are known to be safe. But as far as I know, no
such list exists or is in common use.

> If not, please consider to include this rule into the official udev release.

Besides a few (pretty broken) exceptions the udev sources do not carry
quirks for individual devices, only generic subsystem specific things.
We can't add this at the moment, there is at the moment no
infrastructure to keep lists like this maintained.

Kay

Re: USB suspend and Logitech Iilluminated Keyboard

[Roland Ramthun]

On Mon, 1 Nov 2010 16:33:38 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:

> > I wrote an udev rule to disable USB suspend for this specific model, which solves the described problems. You'll find it attached.
> >
> > Is there another way to circumvent this problem?
> 
> I think usb-auto-suspend is usually off by default and needs to be
> enabled per device. The idea is/was to have whitelist of devices and
> enable devices which are known to be safe. But as far as I know, no
> such list exists or is in common use.

You mean the device driver needs to enable it?
The Logitech is a standard USB keyboard.

[3.052761] generic-usb 0003:046D:C318.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech Logitech Illuminated Keyboard] on usb-0000:00:1d.0-1.1/input0
[3.279286] generic-usb 0003:046D:C318.0002: input,hiddev96,hidraw1: USB HID v1.11 Device [Logitech Logitech Illuminated Keyboard] on usb-0000:00:1d.0-1.1/input1

I think this suggests it uses "normal" USB HID drivers.

Reading the USB power management documentation it turns out, such problems are known.

Documentation/usb/power-management.txt
==
Sometimes it turns out that even when a device does work okay with
autosuspend there are still problems.  For example, there are
experimental patches adding autosuspend support to the usbhid driver,
which manages keyboards and mice, among other things.  Tests with a
number of keyboards showed that typing on a suspended keyboard, while
causing the keyboard to do a remote wakeup all right, would
nonetheless frequently result in lost keystrokes.
==

I'm sure I have no "experimental patches" applied, I use a vanilla 2.6.34 kernel.

> > If not, please consider to include this rule into the official udev release.
> 
> Besides a few (pretty broken) exceptions the udev sources do not carry
> quirks for individual devices, only generic subsystem specific things.

I see how that's reasonable, as this list would need constant care and could become large.
E.g. in the meantime I discovered the same problems exist with a Logitech G15, too.

> We can't add this at the moment, there is at the moment no
> infrastructure to keep lists like this maintained.

Obviously we shouldn't add these exceptions to udev.
But what is the right place?
Judging from the above documentation snippet, there might be something wrong with the fact USB suspend is active on a keyboard at all.

Kind regards,
Roland

Re: USB suspend and Logitech Iilluminated Keyboard

[Kay Sievers]

On Mon, Nov 1, 2010 at 17:38, Roland Ramthun <mail@roland-ramthun.de> wrote:
> On Mon, 1 Nov 2010 16:33:38 +0100
> Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> > I wrote an udev rule to disable USB suspend for this specific model, which solves the described problems. You'll find it attached.
>> >
>> > Is there another way to circumvent this problem?
>>
>> I think usb-auto-suspend is usually off by default and needs to be
>> enabled per device. The idea is/was to have whitelist of devices and
>> enable devices which are known to be safe. But as far as I know, no
>> such list exists or is in common use.
>
> You mean the device driver needs to enable it?
> The Logitech is a standard USB keyboard.
>
> [3.052761] generic-usb 0003:046D:C318.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech Logitech Illuminated Keyboard] on usb-0000:00:1d.0-1.1/input0
> [3.279286] generic-usb 0003:046D:C318.0002: input,hiddev96,hidraw1: USB HID v1.11 Device [Logitech Logitech Illuminated Keyboard] on usb-0000:00:1d.0-1.1/input1
>
> I think this suggests it uses "normal" USB HID drivers.
>
> Reading the USB power management documentation it turns out, such problems are known.
>
> Documentation/usb/power-management.txt
> ==
> Sometimes it turns out that even when a device does work okay with
> autosuspend there are still problems.  For example, there are
> experimental patches adding autosuspend support to the usbhid driver,
> which manages keyboards and mice, among other things.  Tests with a
> number of keyboards showed that typing on a suspended keyboard, while
> causing the keyboard to do a remote wakeup all right, would
> nonetheless frequently result in lost keystrokes.
> ==
>
> I'm sure I have no "experimental patches" applied, I use a vanilla 2.6.34 kernel.
>
>> > If not, please consider to include this rule into the official udev release.
>>
>> Besides a few (pretty broken) exceptions the udev sources do not carry
>> quirks for individual devices, only generic subsystem specific things.
>
> I see how that's reasonable, as this list would need constant care and could become large.
> E.g. in the meantime I discovered the same problems exist with a Logitech G15, too.
>
>> We can't add this at the moment, there is at the moment no
>> infrastructure to keep lists like this maintained.
>
> Obviously we shouldn't add these exceptions to udev.
> But what is the right place?

There is none at the moment. It would probably need to be some generic
device database, that this info can be extracted from and put into
some new tool.

> Judging from the above documentation snippet, there might be something wrong with the fact USB suspend is active on a keyboard at all.

As far as I understand it, usb autosuspend should only be enabled
per-device from userspace and by default be off for most device types.

Kay