All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerry Reno <greno@verizon.net>
To: Josh Boyer <jwboyer@redhat.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Michael Spang <spang@google.com>,
	linux-usb@vger.kernel.org, Dave Jones <davej@redhat.com>,
	Michael Spang <spang@chromium.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Fedora Kernel Team <kernel-team@fedoraproject.org>
Subject: Re: USB keyboard backlight powering down.
Date: Wed, 17 Oct 2012 09:09:56 -0400	[thread overview]
Message-ID: <507EAE24.60407@verizon.net> (raw)
In-Reply-To: <20121017125538.GA2934@hansolo.jdub.homelinux.org>

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



  reply	other threads:[~2012-10-17 14:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-16 15:20 USB keyboard backlight powering down Dave Jones
2012-10-16 16:45 ` Michael Spang
2012-10-16 16:54   ` Greg Kroah-Hartman
2012-10-16 17:35     ` Sarah Sharp
2012-10-17 12:55       ` Josh Boyer
2012-10-17 13:09         ` Gerry Reno [this message]
2012-10-17 13:31           ` Josh Boyer
2012-10-17 13:49             ` Gerry Reno
2012-10-16 17:29 ` Sarah Sharp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=507EAE24.60407@verizon.net \
    --to=greno@verizon.net \
    --cc=davej@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jwboyer@redhat.com \
    --cc=kernel-team@fedoraproject.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sarah.a.sharp@linux.intel.com \
    --cc=spang@chromium.org \
    --cc=spang@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.