USB keyboard backlight powering down.

USB keyboard backlight powering down.

[Dave Jones]

Gerry (CC'd) reported a bug to us that since 3.6.1, his illuminated
Logitech USB keyboard doesn't light up until he hits a key, and then
it immediately powers back off, defeating the purpose of having an
illumated keyboard.

Looking over the 3.6.1 changelog, I see this change, which sounds
like it might be responsible ?

commit ee537508bdc0c00b96ac497f3d82a68f820e6182
Author: Michael Spang <spang@chromium.org>
Date:   Fri Sep 14 13:05:49 2012 -0400

    Increase XHCI suspend timeout to 16ms
    
    commit a6e097dfdfd189b6929af6efa1d289af61858386 upstream.
    
    The Intel XHCI specification says that after clearing the run/stop bit
    the controller may take up to 16ms to halt. We've seen a device take
    14ms, which with the current timeout of 10ms causes the kernel to
    abort the suspend. Increasing the timeout to the recommended value
    fixes the problem.
    
    This patch should be backported to kernels as old as 2.6.37, that
    contain the commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI:
    PCI power management implementation".
    
    Signed-off-by: Michael Spang <spang@chromium.org>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


Any thoughts on how we could prevent this generically, or is this
something we're going to have to quirk around for specific devices we
don't want to power down ?

	Dave

Re: USB keyboard backlight powering down.

[Michael Spang]

On Tue, Oct 16, 2012 at 11:20 AM, Dave Jones <davej@redhat.com> wrote:
> Gerry (CC'd) reported a bug to us that since 3.6.1, his illuminated
> Logitech USB keyboard doesn't light up until he hits a key, and then
> it immediately powers back off, defeating the purpose of having an
> illumated keyboard.
>
> Looking over the 3.6.1 changelog, I see this change, which sounds
> like it might be responsible ?
>
> commit ee537508bdc0c00b96ac497f3d82a68f820e6182
> Author: Michael Spang <spang@chromium.org>
> Date:   Fri Sep 14 13:05:49 2012 -0400
>
>     Increase XHCI suspend timeout to 16ms

I don't think this is related to your problem, as this patch is in
suspend/resume code. It just allows the controller more time to halt.

Thanks,
Michael

Re: USB keyboard backlight powering down.

[Greg Kroah-Hartman]

On Tue, Oct 16, 2012 at 12:45:56PM -0400, Michael Spang wrote:
> On Tue, Oct 16, 2012 at 11:20 AM, Dave Jones <davej@redhat.com> wrote:
> > Gerry (CC'd) reported a bug to us that since 3.6.1, his illuminated
> > Logitech USB keyboard doesn't light up until he hits a key, and then
> > it immediately powers back off, defeating the purpose of having an
> > illumated keyboard.
> >
> > Looking over the 3.6.1 changelog, I see this change, which sounds
> > like it might be responsible ?
> >
> > commit ee537508bdc0c00b96ac497f3d82a68f820e6182
> > Author: Michael Spang <spang@chromium.org>
> > Date:   Fri Sep 14 13:05:49 2012 -0400
> >
> >     Increase XHCI suspend timeout to 16ms
> 
> I don't think this is related to your problem, as this patch is in
> suspend/resume code. It just allows the controller more time to halt.

Yeah, that looks odd.

But, (adding linux-usb@vger), I think we enabled some "put the device to
sleep if it is idle" logic for all devices, which is what is looking
like is happening here.  The keyboard is being told to go to sleep in
order to save power.

We are saving more power, but it looks like the user wants to disable
it, which makes sense for this device.

So, do we do this from within the kernel with a blacklist, or rely on
the user knowing how to poke the proper sysfs file to turn the keyboard
back on?

greg k-h

> 
> Thanks,
> Michael

Re: USB keyboard backlight powering down.

[Sarah Sharp]

On Tue, Oct 16, 2012 at 11:20:23AM -0400, Dave Jones wrote:
> Gerry (CC'd) reported a bug to us that since 3.6.1, his illuminated
> Logitech USB keyboard doesn't light up until he hits a key, and then
> it immediately powers back off, defeating the purpose of having an
> illumated keyboard.

Does he have the udev bug that turns on auto-suspend for USB keyboards?
ISTR there was a Fedora bug that was fixed.

I ask because it sounds like the keyboard is suspended between key
strokes, and that powers down the light.  The USB hid driver doesn't
auto-suspend devices that have user toggleable LEDs.  For instance, it
won't suspend a keyboard if the caps lock or num lock key is set.  But
I'm betting the device doesn't advertise the backlight like the caps
lock key is advertised.

> Looking over the 3.6.1 changelog, I see this change, which sounds
> like it might be responsible ?

Did he actually do a git bisect?  Because that commit only applies to
when the system is suspended, not when the USB device is suspended.

Sarah Sharp

> commit ee537508bdc0c00b96ac497f3d82a68f820e6182
> Author: Michael Spang <spang@chromium.org>
> Date:   Fri Sep 14 13:05:49 2012 -0400
> 
>     Increase XHCI suspend timeout to 16ms
>     
>     commit a6e097dfdfd189b6929af6efa1d289af61858386 upstream.
>     
>     The Intel XHCI specification says that after clearing the run/stop bit
>     the controller may take up to 16ms to halt. We've seen a device take
>     14ms, which with the current timeout of 10ms causes the kernel to
>     abort the suspend. Increasing the timeout to the recommended value
>     fixes the problem.
>     
>     This patch should be backported to kernels as old as 2.6.37, that
>     contain the commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI:
>     PCI power management implementation".
>     
>     Signed-off-by: Michael Spang <spang@chromium.org>
>     Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> 
> Any thoughts on how we could prevent this generically, or is this
> something we're going to have to quirk around for specific devices we
> don't want to power down ?
> 
> 	Dave
> 

Re: USB keyboard backlight powering down.

[Sarah Sharp]

On Tue, Oct 16, 2012 at 09:54:36AM -0700, Greg Kroah-Hartman wrote:
> On Tue, Oct 16, 2012 at 12:45:56PM -0400, Michael Spang wrote:
> > On Tue, Oct 16, 2012 at 11:20 AM, Dave Jones <davej@redhat.com> wrote:
> > > Gerry (CC'd) reported a bug to us that since 3.6.1, his illuminated
> > > Logitech USB keyboard doesn't light up until he hits a key, and then
> > > it immediately powers back off, defeating the purpose of having an
> > > illumated keyboard.
> > >
> > > Looking over the 3.6.1 changelog, I see this change, which sounds
> > > like it might be responsible ?
> > >
> > > commit ee537508bdc0c00b96ac497f3d82a68f820e6182
> > > Author: Michael Spang <spang@chromium.org>
> > > Date:   Fri Sep 14 13:05:49 2012 -0400
> > >
> > >     Increase XHCI suspend timeout to 16ms
> > 
> > I don't think this is related to your problem, as this patch is in
> > suspend/resume code. It just allows the controller more time to halt.
> 
> Yeah, that looks odd.
> 
> But, (adding linux-usb@vger), I think we enabled some "put the device to
> sleep if it is idle" logic for all devices, which is what is looking
> like is happening here.  The keyboard is being told to go to sleep in
> order to save power.
> 
> We are saving more power, but it looks like the user wants to disable
> it, which makes sense for this device.
> 
> So, do we do this from within the kernel with a blacklist, or rely on
> the user knowing how to poke the proper sysfs file to turn the keyboard
> back on?

This was the udev bug I was referring to, which I think is causing the
keyboard to have auto-suspend enabled:

https://bugzilla.redhat.com/show_bug.cgi?id=825284

udev shouldn't be enabling auto-suspend of USB hids by default, since
many of them don't send a wakeup to come out of suspend when they
should.  For example, most USB mice only send a wakeup even when they
are clicked, not when they are moved.  That causes the user to sit
there, frustrated, as they move their mouse and wonder why their screen
doesn't unblank.  Other keyboards also lose keystrokes, which means if
you pause to compose your thoughts, the first couple letters you type
gets dropped.

Sarah Sharp

Re: USB keyboard backlight powering down.

[Josh Boyer]

On Tue, Oct 16, 2012 at 10:35:24AM -0700, Sarah Sharp wrote:
> On Tue, Oct 16, 2012 at 09:54:36AM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Oct 16, 2012 at 12:45:56PM -0400, Michael Spang wrote:
> > > On Tue, Oct 16, 2012 at 11:20 AM, Dave Jones <davej@redhat.com> wrote:
> > > > Gerry (CC'd) reported a bug to us that since 3.6.1, his illuminated
> > > > Logitech USB keyboard doesn't light up until he hits a key, and then
> > > > it immediately powers back off, defeating the purpose of having an
> > > > illumated keyboard.
> > > >
> > > > Looking over the 3.6.1 changelog, I see this change, which sounds
> > > > like it might be responsible ?
> > > >
> > > > commit ee537508bdc0c00b96ac497f3d82a68f820e6182
> > > > Author: Michael Spang <spang@chromium.org>
> > > > Date:   Fri Sep 14 13:05:49 2012 -0400
> > > >
> > > >     Increase XHCI suspend timeout to 16ms
> > > 
> > > I don't think this is related to your problem, as this patch is in
> > > suspend/resume code. It just allows the controller more time to halt.
> > 
> > Yeah, that looks odd.
> > 
> > But, (adding linux-usb@vger), I think we enabled some "put the device to
> > sleep if it is idle" logic for all devices, which is what is looking
> > like is happening here.  The keyboard is being told to go to sleep in
> > order to save power.
> > 
> > We are saving more power, but it looks like the user wants to disable
> > it, which makes sense for this device.
> > 
> > So, do we do this from within the kernel with a blacklist, or rely on
> > the user knowing how to poke the proper sysfs file to turn the keyboard
> > back on?
> 
> This was the udev bug I was referring to, which I think is causing the
> keyboard to have auto-suspend enabled:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=825284
> 
> udev shouldn't be enabling auto-suspend of USB hids by default, since
> many of them don't send a wakeup to come out of suspend when they
> should.  For example, most USB mice only send a wakeup even when they
> are clicked, not when they are moved.  That causes the user to sit
> there, frustrated, as they move their mouse and wonder why their screen
> doesn't unblank.  Other keyboards also lose keystrokes, which means if
> you pause to compose your thoughts, the first couple letters you type
> gets dropped.

I know we fixed that bug for F17, F18, and rawhide.  I did it myself.
I don't think this is udev related, but we'll double check the version.

Gerry, are you using udev-182-3.fc17 or newer on your F17 install?

josh

Re: USB keyboard backlight powering down.

[Gerry Reno]

On 10/17/2012 08:55 AM, Josh Boyer wrote:
> On Tue, Oct 16, 2012 at 10:35:24AM -0700, Sarah Sharp wrote:
>> On Tue, Oct 16, 2012 at 09:54:36AM -0700, Greg Kroah-Hartman wrote:
>>> On Tue, Oct 16, 2012 at 12:45:56PM -0400, Michael Spang wrote:
>>>> On Tue, Oct 16, 2012 at 11:20 AM, Dave Jones <davej@redhat.com> wrote:
>>>>> Gerry (CC'd) reported a bug to us that since 3.6.1, his illuminated
>>>>> Logitech USB keyboard doesn't light up until he hits a key, and then
>>>>> it immediately powers back off, defeating the purpose of having an
>>>>> illumated keyboard.
>>>>>
>>>>> Looking over the 3.6.1 changelog, I see this change, which sounds
>>>>> like it might be responsible ?
>>>>>
>>>>> commit ee537508bdc0c00b96ac497f3d82a68f820e6182
>>>>> Author: Michael Spang <spang@chromium.org>
>>>>> Date:   Fri Sep 14 13:05:49 2012 -0400
>>>>>
>>>>>     Increase XHCI suspend timeout to 16ms
>>>> I don't think this is related to your problem, as this patch is in
>>>> suspend/resume code. It just allows the controller more time to halt.
>>> Yeah, that looks odd.
>>>
>>> But, (adding linux-usb@vger), I think we enabled some "put the device to
>>> sleep if it is idle" logic for all devices, which is what is looking
>>> like is happening here.  The keyboard is being told to go to sleep in
>>> order to save power.
>>>
>>> We are saving more power, but it looks like the user wants to disable
>>> it, which makes sense for this device.
>>>
>>> So, do we do this from within the kernel with a blacklist, or rely on
>>> the user knowing how to poke the proper sysfs file to turn the keyboard
>>> back on?
>> This was the udev bug I was referring to, which I think is causing the
>> keyboard to have auto-suspend enabled:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=825284
>>
>> udev shouldn't be enabling auto-suspend of USB hids by default, since
>> many of them don't send a wakeup to come out of suspend when they
>> should.  For example, most USB mice only send a wakeup even when they
>> are clicked, not when they are moved.  That causes the user to sit
>> there, frustrated, as they move their mouse and wonder why their screen
>> doesn't unblank.  Other keyboards also lose keystrokes, which means if
>> you pause to compose your thoughts, the first couple letters you type
>> gets dropped.
> I know we fixed that bug for F17, F18, and rawhide.  I did it myself.
> I don't think this is udev related, but we'll double check the version.
>
> Gerry, are you using udev-182-3.fc17 or newer on your F17 install?
>
> josh
>



Installed Packages
udev.x86_64                                                182-1.fc17                                               
@anaconda-0

There is an update available to 182-3 but I haven't installed it.  Didn't know what it might impact.

Gerry

Re: USB keyboard backlight powering down.

[Josh Boyer]

On Wed, Oct 17, 2012 at 09:09:56AM -0400, Gerry Reno wrote:
> >> This was the udev bug I was referring to, which I think is causing the
> >> keyboard to have auto-suspend enabled:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=825284
> >>
> >> udev shouldn't be enabling auto-suspend of USB hids by default, since
> >> many of them don't send a wakeup to come out of suspend when they
> >> should.  For example, most USB mice only send a wakeup even when they
> >> are clicked, not when they are moved.  That causes the user to sit
> >> there, frustrated, as they move their mouse and wonder why their screen
> >> doesn't unblank.  Other keyboards also lose keystrokes, which means if
> >> you pause to compose your thoughts, the first couple letters you type
> >> gets dropped.
> > I know we fixed that bug for F17, F18, and rawhide.  I did it myself.
> > I don't think this is udev related, but we'll double check the version.
> >
> > Gerry, are you using udev-182-3.fc17 or newer on your F17 install?
> >
> > josh
> >
> 
> 
> 
> Installed Packages
> udev.x86_64                                                182-1.fc17                                               
> @anaconda-0
> 
> There is an update available to 182-3 but I haven't installed it.  Didn't know what it might impact.

Well, it would certainly be good to update to it and see if this bug is
fixed for you.  You will probably need to rebuild your initramfs with
the updated udev.

josh

Re: USB keyboard backlight powering down.

[Gerry Reno]

On 10/17/2012 09:31 AM, Josh Boyer wrote:
> On Wed, Oct 17, 2012 at 09:09:56AM -0400, Gerry Reno wrote:
>>>> This was the udev bug I was referring to, which I think is causing the
>>>> keyboard to have auto-suspend enabled:
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=825284
>>>>
>>>> udev shouldn't be enabling auto-suspend of USB hids by default, since
>>>> many of them don't send a wakeup to come out of suspend when they
>>>> should.  For example, most USB mice only send a wakeup even when they
>>>> are clicked, not when they are moved.  That causes the user to sit
>>>> there, frustrated, as they move their mouse and wonder why their screen
>>>> doesn't unblank.  Other keyboards also lose keystrokes, which means if
>>>> you pause to compose your thoughts, the first couple letters you type
>>>> gets dropped.
>>> I know we fixed that bug for F17, F18, and rawhide.  I did it myself.
>>> I don't think this is udev related, but we'll double check the version.
>>>
>>> Gerry, are you using udev-182-3.fc17 or newer on your F17 install?
>>>
>>> josh
>>>
>>
>>
>> Installed Packages
>> udev.x86_64                                                182-1.fc17                                               
>> @anaconda-0
>>
>> There is an update available to 182-3 but I haven't installed it.  Didn't know what it might impact.
> Well, it would certainly be good to update to it and see if this bug is
> fixed for you.  You will probably need to rebuild your initramfs with
> the updated udev.
>
> josh
>


I updated udev to 182-3 then rebooted and my illuminated keyboard is now functioning properly.  Didn't need to rebuild
initramfs.  Everything appears to be working fine.

Gerry