keyboard looses light [SOLVED]

freifunk_connewitz · Apprentice Joined: 08 Feb 2006 Posts: 231

hi,
for a year now, I'm using a Logitech Illuminated Keyboard via USB. It has a decent backlight you can adjust with a special key.
everything (except some of the function keys) worked fine until recently. I really can't reconstruct what triggered the new behaviour (xorg-server or any other update, the plugging of a faulty USB HDD...), but for a while now the keyboard performs some kind of unsolicited power save: 3 sec after the last keystroke it switches off the backlight. this can be really annoying when working in a dark room.

I did sort of an elimination of error procedure:
- it's not the keyboard hardware that broke: tried the keyboard with another linux computer (running ubuntu), worked fine there
- it's not the USB port hardware of my PC: when I fire up VMWare Player and click in that window, the light stays ON

so I assume it must be the keyboard driver or something connected, right?

does anybody have an idea what could cause this nasty little problem? xorg-server or -driver? hal? udev? some kernel driver?

I'm running KDE on xorg-1.8.2, here's my config:

BradN · Posted: Mon Sep 13, 2010 12:25 am Post subject:

Does the problem still occur when not running X?

adramalech707 · Posted: Mon Sep 13, 2010 3:15 am Post subject:

i forget because i am running a `amd64 build but aren't u suppose to move to udev?? i think it might alleviate ur issue...because soon hal is going bye bye and everyone will need to migrate to udev....which suxs because half of my packages still have hal as a depends to run....meaning they haven't recoded for udev.... like my thunar volume manager doesn't work well without hal....but i believe u cannot run hal and udev on the same system or u might have issues where hal and udev are both running and trying to do the same thing...

http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.8-upgrade-guide.xml

it specifically states...

BradN · Posted: Mon Sep 13, 2010 4:36 am Post subject:

HAL and udev can both be on the same system, but probably you want the programs using one or the other (preferably udev if hal is going the way of the dinosaurs)

freifunk_connewitz · Apprentice Joined: 08 Feb 2006 Posts: 231

thanks for your replies!

BradN,
when I encounter the problem, it persists too if I switch to the console via ctr-alt-F[1-5].
EDIT: also if I stop X from console and stay in console: same effect.

adra,
as Brad said, hal and udev can reside on the same system. until yesterday my xorg-server even was running with hal and udev USE-flag at the same time (then I remerged it with -hal).

BTW, during the first minutes of my X session the light is working normal.

BradN · Posted: Tue Sep 14, 2010 1:55 am Post subject:

Ok, then it seems this is somehow related to the kernel, but it would be good to remove xdm from startup, shut down, disconnect and reconnect keyboard, then boot up only to the text prompt and see if the keyboard still does it (this way we know X had no chance to configure something on it, or even to change a configuration in the input layer of the kernel).

If the problem still persists, you have the option of tracking down what kernel version initially exhibits the problem (there is a procedure called a bisection test where you must download and compile and test 10 or so kernels to narrow down exactly what change introduced the problem). It's a pain to wait for it all to compile but it enables you to make a much better bug report to the developers, and you will have a better chance of the problem being fixed.

A workaround might be turning off the full usb HID input driver and using the boot protocol usb input driver (this may not be an option if you use joysticks or other unusual usb input devices) - this interfaces with keyboards/mice in a simpler transmission mode that might not exhibit the same issue.

Or the "money is no obstacle" solution, just buy a different keyboard and use this one on another system

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

As a related test, since you see the problem with a USB keyboard, try using a PS/2 keyboard instead. This should tell us whether the problem is related to USB or to something playing with keyboard settings.

Etal · Veteran Joined: 15 Jul 2005 Posts: 1931

Hmm... If you have it, try increasing the value of /sys/module/usbcore/parameters/autosuspend and see if it does anything.

BradN · Posted: Tue Sep 14, 2010 3:11 am Post subject:

freifunk_connewitz · Apprentice Joined: 08 Feb 2006 Posts: 231

thanks a lot for your help and apologies for me not answering for so long (have been away from my computer for a week).

the situation is in a way both trickier and easier now: the keyboard works again as expected without me having changed anything. all that has changed since last week is that x-server and -drivers have been updated to 1.9.0.

if the problem occurs again, I will have a closer look on the possible trigger and try your advices.

thanks again!

freifunk_connewitz · Apprentice Joined: 08 Feb 2006 Posts: 231

and here we go:
happened again, and now at least the trigger is somehow tracked down. the keyboard showed the weird backlighting behaviour again after I plugged in an USB HDD. and now I remember: like it was the last time. logging out/in or switching to console didn't help. then, I did like Brad suggested and removed xdm from default runlevel, shutdown, switched off, un-/replugged keyboard, switched on and restarted into the console: still, keyboard switched off its backlight 2 seconds after the last keystroke, already during the boot process. didn't change when I started xdm again.
BUT, and here it seems like X (or KDE) has a rather positive influence on the whole thing: at a certain point of the KDE starting process (after logging in in kdm and quite at the end, when the splash screen disappears and the desktop shows up) the backlight smoothly came back without having touched any key! but unfortunately, after some time, between 10 seconds and several minutes, in most cases it falls back to the weird behaviour and switches the light off.

it obviously is a kernel related issue - I am running 2.6.34-gentoo-r6 now that I'm having the problems. as a test I just booted into the last kernel that is still installed on my system (2.6.34-gentoo-r1). and: with that version the backlight stayed on all the time, also during boot or anytime within the console. so there must have been some changes in the USB system between 2.6.34-r1 and -r6.

about bisection tests: the problem is that no kernel versions between -r1 and -r6 are in the portage tree, according to eix. and BradN, do you think kernel maintainers will bother to dig into this even if it is about a piece of hardware the manufacturer officially offers only Windoze support for? (BTW: shame on Logitech to build such an almost perfect keyboard and ignoring compatibility issues.)

best,

aCOSwt · Posted: Wed Sep 22, 2010 8:14 am Post subject:

This is definitely a 2.6.34-r6 bug. Many USB HID devices get into trouble with this version in various ways.
https://forums.gentoo.org/viewtopic-t-844438-start-0-postdays-0-postorder-asc-highlight-.html
(follow the link in the last post for the explanation)

You should go with at least 2.6.34-r7 and considering miscellaneous security patches commited since, 2.6.34-r10 is a better choice.

BradN · Posted: Wed Sep 22, 2010 7:24 pm Post subject:

Unfortunately you need access to a git tree to do the bisection test, which probably means you have to duplicate the problem in the vanilla kernels (there's a git server for vanilla kernel.org).

It actually traces the problem not just to a certain release, but to the actual commit (single change or set of changes) that causes it.

Kernel maintainers care about anything that makes hardware misbehave, especially if it was already working in a past version, even if the manufacturer doesn't support it.

freifunk_connewitz · Apprentice Joined: 08 Feb 2006 Posts: 231

aCOSwt,
you are right - installed kernel 2.6.34-r10 and the problem disappeared. thanks to all for your hints. setting it to finally solved now.