linux-kernel - Re: USB keyboard backlight powering down.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Oct 2012 10:35:24 -0700
From:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Michael Spang <spang@...gle.com>, linux-usb@...r.kernel.org,
	Dave Jones <davej@...hat.com>,
	Michael Spang <spang@...omium.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>, greno@...izon.net,
	Fedora Kernel Team <kernel-team@...oraproject.org>
Subject: Re: USB keyboard backlight powering down.

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@...hat.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@...omium.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@...r), 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/