USB keyboard backlight powering down.
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 <[email protected]> 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".
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
Quoted 5 lines · 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.
Quoted 8 lines
Looking over the 3.6.1 changelog, I see this change, which sounds like it might be responsible ?
commit
ee537508bdc0c00b96ac497f3d82a68f820e6182Author: Michael Spang <[email protected]> Date: Fri Sep 14 13:05:49 2012 -0400Increase 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
Quoted 9 lines · Michael Spang
Quoted 8 lines · 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 ?
Quoted 8 lines
Quoted 5 lines
commit
ee537508bdc0c00b96ac497f3d82a68f820e6182Author: Michael Spang <[email protected]> Date: Fri Sep 14 13:05:49 2012 -0400Increase 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
Quoted 3 lines
Thanks,
Michael
Quoted 4 lines · 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.
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.
Quoted 2 lines
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
Quoted 29 lines
commit
ee537508bdc0c00b96ac497f3d82a68f820e6182Author: Michael Spang <[email protected]> Date: Fri Sep 14 13:05:49 2012 -0400Increase XHCI suspend timeout to 16ms
commit
a6e097dfdfd189b6929af6efa1d289af61858386upstream.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 <[email protected]>Signed-off-by Sarah Sharp <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>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
Quoted 26 lines · Greg Kroah-Hartman
Quoted 9 lines · Michael Spang
Quoted 8 lines · 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 ?
Quoted 8 lines
Quoted 5 lines
commit
ee537508bdc0c00b96ac497f3d82a68f820e6182Author: Michael Spang <[email protected]> Date: Fri Sep 14 13:05:49 2012 -0400Increase 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.
Quoted 6 lines
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
Quoted 39 lines · Sarah Sharp
Quoted 26 lines · Greg Kroah-Hartman
Quoted 9 lines · Michael Spang
Quoted 8 lines · 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 ?
Quoted 8 lines
Quoted 5 lines
commit
ee537508bdc0c00b96ac497f3d82a68f820e6182Author: Michael Spang <[email protected]> Date: Fri Sep 14 13:05:49 2012 -0400Increase 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.
Quoted 6 lines
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:
Quoted 8 lines
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
Quoted 23 lines · Gerry Reno
Quoted 13 lines
Quoted 5 lines
This was the udev bug I was referring to, which I think is causing the keyboard to have auto-suspend enabled:
Quoted 8 lines
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.
Quoted 7 lines
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
Quoted 5 lines
Installed Packages
udev.x86_64 182-1.fc17
@anaconda-0There 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
Quoted 45 lines · Josh Boyer
Quoted 36 lines · Sarah Sharp
Quoted 24 lines · Greg Kroah-Hartman
Quoted 9 lines · Michael Spang
Quoted 8 lines · 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 ?
Quoted 7 lines
Quoted 5 lines
commit
ee537508bdc0c00b96ac497f3d82a68f820e6182Author: Michael Spang <[email protected]> Date: Fri Sep 14 13:05:49 2012 -0400Increase 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.
Quoted 6 lines
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:
Quoted 8 lines
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.
Quoted 7 lines
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
Quoted 27 lines · Josh Boyer
Quoted 26 lines · Gerry Reno
Quoted 13 lines
Quoted 5 lines
This was the udev bug I was referring to, which I think is causing the keyboard to have auto-suspend enabled:
Quoted 8 lines
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.
Quoted 7 lines
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
Quoted 7 lines
Quoted 1 line
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